Quick Links



Keywords

ORA-01555 snapshot too old

ORA-01555 – eine der wohl bekanntesten Oracle Fehlermeldungen.

Siehe auch Warum Sie das ORA-01555 Problem lösen sollten.

Spätestens die Erkenntnis, dass auch ein sehr hoher Wert für undo_retention das Auftreten des Fehlers nicht verhindert, lässt den Oracle Administrator meist ratlos zurück.

Die oraservices.de Oracle Support Services bieten Unterstützung zur Analyse und Lösung des Problems.

Beispiele der Unterstützung durch oraservices.de finden Sie auf den oraservices.de Projektseiten .

Das oraservices.de Monitoring Package für Oracle Datenbanken enthält auch ein Modul zur proaktiven Analyse des ORA-01555 Fehlers.

ORA-01555

Die Fehlerbeschreibung ist für Datenbank-Administratoren nicht unbedingt selbsterklärend.

01555, 00000, “snapshot too old: rollback segment number %s with name \”%s\” too small”
// *Cause: rollback records needed by a reader for consistent read are
// overwritten by other writers
// *Action: If in Automatic Undo Management mode, increase undo_retention
// setting. Otherwise, use larger rollback segments

Was bedeutet „snapshot too old“?

Ein snapshot too old Error entsteht meistens durch mindestens 2 gleichzeitige Sessions. Kurz und ungenau ausgedrückt: Eine Update Session ändert das, was ein Select gerade (konsistent) lesen will. Nur, wenn Sie das Zusammenspiel, die Laufzeiten und die Datenmengen dieser Sessions betrachten, kommen Sie dem Problem und einer Lösung auf die Spur.

Bei Auftreten des Fehlers findet sich im Alertlog eine Mitteilung, die ähnlich aussieht, wie die Folgende:

ORA-01555 caused by SQL statement below (Query Duration=851 sec, SCN: 0x0000.0894299b):
Mon Oct 13 12:09:19 2003
SELECT a1, a2, … FROM t …

Das aufgeführte Select Statement ist jedoch, anders als im Alertlog beschrieben, nicht der Verursacher des Fehlers. Vielmehr bricht die Query ab, weil ein oder mehrere DML Statements gleichzeitig viele Änderungen im Datenbereich des Select Statements vornehmen.

Beispiel

ORA-01555 gleichzeitiges Select und Update

Ein Update Statement wird gestartet; kurz danach ein Select Statement. Beide SQL Statements arbeiten auf Tabelle T mit 10.000.000 Zeilen und dauern einige Zeit. Das Update ändert 50 Prozent der Zeilen von T. Das Select liest einige dieser Tabellenblöcke und findet geänderte Daten, die allerdings zum Startzeitpunkt des Selects noch nicht committet waren. Um die Datem in einem konsistenten Zustand ausgeben zu können muss das Select die Daten so rekonstruieren, wie sie zum Startzeitpunkt gültig waren. Da das Update diese Daten im Undo Tablespace abgelegt hat (um bei einem rollback den vorherigen Zustand wieder herstellen zu können), kann sich das Select für diese Rekonstruktion aus den Undo Daten bedienen.

Jedoch: auch der Platz im Undo Tablespace ist begrenzt. Daher werden Undo Daten bei Bedarf überschrieben. Ist nun die Undo Information, die das Select Statement benötigt, schon überschrieben worden, bricht das Select Statement mit einem ORA-01555 ab und liefert kein Ergebnis. Nach einer Laufzeit von mehreren Stunden ist dies besonders ärgerlich.

Typische Kandidaten für einen ORA-01555 sind Oracle Exports, die mit der Option „consistent“ gestartet wurden und lang andauernde Select Statements in Datenbank Systemen, die starken Änderungen unterliegen.

The Rules

Die Regeln zum Management des Undo Tablespaces erscheinen auf den ersten Blick nicht wirklich intuitiv und einsichtig:

(1) Nach Überschreiten der voreingestellten Zeit muss man damit rechnen, dass Undo Informationen überschrieben wird.
(2) Wenn kein Platz im Undo Tablespace mehr verfügbar ist, wird Undo Information auch vor Ablauf der voreingestellten Zeit überschrieben. Leider teilt die Oracle Datenbank nicht mit, wenn sie dies tut.
(3) Ab Oracle 10g lässt sich (optional) sicherstellen, dass Undo Informationen niemals vor Ablauf der voreingestellten Zeit Überschrieben wird. Sind keine hinreichend alten Undo Blöcke mehr verfügbar, bricht das DML Statement mit einem Fehler ab.

Monitoring ORA-01555

Das geringe Mitteilungsbedürfnis des Datenbanksystems beim Handling der Undo Segments macht ein eigenes Monitoring dringend erforderlich oder zumindestens sinnvoll. Der Ressourcen-Engpass lässt sich dann rechtzeitig mitteilen (EMail, SMS) und eine zeitnahe Reaktion vermeidet den Fehler.
Zudem erlauben die Monitoring Daten eine sinnvolle Dimensionierung des Undo Tablespaces.

Allerdings: Beim Undo Tablespace führt die typische Überwachung des Füllstandes aus Tablespace Sicht (Summe der reservierten Blöcke) zu Fehlalarmen, da die Reservierung und Freigabe der Blöcke dem Management der Datenbank obliegt. Relevant für die Überwachung sind hier die noch nicht beschriebenen Blöcke und die, deren voreingestellte Aufbewahrungszeit überschritten wurde.

Ohne eine automatisierte Beobachtung (Monitoring) dieses Phänomens dürfte es schwierig sein, die Rahmenbedingungen so einzustellen, dass ein ORA-01555 nicht mehr auftritt.

Die Einrichtung von Monitoring Funktionalitäten ist ein zentraler Bestandteil für einen fehlerfreien Betrieb Ihrer Oracle Datenbank. Die oraservices.de Monitoring Packages umfassen unverzichtbare Überwachungsfunktionen zur Absicherung Ihrer Datenbank vor Fehlern und Ausfällen.

Interesse? Nehmen Sie Kontakt auf.

Siehe auch Monitoring Package Download.

Zeitmaschine?

Nicht selten findet sich eine Zeile ähnlich der folgenden im Alertlog der Oracle Datenbank:

ORA-01555 caused by SQL statement below (Query Duration=1194070077 sec, SCN: 0x0000.48835c43):

Hier wurde nicht etwa die Query vor 37 Jahren, also lange vor Installation der Datenbank, bzw. vor Gründung der Oracle Corp. abgeschickt. Es handelt sich bei der Zeitangabe schlicht um einen Bug (vermutlich ein Buffer Overflow).

It’s a Feature

Auch, wenn das Handling des Undo Bereiches Wünsche offen lässt: ORA-01555 ist das Resultat eines Features, das in anderen Datenbanksystemen häufig extreme Wartezustände erzeugt. Vielfach wird Datenkonsistenz bei DML Aktionen durch exklusive Tabellensperren erzwungen. Bei dem oben beschriebenen Update bedeutet das, dass auf den entsprechenden Daten „nichts mehr geht“; handelt es sich um zentrale Informationen, die häufiger von Sessions gelesen werden, steht die Datenbank häufig für alle anderen Sessions still.
Die beschriebene Datenrekonstruktion mit Hilfe der Undo Informationen lässt gleichzeitige Zugriffe und umgeht so diese Tabellensperren.

Comments are closed.