Här är några av de vanliga Oracle-väntehändelserna som alla borde känna till.
Vänta händelser
Du kan hitta vilken händelsesession som väntar på den genom att följa frågan
select event from V$session_wait where sid=&1
Jag försöker förklara några vanliga Oracle-väntehändelser, det finns orsaker och lösningar
kö
Processen väntar på en orakelkö (ett lås som du kan se i v$lock). Detta inträffar vanligtvis när en användare försöker uppdatera en rad i en tabell som för närvarande uppdateras av en annan användare. Blockerarna kan ta reda på genom att använda följande fråga
select * from dba_waiters
bibliotekets cachestift
Processen vill fästa ett objekt i minnet i bibliotekets cacheminne för undersökning, för att säkerställa att inga andra processer kan uppdatera objektet samtidigt. Detta händer när du kompilerar eller analyserar ett PL/SQL-objekt eller en vy. Undvik att kompilera PL/SQL-objekt eller orakelvy vid hög användningstid för att undvika denna väntehändelse
låsning av bibliotekscache
Processen väntar på möjligheten att ladda ett objekt eller en del av ett objekt i bibliotekets cache. (Endast en process kan ladda ett objekt eller en del av ett objekt åt gången.)
låsfri
Processen väntar på en spärr som hålls av en annan process. (Denna väntehändelse gäller inte processer som snurrar medan de väntar på en spärr; när en process snurrar väntar den inte.).Latches är lätta serialiseringsenheter som används för att koordinera åtkomst för flera användare till delade datastrukturer, objekt, och filer.
Lås är lås som är designade för att hållas under extremt korta tidsperioder, till exempel den tid det tar att ändra en datastruktur i minnet. De används för att skydda vissa minnesstrukturer, såsom databasblockets buffertcache eller bibliotekscachen i den delade poolen.
Oracle-lås efterfrågas vanligtvis internt i ett "villigt att vänta"-läge. Detta innebär att om spärren inte är tillgänglig, kommer den begärande sessionen att vila under en kort tidsperiod och försöka igen senare. Andra spärrar kan begäras i ett "omedelbart" läge, som i konceptet liknar en SELECT FOR UPDATE NO-WAIT, vilket innebär att processen kommer att göra något annat, som att försöka ta tag i en motsvarande syskonspärr som kan vara gratis, istället för att sitta och vänta på att denna spärr blir tillgänglig. Eftersom många förfrågningar kan vänta på en låsning samtidigt, kan du se att vissa processer väntar längre än andra.
Spärrarna tilldelas ganska slumpmässigt, baserat på lyckan med dragningen, om du så vill. Vilken session som än ber om en spärr direkt efter att den släpptes kommer att få den. Det finns ingen rad servitörer, bara en massa servitörer som ständigt försöker igen.
buffert upptagen väntar
Processen vill komma åt ett datablock som för närvarande inte finns i minnet, men en annan process har redan utfärdat en I/O-begäran för att läsa in blocket i minnet. (Processen väntar på att den andra processen ska slutföra blocket i minnet.). De heta blocken kan hittas med vy V$BH
db-fil spridd läst
Processen har utfärdat en I/O-begäran för att läsa en serie sammanhängande block från en datafil till buffertcachen och väntar på att operationen ska slutföras. Detta händer vanligtvis under en fullständig tabellgenomsökning eller en fullständig indexsökning.
Vi bör kontrollera om frågan ska användas med full tabellskanning. Se till att Oracle Optimizer-statistiken är uppdaterad. Använd partitionsbeskärning för att minska antalet besökta block
Om en fråga som har kört bra ett tag plötsligt klockar mycket tid på db-filens spridda läshändelse och det inte har skett en kodändring, kanske du vill kontrollera om ett eller flera index har tappats eller bli oanvändbar.
db-fil sekventiell läsning
Processen har utfärdat en I/O-begäran om att läsa ett block från en datafil till buffertcachen och väntar på att operationen ska slutföras. Detta händer vanligtvis under en indexsökning eller en hämtning från en orakeltabell av ROWID när det nödvändiga datablocket inte redan finns i minnet. Låt dig inte vilseledas av det förvirrande namnet på denna väntande händelse!
Vi bör kontrollera om rätt index används. Ett felaktigt index kan göra att frågan fungerar dåligt. Se till att optimeringsstatistiken är uppdaterad.
db-fil parallell läsning
Processen har utfärdat flera I/O-förfrågningar parallellt för att läsa block från datafiler till minnet och väntar på att alla förfrågningar ska slutföras. Dokumentationen säger att denna väntehändelse endast inträffar under återställning, men i själva verket inträffar den också under regelbunden aktivitet när en process grupperar många enkla I/O-förfrågningar tillsammans och utfärdar dem parallellt. (Trots namnet kommer du inte att se denna väntehändelse under parallellförfrågan eller parallell DML. I dessa fall inträffar istället väntahändelser med PX i deras namn.)
db-fil parallell skrivning
Processen, vanligtvis DBWR, har utfärdat flera I/O-förfrågningar parallellt för att skriva smutsiga block från buffertcachen till disken, och väntar på att alla förfrågningar ska slutföras.
direkt sökväg läs, direkt sökväg skriv
Processen har utfärdat asynkrona I/O-förfrågningar som kringgår buffertcachen och väntar på att de ska slutföras. Dessa väntehändelser involverar vanligtvis sorteringssegment.
SQL-satser med funktioner som kräver sortering, som ORDER BY, GROUP BY, UNION, DISTINCT och ROLLUP, skrivsorteringskörningar till den temporära tabellytan när indatastorleken är större än arbetsområdet i PGA
Se till att optimeringsstatistiken stämmer överens med data och att frågan använder rätt körtabell. Kontrollera om det sammansatta indexets kolumner kan omarrangeras för att matcha ORDER BY-satsen för att undvika sortering helt.
Se till att lämpligt värde PGA_AGGREGATE_TARGET är inställt. Använd om möjligt UNION ALL istället för UNION.
Delad poolspärr
Den delade poollåset används för att skydda kritiska operationer vid allokering och frigöring av minne i den delade poolen. Invändningar för den delade poolen och bibliotekets cachelås beror huvudsakligen på intensiv hård analys. En hård analys gäller nya markörer och markörer som har åldrats och måste köras om
Kostnaden för att analysera en ny SQL-sats är dyr både när det gäller CPU-krav och antalet gånger bibliotekets cache och delade poolen spärrarna kan behöva skaffas och släppas.
Att eliminera bokstavlig SQL är också användbart för att undvika den delade poollåset
kontrollfil sekventiell läsning
Processen väntar på att block ska läsas från en kontrollfil. Detta händer i allmänhet
- gör en säkerhetskopia av kontrollfilerna
- delning av information (mellan instanser) från kontrollfilen
- läsa andra block från kontrollfilerna
- läser rubrikblocket
Om detta är en stor väntande händelse, betyder det att kontrollfilens plats måste ändras till snabbare diskplats
kontrollfil parallell skrivning
Processen har utfärdat flera I/O-förfrågningar parallellt för att skriva block till alla kontrollfiler och väntar på att alla skrivningar ska slutföras.
loggbuffertutrymme
Processen väntar på att utrymme ska bli tillgängligt i loggbufferten (utrymme blir tillgängligt först efter att LGWR har skrivit det aktuella innehållet i loggbufferten till disken.) Detta händer vanligtvis när applikationer genererar göra om snabbare än LGWR kan skriva det. till disk.
Detta kan också hända om I/O till disk där redo-loggar finns är långsam
Det bör inte finnas något loggbuffertutrymme som sådan i databasen. Överväg att göra loggbufferten större om den är liten eller överväg att flytta loggfiler till snabbare diskar som randiga diskar.
Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');
PCt_buff_alloc_retries bör vara noll eller mindre än 0,01 (<1%). Om den är större överväg att göra loggbufferten större. Om det är större kan du överväga att flytta loggfilerna till snabbare diskar som randiga diskar.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
loggfil sekventiell läsning
Processen väntar på att block ska läsas från online-redo-loggningen till minnet. Detta inträffar i första hand vid uppstart av instanser och när ARCH-processarkiven fyllde omloggar online.
loggfil parallell skrivning
Processen väntar på att block ska skrivas till alla redo-loggmedlemmar online i en grupp. LGWR är vanligtvis den enda processen för att se denna väntande händelse. Det kommer att vänta tills alla block har skrivits till alla medlemmar.
loggfilsynkronisering
Processen väntar på att LGWR ska slutföra tömningen av loggbufferten till disken. Detta inträffar när en användare begår en transaktion. (En transaktion anses inte ha genomförts förrän alla gör om för att återställa transaktionen har skrivits till disken.)
En långsam LGWR-process kan introducera väntetider för synkronisering av loggfiler som gör att användaren upplever väntetider under commit eller rollback. Loggfilens parallellskrivning och loggfilsynkroniseringsväntehändelser är relaterade till varandra och måste hanteras samtidigt.
Vi måste försöka allokera redo-loggarna till högpresterande disk (solid state disk). Vi bör också försöka minska belastningen på LGWR genom att minska commits i apparna.
Den manuella hot-backup-delen kan också introducera stress i systemet genom att generera många gör om saker, så undvik det under högtrafik
Ibland svälter LGWR efter CPU-resurser. Om servern är mycket upptagen kan LGWR också svälta efter CPU. Detta kommer att leda till långsammare svar från LGWR, vilket ökar väntan på "loggfilsynkronisering". När allt kommer omkring måste dessa systemanrop och I/O-anrop använda CPU. I det här fallet är "loggfilsynkronisering" ett sekundärt symptom och att lösa grundorsaken till hög CPU-användning kommer att minska väntan på "loggfilssynkronisering".
På grund av problem med minnessvält kan LGWR också sökas ut. Detta kan också leda till långsammare svar från LGWR.
ångra segmenttillägg
Sessionen väntar på att ett ångra segment ska förlängas eller krympas.
skriv fullständiga väntar
Sessionen väntar på att en begärd buffert ska skrivas till disken; bufferten kan inte användas medan den skrivs.
Latch:cachebuffertkedjor
Cachebuffertkedjornas låsningar används för att skydda en buffertlista i buffertcachen. Dessa spärrar används när du söker efter, lägger till eller tar bort en buffert från buffertcachen.
Block i buffertcachen placeras på länkade listor (cachebuffertkedjor) som hänger utanför en hashtabell. Hashkedjan som ett block placeras på baseras på blockets DBA och KLASS. Varje hashkedja är skyddad av en enda barnspärr. Processer måste få den relevanta spärren så att de kan skanna en hashkedja efter en buffert så att den länkade listan inte ändras under dem.
Tvist om denna spärr betyder vanligtvis att det finns ett block som är i stor strid (känd som ett hot block).
För att identifiera den tungt åtkomliga buffertkedjan, och därmed den omsträvade blockeringen, titta på låsstatistik för cachebuffertkedjornas låsningar med V$LATCH_CHILDREN-vyn. Om det finns en specifik cache-buffertkedjor barnlås som har många fler GETS, MISSES och SLEEPS jämfört med de andra underordnade spärrarna, då är detta den utpekade för barnlås.
Denna spärr har en minnesadress som identifieras av ADDR-kolumnen.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Använd värdet i ADDR-kolumnen förenad med V$BH-vyn för att identifiera blocken som skyddas av denna spärr. Till exempel, givet adressen (V$LATCH_CHILDREN.ADDR) till en hårt omtvistad spärr, frågar detta efter fil- och blocknummer:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH är en pekräkning för bufferten. Ett högt värde för X$BH.TCH indikerar ett hot block.
Många block är skyddade av varje spärr. En av dessa buffertar kommer förmodligen att vara hot blocket. Varje block med ett högt TCH-värde är ett potentiellt hot block. Utför den här frågan ett antal gånger och identifiera blocket som konsekvent visas i utdata.
När du har identifierat hotblocket, fråga DBA_EXTENTS med filnumret och blocknumret för att identifiera segmentet.
Viktig information om väntande händelse
Vyn v$session_wait visar information om väntande händelser som aktiva sessioner väntar på. Följande är beskrivningen av denna vy, och den innehåller några mycket användbara kolumner, särskilt P1- och P2-referenserna till objekten som är associerade med väntehändelserna.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Med hjälp av v$session_wait är det lätt att tolka varje wait-händelseparameter med hjälp av motsvarande beskrivande textkolumner för den parametern. Vänteklasskolumner lades också till så att olika väntehändelser kunde grupperas i relaterade bearbetningsområden såsom nätverk, applikation, inaktiv, samtidighet, etc.
Dessa kolumner lades också till i v$sessionstabellen från 10g och framåt . Så du kan bara använda v$session för att hitta alla detaljer
Varje väntehändelse innehåller andra parametrar som ger ytterligare information om händelsen.
Hur du hittar informationen om väntahändelse och dess parameter
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Låt säga att vi till exempel tog
Inmatningsvärdena för händelsenamn:db-fil spridd läst
Originalvärde på 3:WHERE NAME ='&event_name A'
Det nya värdet 3:WHERE NAME ='db-fil spridd läst'
Namnet P1 P2 P3
db-fil spridd läs fil # block # block
fil #:datafilnummer
Block #:startblocknummer
block:för att läsa numret på datablocket
Låt oss nu se hur informationen ovan kan hjälpa oss fånga olika saker
Anta att en viss session väntar på en buffer busy waits-händelse, databasobjektet som orsakar denna wait-händelse kan enkelt fastställas:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Utdata från denna fråga för en viss session med SID 4563 kan se ut så här:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Kolumnerna P1 och P2 tillåter DBA att fastställa fil- och blocknummer som orsakade denna väntehändelse. Frågan nedan hämtar objektnamnet som äger datablock 155, värdet på P2 ovan:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Möjligheten att analysera och korrigera väntan i Oracle Database är avgörande i alla trimningsprojekt. Majoriteten av aktiviteten i en databas involverar läsning av data, så denna typ av justering kan ha en enorm, positiv inverkan på prestandan.
Obs:När du gör vänteanalys är det viktigt att komma ihåg att alla Oracle-databaser upplever väntehändelser och att förekomsten av väntetider inte alltid indikerar ett problem. Faktum är att alla vältrimmade databaser har en viss flaskhals.
vi kan använda 10046-händelsen för att spåra wait-händelsen för sessionen också
Läser också
Oracle-dokumentation
v$active_session_history
Förklara plan i Oracle