Quick Links



Keywords

ORA-00054 / ORA-00054 / ORA-54 Warten auf Godot

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

ORA-00054 verdient aufgrund seiner Hartnäckigkeit besondere Aufmerksamkeit.

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 helfen, Probleme und Fehler proaktiv zu vermeiden.

ORA-00054 Hintergrund

Sie möchten eine Tabellenänderung machen, aber die Tabelle ist durch Inserts / Updates / Deletes in schneller Folge oder durch extrem lange Updates blockiert?

Die Erklärung zur Oracle Fehlermeldung ist in diesem Fall nur bedingt hilfreich:

00054, 00000, „resource busy and acquire with NOWAIT specified“
// *Cause: Resource interested is busy.
// *Action: Retry if necessary.

oder Oracle 11g:

00054, 00000, „resource busy and acquire with NOWAIT specified or timeout expired“
// *Cause: Interested resource is busy.
// *Action: Retry if necessary or increase timeout.

Die klassische Ursache für einen ORA-00054: Es finden DMLs statt, z.B. uncommitted update oder insert, während Sie versuchen, auf dem gleichen Objekt ein DDL Kommando (z.B. alter table) durchzuführen.

Die Lösung: Sie brauchen ein Exclusive Lock für Ihr DDL Kommando.

Was tun?

Kurz warten, dann wieder probieren?
Funktioniert, wenn Sie Glück haben.

Lange warten, dann wieder probieren?
Vielleicht haben Sie ja damit Glück.

Vermutlich war das aber nicht der Fall.
Würden Sie sonst auf dieser Seite nach einer Problemlösung suchen?

Sie brauchen eine Strategie.

Das einfache Shell Script: Alles, was Sie manuell durchführen, kann eine Maschine auch. Schreiben Sie ein Shell Script, das Ihr DML Kommando ausführt und wiederholt, wenn es eine ORA-00054 Fehlermeldung erhält. Wartezeit zwischen den Versuchen ist sinnvoll, denn sonst wird ggf. Ihr Shell Script selbst zum Datenbank Problem.

Folgen Ihres DML Kommandos (z.B. invalid Packages) sollten Sie natürlich vorher auf einer Test-Datenbank überprüft haben und entsprechend in Ihrem Shell Script berücksichtigen.
Vergessen sollten Sie auch nicht, nach erfolgreicher Ausführung die Endlosschleife zu verlassen.

Das intelligente Shell Script: Jede Sperre hat einen Verursacher, auch in der Datenbank. Mit Hilfe der Dictionary Views v$locked_object und dba_objects lässt sich herausfinden, ob das von Ihnen zu ändernde Objekt noch gesperrt ist. Schreiben Sie ein Shell Script, das dies herausfindet und, wenn kein Hindernis mehr in Sicht ist, das DDL Kommando ausführt. Es gelten die Vorsichtsmaßnahmen, wie beim einfachen Shell Script.

Findet sich auf diese Weise kein geeigneter Zeitpunkt, kommen Sie unter Umständen nicht um eine der folgenden Maßnahmen herum:

Session beenden: User Session ermitteln (v$locked_object, v$session); User benachrichtigen und bitten, die Session zu beenden; im Notfall ALTER SYSTEM KILL SESSION (auf eigene Verantwortung, sagen Sie später nicht, ich hätte es erlaubt); ggf. warten, bis die Resourcen freigegeben sind; eigenes DDL durchführen; fertig.
Bei umfangreicheren Updates kann es durchaus einige Zeit dauern, bis die Resourcen frei werden.
Versuchen Sie, vor dieser Maßnahme sicherzustellen, dass nicht schon die nächste Session auf die Resource wartet.

Wartungsintervall: shutdown der Datenbank; startup restrict; eigenes DDL durchführen; shutdown; startup

In echten 24*7 Datenbanken ist ein Wartungsintervall per Definition nicht vorgesehen (einige Datenbanken werden jedoch nur vom Management als 24*7 bezeichnet und haben aber sehr wohl vorgesehene Wartungsintervalle).

In echten Hochverfügbaren Systemen werden ORA-00054 Probleme strategisch durch Rolling Upgrade Verfahren vermieden.

Weitere Stichworte:

DDL_LOCK_TIMEOUT
(Bitte beachten Sie, dass dieser Parameter in Oracle 11g nur für drop table statements funktioniert; Metalink Doc ID: 779569.1)

DDL_WAIT_FOR_LOCKS
(Bitte beachten Sie: Bug 4254209 – DDL_WAIT_FOR_LOCKS=TRUE HAS NO EFFECT)

Comments are closed.