Start/Stop CDB/PDB

Start/Stop CDBs (Container Database)

As fases de Startup/Stop do CDB continua o mesmo do modelo tradicional, pelo fato do arquivo de parametros e controlfile serem compartilhados, o start da instancia e a montagem da base só podem serem feitos a partir do CDB, ao abrir o CDB também são abertos os Containers CDB$ROOT e PDB$SEED, ambos são containers non-pluggables, os demais PDBs iniciam no Status de mount por default.

Possiveis Parametros para o Stop/Start do CDB:

STARTUP ' NOMOUNT | MOUNT | RESTRICT | FORCE | UPGRADE | READ ONLY '

SHUTDOWN ' IMMEDIATE | NORMAL | TRANSACTIONAL | ABORT '

Start/Stop PDBs (Pluggable Database)

Como os arquivos de parametro e controlfile são compartilhados para todo o CDB os unicos dois estados de banco que é possivel no PDB são Mount e Open, com suas variaveis.

O Stop/Start dos PDBs depende do contexto em que se esta conectado, pode ser realizado operações de stop/start a partir do CDB$ROOT ou a partir do PDB corrente.

Start/Stop PDBs a Partir do ROOT

Quando realizado o stop/start do ROOT, deve ser utilizado o comando "ALTER PLUGGABLE DATABASE", através dele é possivel iniciar/fechar todos, um ou alguns.

ALTER PLUGGABLE DATABASE [ CLAUSULA-PDB ] OPEN [ MODE ] ;

ALTER PLUGGABLE DATABASE [ CLAUSULA-PDB ] CLOSE [ MODE ];

• CLAUSULA-PDB
• Nome do PDB
• All
• All except

• OPEN MODE
• Read Only
• Read Write
• Restrict
• Upgrade

• CLOSE MODE
• Immedate;
• Abort;

Exemplo Stop/Start All PDBs

Start/Stop PDBs a Partir do PDB

Conectado ao PDB além do comando alter pluggable database também é possivel utilizar os comando startup e shutdown, ambos podem ser utilizados as mesmas Clausulas (Open Read Only, upgrade, immediate ou abort).

Os comandos executados a partir de PDBs somente funcionam no PDBs corrente, mesmo utilizando usuários comuns com privilegios elevados em CDBs ou outros PDBs, somente é possivel trabalhar no PDBs conectado.

Clonando PDBs Locais

Como nova da Oracle de Multitenant o Clone de banco de dados é uma feature muito interessante da Oracle que faz parte do pacote de Fast Provisiong, básicamente o clone tem uma origem e um destigo, sendo que a  origem pode ser um PDB de um CDB Local, um PDB de um CDB Remoto ou um Non-CDB.

Pre-requisitos

Básicamente todos os clones de PDBs devem seguir estes pré-requisitos;

• O CDB deve estar aberto e em read/write;
• Deve se estar conectado no CDB$ROOT com usuário comum com privilegio de CREATE PLUGGABLE DATABASE;
• O Nome do PDB deve ser unico em todos os CDBs do mesmo servidor;
• Compatibilidade de Character set do CDB de Origem com o Destino;

Clonando um PDB Local

O Processo de se criar um PDB Local é bem similar ao processo de se criar um PDB from SEED, o processo é basicamente o mesmo, se copia os arquivos do PDB de origem para o PDB de destino, o novo PDB possui novo DBID, Container_ID, GUID, encarnação e um serviço com o nome do PDB.

Ao termino do Clone o novo PDB estará em mount, deve então ser aberto e realizado um backup da base.

Clonando um PDB sem Clausulas de Controle

Pode ser criado um novo Pluggable Database (PDB) a partir do comando Create Pluggable database com a clausula FROM , istó fará com que se crie um novo PDB com o nome do serviço identico ao nome do PDB, os nomes de usuários serão replicados conforme origem, inclusive os usuários administrativos, o destino dos arquivos dependerão dos parametros de destino (OMF) e conversão configurados no CDB.

