Backup und Restore von Optimizer Statistiken. Peter Stalder

Transkript

1 Betrifft: Backup und Restore von Optimizer Statistiken Art der Info: Technical Info (Oktober 2002) Autor: Quelle: Peter Stalder Erfahrung aus der Praxis Einleitung Kennen auch Sie den Fall? Ihr System läuft seit Wochen und Monaten in stabilen Zustand. Die Transaktionen tagsüber werden vom RDMS performant abgewickelt und die tägliche Batchverarbeitung in der Nacht wird meist auch rechtzeitig fertig. Damit es auch so bleibt, sammeln Sie regelmässig innerhalb definierter Wartungsfenster ihre neuen Optimizer- Statistiken, zumal eine Optimierung erwünscht ist, auch wenn sich die Datenverteilung entsprechend ändern sollte. Doch eines Morgens finden Sie Ihre Firma in heller Aufregung. Bestellungen wurden nicht ausgeliefert, Zahlungen nicht ausgeführt oder was immer die Applikation hätte fertigstellen müssen. Der Batch-Lauf steht noch immer am Anfang der Verarbeitung, wobei er doch schon längst fertig sein sollte. Was war geschehen? Änderung des Execution-Plans Der (Cost Based) Optimizer stützt sich ab auf die ihm bekannten Statistiken über Tabellen, Indexe und Histogramme. Weitere Einflüsse auf den Execution-Plan haben noch etwa 20 dokumentierte und etwa zwei Dutzend undokumentierte Initialisierungs-Parameter, bei älteren Versionen auch die Formulierung des Statements (Subqueries vs. Joins). In unserem Beispiel änderte sich der Execution-Plan, nachdem einige Tabellen und Indexe durch das Feature Monitoring mit frischen Statistikzahlen versorgt wurden. Die Abfrage lief im Normalfall innert 10 Minuten durch, doch nun scheint sie nach Stunden noch immer am Anfang zu stehen. Select Statement SELECT SA.PartnerId, SA.AccNo, Count ( SE.EntryNo ) ValidCounter FROM OUTDOOR_ARTICLE SA, CUSTOMER CSA, INDOOR_ARTICLE SE WHERE SA.AccNo = CSA.AccNo And SA.AccNo = SE.AccNo And SA.IsAllowed = :p1

2 And SA.Status NOT IN ( :p2, :p3 ) And SA.Amount > 0 And ( CSA.Mode = :p4 or CSA.mode is null ) And CSA.NEXTTDATE <= to_date(:p5,'yyyymmdd') And SE.Type IN (:p6,:p7,:p8,:p9,:p10,:p11,:p12,:p13,:p14,:p15,:p16,:p17) and SE.Status = :p18 And SE.Status IN (:p19, :p20, :p21) And SE.DDT <= to_date(:p22,'yyyymmdd') And SE.MId = :p23 And SA.AccNo NOT IN ( SELECT AccNo from TOP_REGION where Status = :p24 ) AND decode ( INDICATOR, :p25, - 1 * AMOUNT, AMOUNT ) <> S_AMOUNT GROUP BY SA.Id, SA.AccNo ORDER BY SA.Id, SA.AccNo; Alter Execution Plan mit schneller Laufzeit TABLE_NAME LAST_ANAL NUM_ROWS PAR SAMPLE_SIZE CUSTOMER 31-MAR NO TOP_REGION 03-DEC-01 4 NO 4 OUTDOOR_ARTICLE 31-MAR NO INDOOR_ARTICLE 25-MAR NO SELECT STATEMENT Optimizer=CHOOSE (Cost=80543 Card=1 Bytes=61) SORT *1* (GROUP BY) (Cost=80543 Card=1 Bytes=61) NESTED LOOPS *2* (Cost=80540 Card=1 Bytes=61) NESTED LOOPS *3* (Cost=80539 Card=1 Bytes=48) HASH JOIN *4* (ANTI) (Cost=250 Card=1 Bytes=18) TABLE ACCESS(FULL) OF 'OUTDOOR_ARTICLE' (Cost=248 Card=19 Bytes=266) VIEW OF 'VW_NSO_1' (Cost=1 Card=22 Bytes=88) TABLE ACCESS(FULL) OF 'TOP_REGION' (Cost=1 Card=22 Bytes=132) TABLE ACCESS *8* (FULL) OF 'INDOOR_ARTICLE' (Cost=80289 Card=7136 Bytes=214080) TABLE ACCESS *9* (BY INDEX ROWID) OF 'CUSTOMER' (Cost=1 Card=7302 Bytes=94926) INDEX *10* (UNIQUE SCAN) OF 'PK_CUSTOMER' (UNIQUE) Neuer Execution Plan mit langer Laufzeit TABLE_NAME LAST_ANAL NUM_ROWS PAR SAMPLE_SIZE CUSTOMER 29-APR NO TOP_REGION 29-APR NO 44 OUTDOOR_ARTICLE 31-MAR NO INDOOR_ARTICLE 29-APR NO SELECT STATEMENT Optimizer=CHOOSE (Cost=76504 Card=945 Bytes=57645) SORT *1* (GROUP BY) (Cost=76504 Card=945 Bytes=57645) HASH JOIN *2* (Cost=76498 Card=945 Bytes=57645) NESTED LOOPS *3* (Cost=343 Card=924 Bytes=28644) HASH JOIN(ANTI) (Cost=250 Card=924 Bytes=16632) TABLE ACCESS(FULL) OF 'OUTDOOR_ARTICLE' (Cost=248 Card=928 Bytes=12992) VIEW OF 'VW_NSO_1' (Cost=1 Card=4 Bytes=16) TABLE ACCESS(FULL) OF 'TOP_REGION' (Cost=1 Card=4 Bytes=24) TABLE ACCESS(BY INDEX ROWID) OF 'CUSTOMER' (Cost=1 Card=7198 Bytes=93574) INDEX(UNIQUE SCAN) OF 'PK_CUSTOMER' (UNIQUE) TABLE ACCESS *10* (FULL) OF 'INDOOR_ARTICLE' (Cost=76154 Card=5824 Bytes=174720) Das Select-Statement in unserem Beispiel beinhaltet mehrere Bind-Variablen, was bereits die Histogramme ausschliesst und den Optimizer mit Annahmen fortfahren lässt. Durch das Wachstum der kleinsten Tabelle (TOP_REGION) wurde im innersten Join noch die

