Oracle DBA-Wiki – verstehen, anwenden, nachschlagen

Bei der Diagnose sollte zuerst geklärt werden, welche Ebene bereits funktioniert. Läuft noch keine Instance, beginnt die Untersuchung bei Umgebung, Parameterdatei und frühen Startmeldungen. Ist MOUNT erreicht, hat Oracle das Controlfile geöffnet und die Database der Instance zugeordnet. Ist OPEN erreicht, steht die Database für den vorgesehenen Betrieb zur Verfügung.

Bei einer CDB wird anschließend der Zustand der PDBs betrachtet. Daraus ergibt sich ein einfaches Diagnosemodell: Instance → Database → PDBs → Services/Anwendung. Erst nach dieser Einordnung sollte über eine administrative Aktion entschieden werden.

Im normalen Betrieb bewegt sich Oracle vereinfacht durch eine feste Zustandsfolge. Aus einem gestoppten Zustand entsteht zunächst eine Instance. Danach wird die Database gemountet und schließlich geöffnet.

In NOMOUNT wird die Oracle-Instance aufgebaut. Oracle liest seine Initialisierungsparameter, reserviert den benötigten Instanzspeicher und startet die erforderlichen Hintergrundprozesse.

Die Controlfiles der Database sind in dieser Phase noch nicht geöffnet. Deshalb kennt die Instance die dort gespeicherte physische Datenbankstruktur noch nicht aus dem Controlfile.

Zum Aufbau der Instance benötigt Oracle Initialisierungsparameter. Diese können aus einem SPFILE oder PFILE stammen. Sie bestimmen unter anderem grundlegende Eigenschaften der Instance und enthalten Informationen, die Oracle bereits vor dem Mounten der Database benötigt.

Suchreihenfolge: Bei einem SQL*Plus-Start ohne explizite PFILE-Angabe sucht Oracle im plattformspezifischen Standardverzeichnis zuerst spfile<SID>.ora, danach spfile.ora und schließlich init<SID>.ora. <SID> steht für die betreffende Oracle-SID. Ein explizites STARTUP PFILE=... benennt die zu lesende Textdatei.

Eine PFILE kann selbst mit einem SPFILE-Eintrag auf eine binäre Parameterdatei verweisen, etwa in ASM. Die PFILE-Angabe bedeutet deshalb nicht zwingend, dass sämtliche Parameter direkt in der Textdatei stehen. Bei einer durch Oracle Restart verwalteten Datenbank ist die konfigurierte SPFILE-Adresse im SRVCTL-Startverfahren zu berücksichtigen; dessen Konfiguration ersetzt eine Vermutung über lokale Standardpfade. Die nachfolgenden Beispiele erläutern den SQL*Plus-Ablauf.

Die folgende Vertiefung erklärt, wie Startkonfiguration und laufende Werte zusammenhängen. Für den Startup-Ablauf bleibt entscheidend: Ohne passende Startparameter kann die Instanz nicht korrekt aufgebaut werden.

Beim Wechsel nach MOUNT öffnet Oracle die Controlfiles. Dadurch erhält die Instance zentrale Informationen über die Database, beispielsweise welche Datafiles und Online Redo Logs zur Datenbank gehören.

Die eigentlichen Datafiles sind für den normalen Benutzerbetrieb zu diesem Zeitpunkt noch nicht geöffnet. Deshalb ist MOUNT ein wichtiger administrativer Zwischenzustand.

MOUNT ist besonders dann relevant, wenn Oracle die Struktur der Database kennen muss, die Datenbank aber noch nicht für normalen Benutzerzugriff geöffnet sein soll.

Das ist beispielsweise bei bestimmten Recovery- oder Wartungssituationen wichtig. Die konkreten Recovery-Abläufe werden im Kapitel Backup & Recovery behandelt.

Beim Öffnen werden die für den Betrieb notwendigen Datafiles und Online Redo Logs geöffnet. Oracle prüft, ob der Zustand der Dateien zusammenpasst und ob gegebenenfalls Recovery erforderlich ist.

Erst im Zustand OPEN steht die Database normalerweise für reguläre Anwendungssessions und fachliche Zugriffe zur Verfügung.

Bei einer CDB existiert zusätzlich die Container-Ebene. Die CDB kann OPEN sein, während einzelne PDBs einen anderen Open Mode besitzen. Für eine Anwendung, die über einen PDB-Service verbindet, ist deshalb der PDB-Zustand entscheidend.

Ein normaler STARTUP durchläuft die notwendigen Phasen bis OPEN. Die einzelnen Zustände sind trotzdem wichtig, weil ein DBA einen Start gezielt in NOMOUNT oder MOUNT anhalten kann, wenn eine administrative Aufgabe genau diesen Zustand verlangt.

Für die Diagnose sollte der DBA nicht raten, sondern den aktuellen Zustand aus den Dynamic Performance Views lesen. Besonders hilfreich sind V$INSTANCE und V$DATABASE.

Die verschiedenen Views beschreiben unterschiedliche Ebenen. Deshalb sollte man Statuswerte nicht isoliert betrachten. V$INSTANCE beschreibt den Zustand der Instance; V$DATABASE liefert Informationen zum Zustand beziehungsweise Open Mode der Database.

Eine Database beziehungsweise PDB kann in einem eingeschränkten Modus betrieben werden, in dem normale Benutzerverbindungen nicht uneingeschränkt zugelassen sind. Deshalb reicht bei einer Verbindungsstörung die Aussage „Database ist OPEN“ nicht in jedem Fall aus.

Für dieses Wiki ist vor allem die read-only Feststellung wichtig. Das Aktivieren oder Deaktivieren eines Restricted Modes wäre eine Zustandsänderung und wird hier nicht automatisch ausgeführt.

Ein Fehler beim Startup sollte zuerst der Phase zugeordnet werden. Scheitert bereits der Aufbau der Instance, liegt die Ursache in einem anderen Bereich als bei einem Fehler beim Mounten oder beim Öffnen der Database.

Das Alert Log protokolliert zentrale Ereignisse beim Start und Shutdown. Bei einem fehlgeschlagenen Startup ist es deshalb eine der wichtigsten Quellen, um zu erkennen, welche Phase erreicht wurde und an welcher Stelle Oracle abgebrochen hat.