Após o clone o PDB ficará montado e com o status de New, deve-se então abri-lo e iniciar um backup do CDB.

PDB de origem pré 12.2 ficará disponivel somente para leitura, DMLs irão falhar com o erro ora-16000.

ERROR at line 1:

ORA-16000: database or pluggable database open for read-only access

ORA-06512: at line 5

Exemplo

SQL> select con_id, name, open_mode, total_size from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE
---------- -------------------- ---------- ----------
1 CDB$ROOT READ WRITE    0
2 PDB$SEED READ ONLY   838860800
3 INDAIA READ WRITE  896532480
4 ITU READ WRITE 2417754112
5 RIBERAO READ WRITE  905707520
SQL> 

SQL> show parameter db_create_file_dest
NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest     string +DATA
SQL> 

SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> show con_id
CON_ID
------------------------------
1
SQL> 

SQL> CREATE PLUGGABLE DATABASE SAMPA from INDAIA;
Pluggable database created.
Elapsed: 00:01:07.83
SQL> 

SQL> select con_id, name, open_mode, total_size from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE
---------- -------------------- ---------- ----------
1 CDB$ROOT READ WRITE    0
2 PDB$SEED READ ONLY   838860800
3 INDAIA READ WRITE  896532480
4 ITU READ WRITE 2417754112
5 RIBERAO READ WRITE  905707520
6 SAMPA MOUNTED    0
6 rows selected.
Elapsed: 00:00:00.02

SQL> alter pluggable database SAMPA open;
Pluggable database altered.
Elapsed: 00:00:15.77

SQL> select con_id, name, open_mode, total_size from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE
---------- -------------------- ---------- ----------
1 CDB$ROOT READ WRITE    0
2 PDB$SEED READ ONLY   838860800
3 INDAIA READ WRITE  896532480
4 ITU READ WRITE 2417754112
5 RIBERAO READ WRITE  905707520
6 SAMPA READ WRITE  896532480
6 rows selected.
Elapsed: 00:00:00.02
SQL> 

SQL>  select file_name, con_id from cdb_data_files where con_id=6;
FILE_NAME     CON_ID
-------------------------------------------------------------------------------- ----------
+DATA/CDBSP/5062B61BA5300980E055000000000001/DATAFILE/system.289.944948305  6
+DATA/CDBSP/5062B61BA5300980E055000000000001/DATAFILE/sysaux.288.944948305  6
+DATA/CDBSP/5062B61BA5300980E055000000000001/DATAFILE/users.290.944948307  6
Elapsed: 00:00:00.02
SQL> 

Clausulas e Parametros de Controle para se criar um PDB com SQLPlus

As seguintes clausulas e parametros não são obrigatorios para se criar um novo PDB, porém permitem maior controle e flexibilidade, são elas:

• Controlando o PATH
  O controle da criação dos arquivos podem ser especificados a nivel de instancia ou comando, o comando precede a instancia, e especificando um caminho inicial (OMF) ou convertando os path de origem, a conversão sempre precede o destino (OMF), seguem as clausulas com menos peso para mais peso:
• 4 - Parametro PDB_FILE_NAME_CONVERT - Este parametro converte StringA em StringB;
• 3 - Parameter DB_CREATE_FILE_DEST - Controla o caminho de criação dos Datafiles em OMF;
• 2 - Clausula CREATE_FILE_DEST (12.1.0.2) - Informa no comando de "Create Pluggable" qual o caminho OMF que deve ser criado o PDB;
• 1 - Clausula FILE_NAME_CONVERT - Converte a StringA em StringB dos arquivos de origem;

• Limitando o Tamanho do PDB
• Clausula MAXSIZE - STORAGE (MAXSIZE), limita o tamanho maximo do PDB, o default é unlimited, se o valor for omitido é considerado como unlimited;

• Garantir Path
• PATH_PREFIX - Garante que o caminho especificado, caso não especificado aceita qual path;

