Vollständige Aufzeichnung des DB2-Deadlock-Auflösungsprozesses

DB2 wird hauptsächlich in großen Anwendungssystemen verwendet. Es verfügt über eine gute Skalierbarkeit und kann alles von Mainframe- bis hin zu Einzelbenutzerumgebungen unterstützen. DB2 bietet Datennutzung, Integrität, Sicherheit und Wiederherstellbarkeit auf hohem Niveau. In diesem Artikel wird hauptsächlich die vollständige Aufzeichnung des Deadlock-Auflösungsprozesses in diesem Artikel vorgestellt. Der Verarbeitungsprozess ist ziemlich schwierig 🎜> in der Produktionsumgebung wird DB2 verwendet. Allerdings ist in letzter Zeit häufig ein seltsames Deadlock-Phänomen aufgetreten: Eine bestimmte Select-SQL-Anweisung führt immer zu einem Deadlock.
Nach bisherigen Erfahrungen führen Update-SQL-Anweisungen wie „Update/Delete“ normalerweise zu Deadlock-Problemen. Und diese Select-SQL-Anweisung ist eine ganz normale SQL-Anweisung ohne große Datenverarbeitung.

Wenn man diesen Stillstand analysiert, gibt es viele Dinge, die schwer zu bewältigen sind.

1. Aufgrund der großen Datenmenge in der Produktionsumgebung können wir die Daten der Zuordnungstabelle in der Produktionsumgebung nicht in die Testumgebung importieren. Das heißt, die Datenmenge kann nicht simuliert werden.

2. Es erfolgt keine Protokollausgabe. Weil die Protokollausgabestufe der Produktionsumgebung FEHLER ist.

3. Es kann nicht in der Produktionsumgebung getestet werden, da der Kunde dies nicht zulässt.

4. Die Datenbank in der Produktionsumgebung kann keine Snapshots und andere Funktionen ermöglichen. Weil es die Leistung beeinträchtigt.

Wie Sie sich vorstellen können, kann die Deadlock-Analyse ohne Funktionen wie Snapshots nur auf der Code-Analyse beruhen. Dieser Prozess ist jedoch sehr kompliziert und allein durch die Analyse des Codes erhält man keinen Hinweis.

Stufe 1: Wir vermuten, dass es an der Datenmenge liegt

Aufgrund der extrem großen Datenmenge in der Produktionsumgebung beinhaltet dieser Prozess auch die Verarbeitung von vielen anderen Tischen. Wir fragen uns also, ob die große Datenmenge zu einer Überlastung des Systems und damit zu einem Deadlock geführt hat? Also haben wir die Auslastungsinformationen von CPU, Festplatte, Netzwerk usw. erhalten, als der Deadlock auftrat. Es wurden keine Hinweise gefunden.

Phase 2: Erstellen Sie ein Testprogramm und verwenden Sie Multithreading, um mehrere Benutzer in der Testumgebung zu simulieren, um diese Verarbeitung durchzuführen.


Um diesen Deadlock in der Entwicklungsumgebung zu reproduzieren, haben wir ein Multithread-Testprogramm erstellt, um den Mehrbenutzerbetrieb zu simulieren. Leider wurde es immer noch nicht reproduziert.
Phase 3: Analysieren Sie den Unterschied zwischen der Testumgebungsdatenbank und der Produktionsumgebungsdatenbank
Zu diesem Zeitpunkt vermuten wir, dass das Problem immer noch durch die Datenmenge verursacht wird. Deshalb haben wir unser Bestes gegeben, um in der Entwicklungsumgebung genauso viele Daten wie in der Produktionsumgebung zu haben.
Nachdem der Test ausgeführt wurde, konnte er immer noch nicht reproduziert werden.


Stufe 4: Analysieren Sie das Betriebsprotokoll des Benutzers


Da es keine andere Lösung gibt, müssen wir das Betriebsprotokoll des Benutzers analysieren, in der Hoffnung, einige Hinweise zu finden. Harte Arbeit zahlt sich aus, und wir haben festgestellt, dass es grundsätzlich zu einem Deadlock kommt, wenn zwei Personen diesen Vorgang gleichzeitig ausführen. Daher gehen wir davon aus, dass das Problem dadurch verursacht wird, dass zwei Personen gleichzeitig arbeiten. Warum simuliert die Entwicklungsumgebung jedoch die Vorgänge
vieler Personen, ohne dass ein Deadlock auftritt?

Phase 5: Erkennen von Datenbankeinstellungsproblemen


Wir haben das Testprogramm geändert, um die Anzahl der simulierten Benutzer zu erhöhen, aber leider wurde das Problem nicht reproduziert. An dieser Stelle ist uns aufgefallen: Unterscheiden sich die Datenbankeinstellungen der Entwicklungsumgebung von denen der Produktionsumgebung? Wir verglichen die Einstellungen der beiden Datenbanken und stellten fest, dass viele Parameter unterschiedlich waren. Wir haben uns jedoch nur auf die sperrbezogenen Einstellungen
konzentriert, also auf die Einstellungen, die das Schlüsselwort LOCK enthalten.

Stufe 6: Halten Sie die Einstellungen der Testumgebungsdatenbank und der Produktionsumgebungsdatenbank konsistent


Wir haben alle sperrenbezogenen Einstellungen geändert, um sie mit der Produktionsumgebung konsistent zu machen. Der Deadlock wird jedoch immer noch nicht reproduziert. Schließlich entdeckte jemand, dass die Einstellung „cur_commit“ anders war. Also habe ich die Dokumentation abgefragt und die Eigenschaften von cur_commit entdeckt.
Wenn cur_commit = false, führt die folgende Situation zu einem Deadlock: Thread 1 fügt Daten A ein und dann fügt Thread 2 Daten B ein.
Bevor Thread 2 die Transaktion übermittelt hat, fragt Thread 1 Daten A ab, was zu einem Deadlock führt.
In der Entwicklungsumgebung ist cur_commit = true, daher konnten wir dieses Phänomen nie simulieren.
Also haben wir cur_commit in false geändert.


Phase 7: Verwenden Sie das Testprogramm zur Simulation


Wir haben das Testprogramm geändert, um die Vorgänge der beiden oben genannten Threads zu simulieren, und den Deadlock erfolgreich reproduziert. Die Fehlerprotokollinformationen stimmen auch mit der Produktionsumgebung überein.
Stufe 8: Verwenden Sie Bildschirmoperationen zur Simulation


Dann haben wir das Programm geändert, Bildschirmoperationen verwendet und den Deadlock erfolgreich reproduziert.
Lösung:
Die Lösung ist sehr einfach: Fügen Sie die Bedingungen in der Abfrageanweisung als Indizes hinzu, damit kein Deadlock auftritt.
Da das Datenvolumen dieser Tabelle nicht groß ist, gibt es nahezu keine Auswirkungen auf die Leistung.



Verwandte Empfehlungen:

Detaillierte Erläuterung der Methode der Offline-Installation von db2 mit dem Python-Modul ibm_db

Python Verbindung zur DB2-Datenbank

Fünf Möglichkeiten, PHP zum Betrieb von DB2 Express C (1) zu verwenden_PHP-Tutorial

Das obige ist der detaillierte Inhalt vonVollständige Aufzeichnung des DB2-Deadlock-Auflösungsprozesses. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!