Deadlock in Datenbanken – was ist das und wie löst man ihn?
14/3/2024
Tomasz Chwasewicz
Ein Deadlock tritt auf, wenn zwei oder mehr Transaktionen in einem Datenbanksystem Ressourcen sperren, die andere benötigen. Jede Transaktion wartet darauf, dass die anderen ihre Sperren aufheben, und genau wie zwei Fahrer, die sich nicht sicher sind, wer Vorfahrt hat, kann keiner weitermachen.
Es wäre toll, die Ursachen der Staus aufzählen und sie alle behandeln zu können. Leider ist das zu kompliziert. Man kann jedoch sagen, dass sie in erster Linie auf ein schlechtes Anwendungsdesign, das Fehlen eines angemessenen Transaktionsmanagements oder die unvermeidliche Komplexität hochgradig paralleler Systeme zurückzuführen sind.
Transaktionen, bei denen Vermögenswerte in inkonsistenten Reihenfolge gesperrt werden, sind besonders anfällig für Blockierungen. Wenn beispielsweise Transaktion A Asset 1 sperrt und dann versucht, Asset 2 zu sperren, während Transaktion B Asset 2 sperrt und dann versucht, Asset 1 zu sperren, bleibt sie hängen, wenn beide Transaktionen gleichzeitig stattfinden.
Das ist eine interessante Sache - Oracle macht das nicht, zumindest nicht im Kern. Anstatt den Kern des Problems anzugehen, ermöglicht es die Ausführung eines Trades und zieht einen anderen zurück.
Wenn Oracle einen Deadlock feststellt, wird die Transaktion nicht in der Warteschleife belassen. Stattdessen wählt es eine der Transaktionen als „Opfer“ aus und zieht sie zurück, wodurch die blockierten Ressourcen freigegeben werden. Diese Aktion ermöglicht es anderen Transaktionen, weiter zu funktionieren. Die Entscheidung, welche Transaktion zurückgezogen werden soll, basiert in der Regel auf internen Kriterien, die darauf ausgelegt sind, Arbeitsverluste zu minimieren und die Systemintegrität aufrechtzuerhalten.
Nachdem der Deadlock behoben wurde, protokolliert Oracle den Vorfall, indem es den ORA-00060-Fehler im Alertlog zusammen mit einer Trace-Datei generiert, die detaillierte Informationen über die Pattsituation enthält. Diese Trace-Datei enthält die beteiligten SQL-Anweisungen, gesperrte Objekte und Transaktions-IDs und bietet wertvolle Einblicke in die Diagnose der Ursache des Staus.
Deadlocks stellen eine große Herausforderung für DBA dar, hauptsächlich aufgrund ihrer schwer fassbaren Natur und der Komplexität, die mit ihrer Diagnose und Lösung verbunden ist. Warum? - wir werden diese Frage gleich beantworten.
Einer der Hauptgründe, warum Deadlocks für DBA ein Albtraum sind, ist, dass sie für Entwickler unsichtbar sind. Sie treten tief in der Datenbankinfrastruktur auf, verbrauchen Serverressourcen und beeinträchtigen die Datenbankleistung, ohne dass auf der Anwendungsebene ein ersichtlicher Grund vorliegt. Das macht sie zu einem schrecklichen Problem: aktuell und einflussreich, aber schwer zu erkennen und zu beseitigen.
Das Problem der Unsichtbarkeit wird durch die Tatsache verschärft, dass Deadlocks in der Regel ein Symptom für Probleme auf Anwendungsebene sind — wie schlechtes Design oder Transaktionsmanagement —, die sich in der Datenbankumgebung manifestieren. Dadurch steht DBA an vorderster Front. Sie sind oft die ersten, die auf diese Probleme stoßen, aber ihre Ursache liegt im Anwendungscode, auf den sie keinen direkten Einfluss haben.
Die Replikation und Diagnose von Störungen ist eine weitere Herausforderung. Dies liegt hauptsächlich daran, dass sie in einer unproduktiven Umgebung schwer vorherzusagen und zu reproduzieren sind. Störungen sind oft auf einen ganz bestimmten Zeitpunkt und eine bestimmte Abfolge von Vorgängen zurückzuführen, die sich nur schwer absichtlich nachahmen lassen. In der lokalen Entwicklerumgebung, in der die Last und die Parallelität viel geringer sind als in der Produktionsumgebung, kommt es möglicherweise nie zu einem Deadlock.
Diese Unvorhersehbarkeit bedeutet, dass die Entwickler in 99,99% der Fälle (Quelle: Trust Us) nicht mit dem Auftreten von Staus rechnen. Aus diesem Grund sind Anwendungen oft nicht für den Umgang mit Staus konzipiert. Daher sind wir manchmal mit seltsamen, einmaligen Fehlern konfrontiert, die nur schwer mit einem Stau in Verbindung gebracht werden können, was die Angelegenheit weiter verdunkelt.
Wenn Staus auftreten, können sie zu unerwartetem Anwendungsverhalten führen, was zu Fehlern oder Leistungsproblemen führt, die schwer zu diagnostizieren sind. Da die App nicht darauf vorbereitet war, die Staus zu lösen, können diese Probleme zufällig erscheinen und sowohl für Benutzer als auch für Technikteams, die versuchen, sie zu beheben, zu frustrierenden Erfahrungen führen.
Darüber hinaus wird die Datenbank häufig für diese durch die Anwendung verursachten Probleme verantwortlich gemacht, was den DBA in eine schwierige Lage bringt. Sie müssen nicht nur Deadlock-Symptome erkennen und lösen, sondern auch mit den Entwicklungsteams kommunizieren, um Probleme im Anwendungscode zu lösen.
Gönnen wir uns eine Schweigeminute für alle DBAs, die derzeit mit Deadlocks zu kämpfen haben, weil sie normalerweise nicht viel tun können.
Wenn es um Deadlocks geht, sind DBAs durch die Einschränkungen von Datenbankmanagementsystemen die Hände gebunden. Sie können unter anderem umfangreiche Protokolle generieren und analysieren, die kleinste Datenbanktransaktionen aufzeichnen. Diese Protokolle, die oft von enormer Größe sind, sind der Schlüssel zum Verständnis des Deadlocks. Der Schlüssel wird jedoch nicht mit einem Schloss oder einer Bedienungsanleitung geliefert. Es bietet keine direkte Lösung für das Problem.
Natürlich haben erfahrene DBAs ihre eigenen Skripte, um solche Fälle zu diagnostizieren und zu lösen, aber das ist fast geheimes Wissen.
Unter den begrenzten verfügbaren Interventionsmöglichkeiten besteht eine der entscheidendsten Maßnahmen, die ein DBA ergreifen kann, darin, Sitzungen zu beenden, die in einen Deadlock geraten sind. Zehn drastische Maßnahme, beschrieben vom Datenbankexperten Jonathan Lewis, beinhaltet die Auswahl einer „Opfer“ -Transaktion, die abgehoben werden soll. Dadurch wird der Stillstand durchbrochen und andere Transaktionen können fortgesetzt werden.
Es ist keine einfache Entscheidung, eine Sitzung zum Beenden auszuwählen. Es erfordert eine sorgfältige Abwägung des Arbeitsaufwands, der durch die Rücknahme der Transaktion entsteht, und der möglichen Auswirkungen auf das gesamte System und den Geschäftsbetrieb. Manchmal ist die Entscheidung eindeutig, beispielsweise wenn eine Transaktion eine andere in Bezug auf Verarbeitungszeit oder Wichtigkeit deutlich übertrifft. In anderen Fällen handelt es sich um eine Entscheidung, die unter dem Druck getroffen wird, die Systemintegrität aufrechtzuerhalten und Störungen zu minimieren.
Unter den vielen Funktionen von DBPLUS Performance Monitor, die Tabs „Locks“ und „Logs“ können sehr nützlich sein, wenn es um die Analyse von Stauszenarien geht.
