blogul Rajat DBA

aceasta este o copie a notei de referință Metalink 22908.1, pentru cei care nu au acces la ea.

1. ce este un zăvor?
   zăvoarele sunt mecanisme de serializare de nivel scăzut utilizate pentru a proteja structurile de date partajate în SGA. Implementarea zăvoarelor depinde de sistemul de operare, în special în ceea ce privește dacă un proces va aștepta un zăvor și cât timp.

un zăvor este un tip de încuietoare care poate fi achiziționat și eliberat foarte repede. Zăvoarele sunt de obicei utilizate pentru a împiedica mai multe procese să execute aceeași bucată de cod la un moment dat. Asociat cu fiecare zăvor este o procedură de curățare care va fi apelată dacă un proces moare în timp ce țineți zăvorul. Zăvoarele au un nivel asociat care este utilizat pentru a preveni blocajele. Odată ce un proces dobândește un zăvor la un anumit nivel, acesta nu poate dobândi ulterior un zăvor la un nivel egal sau mai mic decât acel nivel (cu excepția cazului în care îl dobândește nowait).

2.Zăvoarele vs. Enqueues

Enqueues sunt un alt tip de mecanism de blocare utilizat în Oracle.
un enqueue este un mecanism mai sofisticat care permite mai multor procese concurente să aibă un grad diferit de partajare a resurselor “cunoscute”. Orice obiect care poate fi utilizat concomitent, pot fi protejate cu enqueues. Un bun exemplu este de încuietori pe mese. Permitem diferite niveluri de partajare pe tabele, de exemplu, două procese pot bloca un tabel în modul partajare sau în modul actualizare partajare etc. O diferență este că enqueue este obținut folosind un mecanism de blocare specific OS. O solicitare permite utilizatorului să stocheze o valoare în blocare, adică modul în care o solicităm. OS lock manager ține evidența resurselor blocate. Dacă unui proces nu i se poate acorda blocarea, deoarece este incompatibil cu modul solicitat și blocarea este solicitată cu așteptare, sistemul de operare pune procesul solicitant pe o coadă de așteptare care este deservită în FIFO.

o altă diferență între zăvoare și enqueues este că în zăvoare nu există o coadă ordonată de chelneri ca în enqueues. Chelnerii de blocare pot folosi cronometre pentru trezire și Reîncercare sau rotire (numai în multiprocesoare). Deoarece toți chelnerii încearcă simultan (în funcție de planificator), oricine ar putea obține zăvorul și, probabil, primul care încearcă ar putea fi ultimul care obține.

1. când trebuie să obținem un zăvor?

un proces dobândește un zăvor atunci când lucrează cu o structură în SGA (System Global Area). Continuă să țină zăvorul pentru perioada de timp în care funcționează cu structura. Zăvorul este scăpat când procesul este terminat cu structura. Fiecare zăvor protejează un set diferit de date, identificat prin numele zăvorului.

Oracle folosește instrucțiuni atomice precum “test and set” pentru operarea pe zăvoare. Procesele care așteaptă să execute o parte a codului pentru care un zăvor a fost deja obținut printr-un alt proces vor aștepta până când zăvorul este eliberat. Exemple sunt refaceți zăvoarele de alocare, zăvoarele de copiere, zăvorul de control al arhivei etc. Ideea de bază este de a bloca accesul simultan la structurile de date partajate. Deoarece instrucțiunile de setare și zăvoarele libere sunt atomice, sistemul de operare garantează că un singur proces îl primește. Deoarece este doar o instrucțiune, este destul de rapidă. Zăvoarele sunt ținute pentru perioade scurte de timp și oferă un mecanism de curățare în cazul în care un suport moare anormal în timp ce îl ține. Această curățare se face folosind serviciile PMON.

1. moduri de solicitare a zăvoarelor?

