Mano, se vai ficar louco com essa merda...relaxa, vai viajar um final de semana. Se quer uma ideia boa... usa essas placas giga, com um expdp com pipe no lado do servidor origem importanto antes de terminar garanto que daria menos de 2 horas se fosse bem configurado, principalmente se forem varios em paralelo. Não esqueçendo de desabilitar o archive dos dois lados e configurando as bases, uma pra leitura e outra pra escrita antes de começar. Att. Anderson Santiago DBA Sênior. www.ruevers.webs.com PS: tenho umas ideias loucas que poderia tentar usar, mas com certeza ia ficar doido amigo...
----- Mensagem original ---- De: Willian Frasson <[EMAIL PROTECTED]> Para: oracle_br@yahoogrupos.com.br Enviadas: Segunda-feira, 2 de Junho de 2008 9:07:32 Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC Linux (ASM) Chiappa bom dia... Neses dias andei pensando em algumas poissibilidades a mais para aquela migração com 2 horas de downtime, acho que poderia ser feito também e é uma idéia até boa..é mudar a versão da 9 para a 10, depois disso colocar umas 3 a 4 placas de rede(Gigabit) nessas máquinas, criar um database link para cada uma delas depois disso fazer o expdp via network link por owners.. o que acha.. ? abçs.. ----- Original Message ----- From: jlchiappa To: [EMAIL PROTECTED] os.com.br Sent: Thursday, May 29, 2008 10:01 PM Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC Linux (ASM) Seja via transport de tablespace seja via datapump ou o que for, o ponto só que acrescento para sua avaliação é aquele mesmo que já tinha sido citado : via de regra, vc obter no banco-destino só os dados e depois ter um script com os DDLs dos índices, constraints (e triggers no caso de export, o que não é aqui), scrpt esse alterado para fazer a criação em paralel, nologging, enable novalidate, etc : via e regra é MUITO mais performático rodar tal script no bd destino do que vc exportar os índices e/ou transportar as tablespaces dos índices, ok ? Então teste a chance de vc na máquina-origem já updateada, antes de exportar os metadados vc gera os scripts de DDls todos, DROPA AS constraints e índices e (aí sim) exporta os metadados e transporta as tablespaces só de dados ..... Com isso não seria mais necessário o passo do check de violações do transport, ** MAS ** por outro lado abre a chace de eventual erro humano, teste e avalie se o tempopoupado não tendo que transportar índices realmente compensa... []s Chiappa --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <[EMAIL PROTECTED] .> escreveu > > Acho que consegui chegar no resultado final chiappa, consegui fazer da forma que disse utilizando o transport e o convert do rman.. > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2) > > > > 2º Criar diretório padrão do DATA PUMP na máquina A: > > create or replace directory data_pump_dir as '/tmp'; > > > > 3º Cria Banco Todo na máquina A > > > > 4º Instalar Oracle 10 máquina A > > > > 5º Fazer upgrade Oracle 9 para Oracle 10 > > > > 6º Atualizar Patchset máquina A > > > > 7º Criar diretório padrão do DATA PUMP na máquina B: > > create or replace directory data_pump_dir as 'C:\RMAN'; > > > 8º Tirar Listener Máquina A do ar > > > > 9º Habilitar o transport tablespace nas tablespaces: > > exec dbms_tts.transport_ set_check( 'exemplo' , true); > > > > 10º Verificar erros de violação: > > select * from transport_set_ violations; > > > > 11º Colocar as tablespaces em Read Only: > > alter tablespace exemplo read only; > > > > 12º Export do transport tablespaces: > > expdp system/oracle dumpfile=exemplo. dmp transport_tablespac es=exemplo transport_full_ check=y > > > > 13º Convert dos datafiles com RMAN: convert tablespace exemplo to platform 'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; > > 14º Baixa o Banco > > > > 15º Copiar DATA FILES da máquina A para máquina B (via storage) > > > > 16º Import da Estrutura na máquina B: > > impdp system/oracle dumpfile=exemplo. dmp directory=data_ pump_dir transport_datafiles =/tmp/exemplo01. dbf, /tmp/exemplo02. dbf > > > > ----- Original Message ----- > From: jlchiappa > To: [EMAIL PROTECTED] os.com.br > Sent: Wednesday, May 28, 2008 12:52 PM > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC Linux (ASM) > > > É : como o volume desaconelha o export puro, a tua chance é, como eu > falei, vc ter uma rede privada muito rápida entre as duas máquinas e > OU transferir os dados diretamente via rede de a para B (isto é o > datapump), OU copiar via rede os arquivos (isto é o procedimento > "transportar as tablespaces" ), este último é o que vc montou, vou > comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o > datapump enviando dados sem gerar arquivo de dump e a para b, e veja > lá o que se sai melhor. Logicamente também, relembro que nos dois > procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump) > ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois > índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL, > NOVALIDATE, etc. > > Para o procedimento de transport que vc montou neste e-mail, comento > que : > > a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o > conjunto de arquivos em disco (ie, datafiles, initfile, redo log > files, tempfiles, etc), ese conjunto pode ser aberto por uma > "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí > sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único > database , que reside num storage "shared", que todas as máquinas do > cluster enxergam, e esse database é aberto simultaneamente por N > instâncias, normalmente cada uma dessas instâncias residindo numa > máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já > neste primeiro passo vc criar as N instâncias, só criar um único > database com uma única instância na máquina-destino, depois vc inclui > as outras N instãncias cfrme mostrado em > http://www.oracle. com/technology/ pub/articles/ chan_sing2rac_ install.html > , ok ? Acho que deve ser mais rápido, acho.... > > b. a baixa do banco deve ser feita APÓS o export dos metadados > apenas, vc NÃO CONSEGUE fazer export com banco baixado > > c. o export e depois o import dos metadados tanto pode ser feito com > exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou > - a mesma performance > > d. o passo CRÍTICO em termos de performance/ adequação à sua janela é > a cópia física dos datafiles : experimente ftp, experimente rsh, teste > utilitários de download tipo Orbit/wsFTP/ fileZilla! que permitem abrir > N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto > sob pena de degradar, mais uma vez é o teste que vai te demonstrar > isto), veja lá o que dá um tempo m elhor, E não esqueça que os > datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!! > > []s > > Chiappa > > --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <wfrasson@> > escreveu > > > > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM > minha aqui.. seria isso: > > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2) > > > > 2º Cria Banco Todo > > > > 3º Instalar Oracle 10 máquina A > > > > 4º Fazer upgrade Oracle 9 para Oracle 10 > > > > 5º Atualizar Patchset máquina A > > > > 6º Baixa o Banco > > > > 7º Colocar as tablespaces em Read Only: alter tablespace example > read only; > > > > 8º Export do transport tablespaces: expdp system/oracle > DUMPFILE=example. dmp TRANSPORT_TABLESPAC ES=example TRANSPORT_FULL_ CHECK=Y > > > > 9º Convert dos datafiles com RMAN: convert tablespace example TO > PLATFORM 'Linux IA (32-bit)' FORMAT 'C:\RMAN\%U' ; > > > > 10º Copiar DATA FILES da máquina A para máquina B > > > > 11º Import da Estrutura na máquina B: impdp system/oracle > dumpfile=/tmp/ example.dmp directory=data_ pump > transport_data_ files=/tmp/ example01. dbf, example02.dbf > > > > > > > > ----- Original Message ----- > > From: jlchiappa > > To: [EMAIL PROTECTED] os.com.br > > Sent: Wednesday, May 28, 2008 10:43 AM > > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single > Instance / 10G RAC Linux (ASM) > > > > > > O complicador aí em relação ao tamanho total, que pode inviabilizar o > > exp numa base de 1 Tb, é que : > > > > a) vc tem que arranjar o espaço no disco local pra gerar o dump, > > coisa de 100 Gb é difícil mas vc até arranja, já 1 Tb conheço POUCAS > > máquinas prod com 1 Tb sobrando... > > > > b) vc vai querer abrir várias sessões de export, MAS (óbvio) > > certamente os discos são os mesmos pra todos os schemas, a > > controladora é a mesma, há concorência, quantas mais sessões > > simultâneas vc abrir, mais degrada a performance : vamos supor que é > > um RAID, hardware de produção mesmo, que assim vc consiga ter 3 > > sessões simultâneas > > > > c) tipicamente a performance dum export local com as opções todas > > citadas, num hardware de produção, SEM concorrência, exportando só as > > linhas da tabela, etc etc, é coisa de 1 GB por minuto, ou pouco mais, > > um exemplo na minha máquina de testes (disco SATA, 2 Gb de RAM) : > > > > [EMAIL PROTECTED]:SQL> select count(*) from TAB_2G; > > > > COUNT(*) > > ------------ ------ > > 257340 > > > > [EMAIL PROTECTED]:SQL> select bytes from user_segments where > segment_name= 'TAB_2G'; > > > > BYTES > > ------------ ------ > > 2147483648 > > > > C:\>exp system/oracle@ o10gr2 file=teste_2g log=teste_2g. exp direct=y > > buffer=1048 > > 5760 recordlength= 65535 triggers=n constraints= n indexes=n > > statistics=none recor > > d=n tables=sys.TAB_ 2G feedback=100000 > > > > Export: Release 10.2.0.4.0 - Production on Qua Mai 28 10:20:48 2008 > > > > Copyright (c) 1982, 2007, Oracle. All rights reserved. > > > > Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 > > - Product > > ion > > With the Partitioning, Oracle Label Security, OLAP, Data Mining > > Scoring Engine > > and Real Application Testing options > > ExportaþÒo executada no conjunto de caracteres de WE8MSWIN1252 e no > > conjunto de > > caracteres de AL16UTF16 NCHAR > > Obs.: Ýndices em tabelas nÒo serÒo exportados > > Obs.: restriþ§es em tabelas nÒo serÒo exportadas > > > > Sobre exportar tabelas especificadas ... via Caminho Direto ... > > O usußrio atual foi alterado para SYS > > . . exportando tabela TAB_2G > > .. > > 257340 linhas > > exportadas > > ExportaþÒo encerrada com sucesso, sem advertÛncias. > > > > C:\>dir teste_2g.dmp > > Pasta de C:\ > > > > 28/05/2008 10:22 1.031.455.365 teste_2g.DMP > > > > ==> ou seja, coisa de 2 minutos pra exportar coisa de 2 Gb, yes ? > > LÓGICO, vc vai testar no seu hardware, mas acho que 1 Gb/minuto é um > > mínimo em aceitável, muito provável de se obter, legal ? > > Muito bem, fazendo uma conta de padeiro, se formos exportar 100 Gb no > > total e termos 3 sessões cada uma exportando 33 Gb, levaríamos coisa > > de pouco mais de meia hora (33 minutos) só pro export, tá tranquila a > > tua janela, creio... . Já 1 Tb, se cada uma das 3 sessões exportar uns > > 333 Gb, já batemos 333 minutos, ou seja mais de CINCO HORAS, a tua > > janela FOI PRO BREJO, yes ?????? Ainda que vc tivesse um hardware > > realmente bom que permitisse, digamos, 5 sessões simultâneas lendo a > > mesma fonte sem degradação grande, cada uma exportando 200 Gb do 1 Tb > > total, já foram 200 minutos, mais de duas horas, quase acabou a tua > > janela só aí... > > Então a regra de dedão é clara, exp vai bem até um certo volume.... > > > > []s > > > > Chiappa > > > > --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <wfrasson@> > > escreveu > > > > > > hm então inicialmente tinha colocado para o Pessoal 100GB mas na > > verdade a base do cliente é 1 TeraByte msmo... > > > Mas então é complicado mas que se por ex... fizer da forma que > > fizemos com export realmente... mas imaginamos.. . > > > são 5 OWNERS no sistema principal: > > > 200 GB cada um: > > > > > > Export OWNER 1 (da forma que montamos, sem indices) > > > como estará o mesmo na Storage, terminando esse OWNER já deixamos o > > mesmo importando na máquina B > > > enquanto isso...Export OWNER 2 (da forma que montamos, sem > > indices) > > > como estará o mesmo na Storage, terminando esse OWNER2 já deixamos o > > mesmo importando na máquina B > > > e assim sucessivamente. .. > > > > > > > > > ----- Original Message ----- > > > From: jlchiappa > > > To: [EMAIL PROTECTED] os.com.br > > > Sent: Wednesday, May 28, 2008 4:03 AM > > > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single > > Instance / 10G RAC Linux (ASM) > > > > > > > > > --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <wfrasson@> > > > escreveu > > > > > > > > Chiappa então mas a Janela é de 2 a 3 horas no máximo para > migrar 1 > > > Tera > > > > > > OPA OPA, pára tudo aí : na msg original vc tinha dito : > > > > > > > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em > > > Windows," > > > > > > ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo > > > com export ou datapump como falei, MAS 1 Terabyte é OUTRO > BICHINHO, é > > > um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de > > > volume desses a coisa muda TOTALMENTE de figura, começa a ficar > muito > > > MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num > > > volume assim pra começo de conversa o export necessariamente tem que > > > gerar o dump em disco, num volume desses o dump mesmo que só de > dados) > > > certamente ia ficar na casa das várias centenas de Gb, esqueça, > o puro > > > overhead de vc gerar algo assim já te quebra. Assim, as suas opções > > > seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem > > > migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem > > > ninguém mais nela, pode dar uma performance boa), OU transportar as > > > tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc > > > FAZER UM TESTE parcial das opções (preferencialmente em máquinas de > > > homologação, idênticas às produão) é que vc vai ver no seu ambiente > > > qual é a melhor, ok ? E é esse teste que vai te demonstrar se é > > > factível esse volume de 1 Tb nessa janela de duas ou três horas, > ok ? > > > É difícil, como eu disse, mas até pode acontecer... . > > > > > > []s > > > > > > Chiappa > > > > > > OBS : num volume desses certamente o banco original está num storage > > > também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do > > > storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário > > > nativo para exportar os arquivos Oracle do storage original para o > > > destino, sei que alguns fabricantes tem coisas do tipo. SE > tiver, aí a > > > opção seria fazer o transporte das tablespaces, mas gerando os > > > metadados com export transportable= y e na hora de passar os arquivos > > > pro destino ao invés de usar o comando de cópia ou de ftp do SO vc > > > usaria o tal utilitário, ele é nativo, muitas vezes ele é mais > > > eficiente do que o SO, que é genérico, é um layer a mais em cima do > > > hardware. > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas]
