Architektury a technika databzovch systm Ji Zechmeister jiri
Architektury a technika databázových systémů Jiří Zechmeister jiri. zechmeister@unicornsystems. eu 7. přednáška 23. 11. 2016
Obsah • Transakce – Trasakční zpracování – UNDO – COMMIT/ROLLBACK • 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_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 file PARSING IN CURSOR #1 len=923 dep=0 uid=82 oct=3 lid=82 tim=1071461386936456 hv=3471484162 ad='db 203 a 8' 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 p 1=1952673792 p 2=1 p 3=0 WAIT #1: nam='SQL*Net message from client' ela= 19535208 p 1=1952673792 p 2=1 p 3=0 BINDS #1: bind 0: dty=1 mxl=32(03) mal=00 scl=00 pre=00 oacflg=00 oacfl 2=1 size=32 offset=0 bfp=110319 ed 0 bln=32 avl=00 flg=05 WAIT #1: nam='db file sequential read' ela= 27 p 1=45 p 2=119835 p 3=1 WAIT #1: nam='db file sequential read' ela= 10 p 1=45 p 2=119838 p 3=1 WAIT #1: nam='db file scattered read' ela= 74 p 1=45 p 2=119847 p 3=2 WAIT #1: nam='db file sequential read' ela= 9 p 1=45 p 2=119852 p 3=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 mute. X – 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
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: < 10 ms
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: < 10 ms
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: < 20 ms
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 : <4 ms
Log File Parallel Write • Čekání na zápis LGWR do log files • Systémová I/O operace • Rozumná hodnota : <4 ms
Log file switch … • • Nastane, když databáze přepíná log files Zamrznutí celé databáze Rozumná hodnota: 0 ms 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 • User 1, 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 10 g – 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ž 50 k. B ; )
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
- Slides: 44