Entscheidend ist die zeitliche Reihenfolge der Meldungen. Einzelne ORA-Fehler sollten immer zusammen mit den unmittelbar davor und danach protokollierten Ereignissen betrachtet werden.

Ein geplanter Shutdown soll Oracle kontrolliert aus dem Benutzerbetrieb nehmen und einen konsistenten Zustand für den nächsten Start hinterlassen.

Die Shutdown-Varianten unterscheiden sich vor allem darin, wie sie mit bestehenden Sessions und offenen Transaktionen umgehen.

IMMEDIATE ist für geplante Arbeiten praktisch, weil Oracle nicht darauf warten muss, dass jeder Benutzer seine Session selbst beendet. Gleichzeitig wird die Database kontrolliert heruntergefahren.

Nicht bestätigte Transaktionen werden zurückgerollt. Umfangreiche Rollbacks können Zeit beanspruchen: IMMEDIATE bedeutet nicht, dass der Shutdown sofort abgeschlossen ist. Nach einem erfolgreich abgeschlossenen konsistenten Shutdown ist keine crashbedingte Instance Recovery nötig.

ABORT beendet die Instance abrupt. Oracle führt dabei keinen normalen geordneten Shutdown-Ablauf bis zum Ende durch. Nach dem inkonsistenten Abbruch einer geöffneten Database ist beim erneuten Öffnen Instance Recovery erforderlich.

ABORT ist ein Ausnahmeverfahren nach betrieblicher Vorgabe, etwa wenn andere Shutdown-Verfahren scheitern, unmittelbar ein Ausfall droht oder bestimmte Startprobleme vorliegen. Die Entscheidung richtet sich nach dem konkreten Zustand und dem freigegebenen Betriebsverfahren.

Nach einem inkonsistenten Abbruch einer geöffneten Database führt Oracle beim erneuten Öffnen automatisch Instance Recovery durch. Ein bloßes STARTUP NOMOUNT öffnet die Database noch nicht. Oracle wendet benötigte Redo-Informationen an (Roll Forward) und macht nicht bestätigte Änderungen mithilfe von Undo rückgängig (Rollback). Das Rückgängigmachen von Transaktionen kann teilweise nach dem Öffnen weiterlaufen.

Für dieses Kapitel ist nur die Einordnung wichtig: Instance Recovery nach einem Instance-Abbruch ist nicht dasselbe wie ein manueller Restore oder ein Media Recovery nach verloren gegangenen beziehungsweise beschädigten Dateien. Die Recovery-Mechanismen werden im Backup-&-Recovery-Kapitel vertieft.

Ein sauberer Shutdown, ein ungeplanter Instanzabbruch und ein Verlust von Datenbankdateien sind drei grundverschiedene Situationen. Sie dürfen in der Diagnose nicht miteinander vermischt werden.

Bevor ein DBA überhaupt über einen Betriebszustandswechsel nachdenkt, sollte er den Ist-Zustand dokumentieren. Dazu gehören Instance-Status, Open Mode, aktive Sessions und gegebenenfalls laufende Transaktionen.

Bei einem fehlgeschlagenen Start ist die zuletzt erfolgreich erreichte Phase eine der wichtigsten Informationen. Dadurch wird der Suchraum eingegrenzt, ohne bereits eine Ursache vorwegzunehmen.

Oracle verwaltet zu allen drei Objektarten Metadaten im Data Dictionary. Dadurch kann ein DBA read-only untersuchen, welche Spalten eine Tabelle besitzt, welche Indizes darauf definiert sind, welche Spalten ein Index enthält und welche Constraints beziehungsweise Fremdschlüsselbeziehungen existieren.

Ein Index ist eine separate Suchstruktur zu einer Tabelle. Er enthält ausgewählte Spaltenwerte und Verweise auf die zugehörigen Tabellenzeilen. Dadurch kann Oracle unter geeigneten Bedingungen gezielter zu den gesuchten Daten springen, statt die gesamte Tabelle zu lesen.

Das Prinzip ist mit dem Stichwortverzeichnis eines Buches vergleichbar: Du liest nicht jede Seite, sondern suchst einen Begriff im Verzeichnis und springst anschließend zur passenden Seite.

Wenn eine Abfrage einen großen Anteil der Tabelle benötigt, kann ein Full Table Scan günstiger sein. Ein Indexzugriff besteht oft aus zwei Schritten: Index lesen und danach viele Tabellenblöcke über RowIDs besuchen. Bei sehr vielen Treffern kann das teurer sein als ein sequenzieller Scan der Tabelle.

Der klassische Oracle-Index ist der B-Tree-Index. Er eignet sich für viele OLTP-Zugriffsmuster, insbesondere für Gleichheits- und Bereichsprädikate. B-Tree bezeichnet die Struktur; Composite bezeichnet mehrere Schlüsselspalten, Function-Based einen Ausdruck als Indexbestandteil. Diese Eigenschaften sind kombinierbar: Ein B-Tree kann zusammengesetzt und funktionsbasiert sein. UNIQUE und INVISIBLE sind weitere Eigenschaften. Bitmap beschreibt eine andere Indexstruktur.

Ein Bitmap-Index ist nicht einfach ein „Index für wenige verschiedene Werte“. Seine Eignung hängt stark von Workload, Änderungsverhalten und Abfragemustern ab. In schreibintensiven OLTP-Systemen können Bitmap-Indizes wegen ihrer Sperr- und Wartungseigenschaften problematisch sein. Die Auswahl eines Indextyps ist deshalb eine Designentscheidung und keine reine Kardinalitätsregel.

Ein Unique Index verhindert doppelte Indexschlüssel nach der Oracle-Semantik für NULL-Werte. Er kann beispielsweise zur technischen Durchsetzung eines PRIMARY-KEY- oder UNIQUE-Constraints verwendet werden. Trotzdem bleiben Index und Constraint zwei verschiedene Konzepte.

Ein zusammengesetzter Index enthält mehrere Spalten in einer festgelegten Reihenfolge. Diese Reihenfolge beeinflusst, für welche Prädikate der Index besonders gut nutzbar ist. Die erste Spalte beziehungsweise die führenden Spalten sind deshalb bei der Planung wichtig.

