Artigo no estilo: Curso

Por que eu devo ler este artigo:Consolidação de bancos de dados tem sido a alternativa mais utilizada por várias empresas, dos mais variados segmentos e tamanhos.

A redução dos custos de TI tem sido o principal fator para esta adoção e a mais nova funcionalidade do Oracle em sua versão 12c está disponível justamente para oferecer o que há de melhor para alcançar este objetivo: a arquitetura multitenant. Neste artigo apresentaremos o processo de criação de um CDB e finalmente a migração do non-CDB para um PDB.

Esta discussão é útil em cenários onde a versão do Oracle já está na versão 12c porém fora da arquitetura multitenant e a adoção desta nova arquitetura permite, entre outros fatores, a consolidação de vários bancos em um único servidor totalmente otimizado.

Neste artigo será dada continuidade à série de forma totalmente prática. Serão vistas as etapas para consolidação de um primeiro banco de dados na nova arquitetura. Neste momento, já temos um banco na versão 12c, porém ainda non-CDB. Será mostrado agora o processo de convertê-lo em um PDB, ou seja: criação do CDB para em seguida efetuar a migração do non-CDB em PDB.

Esta é a metodologia mais comum para estes casos, pois para utilizar as funcionalidades desta nova arquitetura o banco de dados já precisa estar na nova versão.

Além disso, também é possível estar na versão 12c, porém fora da Arquitetura Multitenant. Perceba que utilizar esta nova arquitetura não é mandatório, mas sim uma boa solução para redução de custos e otimização de recursos na consolidação de bancos de dados que não necessitam de “exclusividade” na utilização dos recursos computacionais disponíveis.

Efetuando o backup

O Oracle RMAN (Recovery Manager) é um gerenciador de backup e recuperação fornecido para bancos de dados Oracle. Ele apresenta funcionalidades de backup, restauração e recuperação, abordando alta disponibilidade e recuperação de falhas em casos de desastres.

A Oracle recomenda o RMAN como seu método preferido para backup e recuperação e apresenta interface em modo de linha de comando e gráfica (via Oracle Enterprise Manager). Os projetistas do RMAN visam a integração com servidores de banco de dados Oracle, proporcionando detecção de corrupção no nível de bloco durante o backup e restauração. O RMAN otimiza o desempenho e consumo do espaço durante o backup através da multiplexação de arquivos e compressão de backup-sets.

Também se integra com o Oracle Secure Backup e com produtos de terceiros para gerenciamento de mídia para backup em fita. Com um sistema de sintaxe de vários comandos, permite que os administradores de banco de dados aperfeiçoem os métodos e o desempenho de backups e restaurações de dados.

Neste contexto, uma "recuperação completa" implica em restaurar todas as informações disponíveis de forma consistente ao ponto mais atual no tempo, enquanto uma "recuperação incompleta" permite especificar uma restauração em um determinado ponto do tempo no passado.

A Listagem 1 apresenta como devemos proceder para realizar o backup do banco non-CDB.

