Esta página foi traduzida pela API Cloud Translation.

Validar a implantação do Data Guard

Depois de configurar o agente do Data Guard, é preciso verificar se o "redo" foi copiado do banco de dados principal e aplicado ao banco de dados em espera. O procedimento a seguir pode ser usado para verificar o status do Data Guard nos bancos de dados principal e em espera.

Os exemplos a seguir são usados neste guia:

Nome exclusivo do banco de dados	Nomes de host do servidor	Nomes de instâncias RAC	Papel
`DBDG_SITE1`	`site1db1`, `site1db2`	`DBDG_SITE11`, `DBDG_SITE12`	Principal
`DBDG_SITE2`	`site2db1`, `site2db2`	`DBDG_SITE21`, `DBDG_SITE22`	Espera

Validar a implantação do Data Guard

Faça login no primeiro servidor da Solução Bare Metal que hospeda o banco de dados principal e defina a variável de ambiente ORACLE_SID para se conectar ao banco de dados principal:
```
source oraenv <<< "DBDG_SITE11"
```
Inicie o SQL*Plus e determine o número de sequência mais recente para os registros de "redo" arquivados:
```
sqlplus / as sysdba
```
```
SELECT THREAD#, max(SEQUENCE#) "Last Primary Seq Archived"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;
```
A saída a seguir tem 40 como o número máximo de sequência para a linha de execução 1 e um número máximo de sequência de 33 para a linha de execução 2:
```
   THREAD# Last Primary Seq Archived
---------- -------------------------
         1                        40
         2                        33
```
Registre os resultados para comparar com o banco de dados em espera. Os números de sequência no banco de dados em espera devem corresponder ao banco de dados principal.
Faça login no primeiro servidor da Solução Bare Metal que hospeda o banco de dados em espera e defina a variável de ambiente ORACLE_SID para se conectar ao banco de dados em espera:
```
source oraenv <<< "DBDG_SITE21"
```

Inicie o SQL*Plus e valide se o número de sequência mais recente recebido e aplicado aos registros "redo" arquivados corresponde ao número de sequência mais recente no banco de dados principal:

sqlplus / as sysdba

SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Received"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# GROUP BY THREAD# ORDER BY 1;

SELECT THREAD#, max(SEQUENCE#) "Last Standby Seq Applied"
FROM V$ARCHIVED_LOG VAL, V$DATABASE VDB WHERE VAL.RESETLOGS_CHANGE# =
VDB.RESETLOGS_CHANGE# AND VAL.APPLIED IN ('YES','IN-MEMORY') GROUP BY
THREAD# ORDER BY 1;

A saída a seguir tem números de sequência que correspondem à execução anterior da consulta com o banco de dados em espera:

   THREAD# Last Standby Seq Received
---------- -------------------------
         1                        40
         2                        33

   THREAD# Last Standby Seq Applied
---------- ------------------------
         1                       40
         2                       33

Verifique se o status do processo de recuperação gerenciado é APPLYING_LOG:
```
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';
```
No exemplo a seguir, mostramos um único processo de recuperação gerenciado chamado MRP0 com status APPLYING_LOG:
```
PROCESS   STATUS
--------- ------------
MRP0      APPLYING_LOG
```

Verifique se há atraso no transporte ou na aplicação no banco de dados em espera:

COLUMN NAME FORMAT a20
COLUMN VALUE FORMAT a30
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';

A saída a seguir não mostra atraso no banco de dados em espera:

NAME                 VALUE
-------------------- ------------------------------
transport lag        +00 00:00:00
apply lag            +00 00:00:00

Se houver atraso, consulte a documentação de solução de problemas do Data Guard da Oracle.

Alternância do banco de dados usando o agente do Data Guard

Uma alternância é uma reversão de papel em que o banco de dados principal se torna um banco de dados em espera e vice-versa. Durante o processo de alternância, os clientes do banco de dados são desconectados do banco de dados principal. Dependendo de como o aplicativo se conecta ao banco de dados, uma alternância pode interromper o tráfego do aplicativo. A Oracle oferece opções para manter a continuidade do aplicativo durante as transições de papéis. Teste a prontidão da recuperação de desastres executando uma alternância de banco de dados com as seguintes instruções:

Faça login no servidor da Solução Bare Metal que hospeda o banco de dados principal.
Inicie a interface de linha de comando do Data Guard e conecte-se ao banco de dados em espera:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando uma senha for solicitada, insira a senha de login remoto do SYS no banco de dados.
Valide se o banco de dados está pronto para uma alternância.
```
VALIDATE DATABASE DBDG_SITE2;
```
Um resultado de êxito informará que o banco de dados está pronto para a alternância.
Se a operação for bem-sucedida, execute o comando de alternância:
```
SWITCHOVER TO DBDG_SITE2;
```
Se o comando for bem-sucedido, você receberá uma mensagem de que DBDG_SITE2 é o novo banco de dados principal na configuração.
Execute o seguinte comando para confirmar se os papéis do banco de dados foram alternados:
```
SHOW CONFIGURATION;
```
Execute o seguinte comando para retornar à configuração original:
```
SWITCHOVER TO DBDG_SITE1;
```

Failover de banco de dados usando o agente do Data Guard

Um failover é uma transição de papel em que um dos bancos de dados em espera é transferido para o papel principal devido a uma interrupção completa do site. O "redo" não será enviado ao banco de dados em espera até que o banco de dados em espera seja restabelecido.

Executar o failover

Faça login no primeiro servidor da Solução Bare Metal que hospeda o banco de dados em espera.
Conecte-se à interface de linha de comando do DataGuard e, em seguida, faça o failover do banco de dados principal para o para o em espera:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando uma senha for solicitada, insira a senha de login remoto do SYS no banco de dados.
Inicie o failover:
```
FAILOVER TO DBDG_SITE2
```
Execute show configuration; para verificar se DBDG_SITE2 agora é o banco de dados principal e DBDG_SITE1 precisa ser restabelecido.

Restabelecer o banco de dados principal

Só será possível restabelecer o banco de dados principal após um failover se flashback database estiver ativado. Para restabelecer o banco de dados primário com falha:

Faça login no primeiro servidor da Solução Bare Metal que hospeda o banco de dados principal.
Conecte-se à interface de linha de comando do Data Guard, faça login nos bancos de dados principais e restaure o banco de dados com falha:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando uma senha for solicitada, insira a senha de login remoto do SYS no banco de dados.
Restabeleça o banco de dados:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Próximas etapas

Em seguida, configure um observador do Data Guard no Compute Engine.