Durante a configuração ou manutenção de um ambiente Oracle Data Guard (ADG), é comum encontrar situações onde o banco de dados standby perde a sincronia com o primário devido à ausência de arquivos de archive log. Esse fenômeno é conhecido como Archive Gap. Quando o mecanismo automático falha em resolver essa lacuna, intervenções manuais via RMAN ou SQL Plus tornam-se necessárias.

Configuração Inicial e Parâmetros de Redundância

Para minimizar a ocorrência de GAPs e permitir que o serviço FAL (Fetch Archive Log) funcione corretamente, os parâmetros de rede e destino de log devem estar devidamente configurados no banco primário e no standby.

-- Configuração do Data Guard Config e FAL Server
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(prod_db,stby_db)';
ALTER SYSTEM SET FAL_SERVER='prod_db';
ALTER SYSTEM SET FAL_CLIENT='stby_db';

-- Definição do destino de arquivamento remoto
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stby_db ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby_db';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Criação do Standby via RMAN (Active Database Duplication)

Se você estiver criando o standby do zero e houver risco de perda de logs, o comando DUPLICATE com a cláusula DORECOVER é a abordagem recomendada. Abaixo, um exemplo de script otimizado com múltiplos canais:

RUN {
    # Canais no banco primário
    ALLOCATE CHANNEL p1 TYPE DISK;
    ALLOCATE CHANNEL p2 TYPE DISK;
    
    # Canais no banco auxiliar (standby)
    ALLOCATE AUXILIARY CHANNEL a1 TYPE DISK;
    ALLOCATE AUXILIARY CHANNEL a2 TYPE DISK;

    DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER;
    
    RELEASE CHANNEL p1;
    RELEASE CHANNEL p2;
}

Identificação e Tratamento de GAPs

Existem dois mecanismos principais para lidar com GAPs no Oracle: o Automatic Gap Resolution, onde o processo ARCn do primário verifica o status do standby periodicamente, e o FAL Gap Resolution, onde o standby (cliente) solicita os logs faltantes ao servidor definido em FAL_SERVER.

Caso o GAP não seja resolvido automaticamente, o primeiro passo é identificar quais sequências estão faltando através da V$ARCHIVE_GAP no standby:

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# 
FROM V$ARCHIVE_GAP;

Resolução Manual em Standby Físico

Se os arquivos ainda existirem no servidor primário, você pode localizá-los e transferi-los manualmente:

-- No Primário: Localizar o caminho dos arquivos faltantes
SELECT NAME 
FROM V$ARCHIVED_LOG 
WHERE THREAD# = 1 
AND SEQUENCE# BETWEEN 500 AND 510;

Após copiar os arquiovs para o servidor standby, registre-os no catálogo do banco de dados para que o processo de recovery possa utilizá-los:

ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/arch/stby_500.arc';
-- Ou registre múltiplos arquivos de um diretório via RMAN
-- RMAN> CATALOG START WITH '/u01/app/oracle/arch/';

Resolução via Restore de Backup (RMAN)

Se os archives já foram removidos do disco no primário, mas estão disponíveis em backup, utilize o RMAN para restaurá-los diretamente no destino de archive:

RUN {
    SET ARCHIVELOG DESTINATION TO '/u01/app/oracle/arch/recovery';
    RESTORE ARCHIVELOG FROM LOGSEQ 500 UNTIL LOGSEQ 510 THREAD 1;
}

Sincronização em Standby Lógico

Para ambientes de Logical Standby, a consulta para identificar interrupções de log é feita na visão DBA_LOGSTDBY_LOG. O procedimento de registro é ligeiramente diferente:

-- Identificar logs faltantes no Logical Standby
SELECT THREAD#, SEQUENCE#, FILE_NAME 
FROM DBA_LOGSTDBY_LOG 
WHERE NEXT_CHANGE# NOT IN (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG)
ORDER BY THREAD#, SEQUENCE#;

-- Registrar o log para aplicação SQL
ALTER DATABASE REGISTER LOGICAL LOGFILE '/u01/app/oracle/arch/log_stby_500.arc';

Se o GAP for muito extenso e os logs originais não estiverem mais disponíveis (nem em backup), a solução a partir do Oracle 10g é realizar um backup incremental baseado no SCN atual do standby para sincronizar a base de dados sem a neecssidade de recriá-la totalmente.