Listagem 1. Efetuando o backup do Banco de Dados non-CDB.

  01. [oracle@OEL6-64 backup]$ rman target /
  02.  
  03. Recovery Manager: Release 12.1.0.1.0 - Production on Thu Nov 20 12:34:42 2014
  04.  
  05. Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
  06.  
  07. connected to target database: SQL12C (DBID=3124618022)
  08.  
  09. RMAN> crosscheck archivelog all;
  10.  
  11. using target database control file instead of recovery catalog
  12. allocated channel: ORA_DISK_1
  13. channel ORA_DISK_1: SID=20 device type=DISK
  14. specification does not match any archived log in the repository
  15.  
  16. RMAN>  backup database format '/oracle/backup/SQL12C_hotfull_%U';
  17.  
  18. Starting backup at 20-NOV-14
  19. using channel ORA_DISK_1
  20. channel ORA_DISK_1: starting full datafile backup set
  21. channel ORA_DISK_1: specifying datafile(s) in backup set
  22. input datafile file number=00001 name=/oracle/oradata/SQL12c/system01.dbf
  23. input datafile file number=00003 name=/oracle/oradata/SQL12c/sysaux01.dbf
  24. input datafile file number=00002 name=/oracle/oradata/SQL12c/example01.dbf
  25. input datafile file number=00004 name=/oracle/oradata/SQL12c/undotbs01.dbf
  26. input datafile file number=00006 name=/oracle/oradata/SQL12c/users01.dbf
  27. channel ORA_DISK_1: starting piece 1 at 20-NOV-14
  28. channel ORA_DISK_1: finished piece 1 at 20-NOV-14
  29. piece handle=/oracle/backup/SQL12C_hotfull_05po36jn_1_1 tag=TAG20141120T123503 comment=NONE
  30. channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
  31. channel ORA_DISK_1: starting full datafile backup set
  32. channel ORA_DISK_1: specifying datafile(s) in backup set
  33. including current control file in backup set
  34. including current SPFILE in backup set
  35. channel ORA_DISK_1: starting piece 1 at 20-NOV-14
  36. channel ORA_DISK_1: finished piece 1 at 20-NOV-14
  37. piece handle=/oracle/backup/SQL12C_hotfull_06po36m2_1_1 tag=TAG20141120T123503 comment=NONE
  38. channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
  39. Finished backup at 20-NOV-14
  40.  
  41. RMAN> exit
  42.  
  43.  
  44. Recovery Manager complete.

Primeiramente iniciou-se o utilitário RMAN utilizando o próprio control file do banco de dados como catálogo (perceba que não há o parâmetro catalog na chamada do utilitário). Isso porque não estamos utilizando um banco de dados centralizado que armazene o catálogo de todos os bancos que se deseje efetuar o backup, como seria o caso de um servidor exclusivo de backup.

Então efetuou-se uma verificação dos archived redo log files para que os mesmos fossem registrados/conferidos com o “catálogo” (o control file, neste caso), como mostra a linha 09. Esta etapa é importante pois, caso não seja feita, o RMAN retornará erro ao tentar copiar arquivos que já não estão mais presentes e são desnecessários.

Feito isto, iniciou-se a execução do backup. Foi necessária a definição da localização dos arquivos gerados (linha 17). Perceba que o backup foi executado com sucesso (linha 39).

Criando o CDB (Container Database)

Conforme apresentado no artigo passado, para utilizar a arquitetura Multitenant é necessário que haja um Container Database.

É possível criar o CDB de duas formas: 1) através do utilitário DBCA (Database Configuration Assistant – Assistente de Configuração de Banco de Dados) ou 2) através de linha de comando utilizando a instrução CREATE DATABASE. Vale lembrar que em muitos casos o ambiente gráfico não está sequer instalado no servidor de banco de dados, portanto será abordado aqui o processo manual, ou seja, através do CREATE DATABASE.

A partir da versão 12c do Oracle é necessário definir o parâmetro ENABLE_PLUGGABLE_DATABASE =TRUE para criar um CDB. Este parâmetro permite ao banco de dados, ainda em estado NOMOUNT, “entender” que o banco será criado como um CDB. Vale lembrar que um CDB pode acomodar até 252 PDBs (Pluggable Databases) e que o parâmetro ENABLE_PLUGGABLE_DATABASE deve ser definido no arquivo de parâmetros de inicialização (o pfile ou, como mais conhecido, arquivo init.ora). O valor padrão para este parâmetro é FALSE, mas há rumores de que isso pode mudar nas versões mais novas.

Para criar o CDB manualmente há, basicamente, três etapas:

1. Criar/atualizar o arquivo de parâmetros de inicialização (pfile);

2. Executar o comando CREATE DATABASE;

3. Executar o script @?/rdbms/admin/catcdb.sql.

Corrigindo o bug 17033183

No entanto, ao verificar todas as condições do ambiente antes de iniciar a criação, você pode se deparar com um bug devidamente documentado. Na versão 12.1.0.1.0 o arquivo catcdb.sql não foi disponibilizado junto com a mídia de instalação.

Este problema já está documentado como “Bug 17033183 : MISSING FILE CATCDB.SQL IN $ORACLE_HOME/RDBMS/ADMIN” e sua resolução se encontra na nota do My Oracle Support “Doc ID 1575778.1”. A Oracle disponibilizou um patch de correção, portanto esta é a primeira ação a ser tomada caso esteja na mesma situação. Vale ressaltar que tal problema não acontece caso utilize o DBCA.

A Listagem 2 apresenta a execução do opatch para aplicar o patch recomendado.

Listagem 2. Execução do opatch para correção do bug 17033183.

  01. [oracle@OEL6-64 ~]$ cd 17316776
  02. [oracle@OEL6-64 17316776]$ /oracle/rdbms/12.1.0/OPatch/opatch apply
  03. Oracle Interim Patch Installer version 12.1.0.1.0
  04. Copyright (c) 2012, Oracle Corporation.  All rights reserved.
  05.  
  06.  
  07. Oracle Home       : /oracle/rdbms/12.1.0
  08. Central Inventory : /oracle/oraInventory
  09.    from           : /oracle/rdbms/12.1.0/oraInst.loc
  10. OPatch version    : 12.1.0.1.0
  11. OUI version       : 12.1.0.1.0
  12. Log file location : /oracle/rdbms/12.1.0/cfgtoollogs/opatch/17316776_Nov_20_2014_11_36_07/apply2014-11-20_11-36-07AM_1.log
  13.  
  14. Applying interim patch '17316776' to OH '/oracle/rdbms/12.1.0'
  15. Verifying environment and performing prerequisite checks...
  16. All checks passed.
  17. Backing up files...
  18.  
  19. Patching component oracle.rdbms.dbscripts, 12.1.0.1.0...
  20.  
  21. Verifying the update...
  22. Patch 17316776 successfully applied
  23. Log file location: /oracle/rdbms/12.1.0/cfgtoollogs/opatch/17316776_Nov_20_2014_11_36_07/apply2014-11-20_11-36-07AM_1.log
  24.  
  25. OPatch succeeded.

Após efetuar o download do patch diretamente no portal My Oracle Support, será descompactado o arquivo .zip e o mesmo criou um diretório com o número do bug. Deve-se acessar o diretório e executar o utilitário opatch (linha 02). Após a conclusão da execução o arquivo necessário para a criação do CDB já se encontra no local desejado.

A descompressão é necessária pois a Oracle compacta o arquivo para diminuir o tráfego de rede e tornar o download mais rápido. Em seguida, é necessário executar o script do patch para corrigir o problema em questão.

Criando o pfile

A primeira etapa é a criação do arquivo de parâmetros de inicialização e os diretórios necessários. A Listagem 3 apresenta a criação dos diretórios administrativos enquanto que a Listagem 4 mostra a criação do pfile.

Listagem 3. Criação da estrutura de diretórios.

  01. [oracle@OEL6-64 ~]$ cd /oracle
  02. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/admin/SQLCDB/adump
  03. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/admin/SQLCDB/dpdump
  04. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/admin/SQLCDB/pfile
  05. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/audit
  06. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/fast_recovery_area/SQLCDB
  07. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/oradata/SQLCDB
  08. [oracle@OEL6-64 oracle]$ mkdir -p /oracle/oradata/SQLCDB/pdbseed

Deve-se entrar no diretório que serão utilizados como base ($ORACLE_BASE) e então começa-se a criar os diretórios.

Criou-se o diretório para armazenar os arquivos de auditoria do bando de dados (linha 02) e depois criou-se o diretório padrão para operações do utilitário Data Pump (linha 03). Na linha 4 criou-se o diretório onde o pfile será armazenado.

O diretório que armazenará os arquivos de log de auditoria foi criado na linha 5. Criou-se também o diretório para a área de recuperação rápida (linha 6) e o diretório onde serão armazenados os arquivos de dados (data files) (linha 7). Por último, criou-se o diretório onde serão armazenados os data files do PDB semente (seed) (linha 8). Todos estes diretórios devem ser criados para que o bando de dados armazene seus arquivos de administração. Caso estes diretórios não sejam criados o processo de criação do banco falhará.

Já na Listagem 4, perceba que se tem um arquivo de parâmetros de inicialização como qualquer outro, com a única diferença do parâmetro enable_pluggable_database definido como true (linha 10). Este novo parâmetro irá permitir que este banco possua PDBs.

Listagem 4. Conteúdo do arquivo de parâmetros de inicialização (pfile).

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo