Architektury a technika databázových systémů Jiří Zechmeister jiri.zechmeister@unicornsystems.eu 7. přednáška 23.11.2016

Obsah Transakce Oracle wait interface Trasakční zpracování UNDO COMMIT/ROLLBACK Oracle wait interface 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)

TRANSAKČNÍ ZPRACOVÁ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ísta Response 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 Nástroje pro trace 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 file PARSING 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 STMT EXEC#1:c=2720000,e=2819768,p=29022,cr=31542,cu=0,mis=0,r=0,dep=0,og=4,tim=1071461386936431 FETCH #1:c=0,e=9,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1071461386936555 WAIT #1: nam='SQL*Net message to client' ela= 5 p1=1952673792 p2=1 p3=0 WAIT #1: nam='SQL*Net message from client' ela= 19535208 p1=1952673792 p2=1 p3=0 BINDS #1: bind 0: dty=1 mxl=32(03) mal=00 scl=00 pre=00 oacflg=00 oacfl2=1 size=32 offset=0 bfp=110319ed0 bln=32 avl=00 flg=05 WAIT #1: nam='db file sequential read' ela= 27 p1=45 p2=119835 p3=1 WAIT #1: nam='db file sequential read' ela= 10 p1=45 p2=119838 p3=1 WAIT #1: nam='db file scattered read' ela= 74 p1=45 p2=119847 p3=2 WAIT #1: nam='db file sequential read' ela= 9 p1=45 p2=119852 p3=1

Pojmy Latch Latch contention 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 KGX mutexes are not OS mutexes!! Od verze 10.2 Fyzicky stejná struktura jako latch Pouze odlehčená a menší KGX mutexes are not OS mutexes!!

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

SELECT * FROM v$event_name; Přehled wait events 41 skupin wait events v 10.2.0.3 wait events v 10.2.0.3 209 enqueue events 29 latch events 41 I/O events 13 tříd wait events v 11.2.0.1 wait events v 11.2.0.1 celkem 1116 290 enqueue events 43 latch events 75 I/O events SELECT * FROM v$event_name;

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