quinta-feira, 28 de dezembro de 2017

ILM - Information Lifecycle Management


Introdução


O ILM "Information Lifecycle Management" é a estrategia implementada em banco de dados para  reduzir custo de armazenamento e melhorar o acesso aos dados,  adaptando-os de acordo com a necessidade de negocio de forma inteligente e automatica. Através do ILM é possivel "classificar" a informação e fazer a manutenção dos dados de forma inteligente e automática.

O ILM surgiu pois nem toda a informação no banco de dados é acessado da mesma maneira, dados novos são lidos com mais frequencia, conforme a informação vai se tornando velha os dados se tornam menos acessados, e por fim quase não são acessados, porém muitas vezes são mantidos no banco de dados. O ILM é o framework responsavel por automatizar a manutenção do dados, utilizando duas features, Compression e Storage Tiering.

OBS - Para fazer uso do ILM deve estar na versão Enterprise, ter a feature Advanced Compression e para 12.1 não estar dentro de um contexto de CDB.


Oracle 12c Information Lifecycle Management
Oracle ILM (Information Lifecycle)

Componentes

Os doiscomponentes para a manutenção do ciclo de vida das informação (ILM), são o mapa de calor (Heat Map) e o ADO (Automatic Database Optimization), otimização dos dados automatica.

A organização das informações é feito pelo através de um mapa de calor, heat map, assim o mecanismo de otimização, ADO Automatic Data Optimization, avalia as informações do mapa de calor e dispara uma ação de acordo com a politica definida. Politicas baseadas em linha são executadas assim que detectadas pelo MMON, politicas baseadas em segmentos são executadas na janela de manutenção.

Heat Map

O Heat Map é uma nova feature do Oracle 12c a qual faz um mapeamento da utilização dos dados a nivel de linhas e segmentos. É mapeado as modificações, leituras, acesso full e acesso via index, assim traçando um mapa de calor do que esta sendo utilizado, sendo a trigger para optimização do armazenamento dos dados, o mapeamento dos dados é feito através de acessos ao segmento e modificações a nivel de bloco e semento.

O primeiro passo para utilizar o ILM é habilitar o Mapa de Calor (Heat Map), o qual é controlado pelo parametro heat_map. Este parametro faz com que DML e acessos a segmentos sejam mapeados na memoria e futuramente armazenados na tablespace SYSAUX.

alter system set heat_map=on;

O Tracking dos dados é armazenado em memoria e pode ser consultado pela view V$HEAT_MAP_SEGMENT, periodicamente é armazenado em disco pela DMBS_SCHEDULER e pode ser consultados pelas views, DBA_HEAT_MAP_SEGMENT, DBA_HEAT_MAP_SEG_HISTOGRAM, DBA_HEATMAP_TOP_TABLESPACES.


Automatic Data Optimization (ADO) 


ADO prove a habilidade de declarar politicas em diferentes escopo de objetos no banco de dados, assim automatizando a manutenção dos dados de acordo com necessidade de negocio, tendo como base o heat map.

O ADO depende de algumas diretrizes para funcionar, basicamente depende do escopo, condição e uma ação.

Basicamente o ADO monitora através das politicas uma condição, como por exemplo N tempo sem acesso a um segmento pode disparar uma ação de compressão da tabela ou partição especifica.

  • Escopo Tablespace, tabela, partição, subpartição e linha
  • Classicação / Condição Ultimo Acesso, ultima modificação, data de criação
  • Ações compression, Storage Tiering
Abaixo temos as diretrizes que podemos utilizar para se criar uma politica.

Oracle 12 Automatic Data Optimization
Oracle ADO (Automatic Data Optimization)















Existem alguma diretrizes que devem ser obervadas.
  • Quando o espoco é de linha, somente pode ser utilizada a condição de "não modificação".
  • Storage Tiering é feito somente com base em dados, ou seja quando a tablespace se encontra com thresshold de utilização acima do definido