cererea de blocare poate fi făcută în două moduri: “dispus să aștepte” sau “nu așteptați”. În mod normal, zăvoarele vor fi solicitate în modul “dispus să aștepte”. O cerere în modul” dispus să aștepte ”
va bucla, așteptați și solicitați din nou până când se obține zăvorul. În modul “nu așteptați” procesul solicită zăvorul. Dacă unul nu este disponibil, în loc să aștepte, este solicitat altul. Numai atunci când toate eșuează, procesul serverului trebuie să aștepte.

Exemple de zăvoare “dispuse să aștepte” sunt: zăvoarele cache pentru piscină și bibliotecă partajate
un exemplu de zăvoare “fără așteptare” este zăvorul de copiere redo.

5. Ce cauzează disputa zăvorului?Dacă un zăvor necesar este ocupat, procesul care îl solicită se învârte, încearcă din nou și, dacă încă nu este disponibil, se învârte din nou. Bucla se repetă până la un număr maxim de ori determinat de parametrul de inițializare _SPIN_COUNT. Dacă după această buclă, zăvorul nu este încă disponibil, procesul trebuie să cedeze CPU-ul și să meargă la culcare. Inițial este doarme pentru o centisecundă. Acest timp este dublat în fiecare somn ulterior.

aceasta determină o încetinire și duce la utilizarea suplimentară a procesorului, până când este disponibil un zăvor. Utilizarea procesorului este o consecință a” filare ” a procesului. “Spinning” înseamnă că procesul continuă să caute disponibilitatea zăvorului după anumite intervale de timp, în timpul cărora doarme.

1. cum se identifică disputa pentru zăvoarele interne?

vizualizări relevante ale dicționarului de date pentru interogare:

V$zăvor
V$LATCHHOLDER
V$LATCHNAME

fiecare rând din tabelul V$zăvor conține statistici pentru un alt tip de zăvor. Coloanele tabelului reflectă activitatea pentru diferite tipuri de solicitări de blocare. Distincția dintre aceste tipuri de solicitări este dacă procesul solicitant continuă să solicite un zăvor dacă nu este disponibil:

dispus să aștepte dacă zăvorul solicitat cu o solicitare dispus să aștepte
nu este disponibil, procesul solicitant
așteaptă un timp scurt și solicită din nou zăvorul.
procesul continuă să aștepte și să solicite până când
zăvorul este disponibil.

nu așteptați dacă zăvorul solicitat cu o solicitare imediată este
nu este disponibil, procesul de solicitare nu
așteptați, ci continuă procesarea.

V$LATCHNAME informații cheie:

devine Numărul de cereri de succes dispuși să aștepte pentru
un zăvor.

ratează de câte ori o cerere inițială dispusă să aștepte
nu a avut succes.

doarme de câte ori un proces a așteptat a solicitat un zăvor
după o cerere inițială de așteptare.

IMMEDIATE_GETS Numărul de Cereri imediate de succes pentru fiecare zăvor.

IMMEDIATE_MISSES Numărul de Cereri imediate nereușite pentru fiecare zăvor.

calculul raportului de lovire a zăvorului

pentru a obține raportul de lovire pentru zăvoare, aplicați următoarea formulă:

“dispus să aștepte” raportul de lovire=(GETS-MISSES)/GETS
“no wait” raportul de lovire=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

acest număr ar trebui să fie aproape de 1. Dacă nu, reglați în funcție de numele zăvorului

1. scripturi SQL utile pentru a obține informații despre zăvor

/*
** Afișează statistici de blocare la nivel de sistem.
*/
Nume coloană format A32 trunchiați titlul “nume de blocare”
coloană pid titlul”suport PID”
selectați c.name,a.addr,a.gets,A.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, B. pid
de la v$zăvor a, v$latchholder b, v$latchname c
unde a. addr = B. laddr(+)
și a. zăvor # = c. zăvor #
comanda de către a. zăvor#;

