新建oracle11 ora12543,Oracle Database 12c – Resolução de Redo Gap (Part I)

最新推荐文章于 2022-07-11 10:35:54 发布

爱吃三明治

最新推荐文章于 2022-07-11 10:35:54 发布

阅读量447

点赞数

文章标签：新建oracle11 ora12543

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).

format,png

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 doStandby 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

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

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

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

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

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:

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.