Abaixo temos as possiveis relação de ação, objeto e condição:

Oracle Compression















Exemplos


Politica a nivel de segmento

ALTER TABLE t1 ILM ADD POLICY
COLUMN STORE COMPRESS FOR QUERY HIGH
SEGMENT AFTER 90 DAYS OF NO MODIFICATION;

Na instrução temos para cada cor um aspecto da politica.

Ação - A ação que será executada quando encontrada a condição
Target - O Target, indica que o segmento inteiro receberá a ação
Condição - A condição que é espera para disparar o gatilho da ação.

Politica a nivel de linha

ALTER TABLE t2 ILM ADD POLICY
ROW STORE COMPRESS ADVANCED
ROW AFTER 90 DAYS OF NO MODIFICATION;

Na instrução temos para cada cor um aspecto da politica.

Ação - A ação que será executada quando encontrada a condição
Target - O Target, indica que a linha receberá a ação
Condição - A condição que é espera para disparar o gatilho da ação.

Casos especiais

Muitas politicas no mesmo segmento

É possivel habilitar muitas policitas desde que sejam seguidas algumas regras, são elas.

Todas as politicas deven seguir a mesma condição, seja ela no access, no modification ou creation time, essa deve seguir sempre com a mesma condição em todas as politicas.

A ação sempre deve ser uma ação em um nivel superior ao anterior, ou seja o nivel de compressão 
sempre deve ser maior, quando mais velho o dado maior o nivel da ação.

Linha

É aceito apenas uma politica a nivel de linha.

A unica condição aceita a nivel de linha é a "No Modification"

Politicas de segmento não sobrepoem politicas de Linhas.

Herança

Caso seja especificado uma politica para um objeto que tenha dependencias, por exemplo partições de uma tabela, as partições recebem a mesma politica como hereança da politica da tabela. Caso nessa tabela seja criada uma politica a nivel de partição, essa politica sobrepoem a politica de tabela para aquela partição.

Mecanismo

Para politicas de linha o ADO utiliza o processo de MMON, o qual a cada 15 minutos avalia as linhas / Politicas e realiza qualquer ação que tiver sua condição quebrada.

Para os demais objetos somente são avaliados e qualquer ação tomada dentro da janela de manutenção. Para quebrar essa regra podemos utilizar duas procedures:

Avalia a politica: DBMS_ILM_ADMIN.EXECUTE_ILM
Para executar a  Politica: DBMS_ILM_ADMIN.EXECUTE_ILM_TASK

Alguasm views que podem ser utilizadas para monitorar o ILM são

DBA_ILM_TASK
DBA_ILMEVALUATIONDETAILS
DBA_ILMRESULTS

Tipos de Compressão

Embora o ILM não trata dos detalhes de compressão, acho interessante ter em mente o básico de comprssão para entender muitas vezes o efeito esperado com o ILM.

  • Row Compression
O tipo de compressão a nivel de linha é feito pelo Oracle através do agrupamento das colunas de uma mesma linha e removida os valores duplicados, assim substituindo por ponteiro para o valor original, até a próxima linha, a qual é agrupada no mesmo bloco. Existe dois tipos de compressão pra linha, row basic e advanced.
    • Row Compression Basic
      • Nivel de compressão mais básico
      • Licença Enterprise Edition
      • Não Suporta DML
      • Metodos - Direct path insert, alter table move, redefinition
    • Advanced Row Compression
      • Adequado para OLT
      • Suporta DML
      • Requer licença especial de Advanced Compression

  • Hybrid Columnar Compression

A compressão colunar é um pouco diferente da linha, o agrupamento é feito por vetores na coluna, portanto é utilizado um grupo de linhas, e a compressão é feito na coluna e armazenada como compression unit, podendo estar fisicamente armazenado em vários blocos.

Basicamente existem dois tipos de compressão HCC, For Query e For Archive.

HCC Requires: Exadata, SuperCluster, Pillar Axiom or ZFSSA storage

  • Warehouse Compression
    • For Query Low
    • For Query High
  • Archive Compression
    • For Archive log
    • For Archive High
Sintaxe para cada tipo de compressão:

Oracle Compression Method

domingo, 24 de dezembro de 2017

Multitenant: Flashback CDB

Introdução


O processo de Flashback consiste em guardar uma copia de cada bloco dos datafiles antes de qualquer alteração nele feito em arquivo de log chamados flashback log, este são armazedos na fast recover area, e são retidos de acordo o espaoços disponivel e/ou o tempo de retenção determinado,  assim quando necessário é possivel desfazer qualquer alteração até o log disponivel.

O processo de "rewid" é muito parecido com o Point-in-Recovery, o banco é trazido em um estado consistente no passado, a diferença é que não é necessário voltar peças de backups e aplicar  archives excessivos, somente é aplicado os flashback log necessários e o grupo de archive/redo para deixar o ambiente consistente naquele ponto.

Pre-Requisitos

Para habilitar o Flashback log alguns pre-requisitos devem ser seguidos

  • Banco de dados deve estar em modo de archivelog.
  • Fast Recover Area deve estar habilitado.


Habilitando o Flashback

O Flash deve ser habilitado a nivel de CDB e pode ser feito on line conforme abaixo, é possivel habilitar tambem o flashback para uma tablesppace especifica ou remover o log de flashback para uma tablespace

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=1440;

ALTER DATABASE FLASHBACK ON;

Criando Restore Point

É possivel criar restore points, que são alias para um SCN, existem dois tipos de restore point, o "normal" e o guarantee, a diferença é que se a flash recover area estiver precisando de espaço os flash back com no guarantee são removidos para garantir a disponibilidade da base de dados.

O Restore point pode existir para o CDB ou para um especifico PDB, depende do escopo o qual o restore point foi criado, (12.2);

Para criar um restore point:

CREATE RESTORE POINT before_upgrade;

CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
        GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE, con_id
        FROM V$RESTORE_POINT;

Flashback CDB (12.1)

Na versão 12.1 somente é possivel fazer flashback a nivel de CDB, ou seja, todos os PDBs voltarão no ponto no tempo, somente a partir do 12.2 é possivel fazer flashback somente do PDB.

Há uma limitação em que não se pode fazer um flashback para um ponto anterior a qualquer PDB que tenha feito Point-in-time recover.

Para realizar então com o Flashback do CDB seguir com os passos abaixo:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
FLASHBACK DATABASE TO RESTORE POINT BEFORE_UPGRADE;
ALTER DATABASE OPEN RESETLOGS;
ALTER PLUGGABLE DATABASE ALL OPEN;

Referencia

https://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV582
https://docs.oracle.com/database/121/BRADV/rcmflash.htm#BRADV80055
https://oracle-base.com/articles/12c/multitenant-flashback-of-container-database-12cr1

Migrando Non-CDBs para CDBs Utilizando DBMS_PDB

Intodução


Este procedimento permite que seja criado um arquivo .xml, onde contém descritores de arquivos os quais serão utilizados para clonar a base de dados Non-CDB para um PDB dentro de um CDB existente, após o processo de clone finalizar é necessário executar o script noncdb_to_pdb.sql para remover linhas e objetos duplicados do dicionário de dados do PDB.

Este metodo considera que já existe um CDB de destino, como pre-requisito a origem e o destino devem estar na versão 12.1 >=  e com Character-set compativeis.

Migrando Oracle Non-CDB to CDB as a PDB

Passos


Colocar o banco de dados em um estado transicional consistente (bounce) e abrir como read only.

Shutdown immediate;
Startup Open read only;

Conectar no banco de dados de origem (non-cdb), e criar o descritor com a procedure dbms_pdb.describe

BEGIN
  DBMS_PDB.DESCRIBE(
    pdb_descr_file => '/tmp/db12c.xml');
END;
/

Utilizar a procedure dbms_pdb.check_plug_compatibility para validar a se a base Non-CDB é compativel com o CDB de destino

SET SERVEROUTPUT ON
DECLARE
  compatible CONSTANT VARCHAR2(3) := 
    CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
           pdb_descr_file => '/tmp/db12c.xml',
           pdb_name       => 'PDB_SP')
    WHEN TRUE THEN 'YES'
    ELSE 'NO'
END;
BEGIN
  DBMS_OUTPUT.PUT_LINE(compatible);
END;
/

Parar a base de dados de Origem (Non-CDB)

shutdown immediate;

Plugar a base de dados Non-CDB no CDB

CREATE PLUGGABLE DATABASE pdb_sp USING '/tmp/db12c.xml';

Executar o script noncdb_to_pdb.sql

ALTER SESSION SET CONTAINER=pdb_sp;

@?/rdbms/admin/noncdb_to_pdb.sql

Abrir o novo PDB

alter pluggable database pdb_sp open;


Referencia


MOS: How to Convert Non-CDB to PDB Database in 12c - Testcase (Doc ID 2012448.1)

Clonando PDB Remotos

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.

Basicamente na versão 12.1 existe 2 formas de provisionar copiar o PDB a partir de outro PDB ou plugar um PDB, neste post irei provisionar um PDB copiando os arquivos de um PDB remote, ou como a Oracle denomina um clone remoto:



Ambiente


Atributo Origem Destino
Hostname ol6-ora121-rac1 ol6-ora121-rac1
CDB CDBRJ CDBSP
PDB PDB_RIO PDB_RIO_COPY
File Location +DATA +DATA
Service PDB_RIO PDB_RIO_COPY
DB Link clone_pdb_rio

Ambos os CDB residem no mesmo servidor e estão registrados no mesmo listener, portanto obrigatóriamente é preciso tratar o nome do serviço, no caso irei renomear o PDB de PDB_RIO para PDB_RIO_COPY assim o servico criado não será o mesmo da origem.

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;
  • Tablespaces de usuarios comuns devem existentes na Origem também devem existir no destino
  • Ambos ambientes devem possuir o mesmo endian

Clonando um PDB Remoto


Para se clonar um PDB Remoto devemos seguir os seguintes passos abaixo, o CDB de destino irá se conectar no PDB de origem e irá copiar os arquivos para o destino.

  • O PDB Remoto deve estar em um estado transacional consistente e em read only.
  • Criar um dblink entre a origem, pode ser o PDB ou CDB, e o CDB de destino
  • Utilizar o comando "create pluggable database from"
  • Abrir o PDB


Exemplo


Origem

Na origem devemos fechar o pdb de forma consistente, deixa-lo me read only e criar um usuário que será utilizado pelo dblink remoto para clonar a base de dados.



SQL> show con_name;



CON_NAME

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

CDB$ROOT

SQL> 


SQL> select con_id, name, open_mode from v$containers where name='PDB_RIO';

    CON_ID NAME   OPEN_MODE
---------- ------------------------------ ----------
3 PDB_RIO   READ WRITE

SQL>

SQL> alter session set container=PDB_RIO;

Session altered.

SQL> show con_name;

CON_NAME
------------------------------
PDB_RIO
SQL> 


SQL> alter session set container=PDB_RIO;

Session altered.

SQL> show con_name;

CON_NAME
------------------------------
PDB_RIO
SQL> CREATE USER clone_user IDENTIFIED BY oracle;

User created.

SQL> GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE TO clone_user;

Grant succeeded.

SQL> shutdown immediate;

Pluggable Database closed.

SQL> alter database open read only;

Database altered.

SQL> 


Destino

No CDB que deverá receber o clone do PDB remoto devemos criar o DBLink apontando para a Origem, e por conta do parametro db_create_file_dest os arquivos do PDB serão criados pelo OMF, sem a necessidade de utilizar clausula de conversão.


