Misura correttiva per eventi del servizio di database

Questo articolo descrive le correzioni necessarie per i problemi riscontrati durante l'utilizzo degli eventi del servizio di database.

Sono disponibili le seguenti misure correttive:

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Nome evento:

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Descrizione dell'evento:

Questo evento viene segnalato quando lo spazio libero del file system guest VM è inferiore al 10% libero, come determinato dal comando df(1) del sistema operativo, per i seguenti file system:

Esposizione del problema:

Uno o più file system guest VM hanno spazio libero inferiore al 10% gratuito.

Rischio:

Lo spazio libero del file system guest VM insufficiente può causare un errore di allocazione dello spazio su disco, che può causare errori e errori di ampio respiro nel software Oracle (Database, Clusterware, Cloud Tooling).

Azione/riparazione:

L'agente Oracle Cloud e DCS viene eseguito automaticamente per rimuovere i vecchi file di log e i file di trace creati dagli strumenti cloud per recuperare lo spazio del file system.

Se le utility di recupero automatico dello spazio del file system non sono in grado di rimuovere in modo sufficiente i vecchi file per cancellare questo evento, eseguire le azioni riportate di seguito.

  1. Rimuovere i file e/o le directory non necessari creati manualmente o da applicazioni o utility installate dal cliente. I file creati dal software installato dal cliente non rientrano nell'ambito delle utility di recupero automatico dello spazio del file system di Oracle. Il comando del sistema operativo riportato di seguito, eseguito come utente root, è utile per identificare le directory che consumano troppo spazio su disco.

    sudo du -hx <file system mount point> | sort -hr

    È possibile rimuovere in sicurezza solo i file o le directory specificate.

  2. Impostare il criterio di rimozione automatica utilizzando gli strumenti cloud. Per ulteriori informazioni, vedere Autologcleanpolicy Commands.
  3. Aprire la richiesta di servizio per ricevere istruzioni aggiuntive sulla riduzione dell'uso dello spazio nel file system.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Nome evento:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Descrizione dell'evento:

Un evento di tipo CRITICAL viene creato quando viene rilevato che il servizio CRS (Cluster Ready Service) è inattivo.

Esposizione del problema:

Lo stack Cluster Ready è in stato offline o non è riuscito.

Rischio:

Se il CRS è offline su un nodo, il nodo non può fornire servizi di database per l'applicazione.

Azione/riparazione:

  1. Verificare se il CRS è stato arrestato dall'amministratore, nell'ambito di un evento di manutenzione pianificato, o se è stato eseguito lo scale up o lo scale down dello storage locale

    1. I seguenti eventi di applicazione delle patch interromperanno CRS

      1. Aggiornamento GRID
      2. Aggiornamento cliente
      3. Aggiornamento dell'host

  2. Se CRS si è arrestato in modo imprevisto, è possibile controllare lo stato corrente eseguendo il comando crsctl check crs.

    1. Se il nodo non risponde, è possibile che venga eseguito il reboot del nodo VM. Attendere il completamento del riavvio del nodo, in genere CRS verrà avviato tramite il processo init.
  3. Se il CRS è ancora inattivo, esaminare la causa dell'errore facendo riferimento al file alert.log disponibile in /u01/app/grid/diag/crs/<node_name>/crs/trace. Esaminare le voci di log corrispondenti alla data/ora dell'evento di inattività e agire su qualsiasi potenziale misura correttiva.
  4. Riavviare la CRS eseguendo il comando crsctl start crs.
  5. Un riavvio riuscito di CRS genererà l'evento di liquidazione: AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Cancellazione evento:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Descrizione evento liquidazione:

Un evento INFORMATION viene creato una volta avviato correttamente il CRS.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Nome evento:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Descrizione dell'evento:

Un evento di tipo CRITICAL viene creato quando il servizio CRS (Cluster Ready Service) rimuove un nodo dal cluster. Il CRS alert.log viene analizzato per l'errore CRS-1632 che indica che un nodo viene rimosso dal cluster.

Esposizione del problema:

Oracle Clusterware è progettato per eseguire una rimozione dei nodi rimuovendo uno o più nodi dal cluster se viene rilevato un problema critico. Un problema critico potrebbe essere un nodo che non risponde tramite un heartbeat di rete, un nodo che non risponde tramite un heartbeat di disco, un computer sospeso o gravemente danneggiato o un processo ocssd.bin sospeso. Lo scopo di questa rimozione dei nodi è quello di mantenere lo stato generale del cluster rimuovendo i membri non sani.

Rischio:

Durante il tempo necessario per riavviare il nodo rimosso, il nodo non può fornire servizi di database per l'applicazione.

Azione/riparazione:

Una rimozione dei nodi CRS potrebbe essere causata dai processi OCSSD (aka daemon CSS), CSSDAGENT o CSSDMONITOR. Ciò richiede la determinazione del processo responsabile della rimozione dei nodi e la revisione dei file di log pertinenti. Le cause comuni della rimozione di OCSSD sono errori di rete / latenze, problemi di I/O con dischi di voto CSS, un'escalation di kill dei membri. Le eliminazioni CSSDAGENT o CSSDMONITOR potrebbero essere un problema dello scheduler del sistema operativo o un thread sospeso all'interno del daemon CSS. I file di log da esaminare includono l'alert log del clusterware, il log cssdagent, il log cssdmonitor, il log ocssd, il log lastgasp, /var/log/messages, i dati CHM/OS Watcher e i dettagli opatch lsinventory.

Per ulteriori informazioni sulla raccolta dei file, vedere Autonomous Health Framework (AHF) Trace File Analyzer (TFA) e ORAchk/EXAchk. Per ulteriori informazioni sulla risoluzione dei problemi relativi alla rimozione dei nodi CRS, vedere Risoluzione dei problemi relativi alle rimozioni dei nodi Clusterware (riavvio).

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Nome evento:

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Descrizione dell'evento:

Un evento DOWN viene creato quando un listener SCAN diventa inattivo. L'evento è di tipo INFORMATION quando un listener SCAN viene chiuso a causa di un'azione dell'utente, ad esempio con i comandi della utility di controllo del server (srvctl) o di controllo del listener (lsnrctl) o qualsiasi azione di manutenzione di Oracle Cloud che utilizza tali comandi, ad esempio l'esecuzione di un aggiornamento software di Grid Infrastructure. L'evento è di tipo CRITICAL quando un listener SCAN si arresta in modo imprevisto. Un evento DOWN_CLEARED corrispondente viene creato all'avvio di un listener SCAN.

Esistono tre listener SCAN per cluster denominati LISTENER_SCAN[1,2,3].

Esposizione del problema:

Un listener SCAN è inattivo e non è in grado di accettare le connessioni dell'applicazione.

Rischio:

Se tutti i listener SCAN sono inattivi, le connessioni delle applicazioni al database tramite il listener SCAN non riusciranno.

Azione/riparazione:

Avviare il listener SCAN per ricevere l'evento DOWN_CLEARED.

DOWN evento di tipo INFORMAZIONI:

  1. Se l'evento è stato causato da un'azione di manutenzione di Oracle Cloud, ad esempio l'esecuzione di un aggiornamento software di Grid Infrastructure, non è necessaria alcuna azione. Il listener SCAN interessato eseguirà automaticamente il failover su un'istanza disponibile.
  2. Se l'evento è stato causato dall'azione dell'utente, avviare il listener SCAN all'opportunità successiva.

Evento DOWN di tipo CRITICO:

  1. Controllare lo stato SCAN e riavviare il listener SCAN

    • Eseguire il login alla VM come utente opc e sudo all'utente grid:

      [opc@vm ~] sudo su - grid

    • Controllare lo stato dei listener SCAN su qualsiasi nodo:

      [grid@vm ~] srvctl status scan_listener

    • Avviare il listener SCAN:

      [grid@vm ~] srvctl start scan_listener

    • Ricontrollare lo stato dei listener SCAN su qualsiasi nodo: se scan_listener è ancora inattivo, analizzare la causa dell'errore del listener SCAN.

      1. Raccogliere sia i log CRS che quelli del sistema operativo 30 minuti prima e 10 minuti per i log <hostName> indicati nel log. Si noti che l'ora nel payload dell'evento è sempre fornita in UTC: per la raccolta tfactl, regolare l'ora in base al fuso orario del cluster VM.

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
    -from "<eventTime adjusted for local vm timezone> - 30 minute "
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"

      2. I problemi del listener SCAN vengono registrati:

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Nome evento:

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Descrizione dell'evento:

