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 misure correttive riportate di seguito.

Argomenti correlati

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 della VM è inferiore al 10% libero, come determinato dal comando del sistema operativo df(1), per i seguenti file system:

  • /
  • /u01
  • /u02
  • /var
  • /tmp

Esposizione del problema

Uno o più file system guest VM dispongono di spazio libero inferiore al 10%.

Rischio

Lo spazio libero del file system guest VM insufficiente può causare errori di allocazione dello spazio su disco, con conseguenti errori ed errori ad ampio raggio 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 spazio nel file system.

Se le utility di recupero dello spazio del file system automatico non sono in grado di rimuovere in modo sufficiente i file precedenti 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 sono inclusi nei programmi di recupero automatico dello spazio del file system di Oracle. Il seguente comando del sistema operativo, eseguito come utente root, è utile per identificare le directory che occupano troppo spazio su disco: 
    sudo du -hx <file system mount point> | sort -hr

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

  2. Imposta il criterio di rimozione automatica utilizzando gli strumenti cloud. Per ulteriori informazioni, vedere Comandi Autologcleanpolicy.
  3. Aprire la richiesta di servizio per ricevere ulteriori indicazioni 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

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

Esposizione del problema

Lo stack predisposto per il cluster è in stato offline o non è riuscito.

Rischio

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

Azione/riparazione

  1. Controllare se il servizio CRS è stato arrestato dall'amministratore nell'ambito di un evento di manutenzione pianificato o di uno scale up o down dello storage locale
    1. I seguenti eventi di applicazione delle patch interromperanno CRS
      1. Aggiornamento GRID
      2. Aggiornamento del 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 riavvio del nodo VM. Attendere il completamento del riavvio del nodo. In genere, il servizio CRS verrà avviato tramite il processo init.
  3. Se il servizio CRS è ancora inattivo, analizzare la causa dell'errore facendo riferimento al file alert.log trovato in /u01/app/grid/diag/crs/<node_name>/crs/trace. Rivedere le voci del log corrispondenti alla data/ora dell'evento inattivo e agire in base a eventuali misure correttive.
  4. Riavviare il 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

Evento di cancellazione

DISPONIBILITÀ.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Descrizione evento liquidazione

Quando il CRS viene avviato correttamente, viene creato un evento INFORMATION.

DISPONIBILITÀ.DB_GUEST.CRS_INSTANCE.EVICTION

Nome evento

DISPONIBILITÀ.DB_GUEST.CRS_INSTANCE.EVICTION

Descrizione dell'evento

Viene creato un evento di tipo CRITICAL quando il servizio CRS (Cluster Ready Service) evita un nodo dal cluster. Il CRS alert.log viene analizzato per l'errore CRS-1632 che indica che è in corso la rimozione di un nodo dal cluster.

Esposizione del problema

Oracle Clusterware è stato 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 del disco, un computer bloccato o gravemente degradato o un processo ocssd.bin bloccato. Lo scopo di questa rimozione dei nodi è quello di mantenere lo stato generale del cluster rimuovendo i membri in cattivo stato.

Rischio

Durante il tempo necessario per riavviare il nodo rimosso, il nodo non è in grado di fornire servizi di database per l'applicazione.

Azione/riparazione

La rimozione di un nodo CRS potrebbe essere causata da processi OCSSD (alias 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 gli errori/latenze di rete, i problemi di I/O con i dischi di voting CSS e l'escalation di eliminazione dei membri. Gli sfratti 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 clusterware, il cssdagent log, il cssdmonitor log, il log ocssd, il log lastgasp, /var/log/messages, i dati CHM/OS Watcher e i dettagli dell'inventario opatch.

Per ulteriori informazioni sulla raccolta dei file, vedere TFA (Autonomous Health Framework) e ORAchk/EXAchk. Per ulteriori informazioni sulla risoluzione dei problemi di rimozione dei nodi CRS, vedere Risoluzione dei problemi di eliminazione dei nodi Clusterware (reboot).

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 Server Control Utility (srvctl) o Listener Control (lsnrctl) o qualsiasi azione di manutenzione di Oracle Cloud che utilizza tali comandi, ad esempio l'esecuzione di un aggiornamento del software di Grid Infrastructure. L'evento è di tipo CRITICAL quando un listener SCAN diventa inattivo in modo imprevisto. Quando viene avviato un listener SCAN, viene creato un evento DOWN_CLEARED corrispondente.

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 dell'applicazione al database tramite il listener SCAN non riusciranno.

Azione/riparazione

Avviare il listener SCAN per ricevere l'evento DOWN_CLEARED.

Evento DOWN di tipo INFORMATION

  1. Se l'evento è stato causato da un'azione di manutenzione di Oracle Cloud, ad esempio l'esecuzione di un aggiornamento del 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 da un'azione utente, avviare il listener SCAN alla prossima opportunità.

Evento DOWN di tipo CRITICAL

  1. Controllare lo stato SCAN e riavviare il listener SCAN
    • Eseguire il login alla VM come utente opc e sudo come 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 il file <hostName> indicato nel log. Si noti che l'ora nel payload degli eventi viene 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 Server Control Utility (srvctl) o Listener Control (lsnrctl) o qualsiasi azione di manutenzione di Oracle Cloud che utilizza tali comandi, ad esempio l'esecuzione di un aggiornamento del software di Grid Infrastructure. L'evento è di tipo CRITICAL quando un listener client si interrompe in modo imprevisto. Quando viene avviato un listener client, viene creato un evento DOWN_CLEARED corrispondente.

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 client per ricevere l'evento DOWN_CLEARED.

Evento DOWN di tipo INFORMATION

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

Evento DOWN di tipo CRITICAL

  1. Controllare lo stato del listener client e riavviare il listener client:
    • Eseguire il login alla VM come utente opc e sudo come 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 client su qualsiasi nodo: se il listener client è ancora inattivo. Esaminare la causa dell'errore del listener client:
      1. Utilizzare tfactl per raccogliere i log di CRS e del sistema operativo 30 minuti prima e 10 minuti per hostName indicato nel log. Si noti che l'ora nel payload degli eventi viene 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. Rivedere il log del listener disponibile 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 chiusa 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 del software della home del database. L'evento è di tipo CRITICAL quando un'istanza di database diventa inattiva in modo imprevisto. Viene creato un evento DOWN_CLEARED corrispondente all'avvio di un'istanza di database.

Esposizione del problema

Un'istanza di database è diventata inattiva.

Rischio

Un'istanza di database è diventata inattiva. Ciò può comportare una riduzione delle prestazioni se le istanze di database sono disponibili su altri nodi del cluster oppure 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.

Evento DOWN di tipo INFORMATION

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

Evento DOWN di tipo CRITICAL

  1. Controllare lo stato del database e riavviare l'istanza di database inattiva.
    1. Eseguire il login alla VM come utente oracle:
    2. Impostare 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. Esaminare la causa dell'errore dell'istanza di database.
    1. Rivedere gli eventi TFA (Trace File Analyzer) per il database:
      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
    2. Rivedere l'alert log del database disponibile all'indirizzo:
      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

SALUTE.DB_CLUSTER.CDB.CORRUZIONE

Nome evento

SALUTE.DB_CLUSTER.CDB.CORRUZIONE

Descrizione dell'evento

Rilevato danneggiamento del database nel database primario o in standby. Il database alert.log viene analizzato per rilevare eventuali errori specifici indicativi di danneggiamenti fisici dei blocchi, danneggiamenti logici dei blocchi o danneggiamenti logici dei blocchi 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 significativa perdita di dati se non risolta tempestivamente.

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

  • In un danneggiamento del blocco fisico, chiamato anche corruzione dei media, il database non riconosce affatto il blocco; il checksum non è valido o il blocco contiene tutti gli zeri. Un esempio di danneggiamento del blocco più sofisticato è quando l'intestazione e il piè di pagina del blocco non corrispondono.
  • In un danneggiamento logico del blocco, il contenuto del blocco è fisicamente valido e supera i controlli fisici del blocco; tuttavia, il blocco può essere logicamente incoerente. Esempi di danneggiamento del blocco logico includono il tipo di blocco errato, i dati errati o il numero di sequenza del blocco di redo, il danneggiamento di una riga o di una voce di indice o il danneggiamento del dizionario dati.

I danneggiamenti dei blocchi possono anche essere suddivisi in corruzione dei blocchi e corruzione dei blocchi interni:

  • In una corruzione intra-blocco, la corruzione si verifica nel blocco stesso e può essere una corruzione fisica o logica del blocco.
  • In una corruzione tra blocchi, la corruzione si verifica tra blocchi e può essere solo una corruzione logica del blocco.

Oracle verifica la presenza dei seguenti errori nel file alert.log:

  • ORA-01578
  • ORA-00752
  • ORA-00753
  • ORA-00600 [3020]
  • ORA-00600 [kdsgrp1]
  • ORA-00600 [kclchkblk_3]
  • ORA-00600 [13013]
  • ORA-00600 [5463]

Rischio

Un'interruzione dei dati si verifica quando un componente hardware, software o di rete causa la lettura o la scrittura di dati danneggiati. L'impatto a livello di servizio di un'indisponibilità di danneggiamento dei dati può variare, da una piccola parte dell'applicazione o del database (fino a un singolo blocco di database) a una grande parte dell'applicazione o del database (rendendola 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 di evento corrente attiva attualmente i danneggiamenti dei blocchi fisici (ORA-01578), le scritture perse (ORA-00752, ORA-00753 e ORA-00600 con il primo argomento 3020) e i 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, un estratto del file alert.log e di trace contenente gli errori di danneggiamento, qualsiasi cronologia delle modifiche recenti all'applicazione, al database o al software e qualsiasi log di sistema, clusterware e database per lo stesso periodo di tempo. Per tutti questi casi, dovrebbe essere disponibile una raccolta TFA da allegare alla richiesta di servizio.
  2. Per ulteriori informazioni sui suggerimenti per la riparazione, vedere Nota principale per la gestione dei problemi di danneggiamento di Oracle Database.

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

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 fisici dei dati 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 dei redo del database primario o in standby. Le seguenti note saranno utili:

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

SALUTE.DB_CLUSTER.CDB.ARCHIVER_HANG

Nome evento

SALUTE.DB_CLUSTER.CDB.ARCHIVER_HANG

Descrizione dell'evento

Viene creato un evento di tipo CRITICAL 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 verrà 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

  • Per determinare la frequenza oraria di ogni thread/istanza, vedere Script per trovare la cronologia degli switch di redo e la dimensione del log di archivio per ogni istanza in RAC (ID documento 2373477.1).
    • Se un bucket orario è maggiore di 12, valutare la possibilità di ridimensionare i redo log in linea. Per le fasi di ridimensionamento, vedere il punto 2.
  • Se il database non risponde temporaneamente, l'archiviatore potrebbe non essere in grado di tenere il passo con il redo log generato.
    • Consultare alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log, per "Tutti i log online richiedono l'archiviazione", più eventi in un breve periodo possono indicare 2 possibili soluzioni.
      1. Se il numero di gruppi di redo log per thread è inferiore a 4, considerare l'opportunità di aggiungere ulteriori gruppi di log per raggiungere 4, vedere item1 di seguito per aggiungere i passi di redo log.
      2. L'altra possibile soluzione consiste nel ridimensionare i redo log, vedere il punto 2 di seguito per i passi di ridimensionamento.
  • Per le linee guida relative al dimensionamento per Data Guard e non Data Guard, vedere Configurare i redo log in linea in modo appropriato.
  • Aggiungere un gruppo di redo log per ogni thread. Il redo log aggiuntivo deve essere uguale alla dimensione del log corrente.
    1. Utilizzare la query seguente: 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Aggiungere un nuovo gruppo per thread utilizzando le stesse dimensioni dei redo log correnti.
      alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>
  • Ridimensionare i redo log in linea aggiungendo redo log più grandi ed eliminando i redo log più piccoli correnti.
    1. Utilizzare la query seguente: 
      select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
    2. Aggiungere lo stesso numero di redo log per ogni thread number_of_groups_per_thread attualmente esistente. Il file new_redo_size_in_bytes deve essere basato su Configura log di redo in linea in modo appropriato. 
      1. alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
      2. I redo log più piccoli originali devono essere eliminati. Un redo log può essere eliminato solo se il relativo stato è inattivo. Per determinare lo stato di un redo log, effettuare la selezione riportata di seguito. 
        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        Eliminare i redo log più piccoli originali:

        alter database drop logfile <group#>;
  • Se il database non risponde, la destinazione dell'archivio di log primario e l'alternativa potrebbero essere pieni.

SALUTE.DB_CLUSTER.CDB.DATABASE_HANG

Nome evento

SALUTE.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.

  • Rivedere gli eventi TFA per il database per i pattern di messaggi riportati di seguito corrispondenti alla data/ora dell'evento: ORA-32701, "DIA0 Critical Database Process Blocked" o "DIA0 Critical Database Process As Root". 
    tfactl events -database <dbName> -instance <instanceName>
  • Esaminare il file alert.log associato nella seguente posizione: 
    $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
  • Per ORA-32701: un sistema sovraccarico può causare progressi lenti, che possono essere interpretati come un blocco. Il resolver di blocco può tentare di risolvere il blocco interrompendo il processo di blocco finale.
  • Per i messaggi del processo di database critico DIA0: esaminare le righe di diagnostica correlate che indicano il processo e il motivo del blocco.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Nome evento

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Descrizione dell'evento

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

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/recuperabilità del database. L'oggetto RPO (Recoverability Point Object) e l'oggetto RTO (Recoverability Time Object) possono essere interessati.

Azione/riparazione

Esaminare i log RMAN corrispondenti alla data/ora dell'evento. Si noti che la data e l'ora dell'evento eventTime sono in formato UTC. Modificare le impostazioni in base alle esigenze per il fuso orario della VM.

Per i backup gestiti da Oracle:

  • L'output RMAN è disponibile all'indirizzo /opt/oracle/dcs/log/<hostname>/rman.
  • Controllare il log per eventuali errori.
    • Se l'errore è dovuto a un evento esterno a RMAN, ad esempio la posizione di backup era piena o a un problema di rete, risolvere il problema esterno.
    • Per altri errori di script RMAN, raccogliere i log di diagnostica e aprire una richiesta di servizio.
      dbcli collect-diagnostics -h
      Usage: collect-diagnostics [options]
  Options:
    --components, -c
       Supported components: [all, dcs, crs, acfs, asm, db]
       all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
       dcs -- Collects diagnosis for dcs
       crs -- Collects diagnosis for crs
       acfs -- Collects diagnosis for acfs
       asm -- Collects diagnosis for asm.
       db -- Collects diagnosis for db.
       For multiple parameter values, follow the example as "-c c1 c2"
       Default: [dcs]
    --dbNames, -d
       Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
    --endTime, -et
       End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
    --help, -h
       get help
    --json, -j
       json output
    --objectstoreuri, -ou
       Pre Authenticated Request URI
    --redaction, -r
       Diagnostic logs redaction. Might take longer time with some components.
    --startTime, -st
    Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
  • Se il problema è transitorio o viene risolto, eseguire un nuovo backup incrementale. Per ulteriori informazioni, vedere Backup di un database mediante la console.

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

  • Esaminare i log RMAN per il backup.

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%. Un evento di tipo INFORMATION viene creato quando l'uso dello spazio dei gruppi di dischi ASM scende al di sotto del 90%.

Esposizione del problema

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

Rischio

Lo spazio del gruppo di dischi ASM insufficiente può causare errori di creazione del database, errori di creazione di tablespace e file di dati, errori di estensione automatica del file di dati o errori di ribilanciamento ASM.

Azione/riparazione

Lo spazio utilizzato per il 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 indicati di seguito.

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

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 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 già sottoposti a backup al di fuori dell'area di recupero flash (FRA). Per ulteriori informazioni, vedere Gestione dell'area di recupero rapido.