Rajat DBA’ s Blog

Detta är en kopia av Metalinks Referensnot 22908.1, för dem som inte har tillgång till den.

1. Vad är en spärr?
   spärrar är lågnivåserialiseringsmekanismer som används för att skydda delade datastrukturer i SGA. 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.

en spärr är en typ av lås som snabbt kan förvärvas och frigöras. Spärrar används vanligtvis för att förhindra att mer än en process kör samma kod vid en given tidpunkt. 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. Spärrar har en tillhörande nivå som används för att förhindra dödlås. 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).

2.Spärrar vs. Enqueues

Enqueues är en annan typ av låsmekanism som används i Oracle.
en kö är en mer sofistikerad mekanism som tillåter flera samtidiga processer att ha varierande grad av delning av” kända ” resurser. Alla objekt som kan användas samtidigt, kan skyddas med köer. Ett bra exempel är lås på bord. Vi tillåter olika nivåer av delning på tabeller, t.ex. två processer kan låsa en tabell i delningsläge eller i delningsuppdateringsläge etc. En skillnad är att köen erhålls med hjälp av en OS-specifik låsmekanism. 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 köer är att i spärrar finns det ingen beställd kö av servitörer som i köer. Latch servitörer kan antingen använda timers för att vakna och försöka igen eller snurra (endast i multiprocessorer). Eftersom alla servitörer samtidigt försöker igen (beroende på schemaläggaren) kan vem som helst få spärren och tänkbart kan den första som försöker vara den sista som får.

1. när behöver vi få en spärr?

en process förvärvar en spärr när man arbetar med en struktur i SGA (System Global Area). Det fortsätter att hålla spärren under den tid det fungerar med strukturen. Spärren tappas när processen är klar med strukturen. Varje spärr skyddar en annan uppsättning data, identifierade med namnet på spärren.

Oracle använder atominstruktioner som” test och set ” för drift på spärrar. 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. Exempel är Gör om allokeringslås, kopieringslås,arkivkontrolllås etc. Grundtanken är att blockera samtidig åtkomst till delade datastrukturer. Eftersom instruktionerna för att ställa in och fria spärrar är atomära garanterar operativsystemet att endast en process får det. Eftersom det bara är en instruktion är det ganska snabbt. Spärrarna hålls under korta perioder och ger en mekanism för sanering om en hållare dör onormalt medan du håller den. Denna rengöring görs med hjälp av pmon: s tjänster.

1. spärrar begäran lägen?

Spärrförfrågan kan göras i två lägen: “willing-to-wait” eller “no wait”. Normalt kommer spärrar att begäras i” willing-to-wait ” – läge. En begäran i” willing-to-wait ” – läge
kommer att slinga, vänta och begära igen tills spärren erhålls. I” no wait ” – läget begär processen spärren. Om en 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.

exempel på” villiga att vänta “spärrar är: delad pool och bibliotek cache spärrar
ett exempel på” ingen vänta ” spärrar är redo kopiera spärren.

5. Vad orsakar spärrstridighet?Om en nödvändig spärr är upptagen, processen begär det snurrar, försöker igen och om det fortfarande inte finns, snurrar igen. Slingan upprepas upp till ett maximalt antal gånger som bestäms av initialiseringsparametern _SPIN_COUNT. Om efter hela denna slinga är spärren fortfarande inte tillgänglig, måste processen ge CPU och gå och lägga sig. Ursprungligen sover för en centisecond. Denna tid fördubblas i varje efterföljande sömn.

detta medför en avmattning och resulterar i ytterligare CPU-användning tills en spärr är tillgänglig. CPU-användningen är en följd av” spinning ” av processen. “Spinning” betyder att processen fortsätter att leta efter spärrens tillgänglighet efter vissa tidsintervaller, under vilken den sover.

1. Hur identifierar man strid för interna spärrar?

relevanta dataordboksvyer för att fråga:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

varje rad i tabellen V$LATCH innehåller statistik för en annan typ av latch. Kolumnerna i tabellen återspeglar aktivitet för olika typer av spärrförfrågningar. Skillnaden mellan dessa typer av förfrågningar är om den begärande processen fortsätter att begära en spärr om den inte är tillgänglig:

villig att vänta om spärren begärs med en villig att vänta
begäran inte är tillgänglig, väntar den begärande processen
en kort tid och begär spärren igen.
processen fortsätter att vänta och begära tills
spärren är tillgänglig.

ingen väntan om spärren begärs med en omedelbar begäran är
inte tillgänglig, den begärande processen inte
vänta, men fortsätter behandlingen.

V$LATCHNAME nyckelinformation:

får antal framgångsrika villiga att vänta förfrågningar om
en spärr.

missar antal gånger en initial begäran om villig att vänta
misslyckades.

sover antal gånger en process väntade en begärd en spärr
efter en initial wiling-to-wait begäran.

IMMEDIATE_GETS antal framgångsrika omedelbara förfrågningar för varje spärr.

IMMEDIATE_MISSES antal misslyckade omedelbara förfrågningar för varje spärr.

beräkning av spärrhattförhållande

för att få Träffförhållandet för spärrar, använd följande formel:

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

detta nummer ska vara nära 1. Om inte, Ställ in enligt spärrnamnet

1. Användbara SQL-skript för att få spärrinformation

/*
** Display systemomfattande spärr statistik.
*/
kolumnnamn format A32 trunkera rubrik “SPÄRRNAMN”
kolumn pid rubrik “hållare PID”
välj c.name,a.addr,a.gets,a.misses, a.sleeps,
a. immediate_gets, a. immediate_misses,b. pid
från V$latch a, v$latchholder b, v$latchname c
där A. addr = B. laddr ( + )
och a. latch# = C. latch#
order av a. latch#;

/*
** med tanke på en spärradress, ta reda på spärrenamnet.
*/
kolumnnamn format A64 rubrik ‘namn’
välj a.name från V$latchname a, v$latch b
där b. addr = ‘&addr ‘
och b. latch#=a. latch#;

/*
** Visa spärrstatistik med spärrnamn.
*/
kolumnnamn format A32 rubrik ‘SPÄRRNAMN’
kolumn pid rubrik ‘hållare PID’
välj c.name,a.addr,a.gets,a.misses, a.sleeps,
a. immediate_gets, a. immediate_misses,b. pid
från V$latch a, v$latchholder b, v$latchname c
där A.addr = B.laddr(+) och a. latch# = C. latch#
och c.name gilla ‘&latch_name% ‘ ordning med en. latch#;

1. lista över alla spärrar

Oracle-versioner kan skilja sig åt i spärren# som tilldelats de befintliga spärrarna.
följande fråga hjälper dig att identifiera alla spärrar och det tilldelade numret.

kolumnnamn format A40 rubrik ‘SPÄRRNAMN’
välj spärr#, namn från V$latchname;

1. lista över spärrar som är mest oroande för en DBA

• BUFFERTCACHE-spärrar: det finns två huvudlås som skyddar datablock i buffertcachen. Strid för dessa två spärrar ses vanligtvis när en databas har höga i/O-priser. Vi kan minska stridigheter för dessa spärrar och ställa in dem genom att justera vissa init.ora parametrar.

Cache buffers chains latch:

denna spärr förvärvas när ett block i buffertcachen nås (fästs).

att minska strid för cache-buffertkedjans spärr kräver vanligtvis att man minskar logiska I/O-hastigheter genom att ställa in och minimera I / O-kraven för den involverade SQL. Höga i / O-priser kan vara ett tecken på ett hett block (vilket betyder ett block som är mycket tillgängligt).

Se Anmärkning 163424.1 Hur man identifierar ett hett Block i databasen för att korrekt identifiera problemet.

Cache buffertar LRU chain latch:

cache bufferten LRU chain latch förvärvas för att införa ett nytt block i buffertcachen och när du skriver en buffert tillbaka till disken, speciellt när du försöker skanna LRU-kedjan (minst nyligen Använd) som innehåller alla smutsiga block i buffertcachen.

det är möjligt att minska stridigheter för cache buffert lru kedja spärren genom att öka storleken på buffertcachen och därigenom minska den hastighet med vilken nya block införs i buffertcachen. Två parametrar dikterar storleken på buffertcachen, DB_BLOCK_SIZE och DB_BLOCK_BUFFERS. I själva verket kan endast DB_BLOCK_BUFFERS ändras utan att återskapa databasen. Varning, när du ställer in buffertpoolen, undvik att använda ytterligare buffertar som bidrar lite eller ingenting till cache-träffförhållandet. Ett vanligt misstag är att fortsätta öka värdet på DB_BLOCK_BUFFERS. Sådana ökningar har ingen effekt om du gör fullständiga tabellskanningar eller andra operationer som inte använder buffertcachen. Flera buffertpooler kan bidra till att minska stridigheter på denna spärr.Du kan skapa ytterligare cache buffert lru kedja spärrar genom att justera konfigurationsparametern DB_BLOCK_LRU_LATCHES. Du kanske kan minska belastningen på cache-buffertkedjelåsarna genom att öka konfigurationsparametern _DB_BLOCK_HASH_BUCKETS

• REDOLOG BUFFERTLÅS: det finns två gör om buffertlås, redo allocation latch och redo copy latch. Spärren för omfördelning måste förvärvas för att allokera utrymme i bufferten. Om den redo-loggpost som ska göras är större än konfigurationsparametern LOG_SMALL_ENTRY_MAX_SIZE, kan sessionen som förvärvar redo-allokeringslåset kopiera posten till redo-bufferten omedelbart medan du håller allokeringslåset. Om loggposten är större än LOG_SMALL_ENTRY_MAX_SIZE, kommer sessionen att släppa om allokeringslåset och förvärva omkopieringslåset för att kopiera posten. Det finns bara en gör om allokeringsspärr, men det kan vara upp till LOG_SIMULTANEOUS_COPIES allokeringslås.

gör om allokeringsspärr:

denna spärr styr allokeringen av utrymme för Gör om poster i Gör om loggbufferten. Det finns en gör om allokeringsspärr per instans.

strid för denna spärr i Oracle7 kan minskas genom att minska värdet på LOG_SMALL_ENTRY_MAX_SIZE på multi-cpu-system för att tvinga användningen av
gör om kopieringsspärren. I Oracle8i är denna parameter föråldrad, så du måste överväga att öka storleken på LOG_BUFFERTEN eller minska belastningen på loggbufferten med hjälp av NOLOGGING-funktioner när det är möjligt.

gör om kopieringsspärr:

denna spärr används för att skriva om poster i redolog-bufferten. Denna spärr väntar på både singel-och multi-cpu-system.

på multi-cpu-system kan strid minskas genom att öka värdet på LOG_SIMULTANEOUS_COPIES (dold i Oracle8i) och/eller öka LOG_ENTRY_PREBUILD_THRESHOLD (odokumenterad i Oracle7).

• BIBLIOTEKSCACHE

bibliotekets cache-spärr:

bibliotekets cache-spärrar skyddar de cachade SQL-satserna och objektdefinitionerna i bibliotekets cache i den delade poolen. Bibliotekets cache-spärr måste förvärvas för att lägga till ett nytt uttalande i bibliotekets cache. Under en tolkning söker Oracle i bibliotekets cache efter ett matchande uttalande. Om man inte hittas, kommer Oracle att analysera SQL-satsen, hämta bibliotekets cache-spärr och sätt in den nya SQL.

den första resursen för att minska strid på denna spärr är att säkerställa att applikationen återanvänder så mycket som möjligt SQL-uttrycksrepresentation. Använd bindningsvariabler när det är möjligt i applikationen. Missar på denna spärr kan också vara ett tecken på att applikationen analyserar SQL i hög takt och kan lida av för mycket parse CPU overhead.Om applikationen redan är inställd kan SHARED_POOL_SIZE ökas. Var medveten om att om programmet inte använder bibliotekets cache på lämpligt sätt kan påståendet vara värre med en större struktur som ska hanteras.

parametern _kgl_latch_count styr antalet spärrar i bibliotekets cache. Standardvärdet bör vara tillräckligt, men om strid för bibliotekets cache-spärr inte kan lösas kan det vara tillrådligt att öka detta värde. Standardvärdet för _KGL_LATCH_COUNT är nästa primtal efter CPU_COUNT. Detta värde får inte överstiga 66 (se:).

Bibliotek cache pin latch:

biblioteket cache pin latch måste förvärvas när ett uttalande i biblioteket cache är reexekuteras. Missar på denna spärr uppstår när det finns mycket höga SQL-körningar.

det finns lite som kan göras för att minska belastningen på bibliotekets cache-pin-spärr, även om man använder privata snarare än offentliga synonymer eller direkta objektreferenser som ägare.Tabell kan hjälpa.

• delade POOLRELATERADE spärrar

delad poolspärr:

medan bibliotekets cache-spärr skyddar operationer med bibliotekets cache, används den delade poolspärren för att skydda kritiska operationer när du allokerar och frigör minne i den delade poolen.
om en applikation använder bokstavlig (odelad) SQL kan detta allvarligt begränsa skalbarhet och genomströmning. Kostnaden för att analysera ett nytt SQL-uttalande är dyrt både när det gäller CPU-krav och antalet gånger bibliotekets cache och delade poollås kan behöva förvärvas och släppas. Innan Oracle9 används det bara en sådan spärr till hela databasen för att skydda allokeringen av minne i bibliotekets cache. I Oracle9 infördes flera barn för att lindra strid om denna resurs.

sätt att minska den delade poolspärren är, undvik hårda parser när det är möjligt, analysera en gång, kör många. Att eliminera bokstavlig SQL är också användbart för att undvika den delade poolspärren. Storleken på shared_pool och användningen av MTS (shared server option) påverkar också den delade poolspärren i hög grad. Anmärkning 62143.1 förklarar hur man identifierar och korrigerar problem med den delade poolen och den delade poolspärren.

Row cache objects latch:

denna spärr spelar in när användarprocesser försöker komma åt de cachade dataordboksvärdena.

det är inte vanligt att ha strid i denna spärr och det enda sättet att minska strid för denna spärr är genom att öka storleken på den delade poolen (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT i Oracle7)

SPIN_COUNT styr hur många gånger processen kommer att försöka få spärren igen innan du backar och lägger dig. Detta innebär i grunden att processen är i en tät CPU-slinga som ständigt försöker få spärren för SPIN_COUNT-försök. På ett enda CPU-system om en Oracle-process försöker skaffa en spärr men den hålls av någon annan kommer processen att släppa CPU: n och gå och sova under en kort period innan du försöker igen. På ett multiprocessorsystem (SMP) är det dock möjligt att processen som håller spärren körs på en av de andra processorerna och så kommer potentiellt att släppa spärren i de närmaste instruktionerna (spärrarna hålls vanligtvis bara under mycket korta tidsperioder).

prestanda kan justeras genom att ändra värdet på SPIN_COUNT. Om ett högt värde används kommer spärren att uppnås tidigare än om du använder ett lågt värde. Du kan dock använda mer CPU-tidsspinnning för att få spärren om du använder ett högt värde för SPIN_COUNT. Du kan minska denna Sannolikhet för session sover genom att öka värdet på konfigurationsparametrarna _LATCH_SPIN_COUNT eller SPIN_COUNT. Denna parameter styr antalet försök som sessionen kommer att göra för att få spärren innan du sover. Spinning på spärren förbrukar CPU, så om du ökar denna parameter kan du se en ökning av ditt systems totala CPU-utnyttjande. Om din dator är nära 100% CPU och din applikation är genomströmning snarare än svarstid driven, kan du överväga att minska SPIN_COUNT för att spara CPU. Justering av SPIN_COUNT är försök och fel. I allmänhet bara öka SPIN_COUNT om det finns tillräckligt med gratis CPU-resurser tillgängliga på systemet, och minska den endast om det inte finns någon ledig CPU-kapacitet.