Upload
aaralyn
View
112
Download
5
Embed Size (px)
DESCRIPTION
Oracle wait interface. Lubom ír Andrle lubomir.andrle @ unicorn.eu 7 . přednáška 18 .1 1 .201 3. Agenda. Co je to Oracle wait interface Co je to wait event Top 10 wait events. Opakování. Opakování - Jak probíhá dotaz. Uživatel zadá dotaz Server začne zpracovávat dotaz - PowerPoint PPT Presentation
Citation preview
Agenda
• Co je to Oracle wait interface• Co je to wait event• Top 10 wait events
Opakování
Opakování - Jak probíhá dotaz
• Uživatel zadá dotaz• Server začne zpracovávat dotaz
– Shared pool provede soft-parse, jinak hard-parse
• Vloží do shared poolu– Vložení nového příkazu do shared poolu vyžaduje latch
• Server proces hledá v buffer cache požadovaný data blok– Data block přesune do sekce naposledy použitých– Nebyl nalezen, server proces načte data ze souboru na disku (I/O
a latch)
Opakování - Jak probíhá update
• Uživatel spustí příkaz UPDATE• Hard-parse x soft-parse• Změněné řádky se změní v shared memory a také v undo
tablespace• Změna se projeví v redo logs souborech• Proces DBWR zapíše změněné data z buffer cache do file
systému• Při commit se logwriter pokusí zkopírovat obsah redo log
bufferu do redo log souborů• Každé 3 vteřiny nebo v případě, že nastane „switch“ redo
logů nastane checkpoint
ORACLE WAIT INTERFACE
Základní myšlenka
• Protože potřebujete vědět kde vaše aplikace tráví čas ;)
• Záznam u každé obslužné rutiny – Před jejím spuštěním vyvolá událost– Provede se vlastní kód– Událost se ukončí
Co je Oracle wait interface (OWI)
• Nástroj pro sledování časové náročnosti činností v rámci životního cyklu session– Umožňuje identifikovat úzká místa (bottleneck)– Slouží pro sledování wait events
Proč OWI
• Dokáže rychle identifikovat úzká místaResponse Time = Service Time + Wait Time
• Při ladění DB dává smysl používat response time
• Přesně ukazuje na úzká místa
OWI
• Od verze Oracle 7.0.12• Sada pohledů– V$SYSTEM_EVENT– V$SESSION_EVENT– V$SESSION_WAIT– V$EVENT_NAME– V$SESSION
Instrumentace
• Myšlenka Oracle– Každá činnost musí být zaznamenána– Každá činnost musí být dohledatelná– Každá činnost musí mít úrovně detailu
• Nástroje pro trace– Event 10046
• Sql extended trace• Ukázka
Použití Trace
• Důležité jak na DB úrovni tak na aplikační vrstvě– „Obalit“ kód pracující s DB (podepsání session, …)– Např. package ILO (Instrumentation Library for Oracle )
• http://method-r.com/software/ilo
• Bez možnosti sledovat skutečný běh nelze systém provozovat, nebo jenom velice obtížně …
Ukázka trace filePARSING IN CURSOR #1 len=923 dep=0 uid=82 oct=3 lid=82 tim=1071461386936456 hv=3471484162 ad='db203a8'select y.oppar_db_job_name,y.oppar_db_job_rec,y.oppar_db_prefix,y.oppar_db_request_flag,y.oppar_db_run_id,TO_CHAR(y.oppar_db_last_date,'yyyymmdd') ,oppar_run_modefrom…………………………….END OF STMTEXEC#1:c=2720000,e=2819768,p=29022,cr=31542,cu=0,mis=0,r=0,dep=0,og=4,tim=1071461386936431FETCH #1:c=0,e=9,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1071461386936555WAIT #1: nam='SQL*Net message to client' ela= 5 p1=1952673792 p2=1 p3=0WAIT #1: nam='SQL*Net message from client' ela= 19535208 p1=1952673792 p2=1 p3=0BINDS #1:bind 0: dty=1 mxl=32(03) mal=00 scl=00 pre=00 oacflg=00 oacfl2=1 size=32 offset=0bfp=110319ed0 bln=32 avl=00 flg=05WAIT #1: nam='db file sequential read' ela= 27 p1=45 p2=119835 p3=1WAIT #1: nam='db file sequential read' ela= 10 p1=45 p2=119838 p3=1WAIT #1: nam='db file scattered read' ela= 74 p1=45 p2=119847 p3=2WAIT #1: nam='db file sequential read' ela= 9 p1=45 p2=119852 p3=1
Pojmy
• Latch– Oracle low-level mechanismus pro serializaci
přístupu do paměťových struktur • buffer cache, …
– Jednoduchá paměťová struktura• Latch contention– Chci latch, ale někdo jiný ji právě používá– Počkám až bude k dispozici
Pojmy II
• KGX = Kernel Generic muteX– Od verze 10.2– Fyzicky stejná struktura jako latch
• Pouze odlehčená a menší
WAIT EVENTS
Co je to wait event
• Oracle termín …• Procesy čekají na– Uvolnění zdrojů– Dokončení jiné akce– Samotnou práci
• OWI umožňuje měření právě těchto wait events
Přehled wait events
• 41 skupin wait events v 10.2.0.3• 878 wait events in 10.2.0.3– 209 enqueue events– 29 latch events– 41 I/O events
TOP 10 WAIT EVENTS
Motivace
• Jde o čistě subjektivní výběr nejdůležitějších wait events
• Měli byste vědět – Co je způsobuje– Jaké hodnoty jsou přiměřené– Co můžete dělat, abyste je opravili
Procesorový čas CPU
• Není čistě wait event• Může být dobrým ukazatelem v mnoha
případech– chybný execution plan
DB File Sequential Read
• Single block read– Obvykle index nebo data block pomocí rowid
• Rozumná hodnota: < 10ms
DB File Sequential Read II
• Dělat toho méně ;)– Ladění SQL
• Redukce LIO
– Zvětšit buffer cache• Pracovat rychleji– Urychlit I/O
DB File Scattered Read
• Multi block read• Obvykle full table scan nebo fast full scan
indexu• Rozumná hodnota: < 10ms
DB File Scattered Read II
• Dělat toho méně ;)– Lepší indexy– Dobré systémové statistiky– Větší buffer cache– Ladění SQL
• Pracovat rychleji– Urychlit I/O
Direct Path Read/Write
• Obvykle třídění v temp• Přístup vždy do PGA• Může být také paralelní dotaz• Rozumná hodnota: < 20ms
Porovnání
Log File Sync
• Uživatelský proces čeká na LGWR – Vyprázdnění redo po uživatelském commit
• Pozor na příliš mnoho commitů• Rozumná hodnota : <4ms
Log File Parallel Write
• Čekání na zápis LGWR do log files• Systémová I/O operace• Rozumná hodnota : <4ms
Log file switch …
• Nastane, když databáze přepíná log files• Zamrznutí celé databáze• Rozumná hodnota: 0ms• Typy– log file switch(archiving needed)– log file switch (checkpoint incomplete) – log file switch (private strand flush incomplete)– log file switch completion
Read by other session
• Soupeření o stejný blok– Více session chce číst stejný blok – Více session čeká na dokončení změny bloku
Read by other session II
• Komplikované předcházení• Obecně– Eliminujte soupeření– Najděte a eliminujte horké objekty
• Jedna z cest odhalení úzkého místa je ASH (active session history)
Read by other session III
• LGWR – proces starající se o zápis do logů• DBWR – proces starající se o zápis dat• User1,2,3 – uživatelské procesy
Read by other session IV
• Při modifikaci bloku musí být zamčena hlavička bloku– Zámek je na velice krátkou dobu, ale v případě
více procesů může jít o úzké místo
Enqueue locks
• Rozdíl oproti latch– Latch poskytuje exkluzivní přístup – Enqueues umožňují sdílený přístup– V případě latch musí session usnout nebo zkoušet
přístup znovu a nemá záruku, že latch získá při dalším pokusu
Monitoring enqueue locks
• V$LOCK– Seznam aktuálních enqueues– Obsahuje typ enqueue
• V$SESSION_WAIT• Lze jednoduše zjistit čekající sessions• V$SESSION– Od verze 10g– Wait informace z V$SESSION_WAIT– BLOCKING_INSTANCE a BLOCKING_SESSION
TX wait events - enqueue
• Transakční zámek (Transaction enqueue)– Contention na konkrétní řádek tabulky
• Cílem je zabránit zápisu dvou session do stejného řádku tabulky
• Uvolněn vždy při commit transakce
TM wait events - enqueue
• „DDL“ zámky (Table Modification Enqueue)• Cílem je zabránit změnit definice tabulky
dvěma session• Typicky nastává při ověřování FK
SQL*Net message from client
• Databáze je v klidovém stavu – Čeká na další požadavek od klienta
• Často označována jako „Idle event“• Ukazuje na přenesení vykonávání na aplikační
vrstvu
SQL*Net message to client
• Přenos na stranu aplikační logiky
SQL*Net more data from client
• Pro poslání SQL je potřeba více jak jeden packet
• Neposílejte SQL větší než 50kB ;)
SQL*Net more data from client
• Stejné jako SQL*Net message to client, ale pro data– Hodnoty bind proměnných– Bulk operace
• Reprezentuje čas potřebný pro zabalení dat do packetů
Q&A