Oracle 10g Tuning und Tracing

Transkript

1 Donnerstag, 10. November h00, Mozartsaal 18. Deutsche ORACLE-Anwenderkonferenz DB-Entwicklung Oracle 10g Tuning und Tracing Uwe Herrmann Herrmann & Lenz Services GmbH, Burscheid Schlüsselworte: Tuning, Tracing, V$SQLAREA, V$SQLTEXT, STATSPACK, Extended Tracing, cursor_sharing, Histogramme, Peeking, Binde-Variablen, Dynamic Sampling Einleitung In diesem Vortrag soll die generelle Vorgehensweise beschrieben werden, die bei Performance-Problemen mit Oracle-Datenbanken angewendet werden kann. Hierbei wird nicht unbedingt auf eine Oracle Version fokussiert, wobei aber neue Möglichkeiten vorgestellt werden und die Unterschiede zwischen 9i und 10g herausgestellt werden. Nach wie vor gilt bei schlechter Performanz eines Oracle-Systems, dass zuerst die Applikation einer Untersuchung unterzogen werden sollte, da nur an dieser Stelle oft notwendige Faktoren an Verbesserungen erreicht werden können. Dazu gehört unter Umständen auch eine Betrachtung des Datenmodells, wenn durch Statement-Tuning direkt keine Lösungen zu finden sind. Erst bei minimierter Nutzung der Ressourcen sollte ein Instanz-Tuning in Angriff genommen werden, wobei natürlich auch im Vorfeld eine sinnvolle Parametrierung der Instanz überprüft werden sollte. Auffinden von Engpässen und problematischen SQL-Befehlen Es existieren diverse Werkzeuge, die beim Tuning unterstützen und eine graphische Visualisierung der Probleme bieten. Hier sollen aber die Basis-Möglichkeiten über die V$-Views und Tracing-Features beschrieben werden. STATSPACK ist ein hilfreiches Instrument, um sich einen ersten Überblick über ein nicht performantes System zu verschaffen. In einem Statspack-Report werden sowohl Trefferraten der einzelnen SGA-Bereiche angezeigt, weiterhin System Events, die Wartezustände der Instanz darstellen, diverse Statistiken zu File-IO, Rollback-Segmenten usw., aber auch Ressorcen-intensive SQL-Befehle, gegliedert nach Buffer Gets, Physical Reads und Executions. Gerade in dieser Gliederung verbirgt sich aber die Schwierigkeit der Interpretation dieser Werte. Hier ein Beispiel: SQL ordered by Gets DB/Inst: ORA10/ora10 Snaps: > Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code. -> End Buffer Gets Threshold: Total Buffer Gets: 5,764,648 -> Captured SQL accounts for 84.9% of Total Buffer Gets -> SQL reported below exceeded 1.0% of Total Buffer Gets CPU Elapsd Old Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value , , Module: JDBC Thin Client Select KD_NAME From KUNDEN Where KDNR = :1 Abb. 1: Auszug aus Statspack-Report Dieser SQL-Befehl rangiert im Statspack-Report an erster Stelle in Bezug auf die Anzahl gelesener Datenbank-Blöcke. Jedoch ist dieses kein Statement, dass für ein Tuning interessant ist, da die Anzahl gelesener Blöcke pro Ausführung mit 4 nicht verbessert werden kann. Vielmehr muss die Kombination aus Gets/Executions und Gets absolut betrachtet werden, um kritische Befehle zu finden, die optimiert werden sollten. Weiterhin verschwinden hier schnell Befehle aus der Betrachtung, die Literale in WHERE-