Die verkürzte Aussage „ohne die erste Spalte kann Oracle den Index nie verwenden“ wäre jedoch falsch. Je nach Abfrage und Kostenmodell sind beispielsweise Index Skip Scans oder andere Zugriffsformen möglich. Ob Oracle einen Index tatsächlich auswählt, entscheidet der Optimizer; dieses Thema wird im Performance-/Execution-Plan-Bereich vertieft.

Ein Function-Based Index speichert nicht nur einen Rohwert, sondern das Ergebnis eines Ausdrucks. Das ist nützlich, wenn eine Abfrage denselben Ausdruck verwendet.

Eine Abfrage mit WHERE UPPER(name) = 'MEIER' kann von diesem Index profitieren. Der Index garantiert aber keinen bestimmten Plan.

Bitmap-Indizes speichern Werte in Bitmap-Strukturen. Sie können in analytischen Umgebungen mit relativ wenigen unterschiedlichen Werten nützlich sein. In stark schreibenden OLTP-Systemen sind sie wegen ihres DML-/Locking-Verhaltens oft ungeeignet.

Ein Invisible Index bleibt physisch vorhanden und wird bei DML weiter gepflegt, steht dem Optimizer standardmäßig aber nicht als normal sichtbarer Zugriffspfad zur Verfügung. Das kann beim Test helfen, ob ein Index wirklich benötigt wird.

Bei Indizes ist insbesondere der Status UNUSABLE relevant. Ein unbenutzbarer Index ist nicht einfach nur „langsam“, sondern steht für normale Indexzugriffe nicht wie ein verwendbarer Index zur Verfügung. Die genaue Ursache muss aus dem betrieblichen Kontext ermittelt werden.

Descending Indexes speichern ausgewählte Schlüsselbestandteile absteigend. Bei partitionierten Tabellen gibt es unter anderem Local und Global Indexes. Local Indexes orientieren sich an den Tabellenpartitionen; Global Indexes besitzen eine davon unabhängigere globale Struktur.

Dictionary-Spalten wie NUM_ROWS, DISTINCT_KEYS, BLEVEL oder LEAF_BLOCKS können von gesammelten Optimizer-Statistiken abhängen. Sie sind deshalb nicht automatisch ein sekundengenauer Live-Zustand.

Die fachliche Vertiefung zu Statistikalter, Cardinality und Histogrammen bleibt in Kapitel 9 – Optimizer-Statistiken.

Ein Constraint ist eine Datenregel. Oracle prüft damit, ob gespeicherte Daten bestimmten Bedingungen entsprechen. Constraints dienen in erster Linie der Datenqualität und Integrität, nicht der Performance.

Ein PRIMARY KEY identifiziert eine Tabellenzeile eindeutig. Die beteiligten Spalten dürfen nicht NULL sein und die Schlüsselkombination darf nicht doppelt vorkommen.

Ein UNIQUE Constraint erzwingt Eindeutigkeit nach Oracle-Semantik. Im Unterschied zum PRIMARY KEY kann eine Tabelle mehrere UNIQUE Constraints besitzen.

Ein FOREIGN KEY stellt eine Beziehung zwischen Child- und Parent-Daten her. Er verhindert beispielsweise, dass ein Child-Wert auf einen nicht vorhandenen Parent-Schlüssel verweist. Ziel ist ein PRIMARY-KEY- oder UNIQUE-Constraint, nicht bloß ein beliebiger Index. Ein Foreign Key verlangt nicht automatisch NOT NULL. Bei einem zusammengesetzten Foreign Key genügt bereits eine NULL-Komponente, damit die Fremdschlüsselbedingung erfüllt ist; zwingende Vollständigkeit benötigt zusätzliche Regeln.

Oracle erzeugt für einen Foreign Key nicht automatisch einen Child-Index. Ein geeigneter Index kann aber für Joins und bestimmte Parent-DML-/Locking-Situationen wichtig sein.

NOT NULL verhindert NULL-Werte in einer Spalte. Ein CHECK-Constraint definiert eine fachliche Bedingung, beispielsweise preis >= 0. Beide sind Regeln und benötigen nicht automatisch einen eigenen Index. CHECK (preis >= 0) erlaubt auch NULL, weil die Bedingung dann UNKNOWN ist. Soll ein Preis zwingend vorhanden sein, wird zusätzlich NOT NULL benötigt.

Bei der Diagnose reicht der Constraint-Name allein nicht. Oracle stellt auch Informationen dazu bereit, ob eine Regel aktiviert und validiert ist sowie ob sie verzögert geprüft werden kann. Ein Constraint kann daher strukturell vorhanden sein, ohne dass jede denkbare Statuskombination dasselbe bedeutet.

Bei einer Objektanalyse sollte nicht nur eine einzelne Dictionary-View betrachtet werden. Erst die Kombination aus Tabellenstruktur, Indexdefinition und Constraints zeigt, welche Aufgabe ein Objekt im Schema erfüllt.

Die logische Sicht beschreibt, wie Oracle Speicher verwaltet. Die physische Sicht beschreibt die Dateien auf Filesystem oder ASM. Ein permanenter Tablespace besitzt Datafiles; ein temporärer Tablespace besitzt Tempfiles. Smallfile-Tablespaces können mehrere Dateien enthalten, ein Bigfile-Tablespace genau eine potenziell sehr große Datei. Die Tablespace-Blockgröße bestimmt die Größe seiner Oracle-Blöcke; sie ist nicht mit der Blockgröße des Filesystems gleichzusetzen.

Speicherverwaltung: Locally Managed Tablespaces (LMT) verwalten die Zuordnung freier und belegter Extents mit Bitmaps. Automatic Segment Space Management (ASSM) verwaltet innerhalb geeigneter Segmente den für Zeilen verfügbaren Blockplatz. Das sind zwei verschiedene Verwaltungsebenen; weder LMT noch ASSM garantieren eine bestimmte Nutzdatenquote.

