Ecco alcuni degli eventi di attesa di Common Oracle che tutti dovrebbero conoscere.
Aspetta eventi
Puoi scoprire quale sessione evento lo sta aspettando seguendo la query
select event from V$session_wait where sid=&1
Sto cercando di spiegare alcuni eventi di attesa Oracle comuni, le cause e le risoluzioni
accodare
Il processo è in attesa di una coda di Oracle (un blocco che puoi vedere in v$lock). Ciò si verifica in genere quando un utente tenta di aggiornare una riga in una tabella che viene attualmente aggiornata da un altro utente. I bloccanti possono essere scoperti utilizzando la seguente query
select * from dba_waiters
pin della cache della libreria
Il processo vuole bloccare un oggetto in memoria nella cache della libreria per l'esame, assicurando che nessun altro processo possa aggiornare l'oggetto contemporaneamente. Ciò accade durante la compilazione o l'analisi di un oggetto PL/SQL o di una vista. Evita di compilare oggetti PL/SQL o viste Oracle in tempi di utilizzo elevati per evitare questo evento di attesa
blocco del caricamento della cache della libreria
Il processo è in attesa dell'opportunità di caricare un oggetto o una parte di un oggetto nella cache della libreria. (Solo un processo può caricare un oggetto o una parte di un oggetto alla volta.)
libero fermo
Il processo è in attesa di un latch trattenuto da un altro processo. (Questo evento di attesa non si applica ai processi che girano in attesa di un latch; quando un processo è in rotazione, non è in attesa.). I latch sono dispositivi di serializzazione leggeri utilizzati per coordinare l'accesso multiutente a strutture di dati condivisi, oggetti, e file.
I chiavistelli sono blocchi progettati per essere mantenuti per periodi di tempo estremamente brevi, ad esempio il tempo necessario per modificare una struttura di dati in memoria. Vengono utilizzati per proteggere determinate strutture di memoria, come la cache del buffer dei blocchi del database o la cache della libreria nel pool condiviso.
Gli Oracle Latch vengono generalmente richiesti internamente in modalità "disposto ad attendere". Ciò significa che se il latch non è disponibile, la sessione richiedente andrà in sospensione per un breve periodo di tempo e ritenterà l'operazione in un secondo momento. Altri latch possono essere richiesti in una modalità "immediata", che è concettualmente simile a SELECT FOR UPDATE NO-WAIT, il che significa che il processo farà qualcos'altro, come provare a prendere un latch fratello equivalente che potrebbe essere gratuito, piuttosto che sedersi e aspettare che questo fermo diventi disponibile. Poiché molte richieste potrebbero essere in attesa di un latch contemporaneamente, potresti vedere alcuni processi attendere più a lungo di altri.
I latch vengono assegnati in modo piuttosto casuale, in base alla fortuna del sorteggio, se vuoi. Qualunque sessione richieda un latch subito dopo il rilascio, lo riceverà. Non c'è una fila di camerieri a scatto, solo una folla di camerieri che riprova costantemente.
Il buffer è occupato attende
Il processo vuole accedere a un blocco di dati che non è attualmente in memoria, ma un altro processo ha già inviato una richiesta di I/O per leggere il blocco in memoria. (Il processo è in attesa che l'altro processo finisca di portare il blocco in memoria.). Gli hot block possono essere trovati utilizzando la vista V$BH
Lettura sparsa del file db
Il processo ha inviato una richiesta di I/O per leggere una serie di blocchi contigui da un file di dati nella cache del buffer ed è in attesa del completamento dell'operazione. Ciò si verifica in genere durante una scansione completa della tabella o una scansione completa dell'indice.
Dovremmo verificare se la query deve utilizzare la scansione completa della tabella. Assicurati che le statistiche di Oracle Optimizer siano aggiornate. Usa lo sfoltimento delle partizioni per ridurre il numero di blocchi visitati
Se una query che è stata eseguita correttamente per un po' di tempo all'improvviso registra molto tempo sull'evento di lettura sparsa del file db e non c'è stata una modifica del codice, potresti voler controllare se uno o più indici sono stati eliminati o diventare inutilizzabile.
lettura sequenziale del file db
Il processo ha inviato una richiesta di I/O per leggere un blocco da un file di dati nella cache del buffer e attende il completamento dell'operazione. Ciò si verifica in genere durante una ricerca nell'indice o un recupero da una tabella Oracle tramite ROWID quando il blocco di dati richiesto non è già in memoria. Non lasciarti ingannare dal nome confuso di questo evento di attesa!
Dovremmo controllare se vengono utilizzati gli indici giusti. Un indice errato può compromettere il rendimento della query. Assicurati che le statistiche dell'ottimizzatore siano aggiornate.
lettura parallela del file db
Il processo ha emesso più richieste di I/O in parallelo per leggere i blocchi dai file di dati nella memoria ed è in attesa del completamento di tutte le richieste. La documentazione afferma che questo evento di attesa si verifica solo durante il ripristino, ma in realtà si verifica anche durante l'attività regolare quando un processo raggruppa in batch molte richieste di I/O a blocco singolo e le emette in parallelo. (Nonostante il nome, non vedrai questo evento di attesa durante la query parallela o DML parallelo. In questi casi si verificano invece eventi di attesa con PX nei loro nomi.)
scrittura parallela del file db
Il processo, tipicamente DBWR, ha emesso più richieste di I/O in parallelo per scrivere blocchi sporchi dalla cache del buffer al disco ed è in attesa del completamento di tutte le richieste.
lettura diretta del percorso, scrittura diretta del percorso
Il processo ha emesso richieste di I/O asincrone che ignorano la cache del buffer e attende il loro completamento. Questi eventi di attesa in genere coinvolgono segmenti di ordinamento.
Le istruzioni SQL con funzioni che richiedono ordinamenti, come ORDER BY, GROUP BY, UNION, DISTINCT e ROLLUP, scrivono l'ordinamento viene eseguito nel tablespace temporaneo quando la dimensione dell'input è maggiore dell'area di lavoro in PGA
Assicurati che le statistiche dell'ottimizzatore siano all'altezza dei dati e che la query utilizzi la tabella di guida corretta. Verifica se le colonne dell'indice composito possono essere riorganizzate in modo che corrispondano alla clausola ORDER BY per evitare l'ordinamento completo.
Assicurati che il valore appropriato PGA_AGGREGATE_TARGET sia impostato. Se possibile usa UNION ALL invece di UNION.
Chiusura piscina condivisa
Il latch del pool condiviso viene utilizzato per proteggere le operazioni critiche durante l'allocazione e la liberazione della memoria nel pool condiviso. I conflitti per il pool condiviso e i latch della cache della libreria sono principalmente dovuti a un'intensa analisi dura. Un hard parse si applica a nuovi cursori e cursori che sono scaduti e devono essere rieseguiti
Il costo dell'analisi di una nuova istruzione SQL è costoso sia in termini di requisiti della CPU che del numero di volte che la cache della libreria e il pool condiviso Potrebbe essere necessario acquisire e rilasciare i chiavistelli.
L'eliminazione dell'SQL letterale è utile anche per evitare il latch del pool condiviso
controlla la lettura sequenziale del file
Il processo è in attesa di leggere i blocchi da un file di controllo. Questo accade generalmente
- effettuare un backup dei file di controllo
- condivisione di informazioni (tra istanze) dal file di controllo
- leggere altri blocchi dai file di controllo
- leggere il blocco di intestazione
Se questo è un evento di attesa importante, significa che la posizione del file di controllo deve essere cambiata in una posizione del disco più veloce
controlla la scrittura parallela del file
Il processo ha emesso più richieste di I/O in parallelo per scrivere blocchi in tutti i file di controllo ed è in attesa del completamento di tutte le scritture.
spazio nel buffer di log
Il processo è in attesa che lo spazio diventi disponibile nel buffer di log (lo spazio diventa disponibile solo dopo che LGWR ha scritto il contenuto corrente del buffer di log su disco.) Ciò si verifica in genere quando le applicazioni generano operazioni di ripetizione più velocemente di quanto LGWR possa scriverlo su disco.
Ciò può verificarsi anche se l'I/O sul disco in cui si trovano i registri di ripristino è lento
Non dovrebbero esserci attese di spazio nel buffer di registro nel database. Considerare di aumentare il buffer di registro se è piccolo o di spostare i file di registro su dischi più veloci come i dischi con striping.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
Il pct_buff_alloc_retries dovrebbe essere zero o inferiore a 0,01 (<1%). Se è maggiore, considera di aumentare il buffer di registro. Se è meglio, considera di spostare i file di registro su dischi più veloci come i dischi con striping.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
lettura sequenziale del file di registro
Il processo è in attesa di leggere i blocchi dal redo online in memoria. Ciò si verifica principalmente all'avvio dell'istanza e quando gli archivi del processo ARCH hanno compilato i registri di ripristino online.
scrittura parallela del file di registro
Il processo è in attesa che i blocchi vengano scritti in tutti i membri del log di ripristino online in un gruppo. LGWR è in genere l'unico processo per vedere questo evento di attesa. Attenderà finché tutti i blocchi non saranno stati scritti in tutti i membri.
sincronizzazione dei file di registro
Il processo è in attesa che LGWR termini lo svuotamento del buffer di registro sul disco. Ciò si verifica quando un utente esegue il commit di una transazione. (Una transazione non è considerata confermata fino a quando tutte le operazioni di ripristino per ripristinare la transazione non sono state scritte correttamente su disco.)
Un lento processo LGWR può introdurre attese di sincronizzazione dei file di registro che fanno sì che l'utente sperimenti tempi di attesa durante il commit o il rollback. Gli eventi di scrittura parallela del file di registro e di attesa della sincronizzazione del file di registro sono correlati e devono essere gestiti contemporaneamente.
Dobbiamo provare ad allocare i registri di ripristino su disco ad alte prestazioni (disco a stato solido). Inoltre, dovremmo provare a ridurre il carico su LGWR riducendo i commit nelle applicazioni.
Il backup manuale a caldo può anche introdurre stress nel sistema generando molte operazioni di ripetizione, quindi evitalo durante le ore di punta
A volte LGWR ha fame di risorse CPU. Se il server è molto occupato, anche LGWR può morire di fame per la CPU. Ciò comporterà una risposta più lenta da LGWR, aumentando le attese di "sincronizzazione dei file di registro". Dopotutto, questi richiami di sistema e di I/O devono utilizzare la CPU. In questo caso, la "sincronizzazione dei file di registro" è un sintomo secondario e la risoluzione della causa principale dell'utilizzo elevato della CPU ridurrà le attese di "sincronizzazione dei file di registro".
A causa di problemi di carenza di memoria, LGWR può anche essere paginato. Questo può portare a una risposta più lenta anche da LGWR.
Annulla estensione segmento
La sessione è in attesa dell'estensione o della riduzione di un segmento di annullamento.
scrivi attese complete
La sessione attende la scrittura su disco di un buffer richiesto; il buffer non può essere utilizzato durante la scrittura.
Latch:catene di buffer della cache
I latch delle catene dei buffer della cache vengono utilizzati per proteggere un elenco di buffer nella cache del buffer. Questi latch vengono utilizzati durante la ricerca, l'aggiunta o la rimozione di un buffer dalla cache del buffer.
I blocchi nella cache del buffer vengono posizionati su elenchi collegati (catene di buffer di cache) che si bloccano su una tabella hash. La catena hash su cui è posizionato un blocco si basa sul DBA e sulla CLASSE del blocco. Ogni catena di hash è protetta da un singolo fermo figlio. I processi devono ottenere il latch pertinente per consentire loro di scansionare una catena di hash per un buffer in modo che l'elenco collegato non cambi sotto di essi.
La contesa su questo fermo di solito significa che c'è un blocco in grande contesa (noto come blocco attivo).
Per identificare la catena di buffer a cui si accede pesantemente, e quindi il blocco conteso, guardare le statistiche di latch per i latch delle catene di buffer della cache utilizzando la vista V$LATCH_CHILDREN. Se è presente uno specifico latch figlio di catene di buffer di cache che ha molti più GETS, MISSES e SLEEPS rispetto agli altri latch figlio, allora questo è il latch figlio contestato.
Questo latch ha un indirizzo di memoria, identificato dalla colonna ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Utilizzare il valore nella colonna ADDR unita alla vista V$BH per identificare i blocchi protetti da questo latch. Ad esempio, dato l'indirizzo (V$LATCH_CHILDREN.ADDR) di un latch molto conteso, questo interroga il file e i numeri di blocco:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH è un conteggio di tocco per il buffer. Un valore alto per X$BH.TCH indica un blocco attivo.
Molti blocchi sono protetti da ciascun fermo. Uno di questi buffer sarà probabilmente l'hot block. Qualsiasi blocco con un valore TCH elevato è un potenziale blocco caldo. Esegui questa query un certo numero di volte e identifica il blocco che appare in modo coerente nell'output.
Dopo aver identificato il blocco attivo, interroga DBA_EXTENTS utilizzando il numero del file e il numero del blocco per identificare il segmento.
Informazioni importanti sull'evento di attesa
La visualizzazione v$session_wait visualizza informazioni sugli eventi di attesa per i quali le sessioni attive sono attualmente in attesa. Quella che segue è la descrizione di questa vista e contiene alcune colonne molto utili, in particolare i riferimenti P1 e P2 agli oggetti associati agli eventi di attesa.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Utilizzando v$session_wait, è facile interpretare ogni parametro dell'evento wait utilizzando le corrispondenti colonne di testo descrittivo per quel parametro. Inoltre, sono state aggiunte colonne della classe di attesa in modo che vari eventi di attesa possano essere raggruppati nelle aree di elaborazione correlate come rete, applicazione, idle, concorrenza, ecc.
Questa colonna è stata aggiunta anche alla tabella v$session da 10 g in poi . Quindi puoi semplicemente usare v$session per trovare tutti i dettagli
Ogni evento wait contiene altri parametri che forniscono informazioni aggiuntive sull'evento.
Come trovare le informazioni sull'evento wait e il relativo parametro
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Diciamo ad esempio che abbiamo preso
I valori di input di event_name:db file sparso letto
Valore originale di 3:WHERE NAME ='&event_name A'
Il nuovo valore 3:WHERE NAME ='db file sparso letto'
Il nome P1 P2 P3
file db file di lettura sparsi # blocco # blocchi
file #:numero file dati
Blocco #:numero blocco iniziale
blocchi:per leggere il numero del blocco dati
Ora vediamo come le informazioni di cui sopra possono aiutarci a catturare varie cose
Supponiamo che una sessione particolare attenda un evento di attesa del buffer occupato, l'oggetto database che causa questo evento di attesa può essere facilmente determinato:
select username, event, p1, p2 from v$session_wait where sid = 4563;
L'output di questa query per una sessione particolare con SID 4563 potrebbe essere simile al seguente:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Le colonne P1 e P2 consentono al DBA di determinare i numeri di file e blocchi che hanno causato questo evento di attesa. La query seguente recupera il nome dell'oggetto che possiede il blocco dati 155, il valore di P2 sopra:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
La capacità di analizzare e correggere gli eventi di attesa di Oracle Database è fondamentale in qualsiasi progetto di ottimizzazione. La maggior parte delle attività in un database riguarda la lettura dei dati, quindi questo tipo di ottimizzazione può avere un enorme impatto positivo sulle prestazioni.
Nota:quando si esegue l'analisi delle attese, è fondamentale ricordare che tutti i database Oracle presentano eventi di attesa e che la presenza di attese non indica sempre un problema. In effetti, tutti i database ben ottimizzati presentano dei colli di bottiglia.
possiamo usare l'evento 10046 anche per tracciare l'evento di attesa della sessione
Legge anche
Documentazione Oracle
v$active_session_history
Spiega il piano in Oracle
