Questa pagina è stata tradotta dall'API Cloud Translation.

Convalida il deployment di Data Guard

Dopo aver configurato il broker Data Guard, devi verificare che il riassorbimento sia stato copiato dal database principale e applicato al database di standby. La procedura riportata di seguito può essere utilizzata per controllare lo stato di Data Guard dai database principali e di standby.

I seguenti esempi vengono utilizzati in tutta la guida:

Nome univoco del database	Nomi host del server	Nomi delle istanze RAC	Ruolo
`DBDG_SITE1`	`site1db1`, `site1db2`	`DBDG_SITE11`, `DBDG_SITE12`	Principale
`DBDG_SITE2`	`site2db1`, `site2db2`	`DBDG_SITE21`, `DBDG_SITE22`	Standby

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 redo 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 da confrontare con il database di riserva. I numeri di sequenza sul database di standby dovrebbero corrispondere a quelli del database principale.
Accedi al primo server Bare Metal Solution che ospita il database di riserva, quindi imposta la variabile di ambiente ORACLE_SID in modo da poterti connettere al database di riserva:
```
source oraenv <<< "DBDG_SITE21"
```

Avvia SQL*Plus, quindi verifica che l'ultimo numero di sequenza ricevuto e applicato per i log di reimpostazione 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;

L'output seguente contiene numeri di sequenza corrispondenti alla query precedente eseguita sul database di standby:

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

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

Verifica che lo stato della procedura di recupero gestita 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
```

Controlla se è presente un ritardo di trasporto o di applicazione nel database di standby:

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

L'output seguente non mostra alcun ritardo nel database di 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.

Passaggio di un database utilizzando il broker Data Guard

Uno switchover è un ribaltamento di ruolo in cui il database principale diventa un database di standby e viceversa. Durante la procedura di passaggio, i client di database vengono disconnessi dal database principale. A seconda di come l'applicazione si connette al database, il passaggio può interrompere il traffico dell'applicazione. Oracle offre opzioni per mantenere la continuità dell'applicazione durante le transizioni dei ruoli. Puoi verificare la tua idoneità al ripristino di emergenza eseguendo un passaggio al database con le seguenti 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 di standby:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando ti 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 positivo indica che il database è pronto per il passaggio.
Se l'operazione ha esito positivo, esegui il comando di passaggio:
```
SWITCHOVER TO DBDG_SITE2;
```
Se il comando ha esito positivo, riceverai un messaggio che indica che DBDG_SITE2 è il nuovo database principale nella configurazione.
Esegui il seguente comando per verificare che i ruoli del database siano scambiati:
```
SHOW CONFIGURATION;
```
Esegui il seguente comando per tornare alla configurazione originale:
```
SWITCHOVER TO DBDG_SITE1;
```

Failover del database utilizzando il broker Data Guard

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

Esegui il failover

Accedi al primo server Bare Metal Solution che ospita il database di standby.
Connettiti all'interfaccia a riga di comando di Data Guard, quindi esegui il failover del database primario al database di standby:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando ti 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 ora sia il database principale e che DBDG_SITE1 debba essere reintegrato.

Reintegra il database principale

Puoi reintegrare il database principale dopo un failover solo se è attivata l'opzione flashback database. Per reintegrare il database principale non riuscito:

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 e reintegra il database con errore:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando ti viene richiesta una password, inserisci la password di accesso remoto SYS per il database.
Reintegra il database:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Passaggi successivi

Successivamente, configura un osservatore Data Guard su Compute Engine.