Oracle låsmekanism – spärrar och köer

denna artikel är en del av Oracle Performance Tuning Series och är skapad för att beskriva Oracles låsmekanism.

ett lås är en resurs som du måste hålla för att få tillgång till resursen. Oracle har två typer av lås: köer och spärrar, vi skulle nu fokusera på dessa låsmekanism individuellt.

Enqueues

Enqueues är sofistikerade lås för att hantera åtkomst till delade resurser (som tabeller, rader, jobb, gör om trådar). En kö kan begäras i olika nivåer / läge:

• Null
• Row share
• Row exclusive
• dela
• dela Row exclusive
• Exclusive

om en session har en kö i delningsläge, kan andra sessioner sedan också ta kö i delningsläge (för samma resurs). Om en session har en kö i exklusivt läge, andra sessioner som vill få det-oberoende på vilken nivå – de måste vänta.

när åtkomst krävs av en session erhålls en låsstruktur och en begäran görs om att få åtkomst till resursen på en viss nivå (läge) görs. Låsstrukturen placeras på en av tre länkade listor som hänger av resursen, kallad ägaren (om frågan kunde förvärvas), servitör (om sessionen väntar på att förvärva frågan) och omvandlare (sessionen håller frågan på en nivå men vill konvertera den till en annan) listor.

Följande är några vanliga typer av förfrågningar:-

• TM-varje gång en session vill låsa ett bord begärs en TM-kö. Om en session tar bort en rad i den överordnade tabellen och en referensbegränsning (sekundärnyckel) skapas utan ett index i den underordnade tabellen, eller om sessionen uppdaterar kolumnen / kolumnerna som den främmande nyckeln refererar till, tas ett delningslås på den underordnade tabellen. Om en annan session försöker göra ändringar i barntabellen måste de vänta (eftersom de vill ha enqueue i row exclusive-läge, och det är inte kompatibelt med delningsläget).
• TX-så snart en transaktion startas behövs en TX-kö. En transaktion definieras unikt av rollback-segmentets nummer, slitsnumret i rollback-segmentets transaktionstabell och slitsnummerets sekvensnummer. En session kan vänta på en TX-kö av flera anledningar:
  1. en annan session låser den begärda raden
  2. när två sessioner försöker infoga samma unika nyckel i en tabell (ingen av dem har gjort ett åtagande), väntar den sista sessionen på att den första ska begå eller rulla tillbaka.
  3. det finns ingen gratis lire (intresserad transaktionslista) i blockhuvudet.
• UL-en session har tagit ett lås med DBMS_LOCK.Begär funktion.

spärrar

spärrar ger en låg nivå serialisering mekanism som skyddar delade datastrukturer i SGA. En spärr är en typ av lås som kan förvärvas mycket snabbt och befrias. Spärrar används vanligtvis för att förhindra att mer än en process kör samma kod vid en given tidpunkt. När en spärr förvärvas förvärvas den på en viss nivå för att förhindra deadlocks. När en process förvärvar en spärr på en viss nivå kan den inte därefter förvärva en spärr på en nivå som är lika med eller mindre än den nivån (såvida den inte förvärvar den nowait). Associerad med varje spärr är en sanering förfarande som kommer att kallas om en process dör medan du håller spärren. Denna rengöring görs med hjälp av pmon: s tjänster. Den underliggande implementeringen av spärrar är operativsystemberoende, särskilt när det gäller huruvida en process kommer att vänta på en spärr och hur länge.

målet med spärrar är att hantera samtidig åtkomst till delade datastrukturer så att endast en process kan komma åt strukturen åt gången. Blockerade processer (processer som väntar på att utföra en del av koden för vilken en spärr redan har erhållits genom någon annan process) väntar tills spärren släpps. Oracle använder atominstruktioner som” test and set ” för drift på spärrar. Eftersom instruktionerna för att ställa in och fria spärrar är atomära garanterar operativsystemet att endast en process får det och eftersom det bara är en enda instruktion är det ganska snabbt.

Spärrförfrågningar kan göras i två lägen:

• willing-to-wait: en begäran om” willing-to-wait ” – läge kommer att slinga, vänta och begära igen tills spärren erhålls.
• ingen väntan: i” ingen väntan ” – läge kommer processen att begära spärren och om den inte är tillgänglig, istället för att vänta, begärs en annan. Först när allt misslyckas måste serverprocessen vänta.

skillnad mellan spärrar & köer

en skillnad mellan en spärr och en kö är att köen erhålls med en OS-specifik låsmekanism medan en spärr erhålls oberoende av OS. En kö tillåter användaren att lagra ett värde i låset (dvs det läge där vi begär det). OS lock manager håller reda på de resurser som är låsta. Om en process inte kan beviljas låset eftersom det är oförenligt med det begärda läget och låset begärs med vänta, sätter operativsystemet den begärande processen i en väntekö som servas i FIFO.

en annan skillnad mellan spärrar och förfrågningar är att förfrågningar upprätthåller och beställer kö av servitörer medan spärrar inte gör det. Alla processer som väntar på en spärr samtidigt försök igen (beroende på Schemaläggaren). Det betyder att någon av servitörerna kan få spärren och tänkbart kan den första som försöker få spärren vara den sista som faktiskt får den. Spärr servitörer kan antingen använda timers att vakna och försöka igen eller de kan snurra (endast i multiprocessorer) spinning på en spärr innebär att hålla CPU och väntar i väntan på att spärren frigörs på kort tid).