Bom, primeira coisa se vc vai aplicar um patchset no seu binário 10g, tenha
CERTEZA de que é o mais recente : pra 10gR2 o mais recente é 10.2.0.5, tenha
CERTEZA ABSOLUTA que não existe 10.2.0.5 pro seu sistema operacional, só se não
existir ** MESMO ** é que vc usa o 10.2.0.4.. E SEMPRE, SEMPRE, SEMPRE,
considere SERIAMENTE a chance de em cima do patchset vc aplicar depois o CPU ou
o PSU mais recente para o release
O procedimento em si é simples : instalar o 10.2.0.1 numa outra ORACLE_HOME,
aplicar nesses binários o patchset desejado, e depois se viável aplicar o
último PSU/CPU Isso ok, vc vai decidir SE vc quer criar um novo database
10gR2 do zero com esses binários atuais e depois transferir os dados da
instância 9i pra ele OU SE vc vai querer abrir os arquivos 9i que já existem
com esses binários 10gR2 aí, efetivamente Migrando o banco A vantagem de
vc criar um novo banco 10g do zero é que vc pode eliminar qquer 'lixo'
desnecessário que existia na 9i, pode implementar NOVAS FEATURES 10g que não
foram usadas porque não existiam quando o banco foi originalmente criado com
software 9i, e a Vantagem de vc abrir os arquivos 9i com o software 10gR2 é que
vc não precisa criar nada de novo, poupando espaço em disco para manobras, e
possivelmente demorando menos E no caso, se vc optar por migrar (ie, abrir
os arquivos 9i com os binários 10g) isso pode ser feito tanto MANUALMENTE
quanto por uma GUI própria, a DBUA...
O melhor tutorial/passo-a-passo pra isso é no próprio metalink/My Oracle
Support a nota "Oracle 10g Upgrade Companion" (Doc ID 466181.1)
[]s
Chiappa
OBS : imho a diferença Maior de se fazer um upgrade pra 10g é que o método de
fazer upgrade in-place (ie, instalando os binários mais recentes na mesma
ORACLE_HOME, 'por cima' dos antigos) só foi Oficializado e Suportado no 11g :
como vc tá fazendo upgrade pra 10g, isso ainda não é Suportado iirc
