Optimalizace serveru O výkonnostních problémech se lze dovědět dvěma způsoby na základě stížnosti uživatelů, či na základě nastavených poplachů v databázi (například při vysokém zatížení CPU, nebo příliš mnoho otevřených kurzorů apod.) Zjišťovat podrobnosti ohledně problému (v případě, že není způsoben mimo db), lze pomocí automatických nástrojů co jsou u Oracle k dispozici (ADDM apod.) Nebo ručně za pomoci dynamických pohledů V$
Optimalizace serveru Identifikace úzkého hrdla (typicky na základě pozorování zpomalení klientské aplikace) Využití CPU V$SYSSTAT(všechny sessiony dohromady), V$SESSTAT(podle jednotlivých session) V případě, že běží Oracle Database Resource Manager pohled V$RSRC_CONSUMER_GROUP (dle consumer group) (Je dobré zároveň ověřit, že procesorový čas nespotřebovává jiný proces.)
Optimalizace serveru Možná řešení problému: Přesunutí některých úloh, popřípadě spouštění některých procesů mimo špičku. Použít SQL_TRACE TKPROF (viz pozdější slidy) a odladit příslušný PL/SQL program
Optimalizace serveru I/O V$SYSTEM_EVENT (zkontrolovat jak často a jak dlouho se čeká na I/O) V$IOSTAT_CONSUMER_GROUP (I/O statistiky dle consumer group) V$IOSTAT_FILE (I/O statistiky dle souboru) V$IOSTAT_FUNCTION(statistiky dle jednotlivých funkcí databáze jako LGWR, DBWR...)
Optimalizace serveru V$SEGSTAT V$SEGMENT_STATISTICS (důležité pohledy co se týče výkonu.. Dá se z nich například spočítat jak často byly data nalezeny v cache a nemuselo se fyzicky číst). Tyto pohledy jsou hlavně dobré pro zjištění kterých tabulek se týkají výkonnostní nedostatky. Řešení: dle typu problému. V některých případech může pomoci zvýšení počtu blok bufferů v SGA, v případě
Optimalizace serveru Síť: V$IOSTAT_NETWORK Obsahuje počet čtení, dobu čekání na čtení a zápis Počet kb dat zapsaných/přečtených. Řesení: Přesunutí úloh mimo spičku, popřípadě přepsání klientských aplikací, aby posílali více žádostí naráz místo opětovného připojování.
Wait events Pohledy V$SESSION informace o tom na co naposledy každá session čekala. V$SESSION_EVENT všechny čekání od začátku session
Některé typy wait events Buffer busy waits záleží na typu bufferu (Čekání na načtení do bufferu popřípadě blok je zamčený) free buffer waits Pomalé DBWR/případně malá cache db file scattered/sequential read, Potřeba prověřit V$SQLAREA a najít dotazy co toto způsobují popřípadě je pomalé I/O
Typy wait events library cache latch waits Parsování sql (V$SQLAREA) log buffer space Redo logy V$SYSSTAT Pomalé I/O log file sync Pomalé disky s logy, případně příliš časté použivání commit
Pamět Velký vliv na výkon má nastavení paměti. Je silně doporučeno používat automatickou správu paměti. Ta lze konfigurovat pomocí inicializačních parametrů MEMORY_TARGET a MEMORY_MAX_TARGET Oracle posléze automaticky rozděluje pamět mezi SGA a PGA Nastavením MEMORY_TARGET na 0 se automatická správa paměti vypíná Je potřeba aby se tyto obě oblasti vešli do paměti a nebyly částečně swapovány na disk. Pakliže je doopravdy potřeba nastavit ručně je na to dobré použít nástroj Memory Advisor
Pamět DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, and STREAMS_POOL_SIZE (velikosti cache) Velikost logbufferu, velikost ostatních cache jako je keep a recycle je bez zásahu automatické správy paměti a je třeba jí konfigurovat ručně. Keep pool se používá, když tabulka(index) je malá a často se k ní přistupuje. Aby nezestárla a nebyla odstraněna Recycle pool, když se přistupuje k ní přistupuje málokdy.
Automatické nástroje na ladění výkonu Automatic Workload Repository Automatic Database Diagnostic Monitor SQL Tuning Advisor SQL Access Advisor End to End Application Tracing
Automatic Workload Repository Vytváří snapshoty z většiny statistik ve výše zmíněných dynamických pohledech jednou za určitý časový úsek Časový úsek i délka historie je nastavitelná
Automatic Database Diagnostic Monitor Analyzuje data získaná pomocí AWR a automaticky zjištuje problémy a ve většině případů poskytuje i rady pro případné řešení. ADDM upozorňuje hlavně na tyto problémy: Na takzvaná uzká hrdla (například pokud jsou disky zatížené na maximum a procesory vícemeně drtivou většinu času čekají na I/O). Na aplikace, které se zbytečně odpojují a připojují. Výkonnostní problémy v souvislosti se zamykáním
SQL Tuning Advisor SQL tuning advisor zkoumá SQL dotazy, které mají velký dopad na výkon celé databáze během času na údržbu a zkouší jestli by se nějakým způsobem nedalo urychlit jejich provádění. V závislosti na nastavení ACCEPT_SQL_PROFILES tyto zlepšení buď rovnou aplikuje nebo pouze doporučí.
Příklad výstupu SQL Tuning Advisor RECOMMENDATIONS -------------------------------------------------------------------------------- GENERAL INFORMATION SECTION ------------------------------------------------------------------------------- Tuning Task Name : emp_dept_tuning_task Scope : COMPREHENSIVE Time Limit(seconds): 60 Completion Status : COMPLETED Started at : 05/06/2004 09:29:13 Completed at : 05/06/2004 09:29:15 ------------------------------------------------------------------------------- SQL ID : 0wrmfv2yvswx1 SQL Text: SELECT e.*, d.* FROM emp e JOIN dept d ON e.deptno = d.deptno WHERE NVL(empno, '0') = :empno ------------------------------------------------------------------------------- FINDINGS SECTION (2 findings) -------------------------------------------------------------------------------
Příklad výstupu SQL Tuning Advisor 1- Statistics Finding --------------------- Table "SCOTT"."EMP" and its indices were not analyzed. Recommendation -------------- Consider collecting optimizer statistics for this table and its indices. execute dbms_stats.gather_table_stats(ownname => 'SCOTT', tabname => 'EMP', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE) Rationale --------- The optimizer requires up-to-date statistics for the table and its indices in order to select a good execution plan. 2- Restructure SQL finding (see plan 1 in explain plans section) ---------------------------------------------------------------- The predicate NVL("E"."EMPNO",0)=:B1 used at line ID 2 of the execution plan contains an expression on indexed column "EMPNO". This expression prevents the optimizer from selecting indices on table "SCOTT"."EMP". Recommendation --------------
Příklad výstupu SQL Tuning Advisor Rewrite the predicate into an equivalent form to take advantage of indices. Alternatively, create a function-based index on the expression. Rationale --------- The optimizer is unable to use an index if the predicate is an inequality condition or if there is an expression or an implicit data type conversion on the indexed column. ------------------------------------------------------------------------------- EXPLAIN PLANS SECTION -------------------------------------------------------------------------------
Příklad výstupu SQL Tuning Advisor 1- Original ----------- Plan hash value: 1863486531 ---------------------------------------------------------------------------------------- Id Operation Name Rows Bytes Cost (%CPU) Time ---------------------------------------------------------------------------------------- 0 SELECT STATEMENT 1 107 4 (0) 00:00:01 1 NESTED LOOPS 1 107 4 (0) 00:00:01 2 TABLE ACCESS FULL EMP 1 87 3 (0) 00:00:01 3 TABLE ACCESS BY INDEX ROWID DEPT 1 20 1 (0) 00:00:01 4 INDEX UNIQUE SCAN PK_DEPT 1 0 (0) 00:00:01 ---------------------------------------------------------------------------------------- Note ----- - dynamic sampling used for this statement ------------------------------------------------------------------------------- 1 row selected.
SQL Access Advisor Doporučuje zřízení/zrušení indexů, vytvoření materializovaných pohledů apod... Jako vstup je potřeba definovat jaké dotazy se budou vykonávat a na základě toho a statistik se generuje výsledné doporučení.
End to End Application Tracing Usnadňuje diagnostikování problémů ve vícevrstvém(multitier) prostředí kdy koncový klient je připojen přes prostředníka a typicky i pomocí více session. Můžeme sledovat požadavky: Dle identifikátoru klienta Dle služby Dle modulu Dle akce (jako INSERT UPDATE)
End to End application Tracing Session Instance Po uložení tracovaných informací mohou být konsolidovány pomocí utility trcsess a analyzován pomocí TKPROF Trcsess je potřeba použít tam kde jsou sessiony vyřizovány pomocí víceroprocesů (shared server installation) TKPROF se použije hlavně na to aby tracefiles byly převedeny do čitelnějšího formátu.
End to End Application Tracing - příklad $ tkprof orcl102_ora_3064.trc output.prf EXPLAIN=scott/tiger SYS=NO Tkprof: Release 9.2.0.1.0 - Production on Tue Dec 24 15:32:43 2002 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Trace file: ORCL102_ora_3064.trc Sort options: default ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ********************************************************************************
End to End Application Tracing Příklad select * from employee where emp_id = 3737 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 10 0.00 0.03 0 0 0 0 Execute 10 0.00 0.00 0 0 0 0 Fetch 20 0.34 0.35 72 4730 0 10 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 40 0.34 0.39 72 4730 0 10 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 59 Rows Row Source Operation ------- --------------------------------------------------- 1 TABLE ACCESS FULL EMPLOYEE
Získávání výkonnostních statistik K efektivnímu zjištování výkonnostních problémů je třeba statistik. Oracle jich generuje spoustu typů ať už pro celý system, sessiony či SQL dotazy. Rovněž lze získat statistiky týkající se služeb a segmentů. Kumulativní hodnoty jsou typicky dostupné přes dynamické pohledy V$SESSTAT a V$SYSSTAT (nutno podotknout že tyto statistiky jsou resetovány s vypnutím systému). Názvy všech statistik jsou dostupné přes pohled V$STATNAME
Získávání výkonnostních statistik Dalšími typy stastik jsou metrické (měřící jak rychle se mění kumulativní statistiky), které jsou rovněž dostupné přes již zmíněné pohledy. Další jsou vzorkové odebrané pomocí ASH (Active session history) dostupné přes pohled V$ACTIVE_SESSION_HISTORY
Stabilní plánování Očekáváme data s podobným rozložením a nechceme, aby se díky změně provádění dotazu neočekávaně nezměnili požadavky na zdroje. Užitečné ve chvilích, zejména ve chvilích, kdy za každou cenu omezit riziko.
Stabilní plánování Plány pro pro provádění dotazů, jsou uchovávány v tzv. outlines. Outline je implementována jako sada hintů k SQL dotazu pro optimizátor. Změníme-li jakýmkoliv způsobem SQL dotaz i přidání hintu pro optimizátor nebo změna textové konstanty (potřeba používat proměnné), výsledkem je nový outline.
Stabilní plánování Pro to aby outlines fungovali je potřeba mít konzistetně nastavené následující parametry: QUERY_REWRITE_ENABLED STAR_TRANSFORMATION_ENABLED OPTIMIZER_FEATURES_ENABLE Outlines lze pro dotazy vytvářet automaticky pro všechny či použitím příkazu CREATE OUTLINE pro specifický dotaz
Stabilní plánování Automatické vytváření outlines plošné ALTER SYSTEM SET create_stored_outlines=true; ALTER SESSION SET create_stored_outlines=true; Pro session
Stabilní plánování Manuální vytváření outlines Napřed potřeba přidělit potřebná práva CONN sys/password AS SYSDBA GRANT CREATE ANY OUTLINE TO nekdo; GRANT EXECUTE_CATALOG_ROLE TO nekdo;
Stabilní plánování příklad CONN nekdo -- Vytvoření outline pro daný dotaz CREATE OUTLINE emp_dept FOR CATEGORY kategorie ON SELECT e.empno, e.ename, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno; -- Kouknout na vytvořenou outline COLUMN name FORMAT A30 SELECT name, category, sql_text FROM user_outlines WHERE category = 'kategorie'; NAME CATEGORY ------------------------------ ------------------------------ SQL_TEXT -------------------------------------------------------------------------------- EMP_DEPT kategorie SELECT e.empno, e.ename, d.dname FROM emp e, dept d WHERE e.deptno = d.deptno 1 row selected.
Stabilní plánování příklad -- Vypsat hinty přiřazené k outline COLUMN hint FORMAT A50 SELECT node, stage, join_pos, hint FROM user_outline_hints WHERE name = 'EMP_DEPT'; NODE STAGE JOIN_POS HINT ---------- ---------- ---------- -------------------------------------------------- 1 1 0 NO_EXPAND(@"SEL$1" ) 1 1 0 PQ_DISTRIBUTE(@"SEL$1" "E"@"SEL$1" NONE NONE) 1 1 0 USE_MERGE(@"SEL$1" "E"@"SEL$1") 1 1 0 LEADING(@"SEL$1" "D"@"SEL$1" "E"@"SEL$1") 1 1 0 NO_STAR_TRANSFORMATION(@"SEL$1" ) 1 1 0 NO_FACT(@"SEL$1" "E"@"SEL$1") 1 1 0 NO_FACT(@"SEL$1" "D"@"SEL$1") 1 1 2 FULL(@"SEL$1" "E"@"SEL$1") 1 1 1 INDEX(@"SEL$1" "D"@"SEL$1" ("DEPT"."DEPTNO")) 1 1 0 NO_REWRITE(@"SEL$1" ) 1 1 0 NO_REWRITE(@"SEL$1" ) 11 rows selected.
Stabilní plánování příklad ALTER SESSION SET query_rewrite_enabled=true; ALTER SESSION SET use_stored_outlines=kategorie; Tímto se nastaví používání outlines v dané kategorii
Zdroje http://docs.oracle.com/cd/b28359_01/server.111/b28 http://docs.oracle.com/cd/b28359_01/server.111/b28 http://docs.oracle.com/cd/b14117_01/server.101/b10 http://www.oracle-base.com/articles/misc/outlines.ph http://psoug.org/reference/outlines.html http://www.databasejournal.com/features/oracle /article.php/3492521/automatic-sql-tuningusing-sql-tuning-advisor.htm