Olá a todos. Neste post irei mostrar um passo-a-passo de como realizar a migração e upgrade de uma base de dados do 11g para o 12c.
1 – Considerações Iniciais
– A base de origem está na versão 11.2.0.4
– A base de destino está na versão 12.1.0.2
– Ambos os servidores são Oracle Linux 7, mantendo o mesmo “Endian Format”
– A base migrada será do tipo non-CDB. Ela deverá ser plugada em um CDB posteriormente.
– Enquanto a base de destino (12c) vai sendo criada, a base de origem (11g) continua online atendendo as aplicações.
– Os diskgroups de origem e destino se mantiveram com os mesmos nomes (+DGDATA e +DGFRA). Caso sejam diferentes, deve-se usar a clausula “SET NEWNAME FOR DATAFILE n” no restore e renomear os REDO Log Files no destino (ALTER DATABASE RENAME FILE ‘nome_antigo’ TO ‘novo_nome’), antes de abrir a base com o RESETLOGS. Também deve-se mudar os parâmetros de destino dos archives, caso necessário.
2 – Passos
2.1) [ORIGEM] Realizar um backup FULL + archives da base 11g:
2.2) [ORIGEM] Criar um BACKUP COPY do Controlfile, para que seja possível montar a base no destino.
RMAN> BACKUP AS COPY CURRENT CONTROLFILE FORMAT ‘/backup/dbmigra/bkp_control_dbmigra.bkp’
2.3) [ORIGEM] Copiar os backups e o controlfile para o ambiente de destino, via scp, por exemplo.
OBS1: O diretório dos backups, no servidor de destino é: “/aux/restore/dbmigra”. Será necessário catalogar esses backups após subir a base no modo MOUNT
2.4) [ORIGEM] Gerar um PFILE da base de origem e copia-lo para o destino.
2.5) [DESTINO] Editar o PFILE criado no passo 2.4, de acordo com o novo ambiente. Mudar o parâmetro COMPATIBLE para “12.1.0.2.0”
2.6) [DESTINO] Iniciar a base em modo NOMOUNT usando o PFILE editado no passo 5. Antes, deve-se definir o ORACLE_SID no novo ambiente com o SID da baseque está sendo migrada. O ORACLE_HOME deve ser o do Oracle 12c:
OBS1: Definir no parâmetro CONTROL_FILES do pfile, o controlfile gerado no passo 2 e copiado no passo 3 para o servidor de destino.
2.7) [DESTINO] Montar a base de dados usando o controlfile gerado no passo 2.2.
2.8) [DESTINO] Catalogar os backups e archives gerados no passo 1 e copiados no passo 3. Ex:
2.9) [DESTINO] Após o catalogo de todos os backupsets, iniciar o restore/recover da base de dados. A base de exemplo possui 6 datafiles apenas:
OBS1: O restore encerrará com um erro dizendo que precisa de um archive para continuar. Nesse momento deve-se desligar a base de origem e abrir ela em modo MOUNT, depois realizar um backup dos archives, copiar e catalogar no destino, e recuperar a base de destino. Com isso, a base de origem e destino estarão sincronizadas.
2.10) [DESTINO] Após o término do restore/recover, deve-se iniciar a base com a opção UPGRADE e executar os scripts. Neste passo, após o MOUNT, é que seria necessário alterar o nome dos REDO Log Members, caso os caminhos dos arquivos sejam diferentes:
OBS1: É possíve paralelizar a execução do “catctl.pl”. “X” indica o grau de paralelização: $ORACLE_HOME/perl/bin/perl catctl.pl -n X catupgrd.sql
OBS2: Após a execução do “catctl.pl”, a base de dados será automaticamente desligada.
2.11) [DESTINO] Após o término da execução do script “catctl.pl”, iniciar normalmente a base de dados, que já deverá estar atualizada:
2.12) [DESTINO] Executar o script “utlu121s.sql” para checar se todos os componentes foram atualizados, e se existe algum erro:
2.13) [DESTINO] Esse passo não é obrigatório, mas recomenda-se recompilar os objetos inválidos:
2.14) Após isso, a base de dados atualizada já podera ser usada normalmente. Lembrando que a base migrada e atualizada é do tipo “non-CDB”. É possível pluga-la em um CDB usando o pacote DBMS_PDB. Falarei sobre esse procedimento em outro post.
3 – Notas
N1: A base ainda estará usando um PFILE para iniciar. Deve-se criar um SPFILE a partir desse PFILE dentro do ASM.
N2: A base de dados estará montada usando apenas um controlfile, localizado no filesystem. Após o procedimento de upgrade, deve-se desligar a base e copiar o controlfile usado para dentro do ASM, atualizando o parâmetro CONTROL_FILES de acordo.
N3: A base restaurada não será registrada automaticamente no Clusterware. Neste caso, deve-se criar um serviço manualmente. Abaixo segue um exemplo tomando como referência a base DBMIGRA, que foi usada em todo este documento. O comando foi executado com o usuário “oracle”:
Bom, é isso por enquanto. Lembrando que a base migrada será do tipo “non-CDB”. Ela poderá ser posteriormente plugada em um CDB usando o pacote DBMS_PDB. Esse procedimento ficará para um outro post. Obrigado a todos.