Angenommen, ein Datafile ist 20 GB groß und darin sind 15 GB Segmentplatz zugeordnet. Daraus folgt nicht, dass 15 GB fachliche Nutzdaten vorhanden sind: freie Bereiche innerhalb von Segmenten und Verwaltungsinformationen zählen mit. Freie Extents sind dagegen noch keinem Segment zugeordnet. Wird eine große Zahl von Zeilen gelöscht, kann der Segmentplatz weiterhin zugeordnet bleiben und später wiederverwendet werden. Die Datei wird dadurch nicht automatisch kleiner.

Praxisfall: Ein Tablespace ist fast vollständig allokiert, obwohl viele Zeilen entfernt wurden. Prüfe zunächst die größten Segmente und den freien Extent-Platz. Zeilenlöschungen können Platz innerhalb eines Segments freigeben, ohne Extents an den Tablespace zurückzugeben. Daraus folgt weder automatisch ein Storage-Fehler noch die Notwendigkeit einer Vergrößerung. Dieses Wiki führt keine Reorganisation und keine Änderung aus.

Die fünf grundlegenden Storage-Sichten ergänzen sich: Die Dateisicht liefert die aktuelle Kapazität und Wachstumsgrenzen, die Segmentsicht zeigt die größten Speicherstrukturen, und die Extentsicht verbindet diese mit konkreten Dateien. Der freie Extent-Platz erklärt, welche Bereiche noch zugeordnet werden können. TEMP bleibt eine separate Betrachtung. Halte im Analyseergebnis fest, auf welche Ebene und welchen Zeitpunkt sich jede Zahl bezieht; so werden Dateigröße, Segmentplatz und aktuelle Nutzung nicht versehentlich gleichgesetzt.

Bei Statistikproblemen ist eine einfache Reihenfolge hilfreich: Objekt identifizieren → vorhandene Statistiken prüfen → Aktualität und Stale-Status bewerten → Datenverteilung berücksichtigen → erst danach einen Zusammenhang mit dem SQL-Plan untersuchen.

Wichtig ist dabei die Trennung zwischen Befund und Maßnahme. Ein altes LAST_ANALYZED beweist noch nicht, dass ein Performanceproblem durch Statistiken verursacht wird. Ebenso bedeutet STALE_STATS='YES' nicht automatisch, dass sofort manuell neue Statistiken gesammelt werden müssen.

Oracle trennt zwei Statistikwelten, die im DBA-Alltag leicht verwechselt werden. Optimizer-Statistiken beschreiben Datenbankobjekte und Eigenschaften, die der Optimizer für Kostenschätzungen verwendet. Performance-Statistiken aus dynamischen Performance Views wie V$SYSSTAT oder V$SESSION beschreiben dagegen Laufzeitaktivität der Instance beziehungsweise Sessions.

DBA_TAB_STATISTICS.NUM_ROWS und V$SYSSTAT beantworten daher grundverschiedene Fragen. Kapitel 9 bleibt bei den Optimizer-Statistiken; Laufzeitdiagnose gehört in die Performance-Kapitel.

NUM_ROWS ist kein Live-Zähler. Der Wert gehört zum gespeicherten Optimizer-Statistikstand und kann auf einer Stichprobe beruhen. Er ist deshalb auch nicht in jedem Fall eine exakte Zählung zum Erfassungszeitpunkt. Wenn seitdem viele Zeilen eingefügt oder gelöscht wurden, kann er vom aktuellen Bestand abweichen.

Deshalb bedeutet NUM_ROWS = 100000 nicht: „Die Tabelle hat jetzt garantiert exakt 100.000 Zeilen.“

Selektivität ist der geschätzte Trefferanteil zwischen 0 und 1. Ein kleiner Zahlenwert bedeutet starke Einschränkung: 1 von 1.000.000 entspricht 0,000001. Umgangssprachlich heißt das „sehr selektiv“.

Wenn aus einer Million Zeilen nur eine Zeile passt, ist das sehr selektiv. Wenn 800.000 Zeilen passen, ist die Bedingung wenig selektiv. Diese Einschätzung beeinflusst, ob ein Index attraktiv ist.

Cardinality bezeichnet eine Zeilenanzahl. Im geschätzten Execution Plan ist damit die vom Optimizer geschätzte Ausgabezeilenzahl einer Operation gemeint; gemessene Zeilenmengen werden in Kapitel 10 davon getrennt.

Beispiel: Oracle erwartet 10 Zeilen, tatsächlich entstehen 500.000. Diese Fehleinschätzung kann dazu führen, dass Oracle einen Plan wählt, der für eine kleine Datenmenge gut, für die reale große Datenmenge aber schlecht ist.

Nicht jede Spalte ist gleichmäßig verteilt. Stell dir eine Spalte STATUS vor: 99 % der Zeilen enthalten CLOSED, nur 1 % enthalten OPEN.

Eine Abfrage auf OPEN kann sehr selektiv sein, eine Abfrage auf CLOSED dagegen nicht. Der Optimizer sollte diesen Unterschied kennen.

Normale Spaltenstatistiken beschreiben unter anderem die Anzahl unterschiedlicher Werte. Bei ungleichmäßiger Datenverteilung kann diese Zusammenfassung für bestimmte Prädikate zu grob sein. Histogramme liefern dem Optimizer zusätzliche Informationen über die Verteilung von Spaltenwerten.

Ein Histogramm ist jedoch nicht pauschal für jede Spalte mit wenigen oder ungleich verteilten Werten erforderlich. Oracle entscheidet bei der automatischen Statistikermittlung anhand verschiedener Informationen, unter anderem Nutzung und Datenverteilung, ob Histogramme sinnvoll sind. Ein vorhandenes Histogramm ist deshalb zunächst ein Statistikmerkmal und nicht automatisch ein Problem.

Oracle 19c kennt verschiedene Histogrammtypen. In DBA_TAB_COL_STATISTICS.HISTOGRAM können unter anderem NONE, FREQUENCY, TOP-FREQUENCY und HYBRID erscheinen. Der Typ beschreibt, wie Oracle Informationen über die Werteverteilung gespeichert hat.

Ein Histogramm sollte nicht allein anhand seines Typs als gut oder schlecht bewertet werden. Entscheidend ist, ob die Statistik die relevante Datenverteilung sinnvoll beschreibt. Die konkrete Auswirkung auf einen Execution Plan gehört in das Plan-/SQL-Tuning-Kapitel.

