Rajat DBA’S Blog

Questa è una copia della Nota di riferimento di Metalink 22908.1, per coloro che non hanno accesso ad essa.

1. Che cos’è un latch?
   I latch sono meccanismi di serializzazione a basso livello utilizzati per proteggere le strutture di dati condivise in SGA. L’implementazione dei fermi dipende dal sistema operativo, in particolare per quanto riguarda se un processo attenderà un fermo e per quanto tempo.

Un latch è un tipo di blocco che può essere acquisito e liberato molto rapidamente. I fermi vengono in genere utilizzati per impedire a più di un processo di eseguire lo stesso pezzo di codice in un dato momento. Associato a ciascun latch è una procedura di pulizia che verrà chiamata se un processo muore mentre si tiene il latch. I fermi hanno un livello associato che viene utilizzato per prevenire i deadlock. Una volta che un processo acquisisce un latch a un certo livello, non può successivamente acquisire un latch a un livello uguale o inferiore a quel livello (a meno che non lo acquisisca nowait).

2.Latches vs. Enqueues

Enqueues sono un altro tipo di meccanismo di blocco utilizzato in Oracle.
Un enqueue è un meccanismo più sofisticato che consente a diversi processi simultanei di avere un diverso grado di condivisione di risorse “note”. Qualsiasi oggetto che può essere utilizzato contemporaneamente, può essere protetto con enqueues. Un buon esempio è di serrature sui tavoli. Consentiamo diversi livelli di condivisione sulle tabelle, ad esempio due processi possono bloccare una tabella in modalità condividi o in modalità condividi aggiornamento, ecc. Una differenza è che l’accodamento è ottenuto utilizzando un meccanismo di blocco specifico del sistema operativo. Un accodamento consente all’utente di memorizzare un valore nel blocco, ovvero la modalità in cui lo stiamo richiedendo. Il gestore di blocco del sistema operativo tiene traccia delle risorse bloccate. Se a un processo non può essere concesso il blocco perché è incompatibile con la modalità richiesta e il blocco viene richiesto con wait, il sistema operativo mette il processo richiedente su una coda di attesa che viene servita in FIFO.

Un’altra differenza tra latch e enqueues è che nei latch non c’è una coda ordinata di camerieri come in enqueues. I camerieri Latch possono utilizzare i timer per riattivare e riprovare o girare (solo in multiprocessori). Poiché tutti i camerieri stanno riprovando contemporaneamente (a seconda dello scheduler), chiunque potrebbe ottenere il latch e, in teoria, il primo da provare potrebbe essere l’ultimo da ottenere.

1. Quando dobbiamo ottenere un latch?

Un processo acquisisce un latch quando si lavora con una struttura nell’area SGA (System Global Area). Continua a tenere il fermo per il periodo di tempo in cui funziona con la struttura. Il fermo viene rilasciato quando il processo è terminato con la struttura. Ogni latch protegge un diverso set di dati, identificati dal nome del latch.

Oracle utilizza istruzioni atomiche come “test and set” per operare su fermi. I processi in attesa di eseguire una parte di codice per la quale un latch è già stato ottenuto da un altro processo attenderanno fino al rilascio del latch. Esempi sono redo allocation latch, copy latch, archive control latch ecc. L’idea di base è bloccare l’accesso simultaneo a strutture di dati condivise. Poiché le istruzioni per impostare e liberare i fermi sono atomici, il sistema operativo garantisce che solo un processo lo ottenga. Poiché è solo un’istruzione, è abbastanza veloce. I fermi sono tenuti per brevi periodi di tempo e forniscono un meccanismo per la pulizia nel caso in cui un supporto muoia anormalmente mentre lo tiene. Questa pulizia viene eseguita utilizzando i servizi di PMON.

1. Modalità di richiesta dei fermi?

La richiesta di fermi può essere effettuata in due modalità:” disposto ad aspettare “o”no wait”. Normalmente, i fermi saranno richiesti in modalità “disposto ad attendere”. Una richiesta in modalità” willing-to-wait ”
eseguirà il loop, attenderà e richiederà di nuovo fino a quando non si ottiene il latch. In modalità “no wait” il processo richiede il latch. Se uno non è disponibile, invece di aspettare, ne viene richiesto un altro. Solo quando tutti falliscono, il processo del server deve attendere.

Esempi di latch “disposti ad aspettare” sono: shared pool and library cache latch
Un esempio di latch “no wait” è il latch redo copy.

5. Quali sono le cause fermo contesa?Se un fermo richiesto è occupato, il processo che lo richiede gira, prova di nuovo e se ancora non disponibile, gira di nuovo. Il ciclo viene ripetuto fino a un numero massimo di volte determinato dal parametro di inizializzazione _SPIN_COUNT. Se dopo questo intero ciclo, il latch non è ancora disponibile, il processo deve cedere la CPU e andare a dormire. Inizialmente è dorme per un centisecondo. Questa volta è raddoppiato in ogni sonno successivo.

Ciò provoca un rallentamento e si traduce in un utilizzo aggiuntivo della CPU, fino a quando non è disponibile un latch. L’utilizzo della CPU è una conseguenza della “rotazione” del processo. “Spinning” significa che il processo continua a cercare la disponibilità del fermo dopo determinati intervalli di tempo, durante i quali dorme.

1. Come identificare la contesa per i fermi interni?

Viste del dizionario dei dati rilevanti da interrogare:

V LATCH LATCH
V V LATCHHOLDER
VNAME LATCHNAME

Ogni riga della tabella V LATCH LATCH contiene statistiche per un diverso tipo di latch. Le colonne della tabella riflettono l’attività per diversi tipi di richieste latch. La distinzione tra questi tipi di richieste è se il processo richiedente continua a richiedere un latch se non è disponibile:

willing-to-wait Se il latch richiesto con una richiesta willing-to-wait
non è disponibile, il processo richiedente
attende un breve periodo di tempo e richiede nuovamente il latch.
Il processo continua ad attendere e richiedere fino a quando
il latch è disponibile.

nessuna attesa Se il latch richiesto con una richiesta immediata è
non disponibile, il processo di richiesta non attende
, ma continua l’elaborazione.

V information LATCHNAME informazioni chiave:

OTTIENE il numero di richieste di attesa di successo per
un latch.

MANCA il numero di volte in cui una richiesta iniziale di attesa
non ha avuto successo.

SLEEPS Numero di volte in cui un processo ha atteso una richiesta di latch
dopo una richiesta iniziale di attesa.

IMMEDIATE_GETS Numero di richieste immediate riuscite per ogni latch.

IMMEDIATE_MISSES Numero di richieste immediate non riuscite per ogni latch.

Calcolo del rapporto hit latch

Per ottenere il rapporto Hit per i latch applicare la seguente formula:

“willing-to-wait” Hit Ratio=(GETS-MISSES)/GETS
“no wait” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

Questo numero dovrebbe essere vicino a 1. In caso contrario, sintonizzare in base al nome latch

1. Script SQL utili per ottenere informazioni latch

/*
** Visualizzare statistiche latch a livello di sistema.
*/
nome della colonna formato A32 troncare voce “FERMO”NOME
colonna pid voce “TITOLARE PID”
selezionare c.nome un.addr,un.si,un.manca una.posti letto,
un.immediate_gets,un.immediate_misses,b.pid
v$fermo a, v$latchholder b, v$latchname c
dove.addr = b.laddr(+)
e un.fermo# = c.fermo#
order by a.fermo#;

/*
** Dato un latch indirizzo, scoprire il gancio nome.
*/
formato nome colonna a64 intestazione’Nome’
seleziona a.name da v lat latchname a, v latch latch b
dove b. addr = ‘& addr ‘
e b. latch # =a. latch#;

/*
** Visualizzare le statistiche latch per nome latch.
*/
nome della colonna formato a32 rubrica “FERMO il NOME”
colonna pid rubrica “TITOLARE PID’
selezionare c.nome un.addr,un.si,un.manca una.posti letto,
un.immediate_gets,un.immediate_misses,b.pid
v$fermo a, v$latchholder b, v$latchname c
dove.addr = b.laddr(+) e un.fermo# = c.fermo#
e c.nome like ‘&latch_name%’ order by a.fermo#;

1. Elenco di tutti i latch

Le versioni Oracle potrebbero differire nel latch# assegnato ai latch esistenti.
La seguente query ti aiuterà a identificare tutti i fermi e il numero assegnato.

formato nome colonna a40 intestazione ‘LATCH NAME’
seleziona latch#, nome da v lat latchname;

1. Elenco dei fermi che sono di maggior preoccupazione per un DBA

• FERMI CACHE BUFFER: ci sono due fermi principali che proteggono i blocchi di dati nella cache buffer. La contesa per questi due fermi si vede di solito quando un database ha alti tassi di I/O. Possiamo ridurre la contesa per questi fermi e sintonizzarli regolando determinati init.parametri ora.

Cache buffer catene latch:

Questo latch viene acquisito ogni volta che si accede a un blocco nella cache del buffer (bloccato).

Ridurre la contesa per le catene di buffer della cache latch di solito richiede di ridurre i tassi di I/O logici sintonizzando e riducendo al minimo i requisiti di I/O dell’SQL coinvolto. Alti tassi di I/O potrebbero essere un segno di un blocco caldo (ovvero un blocco ad alto accesso).

Cfr. Nota 163424.1 Come identificare un blocco caldo all’interno del database per identificare correttamente questo problema.

Cache buffer LRU chain latch:

Il cache buffer lru chain latch viene acquisito per introdurre un nuovo blocco nella cache del buffer e quando si scrive un buffer su disco, in particolare quando si tenta di eseguire la scansione della catena LRU (utilizzata meno di recente) contenente tutti i blocchi sporchi nella cache del buffer.

È possibile ridurre la contesa per il blocco della catena lru del buffer della cache aumentando la dimensione della cache del buffer e riducendo così la velocità con cui vengono introdotti nuovi blocchi nella cache del buffer. Due parametri dettano la dimensione della cache del buffer, DB_BLOCK_SIZE e DB_BLOCK_BUFFERS. In realtà, solo i DB_BLOCK_BUFFERS possono essere modificati senza ricreare il database. Attenzione, quando si sintonizza il pool di buffer, evitare l’uso di buffer aggiuntivi che contribuiscono poco o nulla al rapporto hit della cache. Un errore comune è continuare ad aumentare il valore di DB_BLOCK_BUFFERS. Tali aumenti non hanno alcun effetto se si eseguono scansioni complete della tabella o altre operazioni che non utilizzano la cache del buffer. Più pool di buffer possono aiutare a ridurre la contesa su questo latch.È possibile creare ulteriori fermi catena lru buffer cache regolando il parametro di configurazione DB_BLOCK_LRU_LATCHES. Potresti essere in grado di ridurre il carico sui fermi della catena del buffer della cache aumentando il parametro di configurazione _DB_BLOCK_HASH_BUCKETS

• FERMI DEL BUFFER REDOLOG: ci sono due fermi del buffer Redo, il fermo di allocazione redo e il fermo di copia redo. Il latch redo allocation deve essere acquisito per allocare spazio all’interno del buffer. Se la voce di log redo da effettuare è maggiore del parametro di configurazione LOG_SMALL_ENTRY_MAX_SIZE, la sessione che acquisisce il latch di allocazione redo può copiare immediatamente la voce nel buffer redo tenendo premuto il latch di allocazione. Se la voce del registro è maggiore di LOG_SMALL_ENTRY_MAX_SIZE, la sessione rilascerà il latch di allocazione redo e acquisirà il latch di copia redo per copiare la voce. C’è solo un latch di allocazione redo, ma potrebbero esserci fino a latch di allocazione LOG_SIMULTANEOUS_COPIES.

Redo allocation latch:

Questo latch controlla l’allocazione dello spazio per le voci redo nel buffer redo log. C’è un fermo di allocazione di rifare per istanza.

La contesa per questo latch in Oracle7 può essere ridotta diminuendo il valore di LOG_SMALL_ENTRY_MAX_SIZE su sistemi multi-cpu per forzare l’uso di
redo copy latch. In Oracle8i questo parametro è obsoleto, quindi è necessario considerare di aumentare la dimensione del LOG_BUFFER o ridurre il carico del buffer di log utilizzando le funzionalità NOLOGGING quando possibile.

Redo copy latch:

Questo latch viene utilizzato per scrivere i record redo nel buffer redolog. Questo latch è atteso su entrambi i sistemi single e multi-cpu.

Nei sistemi multi-cpu, la contesa può essere ridotta aumentando il valore di LOG_SIMULTANEOUS_COPIES (Nascosto in Oracle8i) e / o aumentando LOG_ENTRY_PREBUILD_THRESHOLD (non documentato in Oracle7).

• CACHE DELLA LIBRERIA

Latch della cache della libreria:

I latch della cache della libreria proteggono le istruzioni SQL e le definizioni degli oggetti memorizzati nella cache della libreria all’interno del pool condiviso. Il latch della cache della libreria deve essere acquisito per aggiungere una nuova istruzione alla cache della libreria. Durante un’analisi, Oracle cerca nella cache della libreria un’istruzione corrispondente. Se non ne viene trovato uno, Oracle analizzerà l’istruzione SQL, otterrà il latch della cache della libreria e inserirà il nuovo SQL.

La prima risorsa per ridurre la contesa su questo latch è garantire che l’applicazione stia riutilizzando il più possibile la rappresentazione dell’istruzione SQL. Utilizzare le variabili bind quando possibile nell’applicazione. Gli errori su questo latch possono anche essere un segno che l’applicazione sta analizzando SQL ad un ritmo elevato e potrebbe soffrire di un eccessivo sovraccarico della CPU di analisi.Se l’applicazione è già sintonizzata, SHARED_POOL_SIZE può essere aumentato. Tieni presente che se l’applicazione non utilizza la cache della libreria in modo appropriato, la contesa potrebbe essere peggiore con una struttura più grande da gestire.