• Controlando o nome dos serviços
• Para converter os nomes de serviços no momento da criação do PDB utilizar a clausula SERVICE_NAME_CONVERT, a qual converte a StringA em StringB;

• User Tablespaces (12.1.0.2)
  Permite controlar quais tablespaces de usuários serão criadas/clonadas, podem ser todas, algumas, nenhuma ou ignorar uma ou muitas.
• Muitas - USER_TABLESPACE = ('TBS1','TBS2','TBS3');
• Todas - USER_TABLESPACES = ALL;
• Nenhuma -USER_TABLESPACES=NONE;
• Excluir - USER_TABLESPACS = ALL EXCEPT('TBS1','TBS2');

• Logging
  É possivel controlar se o PDB irá gerrar logs ou não com as clausulas LOGGING ou NO LOGGING

• Standbys
  É possivel controlar se o PDB será replicado ou não para o Standby com a Clausula:
• Replicado para Todos: STANDBYS=ALL
• Nenhum: STANDBYS=NONE

• Clonar PDB Sem Dados de Usuarios (12.1.0.2)
  Especificar a Clausula NO DATA

Exemplo 2 Clonando Local PDBs

O Exemplo abaixo clona o PDB Local Indaia para o PDB Sorocaba, limitando o tamanho do PDB a 2GB, o caminho dos arquivos para o +FRA em OMF, e irá excluir a tablespace USERS:

SQL> select con_id, name, open_mode, total_size/1024/1024 from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE/1024/1024
---------- -------------------- ---------- --------------------
1 CDB$ROOT READ WRITE      0
2 PDB$SEED READ ONLY    800
3 INDAIA READ WRITE    855
4 ITU READ WRITE 2305.75
5 RIBERAO READ WRITE 863.75
6 SAMPA READ WRITE    855
6 rows selected.
Elapsed: 00:00:00.02 

SQL> select tablespace_name from cdb_tablespaces where con_id=3;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
TEMP
USERS
Elapsed: 00:00:00.02
SQL>  

SQL> select con_id, name, open_mode, total_size/1024/1024 from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE/1024/1024
---------- -------------------- ---------- --------------------
1 CDB$ROOT READ WRITE      0
2 PDB$SEED READ ONLY    800
3 INDAIA READ WRITE    855
4 ITU READ WRITE 2305.75
5 RIBERAO READ WRITE 863.75
6 SAMPA READ WRITE    855
7 SOROCABA MOUNTED      0
7 rows selected.
Elapsed: 00:00:00.07
SQL> 

SQL> alter pluggable database sorocaba open;
Pluggable database altered.
Elapsed: 00:00:11.98
SQL>  

SQL> select con_id, name, open_mode, total_size/1024/1024 from v$containers;
    CON_ID NAME OPEN_MODE  TOTAL_SIZE/1024/1024
---------- -------------------- ---------- --------------------
1 CDB$ROOT READ WRITE      0
2 PDB$SEED READ ONLY    800
3 INDAIA READ WRITE    855
4 ITU READ WRITE 2305.75
5 RIBERAO READ WRITE 863.75
6 SAMPA READ WRITE    855
7 SOROCABA READ WRITE    850
7 rows selected.
Elapsed: 00:00:00.03
SQL>  

SQL> select file_name from cdB_datA_files where con_id=7;
FILE_NAME
--------------------------------------------------------------------------------
+FRA/CDBSP/5062B61BA5310980E055000000000001/DATAFILE/system.397.944949401
+FRA/CDBSP/5062B61BA5310980E055000000000001/DATAFILE/sysaux.408.944949401
/u01/app/oracle/product/12.1.0.2/db_1/dbs/MISSING00057
Elapsed: 00:00:00.12
SQL> 

É isso,

Espero que tenha ajudado, deixe um comentário.

Diogo

Criando um PDB através do PDB$SEED

Pre-requisitos

Para se criar um PDB através do Container PDB$SEED é necessário seguir as seguintes regras.

