Rajat DBA’ s Blog

Dit is een kopie van Metalink ‘ s Reference Note 22908.1, voor degenen die er geen toegang toe hebben.

1. Wat is een vergrendeling?
   vergrendelingen zijn serialisatiemechanismen op laag niveau die worden gebruikt om gedeelde datastructuren in de SGA te beschermen. De implementatie van grendels is afhankelijk van het besturingssysteem, met name met betrekking tot de vraag of een proces zal wachten op een grendel en voor hoe lang.

een vergrendeling is een type vergrendeling dat zeer snel kan worden verkregen en bevrijd. Vergrendelingen worden meestal gebruikt om te voorkomen dat meer dan één proces van het uitvoeren van hetzelfde stuk code op een bepaald moment. Geassocieerd met elke latch is een opschoonprocedure die zal worden genoemd als een proces sterft terwijl het vasthouden van de latch. Vergrendelingen hebben een bijbehorende niveau dat wordt gebruikt om vastlopen te voorkomen. Zodra een proces een klink op een bepaald niveau verwerft, kan het vervolgens geen klink verwerven op een niveau dat gelijk is aan of lager is dan dat niveau (tenzij het het nowait verwerft).

2.Vergrendelingen vs. Enqueues

Enqueues zijn een ander type vergrendelingsmechanisme dat wordt gebruikt in Oracle.
een enquête is een geavanceerder mechanisme dat het mogelijk maakt dat verschillende gelijktijdige processen in verschillende mate “bekende” bronnen delen. Elk object dat gelijktijdig kan worden gebruikt, kan worden beschermd met enqueues. Een goed voorbeeld is van sloten op tafels. We staan verschillende niveaus van het delen op tabellen toe, bijvoorbeeld twee processen kunnen een tabel vergrendelen in de share-modus of in de Share-updatemodus enz. Een verschil is dat de enqueue wordt verkregen met behulp van een OS-specifiek vergrendelingsmechanisme. Een enqueue stelt de gebruiker in staat om een waarde op te slaan in het slot, dat wil zeggen de modus waarin we het aanvragen. De OS lock manager houdt bij welke bronnen zijn vergrendeld. Als een proces de vergrendeling niet kan worden verleend omdat het niet compatibel is met de gevraagde modus en de vergrendeling wordt aangevraagd met wachten, plaatst het besturingssysteem het aanvraagproces in een wachtrij die wordt onderhouden in FIFO.

een ander verschil tussen sloten en enqueues is dat er in sloten geen geordende wachtrij van obers is zoals in enqueues. Latch obers kunnen ofwel timers gebruiken om wakker te worden en opnieuw te proberen of draaien (alleen in multiprocessors). Aangezien alle obers gelijktijdig opnieuw proberen (afhankelijk van de scheduler), iedereen zou kunnen krijgen de klink en denkbaar de eerste om te proberen zou de laatste te krijgen.

1. Wanneer moeten we een vergrendeling verkrijgen?

een proces krijgt een vergrendeling wanneer het werkt met een structuur in het SGA (System Global Area). Het blijft de vergrendeling te houden voor de periode dat het werkt met de structuur. De vergrendeling valt wanneer het proces is voltooid met de structuur. Elke latch beschermt een andere set van gegevens, geïdentificeerd door de naam van de latch.

Oracle gebruikt atomaire instructies zoals “test and set” voor het werken op sloten. Processen die wachten om een deel van de code uit te voeren waarvoor een latch al is verkregen door een ander proces zullen wachten tot de latch is vrijgegeven. Voorbeelden zijn redo allocation latches, copy latches, archive control latch etc. Het basisidee is om gelijktijdige toegang tot gedeelde datastructuren te blokkeren. Aangezien de instructies voor het instellen en vrij vergrendelen atomisch zijn, garandeert het besturingssysteem dat slechts één proces het krijgt. Aangezien het slechts één instructie is, is het vrij snel. Vergrendelingen worden gehouden voor korte periodes van tijd en bieden een mechanisme voor het opruimen in het geval een houder sterft abnormaal terwijl het houden van het. Deze reiniging wordt gedaan met behulp van de diensten van PMON.

