Oracle Statistiken Ein Mythos in der Datenbank?

Oracle Statistiken Ein Mythos in der Datenbank? Thorsten Bruhns Seniorberater OPITZ CONSULTING Bad Homburg GmbH Nürnberg, 01.12.2008 Oracle Statistiken - Ein Mythos in der Datenbank? Seite 1

Inhalt Ich stehe Statistiken etwas skeptisch gegenüber. Denn laut Statistik haben ein Millionär und ein armer Kerl jeder eine halbe Million. Franklin Delano Roosevelt, 32. Präsident der Vereinigten Staaten von Amerika Oracle Statistiken - Ein Mythos in der Datenbank? Seite 2

Inhalt Was ist ein Optimizer? Rule-based Optimizer (RBO) Cost-based Optimizer (CBO) Voraussetzungen für Cost Based Optimizer Wie werden Statistiken gebildet? Mythen rund um Statistiken Oracle Statistiken - Ein Mythos in der Datenbank? Seite 3

Was ist ein Optimizer? Bildet Ausführungspläne für SQL-Statements Arbeitet nach einer definierten Strategie Regelbasierter Optimizer (RBO) Kostenbasierter Optimizer (CBO) Sehr wichtige Komponente der Datenbank Hat erheblichen Einfluß auf die Performance der Datenbank Oracle Statistiken - Ein Mythos in der Datenbank? Seite 4

regelbasierter Optimizer Rule-based Optimizer arbeitet fest nach einem Regelwerk, um Ausführungspläne zu bilden. Betrachtet ausschließlich die physischen Datenstruktuen Unterstützt keine neuen Indextypen kennt nur bestimmte Joinmethoden Supported bis Oracle 9.2 Desupported (Metalink Note 189702.1 annoucement Mai 2002) Funktioniert noch in 10g jedoch kein Support Beispiele Regeln Reihenfolge der Tabellen hinter FROM hat Einfluß auf den Plan Indizes werden immer genutzt, wenn vorhanden Oracle Statistiken - Ein Mythos in der Datenbank? Seite 5

kostenbasierter Optimizer Eingeführt mit Oracle 7 stetig weiter entwickelt und optimiert Unterstützt immer alle Indextypen und Joinmethoden Neue Joinmethoden => mehr Möglichkeiten bessere Pläne zu bilden Ausführungspläne werden abhängig von den Inhalten der Tabellen gebildet. Wesentliche Erweiterungen mit 11g Optional mittels Hints weitreichend beeinflußbar Oracle Statistiken - Ein Mythos in der Datenbank? Seite 6

Wann welcher Optimizer? Welcher Optimizer wird genutzt? Abhängig vom Parameter optimizer_mode auf System- bzw. Sessionebene oder Hints im Statement. RULE RBO, solange KEINE der folgenden Bedingungen wahr ist: ANSI-Join-Syntax Statistiken auf einer Tabelle oder Index Partitionierte Tabelle über View vorhanden? IOTs oder partitionierte Tabellen vorhanden? Tabelle mit DEGREE oder INSTANCES > 1? Domain, reversed key oder function based index vorhanden? Parallel create table as select Query rewrite aktiv? CHOOSE COST ALL_ROWS Oracle Statistiken - Ein Mythos in der Datenbank? Seite 7

Vorgehensmodell des CBO Transitivity Der Optimizer ergänzt die Where-Clause der beteiligten Tabellen select name from person, office where person_office_id = office_id and office_id = 10 wird zu: select name from person, office where person_office_id = office_id and office_id = 10 and person_office_id = 10 Oracle Statistiken - Ein Mythos in der Datenbank? Seite 8

Vorgehensmodell des CBO Cardinality Abschätzung der Anzahl der Datensätze, die aufgrund der Where-Clause selektiert werden. Beispiel: (Annahme: Keine Histogramme, kein Bind Peeking!) Selektivität wird bei = Vergleich wie folgt berechnet Selektivität=1/(Anzahl Values) => Selektivität nimmt immer einen Wert von 0..1 ein. (0 höchste Selektivität) Gesamtselektivität aller Prädikate einer Tabelle wird wie folgt ermittelt: AND S1 * S2 OR S1 + S2 (S1*S2) NOT 1 S1 S1 = Selektivität Prädikat1, S2 = Selektivität Prädikat2 => Die cardinality wird als Ergebnis aus den Berechnungen ermittelt Oracle Statistiken - Ein Mythos in der Datenbank? Seite 9

Kostenermittlung abhängig von der Cardinality Vorgehensmodell des CBO Bei der Kostenermittlung geht Oracle grundsätzlich davon aus, das die Daten nicht im Buffer-Cache vorhanden sind. Oracle kennt nur 2 Methoden, um Daten aus Tabellen zu lesen Full-Table-Scan (FTS) Table-Access by Row-ID Beide Methoden verursachen aus Sicht des Optimizers immer I/O Besonderheiten beim FTS: Pro Betriebssystem I/O werden n Oracle-Blöcke gelesen. (db_file_multi_block_read_count) Die Kosten für I/O werden geringer, da pro OS I/O n Oracle-Blöcke gelesen werden Es muß immer bis zur High-Water-Mark gelesen werden auch leere Blöcke Oracle Statistiken - Ein Mythos in der Datenbank? Seite 10