TNS a Ser configurada

TNS_PDB_RIO =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = ol6-ora121-rac1)(PORT = 1521)))(CONNECT_DATA =(SERVICE_NAME = PDB_RIO)))



SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
CDBSP1

SQL> 

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT
SQL> 

SQL> CREATE DATABASE LINK link_pdb_rio CONNECT TO pdb_clone IDENTIFIED BY oracle USING 'TNS_PDB_RIO';

Database link created.

SQL> show parameter create_file

NAME      TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest      string +DATA

SQL> select CON_ID, NAME, OPEN_MODE from v$containers;

    CON_ID NAME   OPEN_MODE
---------- ------------------------------ ----------
1 CDB$ROOT   READ WRITE
2 PDB$SEED   READ ONLY

SQL> 

SQL> CREATE PLUGGABLE DATABASE pdb_rio_copy FROM pdb_rio@link_pdb_rio;

Pluggable database created.

SQL> alter pluggable database pdb_rio_copy open;

Pluggable database altered.

SQL> select CON_ID, NAME, OPEN_MODE from v$containers;

    CON_ID NAME   OPEN_MODE
---------- ------------------------------ ----------
1 CDB$ROOT   READ WRITE
2 PDB$SEED   READ ONLY
3 PDB_RIO_COPY   READ WRITE

SQL> 



Referencia



quinta-feira, 21 de dezembro de 2017

Criando e Configurando um CDB

Ambiente Utilizado

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


Servidoresol6-ora121-rac1ol6-ora121-rac2
Database NameCDBSPCDBSP
Instance NameCDBSP1CDBSP2
GI Version12.1.0.212.1.0.2
Source Version11.2.0.411.2.0.4
Dest Version12.1.0.212.1.0.2
ASM Comp12.1.0.0.012.1.0.0.0
ASM DG Comp10.1.0.0.010.1.0.0.0
DB Comp11.2.0.01.2.0.0
SO Red Hat 6.8Red Hat 6.8

Razões para se criar um CDB


O CDB (Container Database) é a base de toda arquitetura multitenant, a razão principal para se criar um novo CDB é a consolidação de bases de dados Oracle, entre as diversas vantagem em utilizar um CDB podemos citar a melhor utilização de recurso de maquina, redução de custo operacional e licença.

Ferramentas Para se criar um novo CDB


OUI - O OUI pode criar uma base de dados durante a instalação de um novo binário, o que no final das contas o OUI acaba utilizando o DBCA para criar o banco de dados.

DBCA - É a ferramenta mais indicada para criar uma nova base de dados, ela irá atualizar qualquer outro arquivo do sistema operacional de forma automatica, se chamada fora do OUI aumenta muito o leque de opções o que flexibiliza muito a criação da base de dados.

SQL*Plus - É a ferramenta que possibilita total controle da criação da base de dados, além de todos os recursos do DBCA, também é possivel instalar o minimo de componentes necessários para uma base de dados, porém requer mais esforço que o DBCA.


Considerações Antes de se criar um CDB


- CHARACTER_SET - O Character Set deve ser escolhido com muito cuidado pois o Character-set dos PDBs devem ser "Sub-Set" do CDB, ou seja compátiveis, portanto, a recomendação da Oracle é que seja utilizado unicode  como Character set do CDB.

- Componentes - Os componentes que podem ser utilizados em cada PDB também devem ser herdados do CDB, portanto na duvida considerar a lista de componentes mais abrangente possivel.

Sizing - No que diz respeito a parametrização e capacidade, pois os recursos são compartilhados entre todos os PDBs do CDB.

- Service Name - O Service Name utilizado para cada PDB deve ser unico dentro do Listener que é utilizado para ser registrado.

Criando um CDB através do DBCA

