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: oracle_br@yahoogrupos.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 oracle_br@yahoogrupos.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_tablespaces=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: oracle_br@yahoogrupos.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 oracle_br@yahoogrupos.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_TABLESPACES=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: oracle_br@yahoogrupos.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/[EMAIL PROTECTED] 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 oracle_br@yahoogrupos.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: oracle_br@yahoogrupos.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 oracle_br@yahoogrupos.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]
