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.
- HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE
- AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN
- DISPONIBILITÀ.DB_GUEST.CRS_INSTANCE.EVICTION
- AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN
- AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN
- AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN
- SALUTE.DB_CLUSTER.CDB.CORRUZIONE
- SALUTE.DB_CLUSTER.CDB.ARCHIVER_HANG
- SALUTE.DB_CLUSTER.CDB.DATABASE_HANG
- HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE
- HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE
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.
- 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.
- Imposta il criterio di rimozione automatica utilizzando gli strumenti cloud. Per ulteriori informazioni, vedere Comandi Autologcleanpolicy.
- 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
- 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
- I seguenti eventi di applicazione delle patch interromperanno CRS
- Aggiornamento GRID
- Aggiornamento del cliente
- Aggiornamento dell'host
- I seguenti eventi di applicazione delle patch interromperanno CRS
- Se CRS si è arrestato in modo imprevisto, è possibile controllare lo stato corrente eseguendo il comando
crsctl check crs
.- 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
.
- 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
- 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. - Riavviare il CRS eseguendo il comando
crsctl start crs
. - 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
- 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.
- Se l'evento è stato causato da un'azione utente, avviare il listener SCAN alla prossima opportunità.
Evento DOWN di tipo CRITICAL
- Controllare lo stato SCAN e riavviare il listener SCAN
- Eseguire il login alla VM come utente
opc
esudo
come utentegrid
:[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:- 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 raccoltatfactl
, 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"
- I problemi del listener SCAN vengono registrati:
/u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace
- Raccogliere sia i log CRS che quelli del sistema operativo 30 minuti prima e 10 minuti per il file
- Eseguire il login alla VM come utente
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
- 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.
- Se l'evento è stato causato da un'azione utente, avviare il listener client all'opportunità successiva.
Evento DOWN di tipo CRITICAL
- Controllare lo stato del listener client e riavviare il listener client:
- Eseguire il login alla VM come utente
opc
esudo
come utentegrid
:[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:
- Utilizzare
tfactl
per raccogliere i log di CRS e del sistema operativo 30 minuti prima e 10 minuti perhostName
indicato nel log. Si noti che l'ora nel payload degli eventi viene sempre fornita in UTC: per la raccoltatfactl
, 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"
- Rivedere il log del listener disponibile in:
/u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace
- Utilizzare
- Eseguire il login alla VM come utente
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
- 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.
- Se l'evento è stato causato da un'azione dell'utente, avviare l'istanza di database interessata alla prossima opportunità.
Evento DOWN di tipo CRITICAL
- Controllare lo stato del database e riavviare l'istanza di database inattiva.
- Eseguire il login alla VM come utente
oracle
: - Impostare l'ambiente.
[oracle@vm ~] . <dbName>.env
- Controllare lo stato del database:
[oracle@vm ~] srvctl status database -db <dbName>
- Avviare l'istanza di database:
[oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>
- Eseguire il login alla VM come utente
- Esaminare la causa dell'errore dell'istanza di database.
- Rivedere gli eventi TFA (Trace File Analyzer) per il database:
[oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
- Rivedere l'alert log del database disponibile all'indirizzo:
$ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
- Rivedere gli eventi TFA (Trace File Analyzer) per il database:
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:
- 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 filealert.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. - 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:
- OERR: ORA-1578 "Blocco dati ORACLE danneggiato (file # %s, blocco # %s)" Nota principale (ID documento 1578.1)
- Come identificare tutti gli oggetti danneggiati nel database con RMAN (ID documento 472231.1)
- Come identificare l'oggetto danneggiato segnalato da ORA-1578 / RMAN / DBVERIFY (ID documento 819533.1)
- Nota principale per la gestione dei problemi di danneggiamento di Oracle Database
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:
- Nota principale per la gestione dei problemi di danneggiamento di Oracle Database
- Se si dispone di un danneggiamento della scrittura in standby e perso nel database primario o in standby, vedere Risoluzione di ORA-00752 o ORA-600 [3020] durante il recupero in standby (ID documento 1265884.1).
Per i danneggiamenti logici (in genere rilevati da ORA-00600
con argomenti di kdsgrp1
, kclchkblk_3
, 13013
o 5463
)
- Per ulteriori informazioni sull'errore rilevato, vedere Nota principale per la gestione dei problemi di danneggiamento di Oracle Database.
- Se si dispone di un danneggiamento logico e in standby sul database primario, vedere Risoluzione degli errori di danneggiamento dei blocchi logici in un database in standby fisico (ID documento 2821699.1).
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.- 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.
- L'altra possibile soluzione consiste nel ridimensionare i redo log, vedere il punto 2 di seguito per i passi di ridimensionamento.
- Consultare
- 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.
- 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
- 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>
- Utilizzare la query seguente:
- Ridimensionare i redo log in linea aggiungendo redo log più grandi ed eliminando i redo log più piccoli correnti.
- 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
- Aggiungere lo stesso numero di redo log per ogni thread
number_of_groups_per_thread
attualmente esistente. Il filenew_redo_size_in_bytes
deve essere basato su Configura log di redo in linea in modo appropriato.alter database add logfile thread <thread_number> group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
- 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#>;
- Utilizzare la query seguente:
- Se il database non risponde, la destinazione dell'archivio di log primario e l'alternativa potrebbero essere pieni.
- Per ulteriori informazioni su come liberare spazio nei gruppi di dischi RECO e DATA, vedere HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE.
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.
- 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:
- 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:
- Elimina punti di ripristino garantiti non necessari. Per ulteriori informazioni, vedere Utilizzo dei punti di ripristino normali e garantiti.
- 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.