Vc ** não o diz ** mas Acredito que o bitsize e o endianess é o mesmo entre os
dois servidores, certo ? Se sim, o formato binário dos arquivos (E dos backups
RMAN, também!!) em qquer distro Linux é o mesmo, vc pode de boa :
a. ter no novo servidor o software RDBMS 9i E o 11g instalados, copiar esse
database pro novo servidor (seja via transportable tablespace, seja via clone
database, seja via restaurando o último backup lá) e depois fazer lá o upgrade
normalmente...
OU
b. ter o software 11g instalado lá, criar um banco vazio e exportar/importar os
dados - OBVIAMENTE vc vai usar o export de maneira EFICIENTE, ie : export
APENAS DOS DADOS (os índices e constraints vc exporta só os DDLs, depois recria
lá no destino em Paralle/Nologging/Novalidate), exportando em direct-mode, em
Paralelo/com múltiplas sessões cada uma exportando parcialmente, o de sempre...
NUm hardware enterprise-class sem grandes gargalos E com o procedimento sendo
feito fora dos horários de pico de uso, 125 GBs não é assim *** tããão ***
enorme : eu estimaria umas 6 a 8 horas pra isso
[]s
Chiappa
OBS : naturalmente, imagino que vc ** já leu ** as Notas do metalink/my oracle
support de guia para Migração/Upgrade (em especial a Upgrade Companion) , que
DETALHAM direitinho os possíveis BUGs, diferenças de otimizador/Performance,
recursos descontinuados e/ou adicionados e métodos de comparar / validar a
migração do 9i pro 11g EM ESPECIAL, vc TEM QUE TER na mão prontamente
disponíveis Métricas de performance aprópriadas no seu ambiente 9i (tipo, tempo
gasto na execução de cada um dos principais Reports e Processamentos do
aplicativo) para os poder COMPARAR com o resultados no 11g... SEM ISSO, vc
corre Sério Risco de descobrir só semanas depois da migração que aquele
relatório de fechamento de mês super-crítico por qquer diferença no 11g está
rodando com performance pior, digamos...