1. Afsluitverzoekmodi?

Latches verzoek kan worden gedaan in twee modi: “willing-to-wait “of”no wait”. Normaal gesproken worden vergrendelingen aangevraagd in de “bereid om te wachten” – modus. Een verzoek in” willing-to-wait ” modus
zal herhalen, wachten en opnieuw Verzoeken totdat de latch is verkregen. In de” no wait ” – modus vraagt het proces de vergrendeling aan. Als er een niet beschikbaar is, in plaats van te wachten, wordt er een andere gevraagd. Alleen als alles mislukt moet het serverproces wachten.

voorbeelden van” willing-to-wait “latches zijn: shared pool and library cache latches
een voorbeeld van” no wait ” latches is de redo copy latch.

5. Wat veroorzaakt latch twisting?Als een vereiste vergrendeling bezet is, draait het proces dat het vraagt opnieuw, probeert het opnieuw en als het nog steeds niet beschikbaar is, draait het opnieuw. De lus wordt herhaald tot een maximum aantal keren bepaald door de initialisatie parameter _SPIN_COUNT. Als na deze hele lus de vergrendeling nog steeds niet beschikbaar is, moet het proces de CPU opleveren en gaan slapen. In eerste instantie slaapt hij een centiseconde. Deze tijd wordt verdubbeld in elke volgende slaap.

dit veroorzaakt een vertraging en resulteert in extra CPU-gebruik, totdat een vergrendeling beschikbaar is. Het CPU-gebruik is een gevolg van het” spinnen ” van het proces. “Draaien” betekent dat het proces blijft zoeken naar de beschikbaarheid van de klink na bepaalde tijdsintervallen, waarin het slaapt.

1. hoe identificeer je twist voor interne vergrendelingen?

relevante weergaven uit het gegevenswoordenboek om op te vragen:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

elke rij in de V$LATCH tabel bevat statistieken voor een ander type latch. De kolommen van de tabel weerspiegelen de activiteit voor verschillende soorten latch-Verzoeken. Het onderscheid tussen deze soorten verzoeken is of het aanvragende proces een sluiting blijft aanvragen als deze niet beschikbaar is:

bereid tot wachten als de met een bereid tot wachten
verzoek gevraagde Sluiting Niet beschikbaar is, wacht het aanvragende proces
een korte tijd en vraagt opnieuw om de sluiting.
het proces blijft wachten en vragen totdat
de latch beschikbaar is.

geen wacht als de vergrendeling die met een onmiddellijk verzoek wordt aangevraagd
niet beschikbaar is, wacht het aanvraagproces niet
, maar gaat verder met verwerken.

V$LATCHNAME sleutelinformatie:

krijgt het aantal succesvolle bereid-tot-wachten-verzoeken voor
een latch.

Aantal keer gemist een eerste bereid-tot-wachten verzoek
was niet succesvol.

SLEEPS aantal keren dat een proces wachtte een vroeg een latch
na een eerste wiling-to-wait verzoek.

IMMEDIATE_GETS aantal succesvolle onmiddellijke verzoeken voor elke latch.

IMMEDIATE_MISES aantal mislukte onmiddellijke verzoeken voor elke latch.

Calculating latch hit ratio

om de Hit ratio voor latches te krijgen, gebruik je de volgende formule:

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

dit getal moet dicht bij 1 liggen. Zo niet, tunen volgens de naam van de latch

1. nuttige SQL-scripts om latch-informatie te verkrijgen

/*
** systeembrede vergrendelingsstatistieken weergeven.
*/
kolom naam formaat A32 afkappen rubriek “KLINK NAAM”
kolom pid rubriek “HOUDER PID”
selecteer c.naam,een.addr,een.krijgt er een.mist,een.slaapt,
een.immediate_gets,een.immediate_misses,b.pid
from v$vergrendeling a, v$latchholder b, v$latchname c
waar een.addr = b.laddr(+)
en.vergrendeling# = c.vergrendeling#
om door een.klink#;

/*
** Gegeven een latch-adres, het vinden van de vergrendeling naam.
* /
kolomnaam formaat A64 kop “naam”
selecteren a.name van v$latchname a, V$latch b
waarbij b. addr = ‘&addr ‘
en b. latch# = a. latch#;

/*
** toon latch statistieken op latch naam.
*/
kolom naam formaat a32 rubriek ‘LATCH NAAM’
kolom pid rubriek ‘HOUDER PID’
selecteer c.naam,een.addr,een.krijgt er een.mist,een.slaapt,
een.immediate_gets,een.immediate_misses,b.pid
from v$vergrendeling a, v$latchholder b, v$latchname c
waar een.addr = b.laddr(+) en een.vergrendeling# = c.vergrendeling#
en c.een naam als ‘&latch_name%’ order by een.klink#;

1. lijst van alle vergrendelingen

Oracle-versies kunnen verschillen in de vergrendeling# toegewezen aan de bestaande vergrendelingen.
de volgende zoekopdracht zal u helpen om alle vergrendelingen en het toegewezen nummer te identificeren.

kolomnaam formaat A40 kop ‘LATCH NAME’
selecteer latch#, naam van v$latchname;

1. lijst van sloten die van het grootste belang zijn voor een DBA

• buffer cache sloten: er zijn twee belangrijke sloten die gegevensblokken in de buffer cache te beschermen. Stelling voor deze twee sloten wordt meestal gezien wanneer een database heeft hoge I/O-tarieven. We kunnen de strijd voor deze sloten verminderen en ze afstemmen door bepaalde init aan te passen.ora parameters.

cache buffers chains latch:

deze latch wordt verkregen wanneer een blok in de buffer cache wordt geopend (vastgezet).

het verminderen van twist voor de cache buffer ketens latch zal meestal vereisen het verminderen van logische I / O rates door het afstemmen en minimaliseren van de I/O vereisten van de betrokken SQL. Hoge I / O-tarieven kunnen een teken zijn van een hot block (wat betekent dat een blok zeer toegankelijk is).

Zie Noot 163424.1 Hoe een Hot Block binnen de Database te identificeren om dit probleem correct te identificeren.

Cache buffers LRU chain latch:

de cache buffer lru chain latch wordt verworven om een nieuw blok in de buffer cache te introduceren en bij het schrijven van een buffer terug naar de schijf, in het bijzonder wanneer het proberen om de LRU (minst recent gebruikte) keten te scannen die alle vuile blokken in de buffer cache bevat.

het is mogelijk om twist voor de buffer buffer lru chain latch te verminderen door de grootte van de buffercache te vergroten en zo de snelheid te verminderen waarmee nieuwe blokken in de buffercache worden ingebracht. Twee parameters bepalen de grootte van de buffer cache, DB_BLOCK_SIZE en DB_BLOCK_BUFFERS. In werkelijkheid kan alleen de DB_BLOCK_BUFFERS worden gewijzigd zonder de database opnieuw aan te maken. Let op, bij het afstemmen van de buffer pool, vermijd het gebruik van extra buffers die weinig of niets bijdragen aan de cache hit ratio. Een veel voorkomende fout is om door te gaan met het verhogen van de waarde van DB_BLOCK_BUFFERS. Dergelijke verhogingen hebben geen effect als u volledige tabelscans of andere bewerkingen doet die de buffercache niet gebruiken. Meerdere bufferpools kunnen bijdragen aan het verminderen van twist op deze vergrendeling.U kunt extra cache buffer lru chain latches maken door de configuratieparameter DB_BLOCK_LRU_LATCHES aan te passen. U kunt de belasting van de cache buffer ketens verminderen door de configuratieparameter _DB_BLOCK_HASH_BUCKETS