O DBCA é o metodo preferencial para se criar uma base de dados, houve algumas alterações e  melhorias entre o DBCA do 11g para o 12c, mas a diferença entre a criação de um banco Non-CDB e um banco de dados CDB esta na opção de selectionar o banco de dados como CDB ou Non-CDB durante a sua criação, claro que dependendo da resposta de leva a uma ou outra etapada.

Segue:


















Criando um CDB com SQL*Plus


A criação do CDB é muito mais prático e fácil através do DBCA, porém ele também pode ser criado através do SQLPlus, uma das razões para se criar o CDB pelo SQLPlus é que podemos ter um controle maior dos componentes que serão instalados, podemos instalar somente aqueles componentes os quais realmente serão utilizados. Pensando um pouco, não achei essa abordagem muito legal pois o objetivo do CDB é a consolidação e os PDBs somente terão os componentes que o CDB também possuir, portanto, até para os PDBs futuros, na minha visão seria legal ter todos os componentes instalados, já que não podemos prever o que pode acontecer no mundo coorporativo.

Há dois metodos possiveis para se criar um CDB

- Gerar os scripts através do DBCA, podendo edita-los para assim executa-los manualmente.
- Criar os scripts de forma manual e popular o dicionário de dados.

Não considerando o metodo do DBCA devemos então passar por todas as etapas manualmente, são elas:


  • Criar um pfile com as parametrizações necessárias.
  • Ajustar o sistema operacional
  • Criar o base dados com a instuação create database
  • Popular o dicionário de dados e instalar os componentes necessários


Criando o PFile inicial


Ao ser criado o arquivo de parametrização inicial para o CDB, obrigatóriamente deve ser habilitado o parametro ENABLE_PLUGGABLE_DATABASE para True, caso contrario a instrução de create database irá  finalizar com erros.

COMPATIBLE ='12.0.0'
DB_NAME='CDBRJ'
DB_UNIQUE_NAME='CDBRJ'
DB_DOMAIN=''
CONTROL_FILES='+DATA','+FRA'
DB_CREATE_FILE_DEST='+DATA'
DB_CREATE_ONLINE_LOG_DEST_1='+DATA'
DB_CREATE_ONLINE_LOG_DEST_2='+FRA'
DIAGNOSTIC_DEST=/u01/app/oracle
AUDIT_FILE_DEST="/u01/app/oracle/admin/cdbrj/adump"
ENABLE_PLUGGABLE_DATABASE=TRUE
DB_BLOCK_SIZE=8192
OPEN_CURSORS=300
PROCESSES=300
SGA_TARGET=1G
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=UNDOTBS01
PGA_AGGREGATE_TARGET=400M


Ajustar o sistema operacional

Deve ser ajustado qualquer parametrização de Sistema Operacional, variavel de ambientes, arquivos e diretórios antes de iniciar a instancia, como o DIAG_DEST e AUDIT_FILE_DEST, caso contrário irá ocorrer erros para iniciar a base de dados.


Criando a base de dados

Antes de iniciar a base de dados deve ser iniciada a instancia em modo de nomount:

SQL> startup nomount
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size     2932632 bytes
Variable Size   281018472 bytes
Database Buffers   784334848 bytes
Redo Buffers     5455872 bytes
SQL> 

Para ser criado o CDB a instrução a similiar a Non-CDB, o que muda é que devemos especificar que se trata de um pluggable database  com a instrução,  ENABLE PLUGGABLE DATABASE, além disso devemos controlar onde serão gerados os arquivos, para isso pode utilizar:

Parametros de instancia

db_create_file_dest - Se configurado não há a necessidade de controlar o caminho da criação dos arquivos durante o comando create database, utiliza-se OMF.

db_create_online_log_dest_n - Se configurado não é necessário controlar o caminho dos logs durante o create database, utiliza-se OMF.

pdb_file_name_convert - Novo parametro para 12c, especifica duas padrões, origem e destino, e converte o nome do caminho dos arquivos do SEED.

Instrução Create Database

