Werken met Latches

Nieuws

Het is mij opgevallen dat dba-ers wel iets weten van latches maar dat de kennis nog erg beperkt is.
Dit komt vooral door slechte documentatie. Als je op internet zoekt is er wel wat te vinden, maar dit ligt erg verspreid.

In dit artikel probeer ik de beschikbare informatie bijeen te brengen en de bronnen aan te geven waar meer (achtergrond)informatie over latches te vinden is. Ik zal een poging doen goed weer te geven wat latches wel of niet doen. Ook zullen de eigenschappen duidelijk worden.
Het blijkt dat het, met deze informatie, veel eenvoudiger wordt om te onderzoeken waar latch contention vandaan komt. De opgenomen hyperlinks verwijzen naar verdere uitleg, tips, tools en bronnen.

Werkgebied van latches

Latches zijn onontbeerlijk voor het verkrijgen van resources in het geheugen zoals de SGA, buffers en shared pool. Eigenlijk wordt alles wat met geheugentoegang te maken heeft met latches (of met mutexes) beschermd.
Het geheugen dat door de verschillende processen wordt benaderd bevat o.a. arrays, hash-tables, pointers, linked-lists en bij Oracle vooral double linked lists.
Om het geheugen te benaderen is een mechanisme nodig om problemen met de verschillende processen te voorkomen. Met behulp van hash-logaritmes en arrays kan men memory resources adresseren en aangeven of deze bezet zijn of niet. Een latch is tussen de 100 en 200 bytes groot, afhankelijk van het OS en de Oracle versie. Sinds versie 10g zijn er ook mutexes. Mutexes zijn de opvolgers van latches. Ze zijn eenvoudiger van opzet en sneller, maar geven minder statistische informatie.
De latch- en mutex-implementatie hebben alles te maken met de scalability van de database. Op de blog van Andrej Nikoleav kun je hier meer over lezen.

Opbouw van latches

Bij de opbouw van een latch staat men voor twee uitdagingen:

Hoe schrijf je een latch zo efficiënt mogelijk?
Er hoeft bijzonder weinig code voor een latch geschreven worden.
Processoren kennen machine instructie en één daarvan is “test en set”. Deze wordt vaak in het OS gebruikt maar ook door de Oracle database. Met deze implementatie wordt aan veel eisen voldaan en blijft de code minimaal. Door de atomic instructie worden ook veel van de eigenschappen duidelijk, onder andere de snelheid (nano seconden bereik). Als je de definitie van Oracle ernaast legt kun je de overige eigenschappen invullen.
Hoeveel code kan men spenderen aan statistieken?
Hoe meer code, des te langer duurt het proces van het verkrijgen van een latch. Dit wil je voorkomen omdat dit de scalability van de database beïnvloedt.

De tijd voor het verkrijgen van de latch met de daarbij horende code voor statistieken e.d. is dan ook kort. We moeten hierbij denken in de orde van grootte van een microseconde. De meeste tijd wordt gespendeerd aan de statistieken.
Als we een context switch krijgen van de CPU welke 10-12 miliseconde duurt, is dit ontzettend lang vergeleken bij een latch. Daarom “spint” een latch als deze bezet is. Eigenlijk is dit niets anders dan een loop; een latch “loopt” 20.000 keer, met als gevolg dat de latch, zoals bedoeld, op dezelfde CPU blijft. Tevens gaat de CPU utilization omhoog.
Wat is latch contention
Wanneer meerdere processen dezelfde latch willen hebben (hetzelfde adres), heet dat latch contention. We kunnen hierbij een aantal zaken constateren:

latch contention is geen oorzaak, maar een gevolg
We kunnen aannemen dat het eerste proces dat aan de beurt is, de latch krijgt als deze vrijkomt. Het gedrag word ook wel vergeleken met een zwerm bijen die zich verdringt bij de ingang. Er is namelijk helemaal geen “intelligentie” of rangorde bij de latch aanwezig, want dat zou tijd kosten
Als een latch niet binnen een bepaald aantal “spins” slaagt, gaat deze in een hele korte sleep (missed statistics).

Contention van de latches hoeft dus niet altijd een probleem te zijn. Wel is het verstandig te weten waar het vandaan komt om dat te kunnen beoordelen.

Afhandeling van latches

Wat als de latch geslaagd is (“gets statistics”)? Het is niet de bedoeling dat deze dan wacht tot de bewerking klaar is. De latch wordt alleen gezet, zodat het geheugen door het proces gepind kan worden. Daarna wordt de latch weer vrijgegeven.
Als de bewerking klaar is, wordt er weer een latch gezet, zodat het geheugen door het proces “ontpind” (unpinned) kan worden.
Het Oracle proces dat een geslaagde latch heeft, wordt een “holder” genoemd.
Informatie hierover is terug te vinden in de view v$latchholder.
Statistieken over een latch zijn terug te vinden in v$latch, v$latch_parent en v$latch_children.

Let wel:
voor het onderzoek in v$latchholder zijn goede tools of scripting nodig omdat een latch holder een heel korte levensduur heeft. In het geval dat er heel snelle latches moeten worden gemeten, moet er zelfs een hidden parameter (_ultrafast_latch_statistics) gezet worden; in 99% van de gevallen is dat echter niet nodig.

Als de holder van een latch ‘sterft’, terwijl de latch nog uitstaat, dan wordt deze door de clean procedure van PMON opgeruimd.
In de praktijk zijn er twee typen latches: “willing to wait” en “immediate”. De “immediate latch” komt voor bij “child latches”; als het proces niet direct een “child latch” krijgt, gaat deze op zoek naar een andere “child latch”.
De latches komen ook in twee smaken: “exclusive” en “shared”; dit is hetzelfde als bij het locking systeem

Constatering latch contention

Om te onderzoeken wat de root cause van latch contention is, moet er eerst vastgesteld worden dàt er contention is. Hiervoor worden de statistieken gebruikt die door de latches aangemaakt zijn.
Er zijn twee methodes voorhanden: statistieken op basis van ratio of statistieken op basis van wait.

Het onderstaande voorbeeld is voor “willing to wait” latches en “immediate” latches, berekend op basis van ratio.

Als je meet op basis van de wait statistieken, meet je de impact van de latches op de totale performance. Een tool die hier veel informatie over geeft is bijvoorbeeld AWR.
Let wel: als je een goed onderzoek met AWR wil doen, zal het snapshot interval teruggebracht moeten worden naar 10-15 minuten i.p.v. 1 uur.
Omdat AWR alle informatie in tabellen opslaat, kan met een query over deze tabellen ook historische informatie verkregen worden.

Latch views

Als eenmaal is vastgesteld dat er latch contention is, kan het onderzoek naar de oorzaak gestart worden. Wat je eigenlijk wil weten, is welk proces de latch wil hebben en waarom (wat doet dit proces).
Daarvoor hebben we al een aantal aanknopingspunten, te vinden in v$latchholder, v$latch_parent, v$latch_children en x$bh.
Daarbij moet wel in de gaten worden gehouden hoe de statistieken geüpdatet worden in de V$ views. De TCH (touch count header) in x$bh is bijvoorbeeld vaak misleidend; deze wordt namelijk om de 3 seconden ververst. Een eeuwigheid dus, vergeleken met de levenscyclus van een latch. Dit mechanisme wordt intern gebruikt voor de LRU cleanup en is dus niet altijd geschikt voor het achterhalen van hot blocks.
Meten hoeft niet lang te duren maar moet wel snel gebeuren. Met de hand uitgevoerde queries gaan dus niet werken, maar men moet tools en scripts inzetten. Metingen hebben nauwelijks invloed op het systeem omdat deze maar enkele seconden duren.

Latch onderzoek

