SQL> EXEC DBMS_TTS.TRANSPORT_SET_CHECK('EXAMPLE', TRUE);
Procedimento PL/SQL concluÝdo com sucesso.
SQL> select * FROM transport_set_violations;
VIOLATIONS
------------------------------------------------------------------------------
Sys owned object CLIENTE in tablespace EXAMPLE not allowed in pluggable set
SQL>
essa tabela cliente foi criada para teste somente...
----- Original Message -----
From: Willian Frasson
To: oracle_br@yahoogrupos.com.br
Sent: Wednesday, May 28, 2008 1:29 PM
Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G
RAC Linux (ASM)
então mas como os DF estarão em STORAGE, possivelmente podemos fazer a cópia
de uma Storage para outra em pouco tempo.
Em realação ao documento, ótimo esse documento.. já está salvo o bixo hehehe
Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de apenas
500MB aqui na VM para teste... para ver se vai rodar direitinho.
----- 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" <[EMAIL PROTECTED]>
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]