SEED FILE_NAME_CONVERT - Controla a conversão dos nomes dos arquivos de origem para o destino

SEED SYSTEM DATAFILE - Controla os atributos da tablespace System

SEED SYSAUX DATAFILE - Controla os atributos da tablespace Sysaux

SEED USER_DATA TABLESPACE - Controla os atributos da default tablespace para usuário

Caso esses parametros sejam configurados no momento da criação da instancia eles seram replicados todas as vezes que um PDB for criado a partir do PDB$SEED.

Como estamos utilizando DB_CREATE_FILE_DEST e DB_CREATE_ONLINE_LOG_DEST_n, não é necessário tratar a conversão dos paths do arquivos do banco, será utilizado OMF.

CREATE DATABASE cdbrj
USER SYS IDENTIFIED BY ORACLE
USER SYSTEM IDENTIFIED BY ORACLE
LOGFILE GROUP 1
('+DATA','+FRA') SIZE 100M,
GROUP 2
('+DATA','+FRA') SIZE 100M
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 1024
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP
UNDO TABLESPACE UNDOTBS01
ENABLE PLUGGABLE DATABASE;


Popular o dicionário de dados

Para um ambiente Non-CDB para se popular o dicionário de dados bastava  executar uma unica vez os scripts como catproc.sql, catalog.sql, pupbld.sql, etc, porém para ambientes CDBs esses scripts devem ser executados em todos os PDBs, portanto a recomendação da Oracle é utilizar o catcdb.sql que popula todo o dicionário de dados, o unico problema do catcdb.sql é que ele instala componentes talvez indesejados, para contornar pode utilizar o utilitário catcon.pl e executar cada script individualmente em todos os containers necessários.

Segue portanto a sequencia necessária para se criar popular o dicionário de dados:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -u sys -d $ORACLE_HOME/rdbms/admin -b catalog_output -e -l /home/oracle catalog.sql
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -u sys -d $ORACLE_HOME/rdbms/admin -b catproc_output -e -l /home/oracle catproc.sql
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -u system -d $ORACLE_HOME/sqlplus/admin -b pupbld_output -e -l /home/oracle pupbld.sql
@?/rdbms/admin/utlrp.sql

Para referencia completa de como utilizar o catcon.pl 


Referencia

Melhor nota que achei a respeito de criação de CDB ToadWorld.com - Criando CDB

domingo, 17 de dezembro de 2017

Manual Upgrade Non-CDB Oracle Database para 12.1

Ambiente Utilizado

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

Servidoresol6-ora121-rac1ol6-ora121-rac2
Database Namesurtsurt
Instance Namesurt1surt2
GI Version12.1.0.212.1.0.2
Source Version11.2.0.411.2.0.4
Dest Version12.1.0.212.1.0.2
ASM Comp12.1.0.0.012.1.0.0.0
ASM DG Comp10.1.0.0.010.1.0.0.0
DB Comp11.2.0.01.2.0.0
SO Red Hat 6.8Red Hat 6.8


Principais Alterações 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:



 

Pre-requisitos


Upgrade Path


Validar quais "caminhos", são possiveis para realizar o upgrade para a versão 12.1, é importante seguir o patchset minimo para cada versão, a lista completa depende de uma série de fatores e deve ser buscada diretamente do fornecedor, a lista a seguir representa o patch minimo para a versão 12.1, pode ser validada a partir dos caminhos:

MOS: Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1) (Doc ID 1503653.1)



Validar a Matrix de Compatibilidade SO / Database


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)




Validar a Matrix de Compatibilidade Client / Database


Em um ambiente distribuido e importante garantir a inter conectividade entre as bases de dados e clientes nas diversas versões necessárias, utilizar a nota abaixo:

Client / Server Interoperability Support Matrix for Different Oracle Versions (Doc ID 207303.1)


Scripts de validação - Pre-upgrade