• O CDB deve estar aberto e em read/write;
• Deve se estar conectado no CDB$ROOT com usuário comum com privilegio de CREATE PLUGGABLE DATABASE;
• O Nome do PDB deve ser unico em todos os CDBs do mesmo servidor;

Processo

O Processo de se criar um novo PDB através do PDB$SEED consiste em cópiar os arquivos e conteudo do SEED gerando um novo container_id para ser utilizado como uma nova base de dados em PDB, esse processo faz parte da Feature de Fast Provisioning. Pode ser criado novos PDBs através do Enterprise Manager Express, DBCA ou SQLPlus.

Após o PDB ter sido criado ele se encontrará no estado de mount, deve ser então aberto o PDB e realizado um backup full do PDB.

Criando um Pluggable Database (PDB) através do PDB$SEED Usado SQLPlus

Para se criar um novo PDB através do PDB$SEED deve ser utilizado o novo comando "CREATE PLUGGABLE DATABASE", é obrigatório informar um usário e senha para ser o DBA local e receber a role de PDB_DBA com a clausula ADMIN USER:

SQL> show con_name;

CON_NAME

------------------------------

CDB$ROOT

SQL>

SQL> CREATE PLUGGABLE DATABASE riberao

ADMIN USER riberao_dba IDENTIFIED BY riberao_dba;

Pluggable database created.

SQL> 

Clausulas e Parametros de Controle para se criar um PDB com SQLPlus

As seguintes clausulas e parametros não são obrigatorios para se criar um novo PDB, porém permitem maior controle e flexibilidade, são elas:

• Controlando o PATH
  O controle da criação dos arquivos podem ser especificados a nivel de instancia ou comando, o comando precede a instancia, e especificando um caminho inicial (OMF) ou convertando os path de origem, a conversão sempre precede o destino (OMF), seguem as clausulas com menos peso para mais peso:
• 4 - Parametro PDB_FILE_NAME_CONVERT - Este parametro converte StringA em StringB;
• 3 - Parameter DB_CREATE_FILE_DEST - Controla o caminho de criação dos Datafiles em OMF;
• 2 - Clausula CREATE_FILE_DEST (12.1.0.2) - Informa no comando de "Create Pluggable" qual o caminho OMF que deve ser criado o PDB;
• 1 - Clausula FILE_NAME_CONVERT - Converte a StringA em StringB dos arquivos de origem;

• Limitando o Tamanho do PDB
• Clausula MAXSIZE - STORAGE (MAXSIZE), limita o tamanho maximo do PDB, o default é unlimited, se o valor for omitido é considerado como unlimited;

• Garantir Path
• PATH_PREFIX - Garante que o caminho especificado, caso não especificado aceita qual path;

• Controlando o nome dos serviços
• Para converter os nomes de serviços no momento da criação do PDB utilizar a clausula SERVICE_NAME_CONVERT, a qual converte a StringA em StringB;

• User Tablespaces (12.1.0.2)
  Permite controlar quais tablespaces de usuários serão criadas/clonadas, podem ser todas, algumas, nenhuma ou ignorar uma ou muitas.
• Muitas - USER_TABLESPACE = ('TBS1','TBS2','TBS3');
• Todas - USER_TABLESPACES = ALL;
• Nenhuma -USER_TABLESPACES=NONE;
• Excluir - USER_TABLESPACS = ALL EXCEPT('TBS1','TBS2');

• Logging
  É possivel controlar se o PDB irá gerrar logs ou não com as clausulas LOGGING ou NO LOGGING

• Standbys
  É possivel controlar se o PDB será replicado ou não para o Standby com a Clausula:
• Replicado para Todos: STANDBYS=ALL
• Nenhum: STANDBYS=NONE

• Clonar PDB Sem Dados de Usuarios (12.1.0.2)
  Especificar a Clausula NO DATA

Exemplo Criando PDB from PDB$SEED

O Exemplo abaixo cria o PDB horto com usuário Admin horto_dba, limitando o tamanho maximo do PDB a 5GBs, define a tablespace default para horto_data e mantém o +DATA como base do OMF:

SQL> show con_name;
CON_NAME
------------------------------
CDB$ROOT
SQL>

SQL> CREATE PLUGGABLE DATABASE horto ADMIN USER horto_dba identified by horto_dba
STORAGE (MAXSIZE 5G)
DEFAULT TABLESPACE HORTO_DATA
CREATE_FILE_DEST='+DATA'; 

 2    3    4  

Pluggable database created.
SQL> 

SQL> alter pluggable database horto open;
Pluggable database altered.
SQL>

Criando um Pluggable Database (PDB) através do PDB$SEED Usando DBCA

A criação do PDB também pode ser criada através do DBCA, o qual também permite realizar as mesmas operações e flexibildiade do SQLPlus:

Oracle Multitenant - Arquitetura

Arquitetura Lógica de um CDB

• CDB - Container Database, é nome que damos a toda estrutura do ambiente, ao conjunto de todos os containers, possui o container_id (con_id) igual 0, qual se refere a componentes compartilhados entre todo o ambiente.
• CDB$ROOT - Container único e obrigatório dentro de um CDB, possuí todos os componentes e objetos comuns a todos os PDBs, possui o identificado container_id (con_id) igual 1.
• PDB$SEED - Container único e obrigatório dentro de um CDB, é um container vázio utilizado como template  para criação de novos PDBs, possui o identificado container_id (con_id) igual 2.
• PDBs - São container exclusivo para uso de aplicação e usuário, possuí con_id entre 3 e 252.

Arquitetura Fisica de um CDB

Apesar da mudança de arquitetura de um CDB, a oracle manteve-se fiel ao modelo tradicional, e em questão de arquitetura quase não houveram alterações no meio fisico.

• Estruturas Fisicas Compartilhadas
• Database Instance - Assim como um Oracle Non-CDB ou Pre-12c, possuimos uma SGA unica, as áreas de memória são compartilhadas entre todos os PDBs contidos no CDB.

• Background Processes - Possuí os mesmo BG Processes de um modelo Non-CDB, dentro de uma arquitetura Non-CDB nenhum novo processos de Background foi adicionado.
• Controlfiles - Um grupo de controlfiles multiplexados suportam todos a estrutura de CDB;
  
  
• Redo Logs Groups - A configuração de Online Redo Logs se dá a nivel do CDB inteiro, as transações de todos os PDBs e CDB$ROOT são todas gravadas no mesmo conjuto de redo e são identificadas através do ID do Container, archive logs não podem se manipulados a nivel de PDB;
• Temporary Files - Arquivos temporários criados no CDB$ROOT podem ser compartilhados entre os PDBs, porém também é possivel atribuir tablespaces temporaris dentro de PDBs;
• Undo Tablespace Datafiles - Na versão 12.1.0.x a tablespace de Undo é unica para todos os PDBs e faz parte do CDB$ROOT;
• CDB$ROOT System e Sysaux Tablespaces Datafiles - Essas tablespaces são compartilhadas entre os demais PDBs pois há apontamentos de dicionários comuns a todos os PDBs dentro do CDB$ROOT;
• Arquivo de Inicialização: O Arquivo de inicialização é unico para toda instancia CDB.
  
  
  
• Estruturas Fisicas Não Compartilhadas
• Local Tablespaces Datafiles - Dentro de cada PDBs há as tablespaces System, Sysaux e Temp, no contexto de PDBs essas tablespaces/Datafiles não possuem informações que compartilhadas nos demais PDBs, assim como os datafiles de tablespaces de usários, estas estão isoladas dentro do PDB local.

O Dicionário de Dados

Em um modelo Non-CDB existe apenas um dicionário de dados, portanto o armazenamento dos metadados interno do Oracle, são compartilhado com as informações de metadados de usuários e aplicações, assim como metadados de usuários distintos ficam armazenados no mesmo dicionário.