• REDOLOG BUFFER LATCHES te verhogen: er zijn twee Redo buffer latches, de redo allocation latch en de redo copy latch. De redo allocation latch moet worden verworven om ruimte binnen de buffer toe te wijzen. Als de redo log entry groter is dan de configuratieparameter LOG_SMALL_ENTRY_MAX_SIZE, kan de sessie die de redo allocation latch verwerft, de entry onmiddellijk in de redo buffer kopiëren terwijl de allocation latch wordt vastgehouden. Als de log entry groter is dan LOG_SMALL_ENTRY_MAX_SIZE, dan zal de sessie de redo allocation latch vrijgeven en zal de redo copy latch verkrijgen om de entry te kopiëren. Er is slechts één redo allocation latch, maar er kunnen tot LOG_SIMULTANEOUS_COPIES allocation latches zijn.

redo allocation latch:

deze latch bepaalt de toewijzing van ruimte voor redo entries in de redo log buffer. Er is één redo allocation latch per instantie.

stelling voor deze latch in Oracle7 kan worden verminderd door de waarde van LOG_SMALL_ENTRY_MAX_SIZE op multi-cpu-systemen te verlagen om het gebruik van de
redo copy latch te forceren. In Oracle8i is deze parameter verouderd, dus je moet overwegen om de grootte van de LOG_BUFFER te vergroten of de belasting van de logbuffer te verminderen met behulp van NOLOGGING functies waar mogelijk.

redo copy latch:

deze latch wordt gebruikt om redo records in de redolog buffer te schrijven. Deze vergrendeling wordt gewacht op zowel single als multi-cpu systemen.

op multi-cpu-systemen kan contention worden verminderd door de waarde van LOG_SIMULTANEOUS_COPIES (verborgen in Oracle8i) te verhogen en/of LOG_ENTRY_PREBUILD_THRESHOLD (ongedocumenteerd in Oracle7) te verhogen.

• LIBRARY CACHE

library cache latch:

de library cache latches beschermen de cache SQL-statements en objectdefinities in de library cache binnen de gedeelde pool. De library cache latch moet aangeschaft worden om een nieuw statement aan de library cache toe te voegen. Tijdens een parse, Oracle doorzoekt de bibliotheek cache voor een matching statement. Als er geen wordt gevonden, dan zal Oracle het SQL statement ontleden, de library cache latch verkrijgen en de nieuwe SQL invoegen.

de eerste bron om twist over deze grendel te verminderen is ervoor te zorgen dat de toepassing zoveel mogelijk SQL-statementweergave hergebruikt. Bind-variabelen gebruiken waar mogelijk in de toepassing. Mist op deze klink kan ook een teken dat de toepassing is het ontleden van SQL op een hoog tarief en kan lijden aan te veel parse CPU overhead.Als de applicatie al is afgesteld kan de SHARED_POOL_SIZE worden verhoogd. Houd er rekening mee dat als de toepassing de bibliotheekcache niet op de juiste manier gebruikt, de stelling erger kan zijn met een grotere structuur die moet worden behandeld.

de parameter _KGL_LATCH_COUNT bepaalt het aantal vergrendelingen van bibliotheekcache. De standaardwaarde zou voldoende moeten zijn, maar als de stelling voor de vergrendeling van de bibliotheekcache niet kan worden opgelost, kan het raadzaam zijn om deze waarde te verhogen. De standaardwaarde voor _KGL_LATCH_COUNT is het volgende priemgetal na CPU_COUNT. Deze waarde mag niet meer dan 66 bedragen (zie:).

pin-vergrendeling voor Bibliotheekcache:

de PIN-vergrendeling voor bibliotheekcache moet worden verkregen wanneer een statement in de bibliotheekcache opnieuw wordt uitgevoerd. Mist op deze klink optreden wanneer er zeer hoge tarieven SQL uitvoering.

er is weinig dat kan worden gedaan om de belasting van de bibliotheek cache pin latch te verminderen, hoewel het gebruik van private in plaats van publieke synoniemen of lijdend voorwerp verwijzingen zoals eigenaar.Tafel kan helpen.