Auch Eigenschaften eines Index fließen in die Kostenschätzung ein. Die Bedeutung von B-Tree, Leaf Blocks, Clustering Factor und den verschiedenen Indexzugriffen wird bewusst nur im zentralen Fachkapitel Indizes & Constraints erklärt. Hier reicht der Zusammenhang: Der Optimizer verwendet auch Indexstatistiken, wenn er Zugriffskosten vergleicht.

Einzelne Spaltenstatistiken können Zusammenhänge zwischen mehreren Spalten nicht immer ausreichend beschreiben. Oracle unterstützt deshalb Extended Statistics, beispielsweise Column-Group-Statistiken für korrelierte Spalten oder Statistiken auf Ausdrücken.

Dieses Kapitel beschränkt sich auf das Konzept. Das Anlegen oder Verändern solcher Statistiken ist eine administrative Aktion und wird in der read-only Diagnose nicht automatisch ausgeführt.

LAST_ANALYZED zeigt den Zeitpunkt der letzten Statistik-Erfassung. Ein altes Datum bedeutet nicht automatisch ein Problem: Wenn sich die Daten kaum verändert haben, können alte Statistiken weiterhin gut passen.

STALE_STATS zeigt, ob Oracle die Statistiken nach seiner Änderungsbeobachtung als veraltet einstuft. Auch das ist ein Diagnosehinweis, kein Beweis für eine Performanceursache.

Oracle verwendet die STALE_PERCENT-Präferenz, um zu bestimmen, ab welchem Änderungsumfang Statistiken als stale gelten. Der Default liegt typischerweise bei 10 Prozent. Weil diese Präferenz verändert werden kann, sollte ein DBA nicht pauschal behaupten: „Oracle markiert Statistiken immer exakt ab 10 Prozent als stale.“

STALE_STATS='YES' bedeutet außerdem nicht, dass die Statistik automatisch die Ursache eines Problems ist. Es bedeutet zunächst, dass Oracle sie anhand seiner Monitoringinformationen und der geltenden Präferenz als veraltet einstuft.

Bei partitionierten Tabellen kann Oracle Statistiken auf mehreren Ebenen speichern: für die gesamte Tabelle, einzelne Partitionen und bei Composite Partitioning auch Subpartitionen. Ein DBA darf deshalb nicht aus einem einzigen LAST_ANALYZED-Wert auf den Statistikzustand aller Partitionen schließen.

Oracle kann bei geeigneter Konfiguration inkrementelle Statistiken verwenden, um globale Statistiken partitionierter Tabellen effizienter zu pflegen. Die Konfiguration davon ist administrativ; die Diagnose des vorhandenen Zustands bleibt hier read-only.

Die read-only Diagnose von Indizes und deren Statistikwerten steht gesammelt im Kapitel Tabellen, Indizes & Constraints. Dadurch bleibt dieses Kapitel auf die Frage konzentriert, warum der Optimizer Statistiken braucht.

Oracle 19c kann Optimizer-Statistiken automatisch in Maintenance Windows sammeln. Das ist die normale Grundlage vieler Systeme.

Trotzdem gibt es Situationen, in denen ein DBA genauer hinschauen muss: sehr große Tabellen, starke Datenänderungen, spezielle Batchläufe oder auffällige Planänderungen.

Bevor man Aussagen über Staleness, Histogramme oder automatische Sammlung trifft, sollte man die für das Objekt geltenden Präferenzen kennen. DBMS_STATS.GET_PREFS liest diese Einstellungen und verändert keine Statistiken.

Optimizer-Statistiken können gesperrt sein. Das ist für die Diagnose wichtig, weil eine automatische oder manuelle Sammlung dann nicht einfach wie bei einem ungesperrten Objekt wirkt. Ein alter Statistikstand kann deshalb bewusst konserviert worden sein.

Das folgende Beispiel sammelt Statistiken für genau ein ausdrücklich benanntes Lernschema. Konto-Status und Default-Tablespace sind keine verlässlichen Auswahlkriterien für die zu bearbeitenden Schemas. Fehler werden nicht abgefangen und als bloße Textmeldung verschluckt; SQL*Plus beendet sich bei einem SQL-/PLSQL-Fehler mit Fehlerstatus. Bereits erfolgte Statistikänderungen sind dadurch nicht automatisch zurückgenommen.

estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE lässt Oracle die Stichprobengröße bestimmen. cascade => TRUE bezieht Indexstatistiken ein. SIZE AUTO überlässt Oracle die Histogrammentscheidung. degree => 1 ist eine bewusst konservative Einstellung ohne Parallelität.

Stelle dir eine Tabelle ORDERS mit einer Million Bestellungen vor. Eine Suche nach einer bestimmten ORDER_ID braucht typischerweise sehr wenige Ergebniszeilen. Ein Monatsbericht kann dagegen einen großen Teil der Tabelle benötigen. Obwohl beide Abfragen dieselbe Tabelle verwenden, unterscheiden sich ihre sinnvollen Arbeitswege.

Der Optimizer betrachtet unter anderem verfügbare Zugriffspfade, Joinreihenfolgen und Joinmethoden. Außerdem können zulässige Query-Transformationen die interne Form verändern, ohne das fachliche Ergebnis zu verändern. SQL-Text und Plan sind deshalb nicht Zeile für Zeile identisch. Der gewählte Plan ist eine kostenbasierte Entscheidung unter den berücksichtigten Möglichkeiten; er ist kein Beweis, dass es unter jeder späteren Lastsituation keinen besseren Weg geben kann.

Die Verbindung ist entscheidend: Eine angenommene kleine Ergebnismenge kann einen gezielten Indexzugriff attraktiv machen. Werden später sehr viel mehr Zeilen verarbeitet, kann derselbe Weg zahlreiche Tabellenblockzugriffe verursachen. Ein Schätzfehler kann dadurch nicht nur eine Zahl verändern, sondern die gesamte Joinstrategie beeinflussen.

Cost ist weder eine Zeit in Sekunden noch eine gemessene CPU-Auslastung. Ein Plan mit Cost 100 muss nicht doppelt so lange laufen wie ein Plan mit Cost 50. Auch ein Vergleich der Kosten verschiedener SQL-Anweisungen ist keine zuverlässige Rangliste ihrer realen Laufzeiten. Gemessene Ausführung und Kostenmodell werden getrennt beurteilt.

