Standby Database Físico: Executado Roll Forward com backups incrementais através do RMAN

Por Joel Perez , Nassyam Basha (OCM) & Carlos H. Y. Furushima
Postado em Fevereiro 2015

Revisado por Marcelo Pivovar - Solution Architect

O que é Archive Gap?
É um intervalo onde houve ocorrência de falta de entradas de redo (missing redo) no standby database, gerando um dessincronizarão entre database primário e standby database, em decorrência disto o Apply Services (serviço de aplicação), no standby database está impedido de prosseguir com suas funções (aplicar entradas de redo geradas no database primário). Isso normalmente acontece quando o standby database é incapaz de receber as entradas de redo geradas no database primário ou as entradas de redo não estejam disponíveis standby database.

Os archivelogs criados neste intervalo pelo database primário devem ser aplicados no standby database, o número de archivelogs gerados (database primário) no momento da incapacidade de recebimento das entradas de redo até sua normalização, resulta em uma lacuna de transações que devem ser aplicadas (faltantes), essa resultante é chamada de GAP. Como não é possível prever o tempo de indisponibilidade de transmissão das entradas de redo, a retomada da sincronização deve ser feita usando os archivelogs gerados neste intervalo de indisponibilidade, devido ao fato dos redo logs serem cíclicos, sendo assim, é possível que ocorra uma sobrescrita de um redo log file sem que as entradas (entradas de redo) sejam enviadas para o standby database. Portanto, pode-se dizer que archive gap é o range de archivelogs criados pelo database primário, sempre que ocorre uma incapacidade de recebimento das entradas de redo entre database primário e standby database.

Algumas possíveis causas de Archive Gap são:

  • Indisponibilidade ou problemas de network bandwidth na infra-estrutura de rede entre database primário e standby database (Cabeamento estrutura entre database primário e standby database).
  • Serviço de transporte de redo (transport service) parado ou com erros de configuração (Apontamentos entre database primário e standby database).
  • Standby database em shutdown.
  • Problemas de I/O no standby database.
  • Corrupção de Archive Redo Data

 

 “WorkAround” para situações de Archive Gap:

  1. Se os archivelogs criados pelo database primário, que representam o archive gap, existirem no database primário e estiverem íntegros (não estiverem corrompidos), esses serão enviados e aplicados no standby database automaticamente (Não é necessário nenhuma ação manual).
  2. Se os archivelogs criados pelo database primário, que representam o archive gap, existirem no database primário em forma de backupset, ou seja, foram backupeados pelo RMAN ou movidos para outra unidade de backup, neste caso é necessário um ação manual de restore dos archivelogs cujo destino é o local onde os archivelogs são gerados.
  3. Backup Incremental através do RMAN, baseado no SCN.

 

Demonstrações técnicas: Resolução de Archive Gap

Ambiente


Versão do oracle database

Oracle Database 11g R1 - 11.1.0.7.0

Versão do Sistema Operacional

Oracle Linux 5 - x86_64

Database primário unique name

CPROD2

Standby database unique name

VPROD3

 

Erro no alert.log ao ocorrer um Archive Gap :

Figura 1 – Verificando Alert.log

 

Verificando geração de archivelogs no database primário para cada thread:

Figura 2. Verificando v$archived_log no database primário.

 

Verificando archivelogs aplicados no standby databasepara cada thread:

Figura 3. Verificando v$archived_log no standby database.

Perceba que existe uma lacuna de transações que devem ser aplicadas (Archive Gap) em ambas as threads, onde para thread 1 a diferença é de 1309 archives e para thread 2 é de 1924 archives. Provavelmente devido à perda de uma ou algumas sequências archivelog no database primário (Isso impossibilita de transferir aquele archivelogs, uma vez que este não exista mais).

Dimensão do Archive Gap em megabytes e gigabytes:

  • Thread #1 (50MB logfile * 1309 archives) = 65450MB  (63,91GB)
  • Thread #2 (50mb logfile * 1924 archives) = 96200MB (93,94GB)

 

Dimensão total do Archive Gap em megabytes e gigabytes (Soma dos archivelogs das thread):

  • Thread #1 (65450MB ou 63,91GB) + Thread #2 (96200MB ou 93,94GB)

65450MB + 96200MB = 161650MB (157,86GB)

MB: CENTO E SESSENTA E UM MIL, SEISCENTOS E CINQUENTA MEGABYTES (161650MB)
GB: CENTO E CINQUENTA E SETE GIGABYTES E OITENTA E SEIS MEGABYTES (157,86GB)

Visto a quantidade de archivelogs (3233 archivelogs) e sua volumetria dimensional é atrativo usarmos a opção 3 do WorkAround, um backup Incremental através do RMAN, baseado no SCN.

Primeiramente, iremos parar o processo MRP e comparar os SCN dos databases (primário e standby), para extrair o backup incremental através do RMAN.

Figura 4. Parando MRP process.

 

Database Primario :

Figura 5. Verificando SCN do database primário.

 

Standby Database :

Figura 6. Verificando SCN do standby database.

 

Para descobrir a diferença entre os SCN basta subtrairmos os valores do primário x standby :

  • SCN Diff = SCN Database Primário - SCN Standby database

SCN Diff = 8405028062 – 8276807480
SCN Diff = 128220582
Neste momento executaremos o backup incremental através do RMAN, este backup deve conter as modificações a partir do SCN 8276807480 até o SCN 8405028062, suprindo assim a diferença (GAP) e também o standby controlfile (current controlfile for standby).

1) From SCN 8276807480 até SCN 8405028062.
RMAN> backup incremental from scn 8276807480 database;

2) Backup do standby controlfile.
RMAN> backup current controlfile for standby;

Figura 7a. backup incremental.

 


Figura 7b. backup incremental.

O procedimento de restore/recover é uma tarefa que deve ser feita com atenção em steps (passo a passo) para evitar qualquer tipo de erros que possa culminar na preda do standby database. Por tanto seguiremos os steps abaixo com os devidos exemplos:

1. Modificar o status da instance do standby database para "NOMOUNT".
OBS.: Comando para modificar o status da instance do standby database para "NOMOUNT" é "startup nomount".

Figura 8.startup nomount.

 

2. Renomear ou remover o controlfile antigo do standby database (Para encontra-lo basta buscar o parametro de instance chamado control_files).
OBS.: Em caso de sistemas UNIX utilize o comando mv para mover ou rm para remover.

  • MOVENDO CONTROLFILE ANTIGO (RECOMENDADO)

mv /u01/app/oracle/oradata/VPROD3/control01.ctl /u01/app/oracle/oradata/VPROD3/control01.ctl_ANTIGO
mv /u01/app/oracle/oradata/VPROD3/control03.ctl /u01/app/oracle/oradata/VPROD3/control03.ctl_ANTIGO

  • REMOVENDO CONTROLFILE ANTIGO

rm/u01/app/oracle/oradata/VPROD3/control01.ctl /u01/app/oracle/oradata/VPROD3/control03.ctl

3. Restaurar o standby controlfile.
OBS.: No RMAN utilize o comando "restore standby controlfile from '/xyz/'" .

Figura 9. Restore standby controlfile.

 

4. Modificar o status da instance do standby database para "MOUNT".
OBS.: Comando para modificar o status da instance do standby database para "NOMOUNT" é "alter database mount standby database".

Figura 10. Instance em estado mount.

 

5. Catalogar o backup incremental feito e transferido do database primário.
OBS.: O backup incremental gerado no database primário foi transferido para  "/u01/app/oracle/oradata/backup/", portanto este diretório deve ser catalogado.

Figura 11. Catalogando backupset gerados de backup incremental.

 

6. No RMAN executar o recover do database para que ocorra a sincronização entre database primário e standby database.

Figura 12. Executando recover.

 

Você poderá acompanhar as instrumentações (logs) que são geradas no alert.log.

Figura 13. Log do recover no alert.log.

 

Após o sucesso do recover, iniciaremos novamente o processo MRP.

Figura 14. Iniciando processo MRP.

A execução do restore/recover, consome um fator natural, chamado tempo, sendo assim, outras atividades transacionais, estão ocorrendo no database primário (Você está executando o restore/recover no standby e usuários estão usando o banco de dados de produção - database primários), portanto um novo archive gap naturalmente é gerado.
OBS.: No database primário verificando a view v$archived_log, usando a função max() no campo sequence# - max(sequence#), veremos que a thread 1 está na sequência 65312 ao passo que antes do restore/recover ela estava na sequência 64998 (Ver imagem "Figura 2" neste artigos), ja na thread 2 a sequência é 54039 ao passo que antes do restore/recover ela estava na sequência 53502 (Ver imagem "Figura 2" neste artigos).

  • ANTES RESTORE/RECOVER

THREAD 1: 64998
THREAD 2: 53502

  • DEPOIS RESTORE/RECOVER

THREAD 1: 65312
THREAD 2: 54039

 

Após iniciado o processo MRP, o archive gap é resolvido automaticamente, conforme é visto no alert.log abaixo:


Figura 15. Log de resolução do archive gap no alert.log .

 

Terminado a aplicação dos archivelogs retroativos, validaremos a sincronização entre database primário x standby database.

Database Primário

 

Standby Database

GAPs

Esperamos que ele tenha sido útil para seguir com o  crescimento do seu conhecimento sobre as tecnologias Oracle.



Joel Pérez é um DBA Especialista (Oracle ACE Director, OCM Cloud Admin. & OCM11g ). Com mais de 14 anos de experiência do mundo Oracle Technology, especializado em arquitetura e implementação de soluções como: Cloud, Alta disponibilidade, Disaster/Recovery, Upgrades, replicação e todos as áreas relacionadas com bancos de dados Oracle. Consultor internacional com deveres, conferências e atividades em mais de 50 países e inúmeros clientes em todo o mundo. Palestrante regular nos eventos Oracle em todo o mundo como: OTN LAD, OTN MENA, OTN APAC e muito mais. Joel sempre foi conhecido por ser pioneiro em tecnologia Oracle desde os primeiros dias de sua carreira sendo o primeiro latino-americano premiado como "OTN Expert" no ano de 2003 pela Oracle Corporation, um dos primeiros "ACE Oracle" no Oracle ACE Program no ano de 2004, um dos primeiros OCP Database Cloud Administrator em todo o mundo no ano de 2013 e como um das maiores realizações profissionais em sua carreira, recentemente ele foi homenageado como o primeiro "OCM Database Cloud Administrator" do mundo.

Nassyam Basha é um DBA. É um OCM 11g, com experiência em tecnologias como Oracle Data Guard, RMAN, RAC. Ele já fez mais de 90 configurações do Data Guard em diferentes plataformas, de não-RAC RAC e vice-versa. Ele fez migrações bem-sucedidas com "switchovers" e "failovers" a vários bancos de dados de produção crítica. Ele participa ativamente de fóruns Oracle utilizando o usuário "CKPT" e ganhou mais de 10.000 pontos (nível guru). Publica regularmente artigos em seu blog www.oracle-ckpt.com e é co-autor do livro "Guia de Administração do Oracle Data Guard 11gR2".

Carlos H. Y. Furushima é um especialista em banco de dados relacional, trabalhando como consultor de TI, atuando principalmente como o Oracle Database Administrator (DBA Oracle). Tem uma vasta experiência e conhecimento em "Performance, diagnosticand tuning", "High Availability", "Backup & Recovery" e "Exadata". Ele também está entusiasmado com sistema operacional Linux/Unix, onde contribui com o desenvolvimento do código do kernel Linux em parceria com a comunidade "GNU Linux", com criação e revisão de novas funcionalidades, melhorias e correções de bugs. Recentemente, Furushima divide seu tempo com consultoria especializada em banco de dados Oracle e estudos sobre "Oracle Internals", com o objetivo de descobrir e entender os benefícios do bancos de dados Oracle em plataforma Linux/Unix.

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.