• shared POOL RELATED LATCHES

shared pool latch:

terwijl de library cache latch operaties met de library cache beschermt, wordt de shared pool latch gebruikt om kritieke operaties te beschermen bij het toewijzen en vrijmaken van geheugen in de gedeelde pool.
als een toepassing gebruik maakt van letterlijke (niet gedeelde) SQL dan kan dit de schaalbaarheid en doorvoersnelheid ernstig beperken. De kosten van het ontleden van een nieuwe SQL-verklaring is duur, zowel in termen van CPU-eisen en het aantal keren dat de bibliotheek cache en gedeelde zwembad sloten moeten worden verworven en vrijgegeven. VÃ3Ã3r Oracle9, er gebruiken om slechts een dergelijke vergrendeling aan de gehele database om de toewijzing van geheugen in de bibliotheek cache te beschermen. In Oracle9 werden meerdere childs geïntroduceerd om twist over deze bron te verlichten.

manieren om de vergrendeling van de gedeelde pool te verminderen zijn, vermijd harde parses indien mogelijk, ontleed één keer, voer veel uit. Het elimineren van letterlijke SQL is ook handig om de vergrendeling van het gedeelde zwembad te vermijden. De grootte van de shared_pool en het gebruik van MTS (shared server option) heeft ook grote invloed op de shared pool latch. Opmerking 62143.1 legt uit hoe je problemen met het gedeelde zwembad en de vergrendeling van het gedeelde zwembad kunt identificeren en corrigeren.

row cache objects latch:

deze latch speelt zich af wanneer gebruikersprocessen proberen toegang te krijgen tot de data dictionary-waarden in de cache.

het is niet gebruikelijk om contention te hebben in deze latch en de enige manier om contention voor deze latch te verminderen is door de grootte van de gedeelde pool te vergroten (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT in Oracle7)

SPIN_COUNT bepaalt hoe vaak het proces opnieuw zal proberen om de vergrendeling te verkrijgen voordat u terugtrekt en gaat slapen. Dit betekent in principe dat het proces is in een strakke CPU lus voortdurend proberen om de klink voor SPIN_COUNT pogingen te krijgen. Op een enkele CPU-systeem als een Oracle proces probeert om een klink te verwerven, maar het wordt vastgehouden door iemand anders het proces zal de CPU vrijgeven en gaan slapen voor een korte periode voordat het opnieuw proberen. Echter, op een multi processor systeem (SMP) is het mogelijk dat het proces dat de vergrendeling draait op een van de andere CPU ‘ s en dus zal potentieel vrijgeven van de vergrendeling in de volgende instructies (vergrendelingen worden meestal gehouden voor slechts zeer korte periodes van tijd).

de prestaties kunnen worden aangepast door de waarde van SPIN_COUNT te wijzigen. Als een hoge waarde wordt gebruikt, zal de klink eerder worden bereikt dan wanneer u een lage waarde gebruikt. Echter, je kunt meer CPU tijd draaien om de grendel te krijgen als je een hoge waarde voor SPIN_COUNT gebruiken. U kunt deze kans op session sleeps verkleinen door de waarde van de configuratieparameters _LATCH_SPIN_COUNT of SPIN_COUNT te verhogen. Deze parameter bepaalt het aantal pogingen dat de sessie zal doen om de vergrendeling te verkrijgen voor het slapen gaan. Draaien op de grendel verbruikt CPU, dus als je deze parameter verhoogt, zie je mogelijk een toename in het totale CPU-gebruik van je systemen. Als uw computer is in de buurt van 100% CPU en uw applicatie is doorvoer in plaats van reactietijd gedreven, kunt u overwegen het verminderen van SPIN_COUNT om CPU te besparen. Het aanpassen van SPIN_COUNT is trial and error. In het algemeen verhoog SPIN_COUNT alleen als er genoeg vrije CPU-bronnen beschikbaar zijn op het systeem, en verlaag het alleen als er geen reserve CPU-capaciteit is.