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" <[EMAIL PROTECTED]>
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]
>