3 gleichen Kosten, aber eine höhere Join-Kardinalität errechnet (924 anstelle 1), anscheinend aber noch immer der beste Einstieg. Letzten Endes werden durch eine Änderung der Join- Reihenfolge tiefere Kosten errechnet. Kardinalität, Selektivität, Join Order Mittels des Events lassen sich die Wege des Optimizers ergründen. Für den technisch Interessierten mag diese Analyse spannend und lehrreich sein, doch die Situation zeigt sich relativ einfach: andere Statistiken können andere Execution-Plans verursachen, diese müssen nicht zwingend besser sein. Nur wenn der Optimizer perfekt wäre, würden die Execution-Plans immer besser. Auch die Schwellwerte, wo sich die Statistiken ändern können, sind nicht so wichtig. Irgendwo gibt es eine Entscheidung, wo vom Table Scan auf Index Scan gewechselt wird, wo ein Hash-Join günstiger wird als ein Nested Loop oder das berechnete Join Result eine Änderung der Reihenfolge nach sich zieht. Das kann morgen (je nach Statistiken, Initialisierung-Parameter, Version) wieder anders sein. Insofern ist nur die Lösung und nicht die Analyse des Problems relevant. Dennoch, wer etwas tiefer in die Thematik einsteigen möchte, dem seien die folgenden Dokumente von zu empfehlen: Doc ID: Cost Based Optimizer (CBO) Overview Doc ID: TECH: Cost Based Optimizer - Common Misconceptions and Issues Doc ID: Predicate Selectivity Doc ID: Use of bind variables in queries

4 Entschärfung der Situation Ein guter DBA kennt seine Datenbanken mit ihren Objekten, aber es wäre zuviel verlangt, wenn er auch noch die Ausführungspläne sämtlicher Abfragen auswendig kennen würde. Es gilt nun, die Problem-Query so schnell wie möglich wieder auf die ursprüngliche Laufzeit zu reduzieren. Bei einer komplexeren Query kann sich die Analyse schnell ein paar Stunden hinziehen Zeit, die in solchen Situationen nicht vorhanden ist. Wäre es nicht schön, wenn man den alten Execution-Plan hätte und sich nun mit Hints behelfen könnte? Oder gar die alten Statistiken, damit der ursprüngliche Execution-Plan generiert werden könnte? Genau hierzu bietet Oracle mit dem Package dbms_stats Unterstützung an. Wir restoren einfach die alten Statistiken und überlassen die Arbeit wieder dem DBMS. In einem ersten Schritt erstellen wir eine Table, in welche wir das Statistik-Material speichern können: DBMS_STATS.CREATE_STAT_TABLE ( ownname => 'StatOwner', tblspace=> 'Tablespace'); Danach erstellen wir ein Script, welcher uns vor einem neuen Analyze-Lauf unsere Backup-Table leert und die aktuellen Statistiken darin speichert. TRUNCATE TABLE StatOwner. StatTable REUSE STORAGE; begin DBMS_STATS.EXPORT_SCHEMA_STATS ( ownname => 'Schema', statown => 'StatOwner'); end; / Das letzte Script schreiben wir auch gleich, obwohl wir hoffen, es nie aufrufen zu müssen. Da meist nur wenige Tables betroffen sind, restoren wir die Statistiken nicht für das ganze Schema, sondern nur für die betroffenen Tables: begin DBMS_STATS.IMPORT_TABLE_STATS ( ownname => 'Schema', tabname => 'ImpTable',

5 end; / statown => 'StatOwner'); Innerhalb weniger Minuten läuft unser Batch wieder an und wird seine Arbeit voraussichtlich zügig beenden. Wir haben nun genügend Zeit gewonnen, die Situation in Ruhe zu analysieren. Eine weitere Möglichkeit bietet Oracle mit Outlines. Hierbei wird der Execution-Plan in Form von Hints gespeichert, was den Vorteil hat, dass sich die Query natürlich nicht mehr verschlechtern kann, aber auch den Nachteil, dass sie sich nicht mehr verbessern kann. Einen ausführlichen Artikel hierzu ( ) sowie weitere interessante Veröffentlichungen finden Sie in der Rubrik Publikationen unter Beides sind unserer Ansicht nach praxistaugliche Lösungen, da sie schnell umgesetzt werden können. Wie aufgezeigt, muss es in solchen Fällen ja schnell gehen. Voraussetzung dafür ist allerdings, dass der DBA auch die Statistiken mittels DBMS_STATS oder die Execution-Plans mit Outlines gesichert hat. Eine kleine Vorbereitung, die sich lohnt. Mit optimalen Grüssen Peter Stalder Trivadis AG Mail: peter.stalder@trivadis.com Peter Stalder Tel: Kanalstrasse 5 Fax: CH-8152 Glattbrugg Internet: