Oracle wait interface

Post on 29-Jan-2016

98 views 5 download

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

transcript

Oracle wait interface

Lubomír Andrlelubomir.andrle@unicorn.eu

7. přednáška18.11.2013

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