Bij het onderzoek naar latches gaat het erom de juiste tool in te zetten. Voorwaarde bij dit onderzoek is dat de metingen in een snelle loop gedaan worden en dat de tijdsmeting nauwkeurig genoeg is. Binnen de Oracle database is dat mogelijk met een SQL script. Men kan gebruik maken van de scripts van Tanel Poder. Deze heeft speciaal voor dit doel twee scripts gemaakt: één dat gebaseerd is op V$ views en één dat gebaseerd is op X$ views. De scripts latchprof en latchprofx zijn niet alleen handig maar ook leerzaam.
In de scripts is goed te zien hoe je een loop opbouwt met nauwkeurige timing; handig als je zelf eens een test script aan het maken bent. Lang hoeven deze scripts niet te lopen omdat ze metingen doen in een omgeving waar 3 seconden al een eeuwigheid is. Het vormt dan ook bijna geen belasting op de database.

Om een goede analyse te maken moet je methodish te werk gaan; Ook dit heeft Tanel Poder beschreven op zijn blog.

In de video’s demo1 en demo2 zie je een eenvoudig voorbeeld van de scripts op een testomgeving.

Demo1 is eigenlijk verkeerd opgezet: hier werd geprobeerd physical IO te genereren. Helaas bestonden de gezochte tabellen niet (verkeerde eigenaar). Doordat de loop nogal groot is werd de query vaak uitgevoerd en geeft dit contention op de sql-area.

Demo2 loopt wel goed en genereert CBC latch contention doordat er veel Logical IO’s worden gegenereerd. In de demo wordt niet gekeken op welk header adres de contention is, maar wel wie de veroorzaker is.

Met het latchprofx script is meer informatie te verkrijgen uit de database: het is een dynamisch SQL script waarbij men zelf kan aangeven welke output zichtbaar is. Hiermee is zelfs heel nauwkeurig vast te stellen wat de hot blocks van de database zijn. Ook deze methode is volledig door Tanel Poder in een artikel op zijn blog beschreven.

Een praktijkvoorbeeld van latch contention
Een database server had x aantal CPU’s toegewezen gekregen. In de drukke periode, een periode van twee uur in de ochtend of één uur in de middag werden alle CPU’s volledig benut. De performance had wel wat te lijden maar alles liep gewoon door. Heel af en toe ging het systeem toch onderuit. Onderzoek wees uit dat er een rapport op onregelmatige periodes werd gemaakt. Als dat rapport in deze piekperiode werd gemaakt, dan ging de database onderuit. Er was contention op de “cache buffers chains” latches, die de CPU utilization omhoog bracht, terwijl er geen CPU meer beschikbaar was. Met als gevolg: CPU starvation. In het rapport bleek een aantal queries een bepaalde tabel flink te gebruiken. Een enkele query veroorzaakte een full table scan. Het bleek dat dit verbeterd kon worden door indexen aan te maken. Bij navraag bij de software leverancier kwamen we erachter, dat die indexen in een patch zaten die niet doorgevoerd was. De klant wilde geen patches doorgevoerd hebben op de database tot het duidelijk was wat de oorzaak was van de database problemen. Het mag duidelijk zijn dat latch contention meestal niet schadelijk is. Echter in dit geval was het desastreus. Te weinig CPU en daar bovenop latch contention was te veel. Doordat aangetoond kon worden dat de patch echt doorgevoerd moest worden kon het probleem worden opgelost.

Bron van scripts:
http://files.e2sn.com/scripts/latchprof.sql
http://files.e2sn.com/scripts/latchprofx.sql

blogs:
http://blog.tanelpoder.com
http://andreynikolaev.wordpress.com

Boeken die het onderwerp behandelen:
Jonathan Lewis – Oracle Core essential internals
Tom Kyte – Expert Oracle Database Architecture

– Rick van Ek

Rick van Ek is Oracle database engineer en Database Consultant, werkzaam bij o.a KLM.