Como melhores praticas seguir com a validação da base de dados através da execução dos scripts abaixo, eles podem ser baixados do metalink direto, o que é recomendavel, pois estaremos utilizando a versão mais nova de cada documento.

Após a execução dos script de pre-upgrade seguir com as recomendações e ações necessárias para realizar o upgrade.

Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) (Doc ID 556610.1)
How to Download and Run Oracle's Database Pre-Upgrade Utility (Doc ID 884522.1)
hcheck.sql - Script to Check for Known Problems in Oracle8i, Oracle9i, Oracle10g, Oracle 11g and Oracle 12c (Doc ID 136697.1)

Após a execução dos scripts acima e qualquer correção apontada, seguir para o passo abaixo


Recomendações gerais


Abaixo estão os passos que eu considero importantes de serem executados e validados antes do upgrade, a lista completa pode ser encontrada em:

Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1) (Doc ID 1503653.1)
Oracle 12cr1 Upgrade Companion(Doc ID 1462240.1)
  • 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.

Executando o upgrade na base de dados

Após os passos acima serem executados, podemos prosseguir com o processo de upgrade, para ajudar no processo utilizei as notas abaixo:

MOS: Oracle 12cR1 Upgrade Companion (Doc ID 1462240.1)
MOS: Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1) (Doc ID 1503653.1)

A maior diferença no processo de upgade entre as versões pre-12c é que na versão 12c temos o novo script em perl catctl.pl que executa o script catupgrd.sql, o script aind pode ser executado como era feito antes, porém não é recomendado pela Oracle.

O script catctl.pl nos permite executar o script em parallel e a trabalhar com banco de dados em multitenant, oferencendo maior flexibilidade ao processo de upgrade. O utilitário DBUA faz uso do script catctl.pl.

Passo a Passo

  • Para banco de dados em Oracle RAC configurar o parametro cluster_database para false
  • Parar a base de dados
    • SQL> shutdown immediate;
  • Copiar arquivos de inicialização e senha dos home antigo para o home novo:
    • $ORACLE_HOME/dbs/init$ORACLE_SID.ora
    • $ORACLE_HOME/dbs/orapwd$ORACLE_SID
  • Ajustar scripts e variaveis de ambiente que apontem para o ORACLE_HOME antigo para o novo
    • /etc/oratab
  • Iniciar a base de dados em startup upgrade
    • Este processo permite que a instancia antiga inicie com um binário mais novo.
    • SQL> startup upgrade
  • Executar o script de upgrade
    • cd $ORACLE_HOME/rdbms/admin
    • $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
    • O Script permite algumas parametrizações como controle da saida de log, numero de processos em parallelo e excluir ou incluir um PDB durante o processo de upgrade, a lista pode ser encontrada em:
  • Revisar o log de upgrade procurando por erros
  • Abrir o banco de dados na nova versão
    • SQL> startup

Atividade Pós upgrade

Após a execução do script de atualização, seguir com as atividades de pós atulização conforme abaixo, alguns passos mais detalhados podem ser encontrados em:

MOS: Oracle 12cR1 Upgrade Companion (Doc ID 1462240.1)
MOS: Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1) (Doc ID 1503653.1)

  • Recompilar os objetos invalidos executando o script abaixo
    • $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql
  • Executar o script de post-upgrade gerado pelo passo de pre-ugrade utility
    • postupgrade_fixups.sql
  • Executar o script utlu121s.sql para validar que todos os problemas foram resolvido
    • SQL> @rdbms/admin/utlu121s.sql
  • Executar o script utluiobj.sql para validar que todas packages esperadas estejam validas
    • $ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utluiobj -d '''.''' utluiobj.sql
  • Executar o script de diagnostico e comparar o resultado com o diagnostico antes do upgrade
    • Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) (Doc ID 556610.1)
  • Executar um backup da base de dados
  • Coletar estatisticas do dicionário

Existem outras atividades que podem ser necessárias, mas devem ser avaliadas conforme o ambiente em questão.

Diogo Nomura