Zde jsou některé běžné události čekání Oracle, které by měl každý znát.
Čekejte události
Jaká relace události na ni čeká, můžete zjistit pomocí následujícího dotazu
select event from V$session_wait where sid=&1
Snažím se vysvětlit několik běžných událostí čekání Oracle, jejich příčiny a řešení
řada
Proces čeká na oracle enqueue (zámek, který můžete vidět ve v$lock). K tomu běžně dochází, když se jeden uživatel pokouší aktualizovat řádek v tabulce, který je aktuálně aktualizován jiným uživatelem. Blokátory lze zjistit pomocí následujícího dotazu
select * from dba_waiters
Kód mezipaměti knihovny
Proces chce připnout objekt v paměti v mezipaměti knihovny za účelem prozkoumání, aby zajistil, že žádný jiný proces nemůže objekt aktualizovat současně. K tomu dochází, když kompilujete nebo analyzujete PL/SQL objekt nebo pohled. Vyhněte se kompilaci objektu PL/SQL nebo pohledu oracle při vysokém využití, abyste se vyhnuli této události čekání
Zámek načítání mezipaměti knihovny
Proces čeká na příležitost načíst objekt nebo část objektu do mezipaměti knihovny. (Objekt nebo část objektu může načíst současně pouze jeden proces.)
Uvolnění západky
Proces čeká na západku drženou jiným procesem. (Tato událost čekání se nevztahuje na procesy, které se točí při čekání na latch; když se proces točí, nečeká.). Latche jsou lehká serializační zařízení používaná ke koordinaci víceuživatelského přístupu ke sdíleným datovým strukturám, objektům, a soubory.
Zámky jsou zámky navržené tak, aby byly drženy po extrémně krátkou dobu, například dobu, kterou zabere úprava datové struktury v paměti. Používají se k ochraně určitých paměťových struktur, jako je vyrovnávací paměť bloku databáze nebo mezipaměť knihovny ve sdíleném fondu.
Oracle Latche jsou obvykle vyžadovány interně v režimu „ochota čekat“. To znamená, že pokud latch není k dispozici, žádající relace na krátkou dobu přejde do režimu spánku a operaci zopakuje později. Jiné západky mohou být požadovány v „okamžitém“ režimu, který je svou koncepcí podobný SELECT FOR UPDATE NO-WAIT, což znamená, že proces udělá něco jiného, například pokusí se chytit ekvivalentní sourozeneckou západku, která může být volná, než sedět a čekat, až bude tato západka k dispozici. Vzhledem k tomu, že na blokování může čekat mnoho požadavků současně, můžete vidět, že některé procesy čekají déle než jiné.
Západky jsou přidělovány spíše náhodně, na základě štěstí při losování, chcete-li. Kterákoli relace požádá o západku hned po jejím uvolnění, dostane ji. Neexistuje žádná fronta číšníků, kteří se přidržují, jen dav číšníků, kteří to neustále opakují.
vyrovnávací paměť čeká na zaneprázdnění
Proces chce přistupovat k datovému bloku, který aktuálně není v paměti, ale jiný proces již vydal I/O požadavek na načtení bloku do paměti. (Proces čeká, až druhý proces dokončí přenesení bloku do paměti.). Horké bloky lze nalézt pomocí zobrazení V$BH
soubor db roztroušeně přečten
Proces vydal I/O požadavek na načtení série souvislých bloků z datového souboru do mezipaměti a čeká na dokončení operace. K tomu obvykle dochází během úplného prohledání tabulky nebo úplného prohledání indexu.
Měli bychom zkontrolovat, zda by měl dotaz používat úplnou kontrolu tabulky. Ujistěte se, že statistiky optimalizátoru Oracle jsou aktuální. Použijte prořezávání oddílu ke snížení počtu navštívených bloků
Pokud dotaz, který nějakou dobu běžel v pořádku, náhle zaznamená spoustu času v události čtení rozptýleného souboru db a nedošlo ke změně kódu, možná budete chtít zkontrolovat, zda nebyl vypuštěn jeden nebo více indexů nebo se stanou nepoužitelnými.
sekvenční čtení souboru db
Proces vydal I/O požadavek na načtení jednoho bloku z datového souboru do mezipaměti a čeká na dokončení operace. To se obvykle děje během vyhledávání indexu nebo načítání z tabulky Oracle pomocí ROWID, když požadovaný datový blok ještě není v paměti. Nenechte se zmást matoucím názvem této události čekání!
Měli bychom zkontrolovat, zda se používají správné indexy. Nesprávný index může způsobit špatný výkon dotazu. Ujistěte se, že statistiky optimalizátoru jsou aktuální.
paralelní čtení souboru db
Proces vydal paralelně několik I/O požadavků na čtení bloků z datových souborů do paměti a čeká na dokončení všech požadavků. Dokumentace říká, že k této události čekání dochází pouze během obnovy, ale ve skutečnosti k ní dochází také během běžné činnosti, kdy proces spojuje mnoho požadavků na I/O v jednom bloku a vydává je paralelně. (Navzdory názvu tuto událost čekání neuvidíte během paralelního dotazu nebo paralelního DML. V těchto případech se místo toho vyskytnou události čekání s PX v názvu.)
paralelní zápis do souboru db
Proces, obvykle DBWR, zadal paralelně několik I/O požadavků na zápis nečistých bloků z mezipaměti na disk a čeká na dokončení všech požadavků.
přímá cesta čtení, přímý zápis cesty
Proces vydal asynchronní požadavky I/O, které obcházejí mezipaměť vyrovnávací paměti, a čeká na jejich dokončení. Tyto události čekání obvykle zahrnují segmenty řazení.
Příkazy SQL s funkcemi, které vyžadují řazení, jako je ORDER BY, GROUP BY, UNION, DISTINCT a ROLLUP, zapisují běhy řazení do dočasného tabulkového prostoru, když je velikost vstupu větší než pracovní oblast v PGA
Ujistěte se, že statistiky optimalizátoru odpovídají údajům a dotaz používá správnou tabulku řízení. Zkontrolujte, zda lze sloupce složeného indexu přeskupit tak, aby odpovídaly klauzuli ORDER BY, abyste se vyhnuli řazení úplně.
Ujistěte se, že je nastavena vhodná hodnota PGA_AGGREGATE_TARGET. Pokud je to možné, použijte UNION ALL místo UNION.
Zámek sdíleného bazénu
Západka sdíleného fondu se používá k ochraně kritických operací při přidělování a uvolňování paměti ve sdíleném fondu. Spor o zámky mezipaměti sdíleného fondu a knihovny jsou způsobeny především intenzivním náročným analyzováním. Tvrdá analýza se vztahuje na nové kurzory a kurzory, které jsou zastaralé a musí být znovu spuštěny
Náklady na analýzu nového příkazu SQL jsou drahé jak z hlediska požadavků na CPU, tak z hlediska počtu vyrovnávací paměti knihovny a sdíleného fondu může být nutné získat a uvolnit západky.
Odstranění doslovného SQL je také užitečné, abyste se vyhnuli latch sdíleného fondu
řídí sekvenční čtení souboru
Proces čeká na načtení bloků z řídicího souboru. To se děje obecně
- vytvoření zálohy kontrolních souborů
- sdílení informací (mezi instancemi) z kontrolního souboru
- čtení dalších bloků z kontrolních souborů
- čtení bloku záhlaví
Pokud se jedná o hlavní čekající událost, znamená to, že umístění řídicího souboru je třeba změnit na rychlejší umístění na disku
řídí paralelní zápis souboru
Proces vydal paralelně několik I/O požadavků na zápis bloků do všech řídicích souborů a čeká na dokončení všech zápisů.
prostor vyrovnávací paměti protokolu
Proces čeká, až bude k dispozici místo ve vyrovnávací paměti protokolu (Prostor se zpřístupní až poté, co společnost LGWR zapíše aktuální obsah vyrovnávací paměti protokolu na disk.) Obvykle k tomu dochází, když aplikace generují opakování rychleji, než jej LGWR dokáže zapsat na disk.
To se také může stát, pokud je vstup/výstup na disk, kde jsou umístěny protokoly redo, pomalý
V databázi by neměl být žádný prostor pro vyrovnávací paměť protokolu jako takový. Zvažte zvětšení vyrovnávací paměti protokolu, pokud je malá, nebo zvažte přesunutí souborů protokolu na rychlejší disky, jako jsou prokládané disky.
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');
Hodnota pct_buff_alloc_retries by měla být nula nebo menší než 0,01 (<1 %). Pokud je větší, zvažte zvětšení vyrovnávací paměti protokolu. Pokud je to větší, zvažte přesunutí souborů protokolu na rychlejší disky, jako jsou prokládané disky.
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';
sekvenční čtení souboru protokolu
Proces čeká na načtení bloků z online opakovaného přihlášení do paměti. K tomu dochází primárně při spuštění instance a když archivy procesu ARCH vyplňují online redo logy.
paralelní zápis do souboru protokolu
Proces čeká na zapsání bloků všem členům online redo logu v jedné skupině. LGWR je obvykle jediný proces, který vidí tuto událost čekání. Počká, dokud nebudou všechny bloky zapsány všem členům.
synchronizace souboru protokolu
Proces čeká, až LGWR dokončí vyprázdnění vyrovnávací paměti protokolu na disk. K tomu dochází, když uživatel potvrdí transakci. (Transakce se nepovažuje za potvrzenou, dokud nebudou všechna opakování pro obnovení transakce úspěšně zapsána na disk.)
Pomalý proces LGWR může zavést čekání na synchronizaci souboru protokolu, díky čemuž uživatel zažije čekací doby během odevzdání nebo vrácení zpět. Události paralelního zápisu do souboru protokolu a události čekání synchronizace souboru protokolu jsou vzájemně propojené a musí být řešeny současně.
Musíme se pokusit alokovat redo logy na vysoce výkonný disk (Solid state disk). Také bychom se měli pokusit snížit zatížení LGWR snížením závazků v aplikacích.
Ruční hot-backup může také zatížit systém tím, že generuje spoustu věcí znovu, takže se tomu vyhněte ve špičce
Někdy má LGWR nedostatek CPU. Pokud je server velmi zaneprázdněn, může LGWR také hladovět kvůli CPU. To povede k pomalejší odezvě ze strany LGWR, čímž se prodlouží doba čekání na synchronizaci souboru protokolu. Koneckonců, tato systémová volání a I/O volání musí využívat CPU. V tomto případě je „synchronizace souboru protokolu“ sekundárním příznakem a vyřešení hlavní příčiny vysokého využití procesoru zkrátí čekání na „synchronizaci souboru protokolu“.
Kvůli problémům s nedostatkem paměti může být LGWR také stránkováno. To může také vést k pomalejší odezvě od LGWR.
vrátit zpět rozšíření segmentu
Relace čeká na prodloužení nebo zmenšení segmentu zpět.
zápis dokončení čekání
Relace čeká na zapsání požadované vyrovnávací paměti na disk; vyrovnávací paměť nelze během zápisu použít.
Latch:Řetězce mezipaměti
Zámky řetězců vyrovnávacích pamětí se používají k ochraně seznamu vyrovnávacích pamětí ve vyrovnávací paměti. Tyto latche se používají při hledání, přidávání nebo odebírání vyrovnávací paměti z mezipaměti.
Bloky ve vyrovnávací paměti jsou umístěny na propojených seznamech (řetězce mezipaměti), které visí z hashovací tabulky. Řetězec hash, na který je blok umístěn, je založen na DBA a CLASS bloku. Každý hash chain je chráněn jedinou dětskou západkou. Procesy potřebují získat relevantní latch, aby jim umožnily prohledat řetězec hash pro vyrovnávací paměť, aby se pod nimi propojený seznam nezměnil.
Spor o tuto západku obvykle znamená, že existuje blok, který je ve velkém sporu (známý jako horký blok).
Chcete-li identifikovat silně přístupný řetězec vyrovnávacích pamětí, a tedy i blok, o který se bojuje, podívejte se na statistiku latch pro zámky řetězců vyrovnávacích pamětí pomocí pohledu V$LATCH_CHILDREN. Pokud existuje specifická podřízená zámka řetězců mezipaměti, která má mnohem více GETS, MISSES a SLEEPS ve srovnání s ostatními podřízenými zámky, pak se jedná o podřízenou západku.
Tato západka má adresu paměti identifikovanou sloupcem ADDR.
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 /
Použijte hodnotu ve sloupci ADDR spojeném s pohledem V$BH k identifikaci bloků chráněných touto západkou. Například s ohledem na adresu (V$LATCH_CHILDREN.ADDR) silně namáhané západky se toto dotazuje na čísla souborů a bloků:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH je počet dotyků pro vyrovnávací paměť. Vysoká hodnota X$BH.TCH označuje aktivní blok.
Mnoho bloků je chráněno každou západkou. Jedním z těchto bufferů bude pravděpodobně horký blok. Jakýkoli blok s vysokou hodnotou TCH je potenciální horký blok. Proveďte tento dotaz několikrát a identifikujte blok, který se trvale objevuje ve výstupu.
Poté, co identifikujete aktivní blok, zadejte dotaz DBA_EXTENTS pomocí čísla souboru a čísla bloku k identifikaci segmentu.
Důležité informace o události čekání
Zobrazení v$session_wait zobrazuje informace o událostech čekání, na které aktuálně čekají aktivní relace. Následuje popis tohoto pohledu a obsahuje některé velmi užitečné sloupce, zejména odkazy P1 a P2 na objekty spojené s událostmi čekání.
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)
Pomocí v$session_wait je snadné interpretovat každý parametr události čekání pomocí odpovídajících sloupců s popisným textem pro daný parametr. Byly také přidány sloupce třídy čekání, aby bylo možné různé události čekání seskupit do souvisejících oblastí zpracování, jako je síť, aplikace, nečinnost, souběžnost atd.
Tyto sloupce byly přidány také do tabulky v$session od 10g výše . Takže můžete jednoduše použít v$session k nalezení všech podrobností
Každá událost čekání obsahuje další parametry, které poskytují další informace o události.
Jak najít informace o události čekání a jejím parametru
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';
Řekněme například, že jsme vzali
Vstupní hodnoty event_name:db soubor rozptýlené čtení
Původní hodnota 3:WHERE NAME ='&event_name A'
Nová hodnota 3:WHERE NAME ='db soubor rozptýlené čtení'
Název P1 P2 P3
db soubor rozptýlený číst soubor # blok # bloky
číslo souboru:číslo datového souboru
Číslo bloku:číslo počátečního bloku
bloky:čtení čísla datového bloku
Nyní se podívejme, jak nám výše uvedené informace mohou pomoci zachytit různé věci
Předpokládejme, že konkrétní relace čeká na událost čekání zaneprázdnění vyrovnávací paměti, lze snadno určit databázový objekt způsobující tuto událost čekání:
select username, event, p1, p2 from v$session_wait where sid = 4563;
Výstup tohoto dotazu pro konkrétní relaci s SID 4563 může vypadat takto:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
Sloupce P1 a P2 umožňují správci databází určit čísla souborů a bloků, které způsobily tuto událost čekání. Dotaz níže načte název objektu, který vlastní datový blok 155, hodnotu P2 výše:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
Schopnost analyzovat a opravovat události čekání databáze Oracle je zásadní v každém ladícím projektu. Většina činností v databázi zahrnuje čtení dat, takže tento typ ladění může mít obrovský pozitivní dopad na výkon.
Poznámka:Při provádění analýzy čekání je důležité mít na paměti, že všechny databáze Oracle zažívají události čekání a že přítomnost čekání nemusí vždy znamenat problém. Ve skutečnosti všechny dobře vyladěné databáze mají nějaké úzké hrdlo.
můžeme také použít událost 10046 ke sledování události čekání relace
Také čte
Dokumentace Oracle
v$active_session_history
Vysvětlení plánu v Oracle