Opções de Atualização no Oracle 12c Multitenant Database

Por Yenugula Venkata RaviKumar Oracle ACE e David Siqueira Oracle ACE
Postado em Abril 2016

Revisado por Marcelo Pivovar - Solution Architect

Introdução

A Oracle introduziu na arquitetura do 12c os Container Databases (CDBs) e Pluggable Databases (PDBs). Os dados dos usuários serão armazenados nos PDBs e os CDBs terão as informações sobre o mapeamento destes pluggable databases. Usuários associados ao container são chamados de Commom users (usuários comuns) que tem acesso  em todos os pluggable databases e os usuários criados nos pluggable databases são chamados de Local Users ( usuários locais) estes usuários tem acesso somente aos pluggable databases (PDBs) particulares.

Atualmente duas versões de Multitenant Databases estão disponíveis, são elas Oracle12c (12.1.0.1.0) e Oracle12c (12.1.0.2.0).

Futuramente os “non multitenant databases” serão descontinuados. Então é recomendado que as bases de dados sejam movidas para a arquitetura Multitenant. O Multitenant pode ser atualizado para versões mais recentes de duas formas:

  • CDB com associações a PDB podem ser atualizados para versões superiores. Todos os PDBs serão atualizados para versões mais recentes juntamente com o CDB.
  • Somente um PDB particular como o HRMS no diagrama  acima pode ser atualizado para versões superiores. O PDB será desplugado do CDB e plugado em um CDB com versão superior. CDBs existentes não serão afetados e os outros PDBs podem operacionalizar normalmente.

Antes de procedermos com os métodos de atualização, nós vamos ver a nova funcionalidade  para atualizações disponível no Oracle 12c.

1. Oracle 12c Novos Recursos de Atualização

  • No Oracle 12c, os processos de atualização podem ser usados em paralelo. Até o Oracle 11gR2 atualizações eram executadas por processos únicos e algumas vezes isto poderia levar um tempo maior para atualização completa. E também neste caso os recursos de HW podem não ser utilizados adequadamente. No Oracle 12c isto foi retificado. Nós podemos especificar o numero de processos em paralelo para executar a atualização. Isto é puramente baseado no numero de CPUs disponível no servidor.  Usando este paralelismo na atualização, podemos completar em menos tempo  com uma otimização de recursos.
  •  O processo de atualização do Oracle 12c é executado em múltiplas fases. Nós podemos executar o Catupgrd.sql para fazer a atualização do banco de dados, mas este script internamente chamará alguns arquivos sql para completar a atualização. Estes scripts sql são responsáveis pelo oracle server e outros componentes de atualização. Alguns desses scripts são dependentes de outros, outros não são. A atividade de atualização irá primeiro coletar todos os arquivos SQL e então dividi-los em múltiplas fases baseadas nas suas dependências em outros arquivos sql. Essa segregação em fases se deve ao fato de que em caso de falha durante o upgrade,  a atualização pode ser repetida em uma fase em particular. Isto quer dizer que nós não precisamos reexecutar todo o processo de atualização.
  • O pré-upgrade script no Oracle 12c está melhorado. Existem 2 scripts nomeados como Preupgrd.sql e Utluppkg.sql os quais são responsáveis pela checagem do pré-upgrade na base de dados de origem. Durante a execução ambos os arquivos sql devem ser colocados na mesma localização. O Preupgrd.sql chama o  Utluppkg.sql  que contém procedimentos para validar a base de dados de origem e recomendar se necessário mudanças requeridas na atualização. Também o pré-upgrade script cria scripts de correções que iram ajudar a alcançar as tarefas requeridas antes e depois da atualização.
  • No Banco de Dados Oracle 12c, a atualização em paralelo é realizada através do script em perl catctl.pl. Isto está disponível no  diretório $ORACLE_HOME/rdbms/admin. Nós devemos passar o catupgrd.sql como um argumento neste script. Juntamente com o número de processos paralelos necessários para ser executado deve ser especificado. Isso irá criar processos em  paralelo e iniciar a execução de cada fase.
  • A atualização cria logs por padrão no formato de  “catupgrd(n).log”.  Cada processo paralelo cria seu próprio logfile. Então os logs serão gerados a partir de catupgrd(n-1) para catupgrd0.log, onde  n é o número do processo usado para executar o script sql. Por exemplo, no caso de 4 processos paralelos serem usados para a atualização, então serão gerados os logs : catupgrd3.log, catupgrd2.log e catupgrd1.log e catupgrd0.log. Estes logs são criados para o CDB e todos os PDBs envolvidos na atualização.
  • No 12c temos o catcon.pl script Perl que irá obter o script sql como entrada e executa-lo no CDB e seus PDBs associados. O  pré-upgrade e pós scripts de upgrade durante a atualização serão dados ao catcon.pl para execução no CDB e PDBs.