/*
** având în vedere o adresă de blocare, aflați numele zăvorului.
* /
Nume coloană format A64 Titlu ‘Nume’
selectați a.name de la v$latchname a, V $ zăvor b
unde B. addr = ‘& addr ‘
și B. zăvor# = a. zăvor#;

/*
** afișați statisticile de blocare după numele zăvorului.
*/
Nume coloană format A32 titlu ‘nume blocare’
coloană PID titlu ‘suport PID’
selectați c.name,a.addr,a.gets,A.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, B. pid
de la v$zăvor a, v$latchholder b, v$latchname c
unde a. addr = B. laddr(+) și a. zăvor # = c. zăvor #
și c.name ca’ &latch_name% ‘ comanda de către un. zăvor#;

1. lista tuturor zăvoarelor

versiunile Oracle pot diferi în zăvorul# atribuit zăvoarelor existente.
următoarea interogare vă va ajuta să identificați toate zăvoarele și numărul atribuit.

Nume coloană format A40 titlu ‘nume zăvor’
selectați zăvor#, nume din v$latchname;

1. lista zăvoarelor care prezintă cea mai mare preocupare pentru un DBA

• blocuri cache tampon: există două blocuri principale care protejează blocurile de date în memoria cache tampon. Disputa pentru aceste două zăvoare este de obicei văzută atunci când o bază de date are rate ridicate de I/O. Putem reduce disputa pentru aceste zăvoare și le putem regla ajustând anumite init.parametrii ora.

blocare lanțuri tampon Cache:

această blocare este achiziționată ori de câte ori este accesat un bloc din memoria cache tampon (fixat).

reducerea contenției pentru zăvorul lanțurilor tampon cache va necesita de obicei reducerea ratelor i/O logice prin reglarea și minimizarea cerințelor i/O ale SQL implicate. Ratele ridicate de I / O ar putea fi un semn al unui bloc fierbinte (adică un bloc foarte accesat).

A Se Vedea Nota 163424.1 Cum să identificați un bloc fierbinte în baza de date pentru a identifica corect această problemă.

cache buffers LRU chain latch:

cache buffer LRU chain latch este achiziționat pentru a introduce un bloc nou în memoria cache tampon și atunci când scrieți un tampon înapoi pe disc, în special atunci când încercați să scanați lanțul LRU (cel mai recent utilizat) care conține toate blocurile murdare din memoria cache tampon.

este posibil să se reducă disputa pentru blocarea lanțului LRU tampon cache prin creșterea dimensiunii memoriei cache tampon și reducând astfel rata la care sunt introduse noi blocuri în memoria cache tampon. Doi parametri dictează dimensiunea cache-ului tampon, DB_BLOCK_SIZE și db_block_buffers. În realitate, numai DB_BLOCK_BUFFERS pot fi modificate fără recrearea bazei de date. Atenție, atunci când reglați piscina tampon, evitați utilizarea tampoanelor suplimentare care contribuie puțin sau nimic la raportul de lovire a cache-ului. O greșeală comună este de a continua creșterea valorii DB_BLOCK_BUFFERS. Astfel de creșteri nu au niciun efect dacă efectuați scanări complete ale tabelului sau alte operații care nu utilizează memoria cache tampon. Mai multe bazine tampon poate ajuta la reducerea dispută pe acest zăvor.Puteți crea zăvoare suplimentare de lanț tampon cache lru prin ajustarea parametrului de configurare db_block_lru_latches. Este posibil să puteți reduce sarcina pe zăvoarele lanțului tampon cache prin creșterea parametrului de configurare _DB_BLOCK_HASH_BUCKETS

• zăvoare tampon REDOLOG: există două zăvoare tampon refaceți, zăvorul de alocare refaceți și zăvorul de copiere refaceți. Zăvorul de alocare redo trebuie achiziționat pentru a aloca spațiu în cadrul tamponului. Dacă intrarea în Jurnalul de refacere care trebuie făcută este mai mare decât parametrul de configurare LOG_SMALL_ENTRY_MAX_SIZE, sesiunea care achiziționează zăvorul de alocare redo poate copia intrarea în tamponul redo imediat în timp ce țineți zăvorul de alocare. Dacă intrarea în jurnal este mai mare decât LOG_SMALL_ENTRY_MAX_SIZE, atunci sesiunea va elibera zăvorul de alocare redo și va achiziționa zăvorul redo copy pentru a copia intrarea. Există doar un singur zăvor de alocare redo, dar pot exista până la log_simultaneous_copies zăvoare de alocare.

Redo allocation zăvor:

acest zăvor controlează alocarea spațiului pentru intrările redo din memoria tampon redo log. Există un zăvor de alocare redo pe instanță.

disputa pentru acest zăvor în Oracle7 poate fi redusă prin scăderea valorii LOG_SMALL_ENTRY_MAX_SIZE pe sistemele multi-cpu pentru a forța utilizarea zăvorului de copiere
redo. În Oracle8i acest parametru este învechit, deci trebuie să luați în considerare creșterea dimensiunii LOG_BUFFER sau reducerea încărcării tamponului de jurnal folosind caracteristici de NOLOGGING atunci când este posibil.

Redo copy zăvor:

acest zăvor este utilizat pentru a scrie înregistrări redo în tamponul redolog. Acest zăvor este așteptat atât pe sistemele single, cât și pe cele multi-cpu.

pe sistemele multi-cpu, disputa poate fi redusă prin creșterea valorii LOG_SIMULTANEOUS_COPIES (ascuns în Oracle8i) și/sau creșterea LOG_ENTRY_PREBUILD_THRESHOLD (nedocumentat în Oracle7).

• memoria cache a Bibliotecii

blocarea memoriei cache a Bibliotecii:

zăvoarele memoriei cache a Bibliotecii protejează instrucțiunile SQL memorate în cache și definițiile obiectelor deținute în memoria cache a bibliotecii din cadrul pool-ului partajat. Zăvorul cache-ului bibliotecii trebuie achiziționat pentru a adăuga o nouă declarație în memoria cache a Bibliotecii. În timpul unei analize, Oracle caută în memoria cache a Bibliotecii o instrucțiune potrivită. Dacă unul nu este găsit, atunci Oracle va analiza instrucțiunea SQL, va obține zăvorul cache al bibliotecii și va introduce noul SQL.

prima resursă pentru a reduce disputa pe acest zăvor este de a se asigura că cererea este reutilizarea cât mai mult posibil SQL declarație de reprezentare. Utilizați variabile de legare ori de câte ori este posibil în aplicație. Ratările acestui zăvor pot fi, de asemenea, un semn că aplicația analizează SQL la o rată ridicată și poate suferi de prea multă analiză a procesorului deasupra capului.Dacă aplicația este deja reglată, SHARED_POOL_SIZE poate fi mărită. Rețineți că, dacă aplicația nu utilizează memoria cache a bibliotecii în mod corespunzător, disputa ar putea fi mai gravă cu o structură mai mare care trebuie tratată.

parametrul _kgl_latch_count controlează numărul de zăvoare cache ale bibliotecii. Valoarea implicită ar trebui să fie adecvată, dar dacă disputa pentru blocarea cache-ului bibliotecii nu poate fi rezolvată, poate fi recomandabil să măriți această valoare. Valoarea implicită pentru _KGL_LATCH_COUNT este următorul număr prim după CPU_COUNT. Această valoare nu poate depăși 66 (A se vedea: ).

blocarea pin-ului cache-ului Bibliotecii:

blocarea pin-ului cache-ului bibliotecii trebuie achiziționată atunci când o instrucțiune din memoria cache a bibliotecii este reexecutată. Rateaza pe acest zăvor apar atunci când există rate foarte mari de execuție SQL.

există puține care se poate face pentru a reduce sarcina pe zăvorul pin cache bibliotecă, deși folosind privat, mai degrabă decât sinonime publice sau referințe obiect directe, cum ar fi proprietar.Tabelul poate ajuta.

• zăvoare legate de POOL-ul partajat

zăvorul pool-ului partajat:

în timp ce zăvorul cache-ului bibliotecii protejează operațiile în memoria cache a Bibliotecii, zăvorul pool-ului partajat este utilizat pentru a proteja operațiile critice la alocarea și eliberarea memoriei în pool-ul partajat.
în cazul în care o aplicație face uz de literal (unshared) SQL, atunci acest lucru poate limita sever scalabilitate și tranzitată. Costul de analiză a unei noi instrucțiuni SQL este scump atât în ceea ce privește cerințele procesorului, cât și de câte ori cache-ul bibliotecii și zăvoarele de piscină partajate ar putea fi necesare pentru a fi achiziționate și eliberate. Înainte de Oracle9, nu folosesc pentru a fi doar un astfel de zăvor la întreaga bază de date pentru a proteja alocarea de memorie în memoria cache bibliotecă. În Oracle9 au fost introduse mai multe copii pentru a ușura disputa asupra acestei resurse.

modalitățile de reducere a zăvorului piscinei partajate sunt, evitați analizele dure atunci când este posibil, analizați o dată, executați multe. Eliminarea SQL literal este, de asemenea, utilă pentru a evita zăvorul de piscină partajat. Dimensiunea shared_pool și utilizarea MTS (opțiunea server partajat) influențează, de asemenea, foarte mult zăvorul pool-ului partajat. Nota 62143.1 explică cum să identificați și să corectați problemele cu piscina partajată și cu zăvorul piscinei partajate.

row cache objects zăvor:

acest zăvor intră în joc atunci când procesele utilizatorului încearcă să acceseze valorile dicționarului de date din cache.

nu este obișnuit să aveți dispută în acest zăvor și singura modalitate de a reduce disputa pentru acest zăvor este prin creșterea dimensiunii pool-ului partajat (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT în Oracle7)

SPIN_COUNT controlează de câte ori procesul va încerca din nou să obțină zăvorul înainte de a se retrage și de a merge la culcare. Acest lucru înseamnă practic că procesul se află într-o buclă CPU strânsă încercând continuu să obțină zăvorul pentru încercările SPIN_COUNT. Pe un singur sistem CPU dacă un proces Oracle încearcă să achiziționeze un zăvor, dar este deținut de altcineva, procesul va elibera CPU-ul și va merge la culcare pentru o perioadă scurtă înainte de a încerca din nou. Cu toate acestea, pe un sistem multi procesor (SMP) este posibil ca procesul care ține zăvorul să ruleze pe unul dintre celelalte procesoare și astfel va elibera zăvorul în următoarele câteva instrucțiuni (zăvoarele sunt de obicei ținute doar pentru perioade foarte scurte de timp).

performanța poate fi ajustată prin modificarea valorii SPIN_COUNT. Dacă se utilizează o valoare ridicată, zăvorul va fi atins mai devreme decât dacă utilizați o valoare scăzută. Cu toate acestea, puteți utiliza mai mult timp de rotire a procesorului pentru a obține zăvorul dacă utilizați o valoare ridicată pentru SPIN_COUNT. Puteți reduce această probabilitate de sesiune doarme prin creșterea valorii parametrilor de configurare _latch_spin_count sau SPIN_COUNT. Acest parametru controlează numărul de încercări pe care le va face sesiunea pentru a obține zăvorul înainte de a dormi. Spinning pe dispozitivul de blocare consumă CPU, deci dacă creșteți acest parametru, este posibil să vedeți o creștere a utilizării globale a procesorului. În cazul în care computerul este aproape de 100% CPU și cererea dumneavoastră este tranzitată, mai degrabă decât timpul de răspuns condus, ai putea lua în considerare scăderea SPIN_COUNT, în scopul de a conserva CPU. Ajustarea SPIN_COUNT este încercare și eroare. În general, creșteți SPIN_COUNT numai dacă există suficiente resurse CPU gratuite disponibile pe sistem și reduceți-l numai dacă nu există o capacitate CPU de rezervă.