Oracle Database 12c – Resolução de Redo Gap (Part I)

Por Joel Perez , Mahir M. Quluzade (OCP) & Carlos H. Y. Furushima , Postado em Novembro 2014

Revisado por Marcelo Pivovar - Solution Architect

Neste artigo vamos discutir Redo Gap em configurações do Oracle Data Guard e alguns métodos de resolução; também, demonstraremos resolução com RMAN usando uma new feature de banco de dados Oracle Database 12c (12.1.0.1) – (Restore/Recover files over the network).

Visão geral sobre Oracle Data Guard Oracle Data Guard garante alta disponibilidade (high availability), proteção de dados (data protection) e disaster recovery para o database primário (banco de dados de produção). O Data Guard prove um conjunto abrangente de serviços para criar, manter, gerenciar e monitorar um ou mais standby databases com o intuito de garantir que um database primario (primary database) sobreviva a desastres e corrupção de dados (data corruptions). Um Standby Database é cópia fiel (clone) do database primário (primary database).  Então, se o database primário (primary database) ficar indisponível o Data Guard pode executar "switch" para que um standby database se torne um database primário (primary database).

Configurar o Oracle Data Guard consiste em disponibilizar um database que terá um papel central ou principal (database primário - primary database - hot database) e um ou mais databases (até 30 database) que terá um papel secundário ou coadjuvante, que é denominado pela Oracle como standby database (Physical, Logical ou Snapshot). Redo Transport Service transmite entradas de redo (Redo Records - Redo Data) do database primario (primary database) para o standby database ou transporte via configuração FAR SYNC instance. As entradas de redo (Redo Records - Redo Data) do database primario (primary database) são trasmitidas de modo a serem escritas no redo log do standby database (standby redo log) ou via FAR SYNC instance. Apply Services promove a aplicação das entradas de redo no standby database, essas entradas de redo são oriundas do database primario e são executadas de forma automatica, o objetivo deste mecanismo é manter a sincronização entre database primario (primary database) e standby database, entende-se por sincronização a manutenção dos dados transacionalmente consistente. Apply Services utiliza-se dos metodos "Redo Apply" em standby físicos (uso de media recovery para sincronização) e "SQL Apply" em standby lógicos (Reconstrução da instrução SQL apartir das entradas de redo e posteriormente serem aplicadas no standby database). Role transition é responsavel em conduzir o processo de trasição entre database primário para standby database na configuração do Data Guard.

É possivel gerenciar o database primario e o standby databases usando o SQLPLUS (SQL Command–Line) ou o prompt de linha de comando "Oracle Data Guard Broker Manager", o Broker Manager prove uma interface de linha de comando (DGMGRL) e tambem uma interface gráfica que está integrada no Oracle Enterprise Manager Cloud Control.

Redo Transport Modes

O destino das entradas de redo geradas no database primario deve ser o standby database ou FAR SYNC instance. O "Redo Transport Destination" (standby database ou FAR SYNC instance) é configurado para receber entradas de redo através de um dos dois modos de transportar redo : synchronous (SYNC) ou asynchronous (ASYNC).

  • Synchronous (SYNC)

O modo sincrono (SYNC) de transporte de redo (SYNC redo transport mode) transmite as alterações transacionais geradas no database primario para o standby database sincronicamente em função da operação de commit. Uma transação não pode ser conformada (executar commit) no database primario ate que todas as entradas de redo geradas por esta transação sejam enviadas com sucesso para o(s) standby database(s) que usam o modo síncrono (SYNC) de transporte de redo (synchronous redo transport mode) .

Importante: Não há limite na distância entre um database primário e um destino SYNC redo (standby database), contudo é natural que uma operação de commit é degrada, a medida que a latencia de rede aumente entre database primário e standby database (Site Prod e Site DR).

  • Asynchronous (ASYNC)

O modo assincrono (ASYNC) de transporte de redo (ASYNC redo transport mode) transmite as alterações transacionais geradas no database primario para o standby database de forma assíncrona. A transação pode ser conformada (executar commit) no database primario sem a necessidade de esperar que todas as entradas de redo que foram geradas, sejam enviadas com sucesso para o(s) standby database(s).

Apply Services

Apply Services proporciona um mecanismo automatizado de aplicação das entradas de redo no standby database, o intuito deste serviço é manter e garantir uma sincronização transacionalmente consistente entre database primario e standby database.

Redo Apply em Standby Database Físico (Physical standby database):

Redo apply é basicamente uma replica física bloco por bloco de um database primario, onde, uma "media recovery" gerada no database primario é lida pelo redo apply, que lê do Standby Redo Logs (SRL) para memória (Standby Redo log Buffer) e aplica os "change vectors" (Vetores de mudança localizados no Redo Records) diretamente para o standby database.

Importante: O sufixo "USING CURRENT LOGFILE" para execução de Real-Time Apply (Aplicação em tempo real) esta obsoleto no Oracle Database 12c (12.1). Você pode usar a sintaxe abaixo para iniciar o Real-Time Apply :


  
SQL> ALTER DATABASE RECOVER MANAGED  STANDBY DATABASE DISCONNECT FROM SESSION;

SQL Apply em Standby Database Lógico (Logical standby database):

SQL Apply usa o processo "logical standby" (LSP - Logical Standby Process) para coordenar aplicações de mudanças em um standby database. Os processos que compõem SQL Apply, lê a estrutura SRL (Standby Redo Logs) convertendo as entradas de redo (redo records) em "logical change records", para construir as transações SQL que posteriormente serão aplicadas no Standby Database.

Active Data Guard É possível abrir em read-only um standby database físico (physical standby database), enquanto o "apply service" estiver executando, essa funcionalidade foi introduzida no Oracle 11g, com o nome de Active Data Guard. O Active Data Guard soluciona em tempo de execução, possiveis problemas de consistência em leituras (em release anteriores era comum problemas de consistencia de dados em uma extração de relatorios em standby database), para utilizar essa funcionalidade é necessarios abrir o banco de dados com a opção "READ ONLY WITH APPLY". Abrir o standby database em modo read-only é util caso seja necessario extrair um relatorio com grande massa de dados ou ad-hoc queries (Query esporádicas - Ciclos não projetados). O Active Data Guard ativo, auxilia na prevenção de corrupção dos dados, ou seja, caso seja identificado um bloco fisico corrompido este é reparado automaticamente onde quer que esteja (seja no database primario ou no standby database), isso evita a interrupção do serviço ou intervenção manual do DBA.

Importante: Active Data Guard é uma option licenciada para Oracle Database 12c Enterprise Edition.

O que é Redo Gap? Esta situação de redo gap ocorre sempre que uma transmissão de redo é interrompida, ou seja, em uma situação de gap de log file, significa que um database primário está executando commit em transações, enquanto o processo LNS (LNS process), parou a transmissão de redo para o standby database, essa situação pode ocorrer quando a infra-estrutura de rede ou o standby database está indisponível (down - fora - sem conectividade) e o modo de proteção do Data Guard (Data Guard protection mode) não é "Maximum Protection" (proteção máxima).

Resolução automatica de Redo Gap (Automatic Redo Gap Resolution) O processo LGWR (LGWR process) continua sua atividade de escrita das transações para o ORL (Online Redo Log Files), o processo ARCH (ARCH process) arquiva o log file corrente (ORL current) quando um log file sofre switch ou quando o log file está completo (full filled). Essa sinergia de funcionamento do mecanismo de redo, acontece repetidas vezes, para garantir a integridade de um banco de dados em caso de crash, em uma situação de interrupção de transmissão de redo, seja por problemas de infra-estrutura de rede ou por indisponibilidade do standby database, é originado um gap de sincronização, o standby database está em uma posição sequencial x e o database primário está em outra posição sequencial x + n, onde o fator n é a lacuna (GAP) provocada pela interrupção da sincronização entre database primário e standby database. Neste caso, o processo ARCH (ARCH process) do database primário, executa um ping contínuo em direção ao standby database, afim de verificar, se a comunicação entre os databases (primário e standby) foi reestabelecida. Em caso de reestabelecimento da conectividade entre os databases (primário e standby), o mecanismo de resolução do gap, iniciará com o processo ARCH (ARCH process) determinando qual foi o último log file aplicado, essa verificação é feita a partir do standby controlfile via processo RFS (RFS process do standby database) e por fim é necessário enviar os archivelogs necessários para resolver o gap, para que a posição sequencial dos logs tendam a igualdade entre os databases (primário e standby). Concomitantemente o processo LNS (LNS process) voltará a enviar as entradas de redo localizada no redo log buffer (SGA) do database primário para o SRL (Standby Redo Logs) no standby database. A figura 1 (Automatic Gap Resolution), esboça o mecanismo de resolução automática de Redo Gap (Automatic Redo Gap Resolution).

Automatic Gap Resolution

Importante: O processo RFS (RFS process) do standby database do standby database pode receber entradas de redo do processo LNS e archivelog do processo ARCH do database primário. Redo transport services has two options that may reduce redo gap resolution time when low performance network links are used:

Redo Transport Compression (Transporte de redo usando tecnica de compressão) O atributo COMPRESSION do parâmetro LOG_ARCHIVE_DEST_n é usado para especificar que as entradas de redo devem ser compactadas antes de serem transmitidas para o standby database.

Parallel Redo Transport Network Sessions (Paralelismo de sessão no transporte de redo) O atributo MAX_CONNECTIONS do parâmetro LOG_ARCHIVE_DEST_n é usado para especificar que mais de um processo "network session" pode ser usada para envio de entradas de redo, para resolver redo gap.

Demonstração Adiante, demonstraremos neste artigo algumas situações. Em todas as demonstrações usaremos o mesmo ambiente, cujas características são descritas abaixo:

Versão do database primário

Oracle Database 12c (12.1.0.1)

Versão do Standby database

Oracle Database 12c (12.1.0.1)

Sistema Operacional (Database primário) / Hostname

Oracle Linux Server 6.2 (x86 64-bit) / oel62-prmdb-12c

Sistema Operacional (Standby database) / Hostname

Oracle Linux Server 6.2 (x86 64-bit) / oel62-stbdb-12c

Database primáriounique name

prmcdb

Standby database unique name

stbcdb

É CDB? (Oracle Multitenant)

Sim; Database primário e Standby database são um Container databases.

Introdução a bancos de dados:

Database primário:  


  
[oracle@oel62-prmdb-12c ~]$ export  ORACLE_SID=prmcdb
[oracle@oel62-prmdb-12c ~]$ sqlplus / as  sysdba
SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 15:07:07 2014
   Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced Analytics  and Real Application Testing options
SQL> select cdb, name, database_role,  log_mode from v$database;
CDB   NAME      DATABASE_ROLE    LOG_MODE
----- --------- ---------------- -------------
YES   PRMCDB    PRIMARY          ARCHIVELOG
SQL> alter system switch logfile;
System altered.
SQL> select max(sequence#) from  v$archived_log;
MAX(SEQUENCE#)
-------------------------
254

Standby Database Físico (Physical standby database):


  
[oracle@oel62-stbdb-12c ~]$ export ORACLE_SID=stbcdb
[oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba
SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 15:07:26 2014
   Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options

SQL> select cdb, db_unique_name,  database_role, open_mode from v$database;

CDB    DB_UNIQUE_NAME     DATABASE_ROLE         OPEN_MODE
------ -----------------  --------------------  --------------------
YES    stbcdb             PHYSICAL STANDBY      MOUNTED

SQL> select process from  v$managed_standby;

PROCESS
---------
 ARCH
 ARCH
 ARCH
 ARCH
 RFS
 RFS
 MRP0
 RFS
   
8 rows selected.

SQL> select max(sequence#) from  v$archived_log;

MAX(SEQUENCE#)
-------------
254

SQL> select max(sequence#) from  v$archived_log where applied='YES';

MAX(SEQUENCE#)
--------------
254

Com é descrito, o Data Guard está configurado e o processo Redo Apply esta running. (Processo RFS)

Demonstração 1: Automatic Gap Resolution (Resolução automática de GAP): Neste cenário é provocado um GAP e analisaremos os logs para o processo de resolução automática de GAP (automatic gap resolution process). Não é parado quaisquer serviços do Data Guard, assim serviço de transporte e de aplicação de redo estão running (Transport e Redo apply services), para simular o GAP no standby database paramos o serviço de network do sistema operacional.

  • Parando o network service do SO no standby database.

  
[oracle@oel62-stbdb-12c  ~]$ su - 
Password: 
[root@oel62-stbdb-12c ~]# service network  stop

Shutting down interface eth0:  Device state: 3 (disconnected)      [  OK  ]
Shutting down loopback interface:                                  [  OK  ]
  • Provocando switch log file no database primário.

  
SQL> alter system switch logfile;
System altered.

SQL> /
System altered.

SQL> /
System altered.

SQL> select max(sequence#) from  v$archived_log;

MAX(SEQUENCE#)
----------------------
258

Alert log do database primário:


  
Thu Aug 01 15:29:45 2014
   Thread 1 advanced to log sequence 256 (LGWR  switch)
   Current log# 1 seq#  256 mem# 0: /u01/app/oracle/oradata/prmcdb/redo01.log
   Thu Aug 01 15:29:46 2014
   Archived Log entry 457 added for thread 1  sequence 255 ID 0x94205ccc dest 1:
   Thu Aug 01 15:29:47 2014
   Thread 1 advanced to log sequence 257 (LGWR  switch)
   Current log# 2 seq#  257 mem# 0: /u01/app/oracle/oradata/prmcdb/redo02.log
   Thu Aug 01 15:29:48 2014
   ...
   
   TNS-12543: TNS:destination host unreachable
   ns  secondary err code: 12560
   nt  main err code: 513
   
   TNS-00513: Destination host unreachable
   nt  secondary err code: 113
   nt  OS err code: 0
   Thu Aug 01 15:30:07 2014
   Error 12543 received logging on to the  standby
   FAL[server, ARC0]: Error 12543 creating  remote archivelog file 'stbcdb'
   FAL[server, ARC0]: FAL archive failed, see  trace file.
   ARCH: FAL archive failed. Archiver continuing
   Thu Aug 01 15:30:07 2014
   ORACLE Instance prmcdb - Archival Error.  Archiver continuing.
   …

Iniciando o network service do SO no standby database.


  
[root@oel62-stbdb-12c  ~]# service network start
   Bringing up loopback interface:                                                      [  OK  ]
   Bringing up interface eth0:  Active connection state: activated Active  
   connection path: /org/freedesktop/NetworkManager/ActiveConnection/11                 [  OK  ]
   [root@oel62-stbdb-12c ~]#

Alert log do database primário:


  
  …
   ARCH: Detected ARCH process failure
   Thu Aug 01 15:35:57 2014
   ARC2: STARTING ARCH PROCESSES
   Starting background process ARC1
   Thu Aug 01 15:35:57 2014
   ARC1 started with pid=24, OS id=23065 
   Thu Aug 01 15:35:58 2014
   ARC0: Becoming the heartbeat ARCH
   Thu Aug 01 15:35:58 2014
   ARC1: Archival started
   ARC2: STARTING ARCH PROCESSES COMPLETE
   Thu Aug 01 15:36:02 2014
   Thread 1 advanced to log sequence 259 (LGWR  switch)
   Current log# 1 seq#  259 mem# 0: /u01/app/oracle/oradata/prmcdb/redo01.log
   Thu Aug 01 15:36:03 2014
   Archived Log entry 463 added for thread 1  sequence 258 ID 0x94205ccc dest 1:
   Thu Aug 01 15:36:04 2014
   ARC3: Standby redo logfile selected for  thread 1 sequence 258 for destination LOG_ARCHIVE_DEST_2
   Thu Aug 01 15:41:02 2014
   ******************************************************************
   TT00: Setting 'active' archival for  destination LOG_ARCHIVE_DEST_2
   ******************************************************************
   TT00: Standby redo logfile selected for  thread 1 sequence 259 for destination LOG_ARCHIVE_DEST_2
   …

Alert log do standby database:


  
 …
   Thu Aug 01 15:34:20 2014
   Media Recovery Waiting for thread 1 sequence  257
   Thu Aug 01 15:35:59 2014
   RFS[4]: Assigned to RFS process (PID:4691)
   RFS[4]: Opened log for thread 1 sequence 257 dbid 2485119180 branch 820252236
   Thu Aug 01 15:35:59 2014
   Archived Log entry 7 added for thread 1  sequence 257 rlc 820252236 ID 0x94205ccc  dest 2:
   Thu Aug 01 15:35:59 2014
   Media Recovery Log  
   /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_257_8zngjh9g_.arc
   Media Recovery Waiting for thread 1 sequence 258
   Thu Aug 01 15:36:03 2014
   SRL log 4 needs clearing because log has not  been created
   RFS[4]: Selected log 5 for thread 1 sequence  258 dbid 2485119180 branch 820252236
   Thu Aug 01 15:36:04 2014
   Recovery of Online Redo Log: Thread 1 Group 5  Seq 258 Reading mem 0
   Mem# 0: /u01/app/oracle/oradata/stbcdb/sredo02.log
   Thu Aug 01 15:36:05 2014
   Archived Log entry 8 added for thread 1  sequence 258 ID 0x94205ccc dest 1:
   Thu Aug 01 15:36:07 2014
   Media Recovery Waiting for thread 1 sequence  259
   Thu Aug 01 15:41:02 2014
   Primary database is in MAXIMUM PERFORMANCE  mode
   SRL log 4 needs clearing because log has not  been created
   RFS[5]: Assigned to RFS process (PID:4710)
   RFS[5]: Selected log 5 for thread 1 sequence  259 dbid 2485119180 branch 820252236
   Thu Aug 01 15:41:08 2014
   Recovery of Online Redo Log: Thread 1 Group 5  Seq 259 Reading mem 0
   Mem# 0:  /u01/app/oracle/oradata/stbcdb/sredo02.log
   …

Database primário:


  
SQL> select max(sequence#) from  v$archived_log;
MAX(SEQUENCE#)
--------------------------
258

Standby database:


  
SQL> select max(sequence#) from  v$archived_log; 
MAX(SEQUENCE#)
--------------------------------
258

SQL> select max(sequence#) from   v$archived_log where applied=’YES’; 
MAX(SEQUENCE#)
--------------------------------
258

Quando o network service é novamente iniciado no standby database, o serviço de transporte (transport service) do data guard enviou as entradas de redo que ainda não foram enviadas para o standby, o que significa que o próprio dataguard resolveu o GAP automaticamente.

Resolvendo Redo Gap usando FAL (Redo Gap Resolution using FAL) FAL é a capacidade do Data Guard de detectar e buscar archive Log para satisfazer a relação de sincronismo entre database primário e standby database, essa propriedade é usada somente em Standby Database Físico (Physical standby database), em caso de missing ou corrupção do archive log file é possível buscar em um FAL Server (standby database primário em cascata e FAR SYNC instance), o mecanismo também é conhecido como "reactive gap resolution". O processo RFS do standby database usando o parâmetro FAL_SERVER (parâmetro FAL_SERVER possui uma lista de entradas TNS) requisita o archive log necessário para resolver o GAP. É importante ressaltar que o parâmetro FAL_CLIENT está depreciado desde Oracle Database 11g R2.

Importante: Processo Redo Apply deve estar em running para detectar GAP de archives no standby database.

Detecção/proteção de corrupção Entradas de redo transmitidas diretamente da SGA (Redo Log Buffer) por modo ASYNC ou SYNC é completamente isento de corrupção por I/O físico. Redo Apply fornece uma proteção a nível de dados, ao impedir que corrupções físicas sejam replicadas para o standby database. Serviço de transporte (Transport service) e o serviço de Redo Apply detecta automaticamente possíveis corrupção no redo logs. Assim o serviço de transporte (Transport service) não transporta quaisquer archived log corrompido e serviço de Redo Apply também não aplica quaisquer archived log corrompido, por meio disto é preservado a integridade dos dados, ou seja, existe uma dupla verificação, sendo uma no transporte e outra na aplicação dos redo logs no standby database.

Demonstração 2:

Resolução de Redo Gap usando FAL: Neste cenário é simulado uma corrupção e remoção de alguns archived logs não aplicados no standby database e analisaremos os alert logs.

  • Parar o processo de Redo Apply no standby database.

  
[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
[oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba
SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 16:22:27 2014
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced  Analytics and Real Application Testing options
SQL> alter database recover managed  standby database cancel;
Database altered.
  • Transporte está em running e enviando redo para standby database.

  
[oracle@oel62-stbdb-12c ~]$ export  ORACLE_SID=stbcdb
[oracle@oel62-stbdb-12c ~]$ sqlplus / as  sysdba
SQL*Plus: Release 12.1.0.1.0 Production on  Thu Aug 1 16:24:36 2014
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
   Oracle Database 12c Enterprise Edition  Release 12.1.0.1.0 - 64bit Production
   With the Partitioning, OLAP, Advanced Analytics  and Real Application Testing options
SQL> select max(sequence#) from  v$archived_log;
MAX(SEQUENCE#)
--------------------------
261
SQL> select max(sequence#) from  v$archived_log where applied='YES';
MAX(SEQUENCE#)
--------------------------
258

Standby database recebeu 3 archivelog do database primário, o processo Redo Apply está parada, assim os 3 archivelog não serão aplicados no standby database.   

  • Removendo e corrompendo archivelog no standby database.

  
[oracle@oel62-stbdb-12c ~]$ cd  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/
   [oracle@oel62-stbdb-12c 2014_08_01]$ ls -l
   total 25376
   -rw-r----- 1 oracle oinstall  7999488 Aug   1 12:42 o1_mf_1_251_8zn4clm3_.arc
   -rw-r----- 1 oracle oinstall   880128 Aug  1 13:03 o1_mf_1_252_8zn5lkdb_.arc
   -rw-r----- 1 oracle oinstall   422912 Aug   1 13:13 o1_mf_1_253_8zn6537t_.arc
   -rw-r----- 1 oracle oinstall 11297792  Aug  1 15:14 o1_mf_1_254_8znf8lr5_.arc
   -rw-r----- 1 oracle oinstall   555008 Aug   1 15:34 o1_mf_1_255_8zngfbk3_.arc
   -rw-r----- 1 oracle oinstall     2048 Aug   1 15:33 o1_mf_1_256_8zngcx8n_.arc
   -rw-r----- 1 oracle oinstall     3584 Aug   1 15:35 o1_mf_1_257_8zngjh9g_.arc
   -rw-r----- 1 oracle oinstall   218624 Aug   1 15:36 o1_mf_1_258_8zngjnx7_.arc
   -rw-r----- 1 oracle oinstall  4582912 Aug   1 16:23 o1_mf_1_259_8znkb877_.arc
   -rw-r----- 1 oracle oinstall     2048 Aug   1 16:23 o1_mf_1_260_8znkbbyp_.arc
   -rw-r----- 1 oracle oinstall     3584 Aug   1 16:24 o1_mf_1_261_8znkbj18_.arc
   
   [oracle@oel62-stbdb-12c 2014_08_01]$ rm -fr o1_mf_1_259_8znkb877_.arc 
   [oracle@oel62-stbdb-12c 2014_08_01]$ cat  >> o1_mf_1_260_8znkbbyp_.arc 
   Corruption on 260 sequence#
   [oracle@oel62-stbdb-12c 2014_08_01]$ cat  o1_mf_1_260_8znkbbyp_.arc

Removendo o archivelog com sequência 259 e corrompendo archivelog com sequencia 260. Iniciando o processo de Redo Apply no standby database.


  
SQL> alter database recover managed  standby database disconnect from session;
Database altered

Alert log no standby database:


  
 …
   MRP0: Background Managed Standby Recovery  process started (stbcdb)
   Thu Aug 01 16:32:14 2014
   Serial Media Recovery started
   Managed Standby Recovery starting Real Time  Apply
   Thu Aug 01 16:32:16 2014
   Waiting for all non-current ORLs to be  archived...
   Thu Aug 01 16:32:16 2014
   All non-current ORLs have been archived.
   Thu Aug 01 16:32:16 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_259_8znkb877_.arc
   Error opening /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_259_8znkb877_.arc
   Attempting refetch
   Media Recovery Waiting for thread 1 sequence  259
   Fetching gap sequence in thread 1, gap sequence 259-259
   Completed: alter database recover managed  standby database disconnect from session
   Thu Aug 01 16:32:17 2014
   RFS[6]: Assigned to RFS process (PID:4915)
   RFS[6]: Allowing overwrite of partial archivelog for thread 1 sequence  259
   RFS[6]: Opened log for thread 1 sequence 259 dbid 2485119180 branch  820252236
   Thu Aug 01 16:32:19 2014
   Archived Log entry 12 added for thread 1  sequence 259 rlc 820252236 ID 0x94205ccc dest 2:
   Thu Aug 01 16:32:20 2014
   Media Recovery Log /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_259_8znkt266_.arc
   Thu Aug 01 16:32:21 2014
   Media Recovery Log  /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_260_8znkbbyp_.arc
   Error opening /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_260_8znkbbyp_.arc
   Attempting refetch
   Media Recovery Waiting for thread 1 sequence  260
   Fetching gap sequence in thread 1, gap sequence 260-260
   Thu Aug 01 16:32:21 2014
   RFS[6]: Allowing overwrite of partial archivelog for thread 1 sequence  260
   RFS[6]: Opened log for thread 1 sequence 260 dbid 2485119180 branch  820252236
   Thu Aug 01 16:32:22 2014
   Archived Log entry 13 added for thread 1  sequence 260 rlc 820252236 ID 0x94205ccc dest 2:
   Thu Aug 01 16:32:22 2014
   Media Recovery Log /u01/app/oracle/fast_recovery_area/STBCDB/archivelog/2014_08_01/o1_mf_1_260_8znkt5t8_.arc
   Thu Aug 01 16:32:24 2014
   …

Como descrito no alert log do standby database, quando o processo de media recovery não consegue abrir o archived log (no standby database) então é iniciado um mecanismo de busca por archivelog (fetching gap sequence), afim de satisfazer a relação de sincronismo entre database primário e standby database, é importante ressaltar que essa relação foi abalada, devido à quebra da continuidade sequencial de logs (falta de archivelog com "log sequence number" 259 e 260), esta busca por archivelog (fetching gap sequence), envolve o processo RFS que solicita ao database primário o(s) archivelog(s) necessários para eliminar o "gap sequence", se os archivelogs existirem no database primário, então, o processo RFS permite que o archivelogs seja refeito ou sobrescrevido, uma vez que o processo ARCH no database primário reenvia as entradas de redo novamente.

Na segunda parte deste artigo, discutiremos e demonstraremos dois casos de resolução de redo gap (redo gap resolution). Em uma cenário onde temos indisponibilidade da infra-estrutura de rede, ocorrendo um archive gap no standby database, antes que a conexão entre o database primário e standby database seja reestabelecida, os archivelogs não enviados (not shipped archived redo logs) são removidos ou corrompidos no database primário.

Gap Sequence: Refere-se a uma lacuna de "log sequence" entre database primário e standby database, devido a uma falha na aplicação de archivelogs, o que impede a continuidade do fluxo de incremento no "log sequence number". (Database primário com "log sequence number" de 261 e standby database com "log sequence number" de 258).

Log Sequence Number: Número inteiro com valor único e não nulo que identifica um conjunto de entradas de redo (redo records) em um redo log file, esse conjunto de entradas de redo (redo log file) pode ser arquivado, caso o database esteja em "archive mode", o processo background responsável pelo arquivamento é o ARCH.

  References:

Oracle Database Backup and Recovery User's Guide 12c Release 1 (12.1)

Oracle Data Guard Concepts and Administration 12c Release 1 (12.1)

Pode continuar a ler a segunda parte deste artigo aqui: Oracle Database 12c – Resolução de Redo Gap (Part II)

Joel é um DBA expert com mais de 14 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director. Durante estes anos, Joel trabalhou como consultor sênior em um grande número de empresas e clientes em diversos países: Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India, Italy, France.

Mahir é um DBA Sênior com 10 anos de experiência em Oracle Database com foco em High Availability e Disaster Recovery Solutions (RAC, Data Guard, RMAN...). Mahir trabalha atualmente no Banco Central da Republica do Azerbaijão. Ele é um OCE DBA. Mahir é membro do Azerbaijan Oracle User Group (AZEROUG)

Furushima é um DBA Sênior com vasta experiência e conhecimento em diversas áreas de banco de dados relacional é especialista em "Performance, diagnostic e tuning", High Availability e Backup & Recovery, nos últimos anos de sua carreira profissional Furushima acumulou cargos de DBA Oracle e SysAdmin em sistemas operacional Unix, atualmente trabalha para Grupo Camargo Correa SA. Siga Furushima no seu blog

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.