Vorgehensmodell des CBO Kostenermittlung abhängig von der Cardinality (Fortsetzung) Kosten der möglichen Indexscans ermitteln Sind Indizes vorhanden, die aufgrund der Prädikate und zu selektierenden Spalten sinnvoll sind? Ermittlung der Kostern der in Frage kommenden Indizes (bestehend aus 2 Schritten) Wieviel Indexblöcke müssen gelesen werden? Wieviel Tabellenblöcke müssen zusätzlich gelesen werden, um alle Daten zu erhalten. (Entfällt, wenn alle Daten im Index.) Oracle Statistiken - Ein Mythos in der Datenbank? Seite 11

Vorgehensmodell des CBO Welche Schritte werden im CBO abgearbeitet? Kosten der möglichen Indexscans ermitteln Bei der Kostenermittlung werden folgende Punkte berücksichtigt: - Tiefe des Index - Anzahl Leaf Blocks - Anzahl Leaf Blocks pro Indexkey - Durchschnittliche Anzahl Datensätze pro Datenblock in der Tabelle - Clustering Factor Oracle berechnet aufgrund dieser Informationen die Kosten für den Indexscan Oracle Statistiken - Ein Mythos in der Datenbank? Seite 12

Welche Schritte werden im CBO abgearbeitet? Kostenermittlung für Sortieroperationen Vorgehensmodell des CBO Notwendig bei order by oder group by ggf. auch bei sort merge join - Operationen - Abschätzung ob die Sortierung im Speicher oder im temporären Segment erfolgen muß. Abhängig von den Daten über die durchschnittliche Datensatzlänge sowie Anzahl der erwarteten Datensätze. Sort im temporären Segment erfordert zusätzlichen I/O, der durch entsprechende Erhöhung der erwarteten Kosten berücksichtigt wird. Oracle Statistiken - Ein Mythos in der Datenbank? Seite 13

Welche Schritte werden im CBO abgearbeitet? Vorgehensmodell des CBO Join-Order ermitteln (nur bei mehr als 1 Tabelle erforderlich) Ermittlung aller möglichen Join-Kombinationen zwischen den beteiligten Tabellen Liste wird durch spezielle Algorithmen bereinigt, um nicht jede Kombination abarbeiten zu müssen Betrachtung der cardinality der beteiligten Tabellen aus den möglichen Join- Kombinationen pro Join-Order werden Kosten bestimmt Plan mit geringsten Kosten ergibt dann den Ausführungsplan Quelle: Metalink 10626.1 Cost Based Optimizer (CBO) Overview Oracle Statistiken - Ein Mythos in der Datenbank? Seite 14

Wie werden Statistiken gebildet? Analyze table/index existiert weiterhin unter 11g, unterstützt nicht alle Möglichkeiten von DBMS_STATS keine Historisierung von Statistiken ab10g! Package DBMS_UTILITY, DBMS_DDL Nutzt intern analyze table/index => Nutzung nicht mehr empfohlen! Package DBMS_STATS mit 8.1.5 eingeführt, ersetzt analyze table/index ; Dringend von Oracle empfohlen! Neue Funktionalitäten nur in dbms_stats verfügbar Beispiele für Wechsel von analyze zu dbms_stats Note:237537.1 How to move ANALYZE to DBMS_STATS on Non-Partitioned tables Note:237538.1 How to move ANALYZE to DBMS_STATS on Partitioned tables Oracle Statistiken - Ein Mythos in der Datenbank? Seite 15

9i Besonderheiten von dbms_stats Wie werden Statistiken gebildet? Achtung bei gather_database_stats(options => gather auto ) => alle Parameter außer statown, stattab, statid und objlist werden ignoriert! method_opt => for all columns size auto 9i-Defaults problematisch, da nicht änderbar bei gather auto Alternative: GATHER EMPTY + GATHER STALE Defaults method_opt => for all columns size 1 estimate_percent => 100% cascade => false no_invalidate => false Table-Monitoring nicht vergessen! (alter table <Table> MONITORING;) Kein Standardjob verfügbar gather auto keine gute Lösung! Oracle Statistiken - Ein Mythos in der Datenbank? Seite 16