2. Checagem de Atualização

Antes de atualizar a base de dados uma checagem genérica de atualização deve ser executada no CDB e PDBs

  • Limpeza de objetos não desejados (Esvaziar a área de recycle bin, remover objetos duplicados).
  • Garantir que todos os componentes de db e objetos estejam válidos no CDB e no PDB.
  • Coletar estatísticas de dicionário.
  • Instalar  12.1.0.2.0 (ou) a versão mais recente disponível emu ma nova localização e checar a integridade dos binários pelo relink.
  • Instalar o último  PSU patch para os binários do Oracle Home 12.1.0.2.0.


3. CDB e sua atualização de PDB (ou) Atualização de Todo CDB

3.1 Pré-upgrade execução de scripts.
O pré-upgrade verifica  o que tem de ser executado no Container Database e conecta aos pluggable databases. Como forma de melhores práticas os scripts de pré-upgrade (preupgrd.sql e utluppkg.sql) podem ser copiados para o Oracle Home de origem ou outra localização.

Na base de dados de origem execute o script no CDB e seus PDBs, rode o  catcon.pl

cd $ORACLE_HOME/rdbms/admin (ou) localização da cópia dos scripts de  pré-upgrade

$ORACLE_HOME/perl/bin/perl catcon.pl -d <directory location of preupgrade scripts> 
-l <log location of preupgrade script> -b <preupgrade_log_base_name> preupgrd.sql

A saída do script de pré-upgrade será gerada para o CDB e todos PDBs. Revise a saída e execute as alterações recomendadas antes de proceder com a atualização. As recomendações podem ser de objetos inválidos no  sys/system, componentes do db inválidos, coleta de estatísticas do dicionário.

Uma vez completada a checagem do pré-upgrade para o CDB e todos os PDBs, a Base de Dados estará pronta para a atualização.

A base de dados pode ser atualizada seja através do DBUA ou método Manual. O DBUA é recomendado pela Oracle o qual irá executar as tarefas de atualização automaticamente. Mas isto pode ser usado somente quando a origem e o destino do Oracle Home estão no mesmo servidor e ambos Oracle Homes são propriedade do mesmo usuário. Embora o DBUA execute a checagem do pré-upgrade durante a atualização, é recomendado que seja executado manualmente antes de proceder com a atualização.

3.2 Assistente de Atualização de Banco de Dados (DBUA)
O DBUA deve ser executado a partir do Oracle Home do alvo. Isto estará disponível  no diretório $ORACLE_HOME/bin . Leia o arquivo ”/etc/oratab”  para conhecer a lista de base de dados executando neste servidor. Quando nós escolhemos a base de dados para atualizar, isso irá conectar na base de dados  como usuário sysdba e executar a checagem de pré-upgrade.

O DBUA tem a opção de corrigir  os avisos de saída do pré-upgrade automaticamente. Neste caso os aviso são manualmente corrigidos, ele também tem a opção de reexecutar o passo do pré-upgrade par a verificar o mesmo .Uma vez que as tarefas de pré-upgrade são completadas nos podemos iniciar a atualização. O DBUA coleta algumas informações do usuário como numero de paralelismo requeridos para a atualização, se necessário uma alteração de armazenamento requerida em versões superiores. A atualização pode ser movida de um Sistema de arquivos para um Sistema em ASM.

O DBUA atualizará o CDB primeiro e então os Seed Database seguidos pela atualização dos pluggables databases. Nós não temos controle para pular qualquer atualização de PDB durante o processo de atualização.

No processo em segundo plano do DBUA a atualização é dividia em múltiplas fases. Cada fase terá scipts sql. Baseados nas dependencias, os scripts sql serão divididos dentro das fases. Os detalhes sobre cada fase serão salvos no log OracleServer.log. Ao final da atualização um “Summary Report” será mostrado contendo os resultados da atualização.

3.3 Atualização Manual
Atualização Manual será utilizada quando:

  • Origem e Destino do Oracle Home estão em diferentes servidores.
  • Origem e Destino do Oracle Home tem proprietários diferentes.
  • Atualização do DB tem que ser executada usando um Backup do Banco de Dados. Backup da Origem será restaurado no destino e atualizado  utilizando a o restore feito.
  • No caso do DBUA falhar e nós não pudermos reexecutar o DBUA novamente na falha da atualização.
  • Nós queremos ter maior controle sobre o processo de atualização.

Preparação do Oracle Home do Alvo:

Instalar o Oracle 12c (12.1.0.2.0) (ou) a versão mais recente disponível no servidor alvo.  Escolha a opção  de apenas instalação de software e crie os arquivos de senhas para o CBD que será atualizado neste Oracle Home.

Copie os datafiles de origem e o pfile para a  Oracle Home do alvo  no caso os servidores de origem e destino são diferentes e inicie a base dados em upgrade mode. Se nós tivermos um backup da base de dados de origem, restaure e recupere isto no servidor destino e abra a base de dados no modo upgrade.

Execute o catupgrd.sql através do utilitário perl catctl.pl para obter o paralelismo.

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl  -l <log location for upgrade>  catupgrd.sql

O Catupgrd.sql será executado primeiro no CDB, então nos PDB seeds e seguidos por todos os PDBs. Em cada atualização serão executadas múltiplas fases. Os logs por padrão serão armazenados no local de onde o catctl.pl for invocado. Nós não devemos excluir qualquer PDB neste método.

Nós podemos ver o status de cada fase em detalhes no OracleServer.log. Seus detalhes sobre o número da fase, método de execução ( serial ou paralelo), scripts executados nas fases e tempo gasto por cada fase. Reiniciar a fase irá reconectar no banco de dados. Devido a esta reconexão, as dependências entre as fases serão alcançadas e atualizadas podendo assim iniciar de qualquer  fase requerida. Por exemplo : no caso da fase 9 falhar durante a atualização, então a reexecução pode iniciar a partir da 9th fase.

OracleServer.log will be like below                                                                                                                                           

Serial Phase #: 0Files: 1Time: 369s
Serial Phase #: 1Files: 3 Time: 80s
Restart Phase #: 2Files: 1 Time: 9s
Parallel Phase #: 3Files: 18Time: 24s
Restart Phase #: 4Files: 1 Time: 1s
Serial Phase #: 5Files: 5 Time: 34s
Serial Phase #: 6Files: 1 Time: 21s
Serial Phase #: 7Files: 2 Time: 19s
Restart Phase #: 8Files: 1 Time: 1s
Parallel Phase #: 9Files: 61 Time: 111s
Restart Phase #: 10Files: 1  Time: 1s
Serial Phase #: 11Files: 1 Time: 23s
Restart Phase #: 12Files: 1 Time: 0s
Parallel Phase #: 13Files: 199 Time: 91s
Restart Phase #: 14Files: 1 Time: 1s


A execução do script catupgrade será armazenada nos logs: catupgrd(n-1) para catupgrd0.log  onde ‘n’  determina o número de processos paralelizados envolvidos na atualização.

OracleServer.log e catupgrd(n) logs serão gerados para o CDB e todos os PDBs.

Execute o pós upgrade script catuppst.sql no CDB e em todos os PDBs usando o script catcon.pl

cd $ORACLE_HOME/rdbms/admin

$ORACLE_HOME/perl/bin/perl catcon.pl  -d <directory location of upgrade scripts> -l <log location of postupgrade 
script>  -b <post upgrade_log_base_name> catuppst.sql


Verifique a dba_registry para saber o status dos componentes do DB.


4. Atualização do Pluggable Database (PDB)

No lugar de atualizarmos todo o Container Database ( CDB ) e todos os Pluggable Databases ( PDBs), nós podemos querer somente atualizar um PDB. Neste caso nós não precisamos executar o pré-upgrade no CDB e em outros PDBs.

Aqui todo o processo de atualização será executado somente nos PDBs selecionados. Outras funções dos PDBs funcionaram normalmente sem qualquer indisponibilidade.

4.1 Execução do Script de Pre-upgrade
Execute o pré-upgrade somente para um particular Pluggable Database (PDB) o qual foi escolhido para atualização.

cd $ORACLE_HOME/rdbms/admin

$ORACLE_HOME/perl/bin/perl catcon.pl –c <pdb name> -d <directory location of preupgrade scripts> -l <log location 
of preupgrade script>  -b <preupgrade_log_base_name> preupgrd.sql

OU

Você pode conectar-se no PDB escolhido usando o sqlplus e executar o preupgrade.sql

SQL> alter system set container =<PDB Name>
SQL> @?/rdbms/admin/preupgrd.sql

 

Uma vez que o checklist do pré-upgrade é executado, o Plugglabe Database (PDB) é preparado para atualização. Uma vez que somente o PDB está sendo atualizado, nós precisamos ter o local do CDB de destino na versão superior.

O PDB será desplugado do CDB de origem e será plugado no CDB com a versão superior. Uma vez que o Pluggable Database (PDB) é plugado, abriremos o mesmo no modo upgrade e então os scripts de atualização serão executados no Pluggable Database (PDB).

4.2 Desplugando o Pluggable Database (PDB) do Oracle Home de origem

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> connect / as sysdba
SQL> alter session set container=CDB$ROOT;
SQL> alter pluggable database <PDB_Name> close;
SQL> alter pluggable database <PDB_Name> unplug into '/stage/<PDB_Name>.xml'; SQL> exit; 


4.3 Plugando o Pluggable Database (PDB) no Oracle Home de destino

No caso da localização do destino ser diferente, copie os arquivos abaixo para o servidor de destino.

1) PDB database files
2) /stage/<PDB_Name>.xml
3) postupgrade_fixups.sql generated by Preupgrade scripts

Conectar no Container Database (CDB) de versão superior

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> connect / as sysdba
SQL> alter session set container=CDB$ROOT;
SQL> create pluggable database <PDB_Name> using '/stage/<PDB_Name>.xml' 
file_name_convert=('<Old Location>', '<New location>');
 

file_name_convert é requisitado quando a estrutura de diretório é diferente entre a origem e o servidor de destino.

4.4 Upgrade Steps
Abra o Pluggable Database (PDB) no modo upgrade.

SQL> alter pluggable database <pdb name> open upgrade;
SQL> exit; 


Execute os scripts de atualização

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl –c <pdb name>  -l <log location for upgrade>  catupgrd.sql
   

-c esta opção é mandatória para especificar o nome do PDB

Para atualizar múltiplos Pluggable Databases (PDBs) ao mesmo tempo, desplugue estes PDBs do container database, plugue-os no container database de versão superior e execute os scripts de atualização através do comando catclt.pl

$ORACLE_HOME/perl/bin/perl catctl.pl -c "<PDB_Name1>, <PDB_Name2>" -l  <log location for upgrade>   catupgrd.sql

 

Execute o pós upgrade  catuppst.sql como segue:

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1  -c <PDB_Name>  -b catuppst -d '''.''' catuppst.sql

 

Execute o catcon.pl para invocar o utlrp.sql que irá recompilar qualquer stored PL/SQL e Java code.

$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -c <PDB_Name>  -b utlrp -d '''.''' utlrp.sql

 

Abra o PDB em modo normal.

4.5 Pós upgrade scripts de correções
Seguido da inicialização e atualização do Pluggable Database (PDB) devemos agora abrir  para recompilação.

SQL> startup pfile=<location of pfile>; 
SQL> alter pluggable database <PDB_Name> open;
 

Execute o script postupgrade_fixups.sql:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -d <post upgrade script location> 
-l <Log location> -c <PDB_Name> -b postupgrade_fixups postupgrade_fixups.sql


(OU)

SQL> alter session set container=<PDB_Name>;
SQL> @<Post_upgrade_script_location>/postupgrade_fixups.sql

 

Resumo:

Este artigo explorou as opções disponíveis para atualização do Oracle Multitenant Database diretamente para uma versão superior. Nós discutimos sobre atualização do CDB e de PDBs.

 


Yenugula Venkata Ravikumar é um DBA com mais de 15 anos de experiencia com Oracle e em ambientes de alta disponibilidade (RAC, Data Guard, dentre outros), tuning e desempenho, migrações, backup e recover, Oracle Exadata X2 e X3, é Expert em sistemas operacionais tais como como AIX, HP-UX e Linux. Já participou como conferencista de Oracle pela India, onde mora atualmente. Obteve o título de "Oracle Certified Master (OCM 10g)" em 2009.

David Siqueira é DBA desde 2001, atuante no mercado de São Paulo Brasil, trabalhou nas principais consultorias sempre buscando melhorar conhecimentos e agregar valor aos ambientes por onde passou, é OCP 10 e 11g, OCE SQL Expert, OCE RAC 10g, OCE Exadata Essentials e foi nomeado Oracle ACE em Dezembro de 2011. Atua com ambientes de Alta Disponibilidade Oracel RAC 11g, Exadata X2-2 e Administração de Banco de Dados em Geral. Também possui conhecimentos em sistemas operacionais Oracle VM server e Oracle Businnes Intelligence.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.