Un evento DOWN viene creato quando un listener client diventa inattivo. L'evento è di tipo INFORMATION quando un listener client viene chiuso a causa di un'azione dell'utente, ad esempio con i comandi della utility di controllo del server (srvctl) o di controllo del listener (lsnrctl) o qualsiasi azione di manutenzione di Oracle Cloud che utilizza tali comandi, ad esempio l'esecuzione di un aggiornamento software di Grid Infrastructure. L'evento è di tipo CRITICAL quando un listener client diventa inattivo in modo imprevisto. Un evento DOWN_CLEARED corrispondente viene creato all'avvio di un listener client.

C'è un LISTENER client per nodo, ognuno chiamato LISTENER.

Esposizione del problema:

Un listener client è inattivo e non è in grado di accettare le connessioni dell'applicazione.

Rischio:

Se il listener client del nodo è inattivo, le istanze di database sul nodo non possono fornire servizi per l'applicazione.

Se il listener client è inattivo su tutti i nodi, qualsiasi applicazione che si connette a qualsiasi database utilizzando SCAN o VIP non riuscirà.

Azione/riparazione:

Avviare il listener del client per ricevere l'evento DOWN_CLEARED.

DOWN evento di tipo INFORMAZIONI:

  1. Se l'evento è stato causato da un'azione di manutenzione di Oracle Cloud, ad esempio l'esecuzione di un aggiornamento software di Grid Infrastructure, non è necessaria alcuna azione. Il listener client interessato verrà riavviato automaticamente al termine della manutenzione che interessa l'istanza Grid.
  2. Se l'evento è stato causato dall'azione dell'utente, avviare il listener del client all'opportunità successiva.

Evento DOWN di tipo CRITICO:

  1. Controllare lo stato del listener client e riavviare il listener client:

    • Eseguire il login alla VM come utente opc e sudo all'utente grid:

      [opc@vm ~] sudo su - grid

    • Controllare lo stato del listener client su qualsiasi nodo:

      [grid@vm ~] srvctl status listener

    • Avviare il listener client:

      [grid@vm ~] srvctl start listener

    • Ricontrollare lo stato del listener del client su qualsiasi nodo: se il listener del client è ancora inattivo. Esaminare la causa dell'errore del listener del client:

      1. Utilizzare tfactl per raccogliere sia i log CRS che i log del sistema operativo 30 minuti prima e 10 minuti per il log hostName indicato. Si noti che l'ora nel payload dell'evento è sempre fornita in UTC: per la raccolta tfactl, regolare l'ora in base al fuso orario del cluster VM.

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
    -from "<eventTime adjusted for local vm timezone> - 30 minute "
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"

      2. Esaminare il log del listener in:

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Nome evento:

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Descrizione dell'evento:

Un evento DOWN viene creato quando un'istanza di database diventa inattiva. L'evento è di tipo INFORMATION quando un'istanza di database viene arrestata a causa di un'azione dell'utente, ad esempio con i comandi SQL*Plus (sqlplus) o Server Control Utility (srvctl) o qualsiasi azione di manutenzione di Oracle Cloud che utilizza tali comandi, ad esempio l'esecuzione di un aggiornamento software della home del database. L'evento è di tipo CRITICO quando un'istanza di database diventa inattiva in modo imprevisto. Un evento DOWN_CLEARED corrispondente viene creato all'avvio di un'istanza di database.

Esposizione del problema:

Un'istanza di database è stata disattivata.

Rischio:

Un'istanza di database è stata disattivata, il che può comportare una riduzione delle prestazioni se le istanze di database sono disponibili su altri nodi del cluster o un tempo di inattività completo se le istanze di database su tutti i nodi sono inattive.

Azione/riparazione:

Avviare l'istanza di database per ricevere l'evento DOWN_CLEARED.

DOWN evento di tipo INFORMAZIONI:

  1. Se l'evento è stato causato da un'azione di manutenzione di Oracle Cloud, ad esempio l'esecuzione di un aggiornamento software della home del database, non è richiesta alcuna azione. L'istanza di database interessata verrà riavviata automaticamente al termine della manutenzione che interessa l'istanza.
  2. Se l'evento è stato causato dall'azione dell'utente, avviare l'istanza di database interessata all'opportunità successiva.

Evento DOWN di tipo CRITICO:

  1. Controllare lo stato del database e riavviare l'istanza di database inattiva.

    1. Eseguire il login alla VM come utente oracle:

    2. Impostate l'ambiente:

      [oracle@vm ~] . <dbName>.env

    3. Controllare lo stato del database:

      [oracle@vm ~] srvctl status database -db <dbName>

    4. Avviare l'istanza di database:

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

  2. Indagare la causa dell'errore dell'istanza di database.

    1. Esaminare gli eventi TFA (Trace File Analyzer) per il database:

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

    2. Esaminare l'alert log del database disponibile all'indirizzo:

      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

SANITÀ.DB_CLUSTER.CDB.CORRUPTION

Nome evento:

SANITÀ.DB_CLUSTER.CDB.CORRUPTION

Descrizione dell'evento:

Il danneggiamento del database è stato rilevato nel database primario o in standby. Il database alert.log viene analizzato per eventuali errori specifici che sono indicativi di danneggiamenti di blocchi fisici, danneggiamenti di blocchi logici o danneggiamenti di blocchi logici causati da scritture perse.

Esposizione del problema:

Le interruzioni possono portare a errori dell'applicazione o del database e, nel peggiore dei casi, comportare una perdita significativa dei dati se non risolti tempestivamente.

Un blocco danneggiato è un blocco modificato in modo che differisca da quanto Oracle Database si aspetta di trovare. I danneggiamenti dei blocchi possono essere classificati come fisici o logici:

Le corruzioni dei blocchi possono anche essere suddivise in corruzione interblocco e corruzione intrablocco:

Oracle verifica la presenza dei seguenti errori in alert.log:

Rischio:

Un'interruzione del danneggiamento dei dati si verifica quando un componente hardware, software o di rete causa la lettura o la scrittura di dati corrotti. L'impatto a livello di servizio di un'indisponibilità di danneggiamento dei dati può variare, da una piccola porzione dell'applicazione o del database (fino a un singolo blocco di database) a una grande parte dell'applicazione o del database (rendendolo essenzialmente inutilizzabile). Se l'azione correttiva non viene intrapresa tempestivamente, i potenziali tempi di inattività e la perdita di dati possono aumentare.

Azione/riparazione:

La notifica dell'evento corrente attualmente si attiva nei danneggiamenti dei blocchi fisici (ORA-01578), nelle scritture perse (ORA-00752, ORA-00753 e ORA-00600 con il primo argomento 3020) e nei danneggiamenti logici (in genere rilevati da ORA-00600 con il primo argomento kdsgrp1, kdsgrp1, kclchkblk_3, 13013 o 5463).

Consigliamo i seguenti passaggi:

  1. Verificare che questi danneggiamenti siano stati segnalati nel file di trace alert.log. Registrare una richiesta di servizio (SR) con il report EXAchk più recente, l'estratto del file alert.log e il file di trace contenenti gli errori di danneggiamento, qualsiasi cronologia delle modifiche recenti a applicazioni, database o software e qualsiasi sistema, clusterware e log di database per lo stesso periodo di tempo. Per tutti questi casi, una raccolta TFA dovrebbe essere disponibile e deve essere allegata alla richiesta di servizio.
  2. Per ulteriori informazioni sui suggerimenti per la riparazione, vedere Nota principale per la gestione dei problemi di Oracle Database Corruption.

Per danneggiamenti fisici o errori ORA-1578, le seguenti note saranno utili:

Nota: RMAN può essere utilizzato per recuperare uno o più blocchi di dati fisicamente danneggiati. Inoltre, utilizzando Active Data Guard con applicazione in tempo reale, la riparazione automatica dei blocchi di danneggiamenti dei dati fisici si sarebbe verificata automaticamente.

Per i danneggiamenti logici causati da scritture perse (ORA-00752, ORA-00753 e ORA-00600 con il primo argomento 3020) nei database primari o in standby, verranno rilevati nel processo di applicazione redo del database primario o in standby. Le seguenti note saranno utili:

Per i danneggiamenti logici (tipici rilevati da ORA-00600 con argomenti kdsgrp1, kclchkblk_3, 13013 o 5463)

STATO.DB_CLUSTER.CDB.ARCHIVER_HANG

Nome evento:

STATO.DB_CLUSTER.CDB.ARCHIVER_HANG

Descrizione dell'evento:

Un evento di tipo CRITICAL viene creato se un container database (CDB) non è in grado di archiviare il redo log in linea attivo o non è in grado di archiviare il redo log in linea attivo abbastanza velocemente per le destinazioni dell'archivio di log.

Esposizione del problema:

L'istanza RAC CDB può bloccarsi temporaneamente o definitivamente a causa dell'incapacità del log writer (LGWR) di scrivere i buffer di log in un redo log in linea. Ciò si verifica perché tutti i log in linea devono essere archiviati. Una volta che l'archiviatore (ARC) può archiviare almeno un redo log in linea, LGWR sarà in grado di riprendere la scrittura dei buffer di log nei redo log in linea e l'impatto dell'applicazione sarà alleviato.

Rischio:

Se l'archiviatore non risponde temporaneamente, le applicazioni potrebbero subire una breve sospensione parziale o un arresto anomalo durante il tentativo di commit delle modifiche al database. Se l'archiviatore non viene ripristinato, i processi dell'applicazione possono subire lunghi ritardi nell'elaborazione.

Azione/riparazione:

STATO.DB_CLUSTER.CDB.DATABASE_HANG

Nome evento:

STATO.DB_CLUSTER.CDB.DATABASE_HANG

Descrizione dell'evento:

Un evento di tipo CRITICAL viene creato quando un processo o una sessione non risponde nel container database (CDB).

Esposizione del problema:

Blocker Resolver ha rilevato un processo o un blocco che non risponde e ha generato un messaggio di errore ORA-32701. Inoltre, questo evento può essere generato se il processo di diagnostica (DIA0) rileva che un processo di database critico non risponde.

Rischio:

Un processo che non risponde o un blocco può indicare problemi relativi a risorse, sistema operativo o codifica delle applicazioni.

Azione/riparazione:

Indagare la causa del blocco di sessione.

STATO.DB_CLUSTER.CDB.BACKUP_FAILURE

Nome evento:

STATO.DB_CLUSTER.CDB.BACKUP_FAILURE

Descrizione dell'evento:

Viene creato un evento di tipo CRITICAL se esiste un backup CDB con stato FAILED riportato nella vista v$rman_status.

Esposizione del problema:

BACKUP incrementale giornaliero del CDB non riuscito.

Rischio:

Un errore del backup può compromettere la possibilità di utilizzare i backup per il ripristino o la recuperabilità del database. L'oggetto punto di recuperabilità (RPO) e l'oggetto tempo di recuperabilità (RTO) possono essere interessati.

Azione/riparazione:

Rivedere i log RMAN corrispondenti alla data/ora dell'evento. Si noti che la data e l'ora dell'evento eventTime sono in formato UTC, rettificare se necessario per il fuso orario della VM.

Per i backup gestiti da Oracle:

Per il backup gestito e di proprietà del cliente eseguito tramite RMAN:

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Nome evento:

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Descrizione dell'evento:

Un evento di tipo CRITICAL viene creato quando un gruppo di dischi ASM raggiunge l'uso dello spazio pari o superiore al 90%. Viene creato un evento di tipo INFORMATION quando l'uso dello spazio dei gruppi di dischi ASM scende sotto il 90%.

Esposizione del problema:

L'uso dello spazio dei gruppi di dischi ASM è pari o superiore al 90%.

Rischio:

Lo spazio insufficiente dei gruppi di dischi ASM può causare un errore di creazione del database, un errore di creazione della tablespace e del file di dati, un errore di estensione automatica del file di dati o un errore di ribilanciamento ASM.

Azione/riparazione:

Lo spazio utilizzato dal gruppo di dischi ASM è determinato dall'esecuzione della query seguente durante la connessione all'istanza ASM.

sudo su - grid
sqlplus / as sysasm
select 'ora.'||name||'.dg', total_mb, free_mb,
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;
NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

La capacità del gruppo di dischi ASM può essere aumentata nei modi seguenti:

  1. Ridimensionare lo storage del cluster VM per aggiungere più capacità del gruppo di dischi ASM. Per ulteriori informazioni, vedere Ridimensionare il sistema DB.

L'uso dello spazio dei gruppi di dischi DATA può essere ridotto nei modi seguenti:

  1. Eliminare i file di dati e i file temporanei non utilizzati dai database. Per ulteriori informazioni, vedere Eliminazione dei file di dati.

L'uso dello spazio dei gruppi di dischi RECO può essere ridotto nei modi seguenti:

  1. Elimina i punti di ripristino garantiti non necessari. Per ulteriori informazioni, vedere Utilizzo dei punti di ripristino normali e garantiti.
  2. Eliminare i redo log archiviati o i backup del database di cui è stato già eseguito il backup al di fuori dell'area di recupero flash (FRA). Per ulteriori informazioni, vedere Gestione dell'area di recupero rapido.