No modelo CDB cada container possuí sua tablespace System e Syaux, possibilitando assim que cada container possua seu próprio dicionário. As informações de dicionário são divididas e armazenadas os PDBs Locais e o CDB$ROOT para afim de evitar duplicidade de dados, portanto uma tabela com definições globais são armazenadas no CDB$ROOT container e acessadas pelos PDBs Locais através de apontamentos. Assim com os objetos comuns os objetos de sistema, como dbms_output são armazenados unicamente no CDB$ROOT e são acessados pelos PDBs Locais através de ponteiros.

Essas caracteristicas proporcionam a redução de consumo de armazenamento, pois os dados não são duplicados entre containers, e o fast patching e upgrade, caso o mesmo dicionário existisse em todos os PDBs o upgrade deveria ser feito em cada PDB isoladamente.

Desenho abaixo mostra uma tabela de sistema de um PDB com apontamentos para o Dicionário do CDB$ROOT:

Views do Sistema

No Multitenant há  um novo tipo de View, CDB_*, a qual se trata de um Container Object, container objects, são objetos que possuem informações comuns a varios containers, assim como as views dinamicas GV$ / V$, também são Container Objects ou Shared Objects.

Shared Objects possuem uma nova coluna chamada de con_id, onde é possivel identificar o container a qual essa informação pertence, o resultado da saída de consultas em objetos comuns, depende da contexto ao qual esta conectado, se conectado ao CDB$ROOT a saída esperada é relacionada a todos os containers que o usuário tem permissão, se executada a partir de um PDB, a saída esperada é unicamente do PDB conectado.

As views DBA_* existem para compatibilidade de versão, porém para cada DBA_* existe uma respectiva view CDB_*.

Fontes:

Overview of the Multitenant Architecture

Oracle Multitenant - Visão Geral

Conceito

Arquitetura disponivel a partir do 12c, o multitenant permite trabalhar com o Oracle no modelo de container database, CDB, podendo utilizar nenhum, um ou muitos banco de dados de clientes, PDBs, Pluggable databases.

A proposta de se trabalhar com o modelo de multitenant é facilitar a consolidação de schemas e bases de dados, compartilhando hardware, recursos de processamento e armazenamento, ao mesmo tempo estando em um ambiente seguro e isolado.

Principais Desafios Pre-12c

• Diversos bancos de dados departamentais;
• Desperdício de capacidade de processamento e memoria;
• Alto custo operacional e de licença;

Cenários Identificados Pre-12c

Anteriormente ao 12c, poderiamos encontrar as seguintes distruições de base de dados Oracle, porém nenhuma delas apresenta uma solução completa em consolidação provendo redução de waste, provisionamento rapido e isolamento.

• Bancos de dados e instancias isoladas;
• Bancos de dados consolidados em servidores unicos;
• Schemas de banco de dados consolidados em uma unica base;

Com advento do 12c a arquitetura Multitenant nos permite uma consolidação muito mais inteligente, segura e isolada.

Benefícios

O principal beneficio em trabalhar em modo Multitenant é a consolidação dos diversos bancos de dados, através desta nova essa abstração dos dados, anteriormente feita a nivel de instancia ou schema, configurando o produto como Multinant conseguimos consolidar as aplicações de maneira mais inteligente, segura e dinâmica.

Com o Multitenant conseguimos isolar as aplicações em Plugables database (PDB), cada PDB é uma base de dados completa, possuem seu proprio dicionário de dados, arquivos fisicos, privilegios e usuarios. Todo PDB é conectado ao ROOT, fazendo com que alguns recursos sejam compartilhados, como por exemplo Redos Logs, Archive, Undo TBs e SGA.

Através de algumas features de Multitenant como Fast Provisioning e fast upgrade/patching, conseguimos eliminar o desperdício que temos em algumas tarefas, como aplicação de patch, criação de base e refresh.

Possíveis Arquiteturas 12c

Non-CDB - Arquitetura "tradicional", ou pre-12c, este é o modelo chamado pela Oracle de Non-CDB, onde não temos o Container Database Criado, pode ser utilizado em EE ou SE, e no 12.1 já esta deprecated, indicando que em breve a Oracle não suportará esse modelo de banco de dados.