Il parametro _KGL_LATCH_COUNT controlla il numero di latch della cache della libreria. Il valore predefinito dovrebbe essere adeguato, ma se la contesa per il latch della cache della libreria non può essere risolta, potrebbe essere consigliabile aumentare questo valore. Il valore predefinito per _KGL_LATCH_COUNT è il numero primo successivo dopo CPU_COUNT. Questo valore non può superare 66 (Vedi: ).

Blocco pin della cache della libreria:

Il blocco pin della cache della libreria deve essere acquisito quando viene rieseguita un’istruzione nella cache della libreria. Gli errori su questo latch si verificano quando c’è un’esecuzione SQL a tassi molto alti.

C’è poco che si può fare per ridurre il carico sul pin latch della cache della libreria, anche se si usano sinonimi privati piuttosto che pubblici o riferimenti diretti a oggetti come OWNER.TABELLA può aiutare.

• LATCH RELATIVI AL POOL CONDIVISO

Latch del pool condiviso:

Mentre il latch della cache della libreria protegge le operazioni all’interno della cache della libreria, il latch del pool condiviso viene utilizzato per proteggere le operazioni critiche durante l’allocazione e la liberazione della memoria nel pool condiviso.
Se un’applicazione fa uso di SQL letterale (non condiviso), questo può limitare gravemente la scalabilità e il throughput. Il costo dell’analisi di una nuova istruzione SQL è costoso sia in termini di requisiti della CPU che di numero di volte in cui la cache della libreria e i latch del pool condiviso potrebbero dover essere acquisiti e rilasciati. Prima di Oracle9, ci deve essere solo uno di questi latch per l’intero database per proteggere l’allocazione della memoria nella cache della libreria. In Oracle9 sono stati introdotti più bambini per alleviare la contesa su questa risorsa.

I modi per ridurre il latch del pool condiviso sono, evitare analisi difficili quando possibile, analizzare una volta, eseguire molti. L’eliminazione di SQL letterale è anche utile per evitare il latch del pool condiviso. Anche la dimensione di shared_pool e l’uso di MTS (opzione server condiviso) influenzano notevolmente il latch del pool condiviso. Nota 62143.1 spiega come identificare e correggere i problemi con il pool condiviso e il latch del pool condiviso.

Riga oggetti cache latch:

Questo latch entra in gioco quando i processi utente tentano di accedere ai valori del dizionario dei dati memorizzati nella cache.

Non è comune avere contesa in questo latch e l’unico modo per ridurre la contesa per questo latch è aumentando la dimensione del pool condiviso (SHARED_POOL_SIZE).

1. Messa a punto di _SPIN_COUNT (_LATCH_SPIN_COUNT in Oracle7)

SPIN_COUNT controlla quante volte il processo tenterà nuovamente di ottenere il latch prima di ritirarsi e andare a dormire. Ciò significa fondamentalmente che il processo si trova in un ciclo di CPU stretto che cerca continuamente di ottenere il latch per i tentativi di SPIN_COUNT. Su un singolo sistema CPU se un processo Oracle tenta di acquisire un latch ma è tenuto da qualcun altro, il processo rilascerà la CPU e andrà a dormire per un breve periodo prima di riprovare. Tuttavia, su un sistema multi processore (SMP) è possibile che il processo che tiene il latch sia in esecuzione su una delle altre CPU e quindi potenzialmente rilascerà il latch nelle prossime istruzioni (i latch sono solitamente tenuti solo per periodi di tempo molto brevi).

Le prestazioni possono essere regolate modificando il valore di SPIN_COUNT. Se si utilizza un valore elevato, il fermo sarà raggiunto prima che se si utilizza un valore basso. Tuttavia, è possibile utilizzare più tempo di rotazione della CPU per ottenere il latch se si utilizza un valore elevato per SPIN_COUNT. È possibile ridurre questa probabilità di sospensione della sessione aumentando il valore dei parametri di configurazione _LATCH_SPIN_COUNT o SPIN_COUNT. Questo parametro controlla il numero di tentativi che la sessione farà per ottenere il latch prima di dormire. La rotazione sul latch consuma la CPU, quindi se aumenti questo parametro, potresti vedere un aumento dell’utilizzo complessivo della CPU dei tuoi sistemi. Se il tuo computer è vicino al 100% della CPU e la tua applicazione è basata sul throughput piuttosto che sul tempo di risposta, potresti considerare di ridurre SPIN_COUNT per risparmiare CPU. La regolazione di SPIN_COUNT è prova ed errore. In generale, aumentare SPIN_COUNT solo se ci sono abbastanza risorse CPU gratuite disponibili sul sistema e diminuirlo solo se non c’è capacità CPU di riserva.