Convalida il deployment di Data Guard

Dopo aver configurato il broker Data Guard, devi verificare che la ripetizione sia stata copiata dal database principale e applicata al database in standby. La seguente procedura può essere utilizzata per verificare lo stato di Data Guard dall'interno dei database principali e di standby.

In questa guida vengono utilizzati i seguenti esempi:

Nome univoco database	Nomi host dei server	Nomi istanze RAC	Ruolo
`DBDG_SITE1`	`site1db1`, `site1db2`	`DBDG_SITE11`, `DBDG_SITE12`	Principale
`DBDG_SITE2`	`site2db1`, `site2db2`	`DBDG_SITE21`, `DBDG_SITE22`	In attesa

Convalida il deployment di Data Guard

Accedi al primo server Bare Metal Solution che ospita il database principale, quindi imposta la variabile di ambiente ORACLE_SID in modo da poterti connettere al database principale:
```
source oraenv <<< "DBDG_SITE11"
```
Avvia SQL*Plus, quindi determina l'ultimo numero di sequenza per i log di ripetizione archiviati:
```
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;
```
Il seguente output ha un numero di sequenza massimo di 40 per il thread 1 e un numero di sequenza massimo di 33 per il thread 2:
```
   THREAD# Last Primary Seq Archived
---------- -------------------------
         1                        40
         2                        33
```
Registra i risultati per confrontarli con il database in standby. I numeri di sequenza nel database in standby devono corrispondere al database principale.
Accedi al primo server Bare Metal Solution che ospita il database in standby, quindi imposta la variabile di ambiente ORACLE_SID in modo da poterti connettere al database di standby:
```
source oraenv <<< "DBDG_SITE21"
```

Avvia SQL*Plus, quindi verifica che l'ultimo numero di sequenza ricevuto e applicato per i log di ripetizione archiviati corrisponda all'ultimo numero di sequenza nel database principale:

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;

Il seguente output contiene numeri di sequenza che corrispondono all'esecuzione della query precedente sul database in standby:

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

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

Controlla che lo stato del processo di recupero gestito sia APPLYING_LOG:
```
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE '%MRP%';
```
L'esempio seguente mostra un singolo processo di recupero gestito denominato MRP0 con stato APPLYING_LOG:
```
PROCESS   STATUS
--------- ------------
MRP0      APPLYING_LOG
```
Verifica la presenza di eventuali mezzi di trasporto o applica il ritardo nel database in standby:
```
COLUMN NAME FORMAT a20
COLUMN VALUE FORMAT a30
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME LIKE '%lag%';
```
L'output seguente mostra l'assenza di ritardi nel database in standby:
```
NAME                 VALUE
-------------------- ------------------------------
transport lag        +00 00:00:00
apply lag            +00 00:00:00
```
In caso di ritardo, consulta la documentazione per la risoluzione dei problemi di Data Guard di Oracle.

Cambio di database utilizzando il broker Data Guard

Una commutazione è un'inversione dei ruoli in cui il database principale diventa un database in standby e viceversa. Durante il processo di passaggio, i client di database vengono disconnessi dal database principale. A seconda di come l'applicazione si connette al database, un passaggio può interrompere il traffico dell'applicazione. Oracle offre opzioni per mantenere la continuità delle applicazioni durante le transizioni dei ruoli. Puoi verificare l'idoneità al ripristino di emergenza eseguendo il passaggio al database seguendo queste istruzioni:

Accedi al server Bare Metal Solution che ospita il database principale.
Avvia l'interfaccia a riga di comando di Data Guard e connettiti al database in standby:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando viene richiesta una password, inserisci la password di accesso remoto SYS per il database.
Verifica che il database sia pronto per il passaggio.
```
VALIDATE DATABASE DBDG_SITE2;
```
Un risultato riuscito segnalerà che il database è pronto per il passaggio.
In caso di esito positivo, esegui il comando di passaggio:
```
SWITCHOVER TO DBDG_SITE2;
```
Se il comando ha esito positivo, verrà visualizzato un messaggio che indica che DBDG_SITE2 è il nuovo database principale della configurazione.
Esegui questo comando per confermare che i ruoli del database siano stati scambiati:
```
SHOW CONFIGURATION;
```
Esegui questo comando per tornare alla configurazione originale:
```
SWITCHOVER TO DBDG_SITE1;
```

Failover del database tramite il broker Data Guard

Un failover è una transizione del ruolo in cui uno dei database in standby passa al ruolo principale a causa di un'interruzione completa del sito. La ripetizione non verrà inviata al database in standby finché il database in standby non sarà stato reintegrato.

Esegui il failover

Accedi al primo server Bare Metal Solution che ospita il database in standby.
Connettiti all'interfaccia a riga di comando di Data Guard, quindi esegui il failover dell'istanza principale al database in standby:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando viene richiesta una password, inserisci la password di accesso remoto SYS per il database.
Avvia il failover:
```
FAILOVER TO DBDG_SITE2
```
Esegui show configuration; per verificare che DBDG_SITE2 sia ora il database principale e che DBDG_SITE1 debba essere reintegrato.

Ripristinare il database principale

Puoi reintegrare il database principale solo dopo un failover se flashback database è abilitato. Per reintegrare il database principale con errori:

Accedi al primo server Bare Metal Solution che ospita il database principale.
Connettiti all'interfaccia a riga di comando di Data Guard, accedi ai database principali, quindi reintegra il database con errori:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando viene richiesta una password, inserisci la password di accesso remoto SYS per il database.
Ripristina il database:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Passaggi successivi

Quindi, configura un osservatore Data Guard su Compute Engine.