Questa pagina è stata tradotta dall'API Cloud Translation.

Convalida il deployment di Data Guard

Dopo aver configurato il broker Data Guard, devi verificare che l'operazione di ripetizione sia stata copiata dal database principale e applicata il database in standby. La procedura seguente può essere utilizzata per controllare lo stato di Data Guard dai database principale e di standby.

In questa guida vengono utilizzati i seguenti esempi:

Nome univoco database	Nomi host 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 il numero di sequenza più recente per la ripetizione archiviata log:
```
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 pari a 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 in standby, quindi imposta la variabile di ambiente ORACLE_SID in modo da poterti connettere in standby database:
```
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 che corrispondono all'esecuzione della query precedente rispetto al 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
```

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 in standby:

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

In caso di ritardo, consulta la documentazione sulla risoluzione dei problemi di Data Guard di Oracle.

Cambio del database mediante il broker Data Guard

Uno switchover è un'inversione di ruolo in cui il database principale diventa un database standby e viceversa. Durante il processo di cambio, i client di database e disconnesso 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à delle applicazioni durante le transizioni dei ruoli. Puoi testare la tua preparazione al ripristino di emergenza eseguendo un cambio del 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 all'app in standby database:
```
dgmgrl
```
```
CONNECT SYS@DBDG_SITE2
```
Quando viene richiesta la password, inserisci la password di accesso remoto SYS per per configurare un 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 primario nella configurazione.
Esegui questo comando per confermare che i ruoli del database siano stati 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 non verrà spedita nel in standby finché non viene 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 ed esegui il failover dell'istanza principale al database in 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.

Ripristina il database principale

Puoi reintegrare il database principale dopo un failover solo se è attivata l'opzione flashback database. Per ripristinare il database principale in errore:

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.
Ripristina il database:
```
REINSTATE DATABASE DBDG_SITE1;
EXIT;
```

Passaggi successivi

Successivamente, configura un osservatore Data Guard su Compute Engine.