A técnica de DUPLICATE pode ser executada de diferentes modos, cabendo ao DBA decidir-se pelo modo mais adequado, levando em conta o cenário em que está contido. Neste exemplo, demonstraremos o modo “Active Database Duplication”. O Active Database Duplication é um modo de executar um duplicate database, onde não é necessário haver um backup prévio (Backup RMAN existente) para execução da tarefa, assim o RMAN duplica os database files localizado em um host origem (SOURCE HOST), diretamente de qualquer database em estado OPEN ou MOUNT, transferindo suas “image copie” ou “backup set” gerados no momento da execução da tarefa para o host destino (AUXILIARY HOST), onde serão usados para construir o database duplicado.

Antes de iniciar o passo a passo para execução do “Active Database Duplication” é importante estarmos familiarizados com as nomenclaturas dos diversos componentes envolvidas no processo de duplicate.

Source Host: Maquina origem onde portam os database files que serão duplicados.

Auxiliary Host: Maquina destino que receberá os database files do Source Host.

Source Database Instance: Instance origem no processo de duplicate (Está localizada no Source Host e pertence ao Source Database)

Auxiliary Database Instance: Instance destino no processo de duplicate (Está localizada no Auxiliary Host e pertence ao Auxiliary Database)

Source Database: Database que será duplicado (Database Origem).

Auxiliary Database: Clone do Source Database (Database Duplicado).

Passo a passo para execução do “Active Database Duplication”
Considere o cenário abaixo:

Passo 1) Preparação do ambiente para executar “Active Database Duplication”

  • Configuração da Auxiliary Database Instance.

OBS.: Em um cenário de “Active Database Duplication”, um banco de dados está sendo duplicado, o produto final desta duplicação é um clone do database target (Source Database), com isso é possível deduzir que o database target (Source Database) já existe e está funcional.

A database instance é uma estrutura de memória criada a partir de um dos arquivos de parâmetros (parameter file) pfile ou spfile, essa estrutura é responsável pelo gerenciamento dos database files. O arquivo de parâmetros (parameter file) traz consigo uma série de importantes informações tais como localização do controlfile (control_files), destino dos arquivos de auditoria (audit_file_dest) e FRA (db_recovery_file_dest), esses parâmetros possuem como valor caminho de diretórios, essas estruturas devem ser criadas no Auxiliary Host, bem como, todos os diretórios continhos em ADR BASE e ADR HOME ($ADR_BASE/diag/rdbms/{DB-name}/{SID}/). Obviamente, a mudança de nomenclatura de algum diretório pertencente a esta estrutura é uma opção do DBA, sendo condicionado pela alteração do valor dos parâmetros do parameter file (arquivo de parâmetros) e o nome do database instance (ORACLE_SID).

OBS.: Para verificar a estrutura de diretórios do ADR, basta consultar a view V$DIAG_INFO.

É necessários transferir um dos arquivos de parâmetros (parameter file), localizado no Source Host referente a Source Database Instance para o Auxiliary Host referente a Auxiliary Database Instance, nesta etapa, estamos condicionando o Oracle para que seja capaz de criar a estrutura de memória (database instance) responsável pelo gerencialmente dos database files.

Uma vez que o pfile esteja em $ORACLE_HOME/dbs no Auxiliary Host é necessário ajusta-lo, com o intuito organizacional, modificando a nomenclatura da estrutura de diretórios, substituindo o nível, cuja string é CDB1 por STBY.

Parâmetros alterados no PFILE
Ajustando estrutura de diretório do parâmetro audit_file_dest com a nomenclatura referente ao SID do Auxiliary Database

Ajustando estrutura de diretório onde estará o controlfile com a nomenclatura referente ao SID do Auxiliary Database

Ajustando estrutura de diretório onde estará a FRA com a nomenclatura referente ao SID do Auxiliary Database

Depois de ajustado é imprescindível que esses diretórios existam no filesystem, portanto é necessário cria-los.

OBS.: É impreterível que todos os diretórios referenciados no pfile esteja criados.

Conforme descrito anteriormente, a database instance é uma estrutura de memória para gerenciar o database, portanto também se faz necessários a criação da estrutura de diretórios para os datafiles, seguindo o mesmo intuito organizacional, a nomenclatura da estrutura de diretórios, também será substituída no nível, cuja string é CDB1 por STBY. Faremos o levantamento dessa estrutura (diretórios), consultando o campo NAME da view V$DATAFILE.

Criação da estrutura de diretório onde estarão os datafiles.

O duplicate irá depositar os datafiles nos mesmos lugares em que originalmente estão, uma vez que, a localização dos datafiles estão catalogados no controlfile, que por sua vez é um dos protagonistas em uma operação de restore. Na execução do duplicate, veremos nas logs geradas, que esta operação nada mais é que um restore/recover completo do banco de dados de forma automatizada em uma única operação. Com o intuito organizacional, iremos mudar a nomenclatura da estrutura de diretórios, trocando CDB1 por STBY, para tanto, utilizaremos dois parâmetros, db_file_name_convert e log_file_name_convert, que deve ser incluídos no pfile localizado no Auxiliary host (Lembre-se que após incluído é necessário um shutdown/startup na instance).

A versão ajustada do pfile é descrito abaixo:

Para finalizar a criação de todas as estruturas de diretórios, criaremos a estrutura de ADR (Automatic Diagnostics Repository).

  • Configuração de conectividade entre Source x Auxiliary.

O procedimento de “Active Database Duplication”, inclui a conectividade entre Source Database Instance e Auxiliary Database Instance, uma vez que o RMAN necessita de uma integração entre as instance para executar o processo de clonagem de forma automatizada do database. É mandatório que a Auxiliary Database Instance esteja em estado nomount (status STARTED na view V$INSTANCE) quando o “Active Database Duplication” iniciar, por esta razão é necessário uma registo de serviço estático no listener (Static Service Registration), possibilitando um logon remoto com a instance em qualquer estado (DOWN, NOMOUNT, MOUNT ou OPEN).
Veja abaixo, o conteúdo do arquivo $ORACLE_HOME/network/admin/listener.ora e sua respectiva string de conexão (Entrada no TNSNAMES.ORA), o serviço estático no listener (Static Service Registration) é representado pela(as) entrada(as) em SID_LIST_LISTENER.

Source Host
$ORACLE_HOME/network/admin/listener.ora

$ORACLE_HOME/network/admin/tnsnames.ora

Auxiliary Host
$ORACLE_HOME/network/admin/listener.ora

$ORACLE_HOME/network/admin/tnsnames.ora

Finalizado a configuração de conectividade, é necessário ajustar a autenticação do acesso remoto entre Source Database Instance e Auxiliary Database Instance, ou seja, fazer com que o RMAN se conecte com a string de conexão DB_SOURCE e DB_AUXILIARY, que deveram estar no TNSNAMES.ORA de ambos os host (SOURCE e AUXILIARY), para tanto é necessário que os arquivo de senha (Password File) estejam criados em ambos os hosts, utilizando a mesma senha para o usuário sys (Utilizaremos o usuário sys para executar o duplicate).

Para criar o arquivo de senha (Password File), utilize o comando abaixo:

EXEMPLO:

IMPORTANTE: Este arquivo gerado pelo utilitário orapwd deve existir em ambos os hosts e deve conter a mesma senha. Portanto utilize o mesmo comando para criar o password file.

No Source Database é possível validar a compatibilidade da senha, cruzando informações da tabela no dicionário de dados sys.user$ e o arquivo $ORACLE_HOME/dbs/orapw, veja abaixo:

Validaremos a conectividade entre as database instance (SOURCE e AUXILIARY) utilizando as string de conexão publicada em $ORACLE_HOME/network/admin/tnsnames.ora .

TESTE DE CONECTIVIDADE NO SOURCE DATABASE

TESTE DE CONECTIVIDADE NO AUXILIARY DATABASE

  • Validação de conectividade no RMAN

Uma operação de “Active Database Duplication” é feita via RMAN, envolvendo um target, que representa o Source Database e um auxiliary, que representa o auxiliary database. É importante ressaltar que esta operação não envolve um catalogo do RMAN, caso exista, somente o target.
Para validar execute o comando abaixo:

TESTE DE CONECTIVIDADE NO SOURCE DATABASE

TESTE DE CONECTIVIDADE NO AUXILIARY DATABASE

Passo 2) Execução do “Active Database Duplication”

A partir do Oracle Database 12c, é possível optar por dois diferentes métodos de realizar o Active Database Duplication, são eles:

  • Push-based Method: O database duplication é realizado usando “image copie”, onde o source database transfere os database files para o auxiliary, que são necessários para clonagem. É importante ressaltar que o target channel fazem a maior parte do trabalho, neste métodos, ou seja, ocorre maior degradação do desempenho no target database. Este é o tradicional e único método utilizado nas versões pre-12c.
  • Pull-based Method: O database duplication é realizado usando “backup set”, permitindo assim o uso de compressão, com isso é reduzido volume de dados o trafegados via rede (transferência dos backupset para o Auxiliary host), a transferência do backup set é feita através do Oracle Net Service. É importante ressaltar que a auxiliary channel fazem a maior parte do trabalho, evitando assim uma degradação do desempenho no target database.  Este novo método foi introduzido no oracle 12c.

Importantes considerações antes de iniciar o duplicate

  • Active Database Duplicate não envolve catalogo do RMAN (Somente target).
  • Senha do password file criadas via orapwd, deve ser iguais em ambos os hosts.
  • O DB_NAME de ambos os database devem ser o mesmo ao executar o duplicate.

 

 

Executando Active Duplicate utilizando Push-based Method

Executando Active Duplicate utilizando Pull-based Method

É importante ressaltar que o produto final da operação de active database duplicate, é um database duplicado, ou seja, não é produzido um banco de dados idêntico ao source database, obviamente isso pode gerar uma certa confusão, uma vez que em muitas oportunidade referimos essa operação como clonagem, contudo, perceba que em um certo momento da operação, o controlfile é recriado, provocando assim uma alteração no DBID.

Essa troca é necessária em caso de utilização de um catalogo de recuperação do RMAN, não é possível registrar dois databases com um mesmo DBID. Caso o intuito do duplicate seja criar um standby database, obviamente o DBID não seria alterado, não existindo a recriação do controlfile.