Ein Index ist ein zusätzlicher Suchweg, keine allgemeine Beschleunigungsgarantie. Wenn viele Treffer über ROWID in verstreuten Tabellenblöcken nachgeladen werden, kann der zusätzliche Aufwand größer sein als bei einem Scan. Der Clustering Factor hilft dem Optimizer einzuschätzen, wie gut Indexreihenfolge und physische Verteilung der Tabellenzeilen zusammenpassen.

Es gibt keine allgemeingültige Prozentgrenze, ab der Oracle zwingend einen Full Table Scan wählen muss. Tabellenumfang, Zeilenbreite, Cachezustand, Systemstatistiken und die konkret benötigten Spalten wirken zusammen. Beurteile deshalb die beobachtete Arbeit, statt den Namen der Operation als Ampel zu verwenden.

Nehmen wir 20 ausgewählte Kunden und einen passenden Index auf ORDERS.CUSTOMER_ID: Nested Loops kann die Bestellungen je Kunde gezielt nachladen. Wenn der äußere Filter stattdessen 200.000 Kunden liefert, wird derselbe innere Zugriff sehr häufig gestartet. Dann ist nicht zwingend jeder einzelne Zugriff teuer; die große Zahl der Wiederholungen kann das Problem erklären.

Ein Hash Join kann große Gleichheitsverknüpfungen effizient bearbeiten, braucht aber einen Arbeitsbereich. Reicht dessen Speicher nicht aus, kann TEMP hinzukommen. Das ist ein Anlass, Arbeitsspeicher, Datenmenge und Laufzeit zusammen zu betrachten. Sort Merge kann unter anderem bei passenden Ordnungen oder geeigneten Vergleichsbedingungen sinnvoll sein. Keine der drei Methoden ist allein aufgrund ihres Namens gut oder schlecht.

Die Reihenfolge beeinflusst, wie viele Zwischenzeilen nachfolgende Operationen verarbeiten. Wird ein wirksamer Filter früh angewendet, kann der Rest des Plans mit einer kleinen Menge arbeiten. Werden zunächst große Mengen verknüpft, kann die Zwischenarbeit erheblich wachsen. Die geschätzten Zeilenmengen sind deshalb auch für die Joinreihenfolge zentral.

In der Predicate Information eines Plans beschreibt access beispielsweise Bedingungen, mit denen eine Indexsuche oder Joinoperation eingegrenzt wird. filter beschreibt Bedingungen, die an einer Operation zur Auswahl der Zeilen geprüft werden. Ein Filter ist nicht automatisch schlecht; wichtig ist, wie viele Zeilen zuvor verarbeitet werden mussten. Funktionen auf Spalten, implizite Datentypumwandlungen oder unpassende Bind-Datentypen können die nutzbaren Zugriffswege beeinflussen. Eine sichtbare Funktion beweist aber noch nicht, dass kein geeigneter function-based Index vorhanden ist.

Die Zahlen schrittweise lesen: Child 0 hat 100 registrierte Ausführungen und kumuliert 12 Sekunden Elapsed Time. Die einfache Durchschnittsrechnung ergibt 12 / 100 = 0,12 Sekunden je registrierter Ausführung. Child 1 ergibt 8 / 20 = 0,4 Sekunden. Das ist eine erste Zusammenfassung der Lebensdauerwerte im Cache, kein Beweis für die Laufzeit einer bestimmten letzten Ausführung.

Auch BUFFER_GETS und DISK_READS sind hier kumuliert. Unterschiedliche Cursorlebensdauer, Bind-Werte, Ergebnisgrößen, Abbrüche und laufende Ausführungen können den Vergleich verzerren. END_OF_FETCH_COUNT unterstützt die Prüfung, wie viele Ausführungen vollständig bis zum Ende geholt wurden; auch gleiche Zähler garantieren keine identische Arbeitsmenge. Bei paralleler Ausführung hat ELAPSED_TIME zusätzliche Aggregationseigenschaften. Die Beispielrechnung ist für den hier angenommenen seriellen Betrieb gedacht.

Die verschiedenen PLAN_HASH_VALUE-Werte weisen auf unterschiedliche Planstrukturen hin. Die Kennung ist kein vollständiger Fingerabdruck aller Prädikate, Bind-Werte oder Laufzeitbedingungen. IS_BIND_SENSITIVE und IS_BIND_AWARE beschreiben den Cursorstatus bezüglich Bind-Sensitivität und adaptivem Cursor Sharing; ein Y ist kein Fehlerstatus. Wähle für die nächste Abfrage SQL_ID und CHILD_NUMBER gezielt aus.

Die Identität ist wichtig: Ein anderer Child Cursor kann einen anderen Plan oder andere Bind-Eigenschaften haben. Die letzte verfügbare Ausführung dieses Cursors muss außerdem nicht die vom Anwender gemeldete langsame Ausführung sein. Kontrolliere den zeitlichen Zusammenhang und lies Notes sowie Predicate Information mit. Adaptive Pläne können inaktive Alternativen enthalten; diese dürfen nicht als vollständig ausgeführte Zusatzarbeit interpretiert werden.

Spaltenbedeutung: Id identifiziert die Planoperation, nicht ihre chronologische Ausführungsreihenfolge. Operation nennt den Arbeitsschritt und Name das zugehörige Objekt, soweit vorhanden. Starts zählt die Starts einer Operation im betrachteten Messumfang. E-Rows ist ihre geschätzte Ausgabezeilenzahl; A-Rows zeigt die tatsächlich gelieferten Zeilen des Messumfangs. „—“ steht im Beispiel für einen nicht ausgewiesenen Wert.

Hier startet der Indexzugriff einmal. Geschätzt wurden 10 Treffer, beobachtet wurden 10.000. Die Abweichung beträgt den Faktor 1.000 (10.000 geteilt durch 10). Die Operation über dem Index lädt diese Treffer aus ORDERS nach. Eine sinnvolle erste Hypothese lautet deshalb: Die angenommene Filterwirkung war für diese Ausführung wesentlich zu hoch. Prüfe das konkrete Prädikat, den Datentyp, die verwendeten Bind-Werte und den Statistikbezug. Der Zahlenunterschied beweist noch nicht, dass eine Statistikerneuerung die richtige Maßnahme ist.

Die 50 Buffers beim Index und 24.000 Buffers bei der Tabellenoperation lenken den Blick auf das Nachladen der Tabellenzeilen. Messwerte übergeordneter Operationen können Arbeit untergeordneter Schritte enthalten. Addiere deshalb nicht alle Zeilen der Anzeige zu einer vermeintlichen Gesamtarbeit. Für diesen Ausschnitt dürfen insbesondere die 24.000 bei Id 0 und Id 1 nicht zweimal gezählt werden.

Der äußere Zugriff liefert 2.000 Kunden statt geschätzter 20. Der innere Indexzugriff startet deshalb 2.000-mal und liefert insgesamt 6.000 Zeilen. Für diesen einfachen Fall ergibt A-Rows / Starts = 6.000 / 2.000 = 3 Zeilen pro Start. Die innere Schätzung von 3 Zeilen passt damit zur durchschnittlichen tatsächlichen Trefferzahl pro Start.

Ein direkter Vergleich „E-Rows 3 gegen A-Rows 6.000“ würde die innere Schätzung irrtümlich als stark falsch darstellen. Das eigentliche frühe Schätzproblem liegt hier beim äußeren Zugriff: Er liefert hundertmal so viele Kunden wie angenommen. Genau dadurch vervielfacht sich die Zahl der inneren Zugriffe. Suche deshalb die erste relevante Abweichung im Datenfluss, bevor du die letzte auffällige Planzeile zum Verursacher erklärst.

Diese Normalisierung ist eine Interpretationshilfe für den dargestellten einfachen Nested-Loops-Fall. Bei parallelen, adaptiven oder komplexer wiederholt gestarteten Operationen müssen Ausführungsumfang und Planform zusätzlich berücksichtigt werden.

Buffers beschreibt logische Buffer-Zugriffe im jeweiligen Planmessumfang. Viele logische Zugriffe können CPU und Speicherarbeit verursachen, selbst wenn nur wenige physische Reads nötig sind. Reads bezeichnet physische Lesezugriffe im angezeigten Messkontext; das sind nicht automatisch dieselben Zähler wie DISK_READS aus einer separat gelesenen V$SQL-Zeile. Quelle, Zeitraum und Aggregation müssen zusammenpassen.

Eine Abfrage mit vielen Buffers und wenigen Reads kann trotzdem langsam sein. Eine Abfrage mit vielen Reads kann bei großem, sinnvoll angefordertem Datenumfang normal sein. Erst die Verbindung mit Laufzeit, gelieferter Datenmenge und gegebenenfalls beobachteten Waits erklärt den Aufwand. Ein warmer Cache kann Reads reduzieren, ohne dass der gewählte Arbeitsweg oder seine logische Arbeit geändert wurde.

A-Time in einer Plananzeige ist ein Laufzeitmesswert der Operation im dargestellten Umfang. Zeiten verschachtelter Schritte dürfen ebenfalls nicht blind addiert werden. Ein niedriger Cost und eine hohe gemessene Laufzeit sind kein Widerspruch: Das erste ist ein Modellwert, das zweite ein beobachteter Ablauf unter konkreten Bedingungen.

PARENT_ID macht die Beziehung sichtbar: Operation 2 liefert an Operation 1, diese an Operation 0. Die Zusammenfassung von LAST_CR_BUFFER_GETS und LAST_CU_BUFFER_GETS berücksichtigt konsistente und aktuelle Buffer-Zugriffe. Die verwendeten LAST_-Spalten beziehen sich auf den zuletzt verfügbaren Ausführungsumfang dieses Cursors. LAST_ELAPSED_TIME wird von Mikrosekunden in Sekunden umgerechnet. Die beiden übergeordneten Zeiten enthalten überlappende Arbeit und dürfen nicht addiert werden. NULL oder fehlende Messwerte sind keine gesicherte Aussage „keine Arbeit“.

Die Abfrage ist eine alternative Darstellung der gleichen Messgrundlage, keine unabhängige Gegenmessung zur Plananzeige. Sie erklärt daher die zusätzlichen Spalten und die Hierarchie; die Interpretation der 10 gegenüber 10.000 Zeilen steht bereits in Abschnitt 8. Wenn der Cursor aus dem Cache entfernt wurde, kann die Abfrage keine Zeilen liefern. Das beweist weder einen Fehler der SQL-Anweisung noch, dass sie nie ausgeführt wurde.

Ein Plan entsteht im Kontext seiner Optimizer-Umgebung, Objektmetadaten und Bind-Eigenschaften. Ein späterer Hard Parse kann unter anderen Bedingungen eine andere Entscheidung treffen. Geänderte Statistiken oder Objektstrukturen können ebenfalls relevant sein. Mehrere Child Cursor bedeuten jedoch nicht automatisch mehrere unterschiedliche Planstrukturen; prüfe Child Number, Plananzeige und Kontext gemeinsam.

Bind Peeking kann beim Hard Parse einen vorhandenen Bind-Wert in die Schätzung einbeziehen. Wenn verschiedene Werte sehr unterschiedliche Trefferzahlen besitzen, kann eine für einen Wert günstige Strategie für einen anderen Wert teuer sein. Adaptive Cursor Sharing kann dafür unterschiedliche geeignete Cursorvarianten entstehen lassen. Das bedeutet nicht, dass Oracle für jeden Bind-Wert zwingend einen neuen Plan erstellt.

Eine Laufzeitänderung beweist umgekehrt keinen Planwechsel. Derselbe Plan kann mit anderen Ergebnisgrößen, Cachezuständen, I/O-Zeiten oder konkurrierender Last anders laufen. Ein gemeldeter langsamer Lauf muss deshalb sowohl mit seiner Planidentität als auch mit seinem tatsächlichen Ausführungsumfang verbunden werden.

Bei der bestehenden Überweisung werden 100 Euro von einem Konto abgebucht und einem anderen gutgeschrieben. Beide Anweisungen müssen innerhalb derselben fachlichen Arbeitseinheit liegen. Die Datenbank kann die beabsichtigte Zusammengehörigkeit nicht allein aus den beiden Beträgen erkennen.