10g Besonderheiten von dbms_stats Neuer Default-Scheduler-Job GATHER_STATS_JOB für System- und/oder Userobjekte konfigurierbar Statistiken für Data-Dictionary zwingend erforderlich Wie werden Statistiken gebildet? Monitoring auf Tabellen per Default aktiv (statistics_level TYPICAL oder ALL) Neue Defaults (konfigurierbar! dbms_stats.set_param(parameter, wert) method_opt => for all columns size auto estimate_percent => auto_sample_size cascade => auto_cascade no_invalidate => auto_invalidate Table-Monitoring automatisch aktiv (statistics_level = TYPICAL/ALL) Vergleich von Tabellenstatistiken (ab 10.2.0.4) Oracle Statistiken - Ein Mythos in der Datenbank? Seite 17

11g Besonderheiten von dbms_stats Wie werden Statistiken gebildet? auto_sample_size überarbeitet wesentlich schneller als 100% sample bei vergleichbaren Ergebnissen Individuelle Konfiguration des GATHER_STATS_JOB pro Tabelle Multi-Column-Statistiken Vergleich von Tabellenstatistiken Invisible Indizes Histogramme können gelöscht werden Pending Statistics Oracle Statistiken - Ein Mythos in der Datenbank? Seite 18

sample_size > 10% möglichst immer 100% Mythen rund um Statistiken Falsch! Statistiken müssen bestehende Daten nicht exakt beschreiben sondern nur ein repräsentatives Bild liefern. Kann in sehr großen Tabellen bei < 1% erreicht werden. Insbesondere ohne Histogramme kleine sample_size häufig ausreichend Achtung bei kleinen Tabellen kleine sample_size => Gefahr von falschen Statistiken! dbms_stats.auto_sample_size reagiert dynamisch auf die Größe des zu analysierenden Objektes. Neuer Algorythmus in 11g. größere sample_size bei geringem Zeitbedarf sample_size aus ALL/USER/DBA_TABLES beschreibt, wieviel Datensätze tatsächlich analysiert wurden Oracle Statistiken - Ein Mythos in der Datenbank? Seite 19

Mythen rund um Statistiken Regelmäßiger Statistikaufbau zwingend erforderlich Falsch! Sie müssen so regelmäßig aktualisiert werden, das sie ein Bild der Daten wiedergeben. Mittels Table-Monitoring kann erkannt werden, wieviel sich geändert hat. => nur geänderte Tabellen müssen analysiert werden. granularity bei partitionierten Tabellen beachten! Achtung: Min/Max-Value bei Tabellen mit vielen Änderungen beobachten Oracle Statistiken - Ein Mythos in der Datenbank? Seite 20

Mythen rund um Statistiken Statements müssen dem Optimizer angepaßt werden teilweise Richtig RBO zahlreiche Anpassungen erforderlich, meist intuitiv schon vorgenommen Wer kann heute noch Statements für den RBO schreiben? CBO Anpassungen vom RBO sehr häufig schädlich beim Wechsel zum CBO Algorytmus des CBO benötigt manchmal Hilfen (Hints). Ursache Statistiken können den Datenbestand nicht korrekt beschreiben! SQL-Profile können hier hilfreich sein, um den Einsatz von Hints zu umgehen Oracle Statistiken - Ein Mythos in der Datenbank? Seite 21

Bestimmte Init.ora-Parameter zwingend Mythen rund um Statistiken teilweise Richtig Notwendigkeit von Parametern muß klar sein Bugs können bestimmte Parameter erfordern _optim_peek_user_binds unter 10gR2 (Bug 5082178 Metalink Note: 387394.1) Nur selten sind Parameter für Performanceprobleme verantwortlich Manchmal werden Defaults von _ mit Patchsets geändert. => Kann ein Grund für das Setzen sein Nur wenige Kunden können genau erklären, warum ein _ -Paramter gesetzt wurde! Oracle Statistiken - Ein Mythos in der Datenbank? Seite 22

Verständnis für Trace-Event 10053 notwendig Mythen rund um Statistiken Falsch Das genaue Format der Trace-Files ist nicht dokumentiert. Dient zur Analyse, wie der Optimizer zum Plan kam. Alle Steps werden aufgelistet Manchmal hilfreich, wenn keine Erklärung für die cardinalty auffindbar ist. Tracefiles sind schwer lesbar Metalink Note: 225598.1 How to obtain Tracing of Optimizer Computations Note: 338137.1 Case study: Analyzing 10053 Trace Files Oracle Statistiken - Ein Mythos in der Datenbank? Seite 23

Mythen rund um Statistiken Fazit RBO CBO => CBO komplexer aber flexibler Statistiken sind wichtig, müssen nicht zwingend exakt sein dbms_stats wird zunehmend einfacher in der Bedienung Viele Mythen sind falsch beruhen auf uralten Annahmen RBO ist Geschichte es lebe der CBO! Oracle Statistiken - Ein Mythos in der Datenbank? Seite 24

Ich stehe Statistiken etwas skeptisch gegenüber. Denn laut Statistik haben ein Millionär und ein armer Kerl jeder eine halbe Million. Franklin Delano Roosevelt, 32. Präsident der Vereinigten Staaten von Amerika Oracle Statistiken - Ein Mythos in der Datenbank? Seite 25

Kontakt Kontakt: Thorsten Bruhns OPITZ CONSULTING Bad Homburg GmbH Thorsten.Bruhns@opitz-consulting.de +49 174 30 49 64 2 Vielen Dank für Ihre Aufmerksamkeit! Oracle Statistiken - Ein Mythos in der Datenbank? Seite 26