Singletenant - Modelo em Container Database (CDB), porém com apenas um pluggable database, este modelo não requer custo extra de licença, e pode ser instalado na versão EE ou SE.

Multitenant - Modelo em Container Database (CDB), onde possui diversos Pluggables database, requer custo adicional de licença e somente disponivel na versão Enterprise (EE).

Fonte: MOS 1628809.1

Componentes

CDB$ROOT - Todo ambiente CDB possui um Root Container obrigatoriamente. ;de forma lógica este armazena informações que são compartilhadas entre todos os PDBs e usuários comuns a todos os CDBs, seu dicionário de dados engloba objetos comuns a todos os containers do CDB;

PDB$SEED - Todo ambiente CDB possui um SEED, este é um containter vazio utilizado como template para criação de novos Pluggables.

PDB - Pluggable Database - Este é o container que irá receber dados e objetos locais de usuários locais, destinado para uso individual das aplicações.

Fontes

Website: Oracle Interactive Quick Reference

Video: Oracle Database 12c: Introduction to a Multitenant Environment with Tom Kyte

Video: Oracle Database 12c Multitenant Architecture Overview

Docs: Overview of Managing a Multitenant Environment
Docs: Introduction to the Multitenant Architecture

Upgrade Oracle Database to 12.1 using DBUA

Devo ser sincero, antes do 12c eu nunca usei o DBUA para nada, nem mesmo em laboratorio, a escolha principal sempre foi o catupgrade.sql, porém acho que a Oracle me deu algumas boas razões para experimentar o DBUA, esta ferramenta esta cheia de Novas Funções e acredito que para upgrade simples pode ser utilizada tranquilamente, acho que agora acabou o preconceito com o DBUA, rs.

Outro ponto importante a Oracle passou o nosso tradicional catupgrade para deprecated, então já devemos ir nos habituando com o novo script em pearl ou o DBUA. Vamos começar com o DBUA.

Ambiente Utilizado

Abaixo estão as principais caracteristicas do ambiente que será atualizado:

Servidores	ol6-ora121-rac1	ol6-ora121-rac2
Database Name	SAMPA	SAMPA
Instance Name	SAMPA1	SAMPA2
GI Version	12.1.0.2	12.1.0.2
Source Version	11.2.0.4	11.2.0.4
Dest Version	12.1.0.2	12.1.0.2
ASM Comp	12.1.0.0.0	12.1.0.0.0
ASM DG Comp	10.1.0.0.0	10.1.0.0.0
DB Comp	11.2.0.0	1.2.0.0
SO	Red Hat 6.8	Red Hat 6.8

 

 

 Principais Diferenças Para Atualizar Para o Oracle 12c

No 12c houveram muitas atualizações, o processo de upgrade tradicional o qual estamos acostumados ficou bem diferente, para os DBAs um pouco mais antigos é legal executar alguns Labs antes de partir para produção. As principais modificações estão listadas abaixo:

 

 

Novas Funções do DBUA

 

O DBUA ficou muito mais robusto e muita coisa me chamou a atenção, segue o que eu identifiquei como principais melhorias:

• Execução do uprade de forma paralela;
• Pode ser reiniciado;
• Melhora na saida do processo de upgrade, há possibilidade de mostrar o alertlog e as fases do upgrade;
• Executa os scripts de pre e pós upgrade;
• Suporte a Plugable database;
• Possibilita criar um backup rman ou um ponto de restore com flashback;
• Possibilita o restore ou flashback database para o ponto antes da atualização, a base de dados precisa estar em modo de flashback habilitado;
• Possibilita configurar o Enterprise Manager Express.

Passos Recomendados

Segundo documentado pela Oracle:

• Validar se há objetos invalidos na base de dados;
• Validar se há componentes invalidos na base de dados;
• Desabilitar Triggers que podem disparar DDLs;
• Garantir um bom backup;
• Checar a Matrix de compatibilidade;
• Executar o script de pre-upgrade;
• Configurar a base em archivelog;
• Para Oracle RAC com DBUA manter o Cluster_Database to True, esse passo é diferenciado, pois até o momento sempre realizei upgrades com o parametro configurado para falso;
• Desabilitar a coleta de estatisticas em paralelo.

Para validar os objetos invalidos, componentes e outras caracteristicas do ambiente a Oracle recomenda a utilização do script dbupgdiag.sql, o qual pode ser obtido na Note 556610.1 direto do metalink, este script deve ser  executado antes e depois do upgrade e comparado os resultados, segue uma parte da saida:

Esses foram os passo a passos  que a Oracle recomenda, também costumo fazer mais alguns se possiveis:

• Truncar a tabela sys.aud$;
• Esvaziar a Recycle Bin;
• Remover objetos do sys e system duplicados, sob a supervisão da Oracle;
• Remover componentes obsoletos;
• Validar instalação e o Inventário;
• Instalação de qualquer Patchset e/ou PSU necessáros;
• Coletar estatisticas para o sys;
• Copiar arquivos de Network e Password entre as instalações de origem e destino.

Passos Requeridos

• Instalação do Software de destino requerido;
• Executar o script de preupgrade preupgrd.sql;
• Desabilitar o Database Vault;

Abaixo esta o print da execução do script de Pre-upgrade, este esta muito mais completo que o script anterior, e tem como saida 3 arquivos, um de log, e dois scripts, pre e pos upgrade, que devem ser executados conforme denominado:

Validando a Matrix de Compatibilidade

Sempre em qualquer atualização validar a matrix de compatibilidade  entre SW e SO, Cluster, ASM, Client e Drivers de Conexão, neste exemplo apenas temos as validações de SO e GI:

A Matrix de cluster por ser encontrada no MOS: Oracle Clusterware (CRS/GI) - ASM - Database Version Compatibility (Doc ID 337737.1)

Validando o Tipo de Upgrade

A tabela a Seguir demonstra quais as versões de banco de dados Oracle podem ser atualizadas diretamente para a versão 12.1.0.2.0, versão a qual estamos trabalhando.

Veja que queremos atualizar uma versão 11.2.0.4 para 12.1.0.2, essa tarefa pode ser realiza sem a necessidade de utilizar qualquer versão ponte.

Executando a Atualização com DBUA

Assim que estiver seguro que todas as ações e passos recomendadas e requiridas foram seguidas é hora de iniciar o upgrade da base.

Logo na primeira tela temos uma nova função que permite escolhermos entre atualizar a versão da base ou mover a base de Oracle_home, nosso casos iremos atualizar a versão:

Em seguida percebam que iniciei o upgrade com a base em up e open, isso porque o DBUA irá controlar os passos de backup, startup e shutdown:

O DBUA executa os scripts de pre-upgrade que podemos executar manualmente e caso possivel fornece um sript de correção:

Essa parte podemos especificar em quantas threads iremos em paralelo iremos executar o upgrade, podemos também atualizar o timezone e coletar estatisticas ao termino, todos steps que fariamos manualmente, fora o parallel que não existia antes da versão 12c.

Podemos registrar a nova base no Cloud Control ou utilizar a nova ferramenta Database Express:

Outra Nova função, o DBUA pode criar um restore point (Se o FlashBack Database estiver habilitado) ou um backup do Rman, o que permite que a base de dados seja restaurada até o momento antes da atualização.

Temos o Sumário do que será feito:

E a atualização, perceba que há novos botões que oferecem muitos detalhes que antes não era possivel de se visualizar.

Referencias Utilizadas:

Livro Oracle Database 12c New Features - Robert G. Freeman

https://mikedietrichde.com/2013/06/25/oracle-database-12c-is-available-for-download-now - Aborda praticamente todos os aspectos para migrar o Oracle para 12c.

MOS: Complete Checklist for Upgrading to Oracle Database 12c Release 1 using DBUA (Doc ID 1516557.1)