Eine Transaktion kann mehrere einzelne Anweisungen enthalten. Eine erfolgreich ausgeführte Änderung ist deshalb nicht automatisch schon dauerhaft bestätigt. Die Anwendung bestimmt, wann das Arbeitspaket abgeschlossen wird. Manche Programme bestätigen automatisch nach jedem Schritt; diese Einstellung heißt Autocommit.

Ein Savepoint ist wie ein Lesezeichen, nicht wie ein fertig gespeichertes zweites Paket. Erst das abschließende Bestätigen macht die Arbeit dauerhaft. Ein späteres Rollback kann eine bereits bestätigte Überweisung nicht einfach rückgängig machen.

Diese Begriffe werden hier nur erklärt. Das Wiki führt keine Überweisung, Änderung oder Bestätigung aus.

Anna und Ben arbeiten mit derselben Datenbank. Der bestätigte Betrag einer Beispielzeile ist 100. Anna ändert ihn auf 120, bestätigt aber noch nicht. Anna sieht ihre eigene Änderung bereits. Ben sieht weiterhin 100.

Das verhindert, dass Ben einen unfertigen Zwischenstand übernimmt. Bestätigt Anna ihre Änderung, kann Bens danach neu gestartete Abfrage 120 sehen. Nimmt Anna ihre Änderung zurück, bleibt der bestätigte Wert 100.

Eine Abfrage soll ein zusammenpassendes Ergebnis liefern. Deshalb liest sie nach festen Regeln einen Datenstand. Stell dir diesen Stand wie eine Momentaufnahme vor. Oracle nennt ihn einen Snapshot; es wird dafür jedoch nicht jedes Mal eine vollständige Kopie aller Tabellen angelegt.

Ben startet einen langen Bericht, während der Wert noch 100 ist. Anna bestätigt währenddessen 120. Bens bereits laufender Bericht wechselt dadurch nicht mittendrin auf den neuen Stand. Ein danach gestarteter Bericht kann den neuen Wert berücksichtigen.

Dieses Verhalten heißt Read Consistency, also konsistentes Lesen. „Konsistent“ bedeutet hier: Die Daten passen zu dem für die Abfrage geltenden Stand. Es bedeutet nicht: Jede Anzeige zeigt jederzeit den allerneuesten Wert.

Wenn Daten geändert werden, bewahrt Oracle Informationen zum früheren Zustand auf. Diese Informationen heißen UNDO. Sie helfen sowohl beim Zurücknehmen offener Änderungen als auch beim Lesen eines passenden älteren Standes.

Oracle ordnet Datenstände mit einer internen Nummer ein, der SCN. Du kannst sie dir als logische Fortschrittsmarke vorstellen. Sie ist keine Uhrzeit und wird nicht in Sekunden gemessen. Für das Grundverständnis reicht: Oracle kann erkennen, welche Version zur Abfrage gehört.

Wie UNDO gespeichert wird, erklärt das UNDO-Kapitel. Hier bleibt der Schwerpunkt auf dem sichtbaren Verhalten.

Im üblichen Oracle-Verhalten bekommt jede neue Abfrage ihren eigenen Lesestand. Die erste Abfrage von Ben kann 100 zeigen. Bestätigt Anna danach 120, kann Bens zweite Abfrage 120 zeigen. Beide Ergebnisse sind richtig für ihren jeweiligen Zeitpunkt.

Konsistent lesen verhindert nicht jedes Überschreiben. Die Lesesicht schützt den Zusammenhang einer Abfrage. Sie reserviert die gelesenen Zeilen aber nicht automatisch für eine spätere Änderung. Wenn eine Anwendung erst liest und später einen aus diesem alten Stand berechneten Wert zurückschreibt, kann sie inzwischen bestätigte Änderungen überdecken. Oracle bezeichnet dieses Anwendungsproblem als Lost Update. Eine passende Konfliktprüfung beim Schreiben oder eine bewusst eingesetzte Sperrstrategie gehört deshalb zum Transaktionsentwurf. ACID und automatisch vergebene Row Locks ersetzen diese fachliche Entscheidung nicht. Oracle 19c.

Der Fachname für dieses übliche Verhalten ist READ COMMITTED: Gelesen werden bestätigte Daten, wobei die eigene offene Arbeit der jeweiligen Session berücksichtigt wird. Eine Session ist der logische Arbeitskontext einer Anmeldung in Oracle. Die Verbindung ist der Kommunikationsweg zur Instanz; beides ist technisch zu unterscheiden. Im einfachen Beispiel arbeitet jede Verbindung mit einer Session.

Es gibt auch Arbeitsweisen, die mehrere Abfragen innerhalb eines Arbeitspakets auf einen gemeinsamen älteren Stand beziehen. Dazu gehört SERIALIZABLE. Wenn dort eine konkurrierende Änderung nicht passt, kann Oracle einen Konflikt melden. Die Anwendung muss damit richtig umgehen. Das ist ein Vertiefungsthema, keine Voraussetzung für die ersten Beispiele.

ACID ist eine Abkürzung für vier Eigenschaften von Transaktionen. Die Namen sind englisch; die Grundidee ist einfach:

Die Regeln garantieren nicht, dass jede fachliche Entscheidung richtig ist. Wenn die Anwendung den falschen Empfänger auswählt, kann die Überweisung technisch korrekt und trotzdem fachlich falsch sein.

Ben liest sehr lange an seinem Bericht. Währenddessen ändern andere Benutzer weiter Daten. Für einige Stellen braucht der Bericht deshalb ältere Informationen. Sind die benötigten alten Informationen nicht mehr verfügbar, kann Oracle den passenden Stand nicht vollständig herstellen.

Die Meldung heißt ORA-01555: Snapshot too old. Sie bedeutet nicht, dass Ben ein altes Programm benutzt. Es fehlen Informationen für die benötigte ältere Datenversion. Laufzeit, Änderungen im gleichen Zeitraum und UNDO-Situation werden zusammen untersucht.

Eine einzelne Zahl oder ein häufiger Commit ist keine allgemeine Lösung. Die passende Diagnose steht in der folgenden aufklappbaren Vertiefung.