2 Klauseln verwenden, daher nur einmalig ausgeführt werden und so aus der Betrachtung der absoluten Zahlen verschwinden. Gleiches gilt für IO-intensive Befehle und Befehle mit hoher Ausführungs-Häufigkeit, eventuell gekoppelt mit CPU-Zeit Verbrauch und Verweilzeit. Diese Informationen sind leicht aus den Views V$SQLAREA oder V$SQL abzulesen und auszuwerten. SQL> select address, executions, disk_reads, buffer_gets, buffer_gets/executions bgpe, 2 rows_processed, cpu_time, elapsed_time 3 from v$sqlarea 4 where executions > 0 5 and buffer_gets/executions > order by buffer_gets/executions; ADDRESS EXECUTIONS DISK_READS BUFFER_GETS BGPE ROWS_PROCESSED CPU_TIME ELAPSED_TIME A501E A6A SQL> select address,piece,sql_text 2 from v$sqltext 3 where address = '68A6A064' 4 order by piece; ADDRESS PIECE SQL_TEXT A6A064 0 select count(*) from kunden_big Abb. 2: Abfrage auf V$SQLAREA und V$SQLTEXT Diese Auswertungen können so einfach bezogen auf IO, Ausführungsanzahl, gelesene Blöcke pro Ausführung, CPU- und Verweilzeit mit passenden Sortierungen ausgeführt werden, um Tuning-würdige SQL- Befehle zu ermitteln. CPU- und Elapsed-Time sind jeweils in Mikrosekunden dargestellt. Mit Oracle 10g können aus der View V$SQLAREA sogar folgende Informationen direkt abgegriffen werden: APPLICATION_WAIT_TIME, CONCURRENCY_WAIT_TIME, USER_IO_WAIT_TIME PLSQL_EXEC_TIME Extended Tracing In Statspack-Reports werden, wie bereits erwähnt, Wait Events protokolliert, die im entsprechenden Intervall aufgetaucht sind. Die Kumulation der Wait Events für die Instanz ist aus der View V$SYSTEM_EVENT zu ermitteln. Hier ein Auszug aus einem Statspack-Report: Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Call Time CPU time db file sequential read 15, class slave wait db file scattered read 2, db file parallel write 9, Abb. 3: Auszug aus Statspack-Report mit Top5 Timed Events In diesem Auszug ist zu sehen, dass ein Grossteil der Waits auf db file scattered read, db file sequential read und db file parallel write entfällt, was de facto Plattenzugriffe sind. Diese sind aber in dieser Kumulation nicht einzelnen SQL-Befehlen zuzuordnen. Bei der zuvor gezeigten Auswertung der V$SQLAREA ist bei den gefundenen SQL-Befehlen eine Diskrepanz zwischen CPU time und Elapsed Time festzustellen. Für ein Tuning ist nun die Zuordnung der Waits zu einzelnen SQL-Befehlen von Interesse. Bisher waren solche Betrachtungen nicht einfach möglich, nur Werkzeuge waren zu dieser Darstellung in der Lage. Mit dem seit Oracle 9i mitgelieferten Package DBMS_SUPPORT, das mit der Prozedur START_TRACE_IN_SES- SION(sid, serial#, WAITS, BINDS) kann ein erweitertes Tracing für eine Session aktiviert werden, was zu

3 18. Deutsche ORACLE-Anwenderkonferenz einem Statement auftretende Wartezustände protokolliert. STOP_TRACE_IN_SESSION(sid,serial#) schaltet das Tracing wieder aus. Damit wird die Prozedur DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION ersetzt. DBMS_SUPPORT ist nicht dokumentiert. Das Package wird mit dem Skript DBMS_SUPP.SQL erstellt, das im Verzeichnis ORACLE_HOME/rdbms/admin zu finden ist. Das Package soll nur auf Anforderung von Oracle Support verwendet werden. Verständlich ist dieser Hinweis nicht, da dieselben Ergebnisse über ALTER SESSION Kommandos dokumentiert sind, was aber besonders bei Applikationen in der Praxis kaum einsetzbar ist. Hier ist nur die Möglichkeit gegeben, diese Funktionalitäten von einem Administrator von außen zu aktivieren. Beispiel: DB-Entwicklung SQL> execute dbms_support.start_trace_in_session(8,27,true,true); PL/SQL-Prozedur wurde erfolgreich abgeschlossen. SQL> execute dbms_support.stop_trace_in_session(8,27); PL/SQL-Prozedur wurde erfolgreich abgeschlossen. Abb. 4: Beispiel zur Aktivierung des Extended Tracings Die erzeugte Trace-Datei kann wie bekannt mit TKPROF formatiert werden und zeigt folgendes Ergebnis: select count(a.kdnr), count(k.nachname) from demo.adressen a, demo.kunden_big k where a.kdnr=k.kdnr and k.kdnr=7 call count cpu elapsed disk query current rows Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 34 (DEMO) Rows Execution Plan SELECT STATEMENT GOAL: CHOOSE 0 SORT (AGGREGATE) 0 MERGE JOIN (CARTESIAN) 0 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADRESSEN' 0 BUFFER (SORT) 0 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'KUNDEN_BIG' Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited Waited SQL*Net message to client db file sequential read db file scattered read SQL*Net message from client Abb. 5: Auszug aus TKPROF-Datei Zu sehen sind also die zu dem SQL-Befehl aufgetretenen Waits mit entsprechenden Zeiten zu sehen, was durch den Parameter WAITS => TRUE eingeschaltet wurde. Auf den zweiten Parameter BINDS wird später eingegangen.

4 Die Informationen, die über die Waits geliefert werden, sind sehr hilfreich, um den entsprechenden SQL- Befehl zu optimieren. Häufig werden hier in Verbindung mit Disk-IO Wartezustände für die Reads zu sehen sein, jedoch können auch Waits auf Netzwerkommunikation (SQL*Net Message...) oder Latching- Probleme entdeckt werden. Damit lassen sich dann Differenzen zwischen CPU-Zeit-Verbrauch und Lieferzeiten analysieren. Cursor_sharing, Histogramme und Peeking Hier sei als Exkurs auf den Initialisierungsparameter CURSOR_SHARING in Zusammenhang mit Histogrammen und dem mit Oracle 9i eingeführten Peeking für Bindevariablen eingegangen werden. Um Parsing von SQL-Befehlen zu vermeiden und SQL-Befehle in der SQL-Area wiederbenutzbar zu machen, auch wenn in SQL-Befehlen Literale verwendet werden, ist der Parameter CURSOR_SHARING (Standardeinstellung EXACT) eingeführt worden. Dieser bewirkt, dass bei einer Einstellung auf FORCE oder SIMILAR automatisch Literale durch Bindevariablen ersetzt werden. Bei Statistiken auf Tabellen-Spalten und indizierte Felder können Histogramme erstellt werden, die für den Cost Based Optimizer Informationen über die Schlüsselverteilungen bereitstellen. Histogramme werden gerade dann sinnvoll, wenn bei wechselnden WHERE-Bedingungen unterschiedliche Selektivitäten erreicht werden, was aber nur bei der Verwendung von Literalen genutzt werden kann. Andererseits ist die Verwendung von Literalen nicht wünschenswert, da damit die Statement nicht identisch sind, daher nicht aus der Shared SQL Area wiederverwendet werden können und neben erhöhten Parsing-Aufwand auch zu Latching-Problemen im Library Cache führen können. Seit Oracle 9i wird bei einem erstmaligen Parsing eines SQL-Befehls der Inhalt der Bindevariablen benutzt, um den Ausführungsplan zu ermitteln. Weitere Ausführungen des SQL-Befehls benutzen dann, dem Cursor-Sharing folgend, den ermittelten Ausführungsplan, ohne das ein erneutes Peeking durchgeführt wird. Sind Histogramme vorhanden, kann dieses Feature zu nicht optimalen Ausführungsplänen führen, wenn der Variableinhalt beim ersten Aufruf abweichend zu der sonstigen Verwendung ist. Inhalte von Binde-Variablen Beim SQL-Tuning muss häufig die Selektivität der einschränkenden Bedingungen beurteilt werden, um die Güte eines Ausführungsplans beurteilen zu können. Insbesondere bei Bereichs-Suchen (range scans) müssen natürlich die Grenzen der Bereiche bekannt sein. Beispiel: select aufnr from auftraege where aufdatum between :v1 and :v2; Hier können die Aufträge eines Tages oder eines Jahres gesucht werden, was natürlich die Selektivität der Einschränkung gravierend beeinflusst. So könnte eine Zugriff über einen Index oder aber auch ein Full Table Scan sinnvoll sein. So ist man auf die Information durch den Anwender angewiesen, um zu erfahren, welche Einschränkung angegeben worden ist. Ebenso kann ein nicht erwarteter Ausführungsplan gewählt werden, wenn die Bindevariablen einen falschen Datentyp haben, deshalb eine implizite Konvertierung durchgeführt wird und dadurch ein vorhandener Index nicht genutzt werden kann. In beiden Fällen ist die Information über Datentypen und Inhalte der Bindevariablen notwendig. Mit Oracle 9i stehen die Views V$SQL_BIND_DATA und V$SQL_BIND_METADATA zur Verfügung, um diese Informationen zu bekommen. Allerdings ist hier das Handling kompliziert, da die Information nur für die aufrufende Session abgreifbar sind. Insbesondere bei Applikationen tauchen hier Schwierigkeiten auf, die nur über Trigger gelöst werden können. Mit Oracle 10g ist hier schon eine sinnvolle Erweiterung der View V$SQL_BIND_METADATA durchgeführt worden, die eine Referenzierung über die Adresse des SQL-Befehls erlauben. Hilfreich ist die neue View in Oracle 10g, V$SQL_BIND_CAPTURE. Die View enthält folgende Informationen (nicht vollständig): ADDRESS Adresse des Parent Cursors HASH_VALUE Hash Values des Parent Cursors SQL_ID Id des Parent Cursors NAME Name der Bindevariable DATATYPE Datentyp der Bindevariable WAS_CAPTURED Yes No LAST_CAPTURTED Datum des letzten Auszugs VALUE_STRING Inhalt der Bindevariable

5 18. Deutsche ORACLE-Anwenderkonferenz Da das Protokollieren dieser Inhalte Performanz kostet, werden nur in einem Intervall von 15 Minuten die Inhalte der Variablen für einen Cursor gespeichert, daher auch das Feld LAST_CAPTURED. Über die Adresse und den Hash_Value kann ein Join mit V$SQLAREA und V$SQL durchgeführt werden. Die Protokollierung wird ausgeschaltet, wenn der Initialisierungsparameter STATISTICS_LEVEL auf BASIC gesetzt wird. Aber auch hier kann Extended Tracing verwendet werden, um auch mit Oracle 9i elegant an die benötigten Informationen zu kommen. Dafür wird der Parameter BINDS => TRUE verwendet, um das Protokollieren der Bindevariablen zu aktivieren. Leider ist diese Information nicht in der durch TKPROF formatierten Auswertung zu sehen, sondern muss direkt aus der Trace-Datei gelesen werden. Folgende Information ist zu sehen: DB-Entwicklung PARSING IN CURSOR #1 len=67 dep=0 uid=34 oct=3 lid=34 tim= hv= ad='689df660' select kdnr from kunden_big where rownum < :"SYS_B_0" order by kdnr END OF STMT PARSE #1:c=0,e=36780,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim= BINDS #1: bind 0: dty=2 mxl=22(02) mal=00 scl=00 pre=00 oacflg=10 oacfl2=100 size=24 offset=0 bfp=044cc550 bln=22 avl=02 flg=09 value=1000 Abb. 6: Auszug aus Trace-Datei mit Informationen über Bindevariablen Hier ist die Information über den Datentyp in dty=2 (number, siehe Datentypen in SQL-Reference) zusehen, der Inhalt ist value=1000. hv verweist auf den HASH_VALUE, ad auf die Adresse. Optimizer Dynamic Sampling Bei einem durchgängigen Einsatz des Cost Based Optimizers ist davon auszugehen, dass sämtliche Tabellen und Indizes mit Statistiken versorgt sind, resultierend aus einem DBMS_STATS Aufruf oder über ANA- LYZE. Es gibt jedoch Anwendungsfälle, in denen Tabellen aus Applikationen heraus generiert werden und dann keine Statistiken besitzen. Bisher wurden für solche Tabellen Standardannahmen getroffen, die in den meisten Fällen nicht die Realität widerspiegeln. Um in solchen Fällen trotzdem optimale Ausführungspläne ermitteln zu können, wurde das Feature DYNAMIC SAMPLING eingeführt. Es sollen also zur Ausführungszeit dynamisch Statistiken für nichtanalysierte Tabellen ermittelt werden. Das Feature wird aktiviert entweder durch den Initialisierungsparameter OPTIMIZER_DYNAMIC_ SAMPLING oder auf Statement Level durch den Hint DYNAMIC_SAMPLING. Wertebereich: 0-10 Standardeinstellungen: Oracle 9iR2 1 Oracle 10g 2 Die Bedeutung der Werte ist im Handbuch Oracle Performance und Tuning Guide beschrieben, dort unter Managing Optimizer Statistics, Managing Statistics, Estimating Statistics with Dynamic Sampling. Zwischen Oracle 9iR2 und Oracle 10g existieren gravierende Unterschiede in den Voraussetzungen, wann Dynamic Sampling angewendet wird. Weitere Details sollen hier nicht besprochen werden, da diese dokumentiert sind. Vielmehr sollen hier Betrachtungen über die Kosten des Dynamic Sampling angestellt werden. Als gravierend sei hier erwähnt, dass bei einem Join auf zwei nicht-analysierte Tabellen bei der unter Oracle 9i noch möglichen Einstellung OPTIMIZER_MODE=CHOOSE kein Dynamic Sampling genutzt wird, sondern der Rule Based Optimizer genutzt wird. Für das Sampling werden mindestens 32 Blöcke einer entsprechenden Tabelle benutzt, bis hinauf zu dem 256-fachen der Standardeinstellung, also bis zu 8192 Blöcke. Dieses kann zu einer signifikanten zusätzlichen Belastung des Systems führen, vor allem, wenn die CPU-Belastung oder die IO-Belastung bereits im Grenzbereich liegt. Ob Dynamic Sampling benutzt wird und welche Kosten es verursacht, kann über Aktivierung eines Events über Tracing protokolliert werden.

6 SQL> alter session set events '10053 trace name context forever, level 10'; Folgende Information wird nach Formatierung mit TKPROF geliefert: SELECT /*+ ALL_ROWS IGNORE_WHERE_CLAUSE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NOPARALLEL("K") */ 1 AS C1, CASE WHEN "K"."KDNR"=7 THEN 1 ELSE 0 END AS C2 FROM "DEMO"."KUNDEN_BIG" SAMPLE BLOCK ( ) "K") SAMPLESUB call count cpu elapsed disk query current rows Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: ALL_ROWS Parsing user id: 5 (recursive depth: 1) Rows Row Source Operation SORT AGGREGATE (cr=31 r=41 w=0 time=83628 us) 5821 TABLE ACCESS SAMPLE KUNDEN_BIG (cr=31 r=41 w=0 time=73005 us) Abb. 7: Auszug aus TKPROF-Datei mit Tracing des Dynamic Sampling Dieses ist das interne Statement, das zur Ermittlung der Statistik ausgeführt wird. Hier ist die Default Sample Size von 32 Blöcken zu sehen. Hier ist ersichtlich, dass insbesondere bei einem belasteten System zusätzlicher Overhead auftritt, der bei Wartezuständen, z.b. im IO-Bereicht, zu weiteren Wartezuständen führen kann. In diesem Vortrag sollten Fälle aus der Praxis dargestellt werden, die mit den neuen Möglichkeiten, insbesondere im Bereich Tracing, sinnvoll optimiert werden konnten. Natürlich bietet insbesondere Oracle 10g neue Möglichkeiten im Bereich Performance Monitoring und Automatic SQL Tuning, die aber umfangreiche Vorarbeiten notwendig machen, um eine Tuning-Umgebung aufzubauen. Hier wird oft der Einsatz des Oracle Enterprise Managers verknüpft. Hier sollten relativ einfache und schnell anzuwendende Verfahren aufgezeigt werden, die auch als Grundlagen aus älteren Oracle-Versionen bekannt sind. Die Folien des Vortrages werden über die DOAG und unsere Internet-Seiten zur Verfügung gestellt. Kontaktadresse: Uwe Herrmann Herrmann & Lenz Services GmbH Höhestr. 37 D Burscheid Telefon: +49(0) Fax: +49(0) uwe.herrmann@hl-services.de Internet: