Sperrung aufgrund von Anwendungsproblemen: Fallstudie

Ausgangssituation

Werfen wir mit der DBPLUS PERFORMANCE MONITOR-Software einen Blick auf die Ladezeit vom 20. April. Wir stellen sofort fest, dass die Ladezeit der Abfrage zwar normalerweise zwischen 12 und 15 Sekunden pro Snapshot variiert, in einigen Zeiträumen jedoch ein signifikanter Sprung auf mehr als 2000 Sekunden erfolgt.

Eine solche Anomalie kann schwerwiegende Auswirkungen auf die Gesamtleistung der Datenbank haben. Die längere Bearbeitungszeit der Abfragen deutete darauf hin, dass das System auf ein tieferes, möglicherweise systemisches Problem hinwies. Dieses erste Ergebnis erforderte eine eingehendere Untersuchung der Ursachen dieser Verzögerungen, um den Problemlösungsprozess auf spezifische Leistungsengpässe auszurichten.

Auf dem Weg zur Identifizierung des Problems

Nach der Identifizierung von Anomalien bei der Verwendung der DBPLUS PERFORMANCE MONITOR-Software bestand der nächste logische Schritt darin, nach einer möglichen Korrelation von Sperren mit Ausführungen, Lesevorgängen von der Festplatte, Pufferschreibvorgängen usw. zu suchen. Doch erst nach der Analyse der Sperrenstatistiken wurde das Muster klar — es gab eine signifikante Überlappung von Momenten, in denen die Dauer von Abfragen zunimmt und wenn Probleme mit Blockaden zunehmen.

Detaillierte Analyse des Schlosses

Um eine gründliche Analyse zu starten, gehen wir zur Registerkarte Verlauf sperren, das alle Sperrenereignisse an einem bestimmten Tag aufzeichnet. Der Zweck dieses Abschnitts ist es, uns eine Chronologie der Ereignisse zu geben. Wir klicken auf einzelne Punkte auf der Zeitleiste, um auf umfassende Daten zu jedem Sperrenereignis zuzugreifen.

Wie werden wir die Analyse der Blockade durchführen:

• Zugang zu ausführlichen Informationen: Wenn wir einen bestimmten Punkt auf der Zeitleiste auswählen, erhalten wir mehr Details zu jedem Sperrenereignis. Dazu gehören der Zeitpunkt, zu dem die Sperre aufgetreten ist, ihre Dauer und die spezifischen Datenbankelemente, die betroffen waren.
• Analyse blockierter und ausstehender Sitzungen: Am wichtigsten sind nicht nur Sitzungen, die Sperren aktiv aufrechterhalten, sondern auch solche, die sich aufgrund dieser Blockaden in einem Wartezustand befinden. Für jede Sitzung werden wichtige Daten wie Sitzungs-ID, Status (aktiv, ausstehend, inaktiv) und die genaue Startzeit der Transaktion angezeigt.
• Analyse der Wartezeiten: Eine wichtige Funktion der Registerkarte Blockverlauf ist die Möglichkeit anzuzeigen, wie lange Sitzungen aufgrund von App-Abstürzen gewartet haben. Dies ist besonders nützlich, um Sitzungen zu identifizieren, die zu erheblichen Verzögerungen führen, und klare Ziele für weitere Untersuchungen oder sofortige Maßnahmen vorzugeben.

Analyse der Sitzung

Die fragliche Sitzung wurde in vielen Schnappschüssen durchweg als „inaktiv“ bezeichnet. Dieser Status gibt an, dass, während die Sitzung verbunden und die Transaktion initiiert wurde, über einen längeren Zeitraum keine aktiven Abfragen ausgeführt wurden. Die Sitzung begann um 11:55 Uhr zu handeln, zeigte aber in der ersten Beobachtung 257 Sekunden lang keine Aktivität. Nachfolgende Schnappschüsse deuteten darauf hin, dass diese Inaktivität andauerte und die Sitzung immer noch keine Abfragen durchführte. Durch diese anhaltende Inaktivität wurden Ressourcen ausgesetzt, während andere Trades blockiert wurden, was zu längeren Wartezeiten für andere Sitzungen führte.

Ursachenanalyse

Die Analyse ergab, dass die Anwendung des Benutzers ihre Transaktionen. Der inaktive Status der Transaktion deutete darauf hin, dass sie zwar initiiert, aber nicht aktiv bearbeitet wurde, da keine Abfragen ausgeführt wurden oder keine Befehle zum Abschluss der Transaktion, wie z. B. Genehmigung oder Rücknahme, vorliegen. Dieses Missmanagement der Transaktionen deutet darauf hin, dass die App möglicherweise nicht über robuste Richtlinien zur Fehlerbehandlung oder zum Timeout von Transaktionen verfügt, die eine längere Inaktivität verhindern könnten.

Auswirkungen auf das System

Eine unsachgemäße Behandlung von Transaktionen kann zu verschiedenen Problemen in der Datenbankumgebung führen, hauptsächlich durch das Erstellen unfreigegebener Sperren. In diesem Fall führte die unzureichende Verwaltung des Transaktionsstatus durch die Anwendung zu unnötigen Sperren von Ressourcen, die nicht aktiv genutzt wurden. Dies führte dazu, dass andere Transaktionen blockiert wurden und die Gesamtleistung des Systems beeinträchtigt wurde. Diese Situation verschlimmerte sich in Zeiten hoher Arbeitsbelastung, als die kumulative Wirkung vieler ineffizienter Transaktionen den Betrieb des Systems verlangsamte.

Wie geht man damit um?

Es gibt viel zu tun, um solche Situationen in Zukunft zu verhindern:

• Implementieren Sie die Abfrageoptimierung: Überprüfen und optimieren Sie langsam laufende Abfragen. Verwenden Sie Indexierungsstrategien und optimieren Sie SQL-Abfragen, um die Ausführungszeit zu reduzieren und die Blockierung von Ressourcen zu reduzieren.
• Anpassen der Sperr-Timeout-Einstellungen: Stellen Sie geeignete Timeout-Einstellungen für Transaktionen ein, um lange Wartezeiten zu vermeiden. Dies kann Ihnen helfen, Trades, die zu Sperrungen führen, automatisch abzuschließen, wenn sie einen bestimmten Zeitschwellenwert überschreiten.
• INDurchführung des Lastenausgleichs: Verteilung der Datenbanklast auf mehrere Server oder Instanzen. Dies trägt dazu bei, die Auswirkungen umfangreicher Abfragen zu mildern und das Auftreten von Blockaden während der Spitzenzeiten zu reduzieren.
• Mechanismen zur Kontrolle der Parallelität: Implementierung fortschrittlicher Parallelitätskontrollmechanismen. Lösungen wie optimistische Parallelität oder Zeilenversionierung helfen Ihnen dabei, die Datenkonsistenz zu verwalten, ohne dass große Blöcke erforderlich sind.
• Regelmäßige Leistungsüberwachung: Verwenden Sie Tools häufiger Überwachung wie DBPLUS PERFORMANCE MONITOR. Sie sind unerlässlich, um Leistungsengpässe frühzeitig zu erkennen und proaktive Maßnahmen zu ergreifen, bevor sie sich auf die Systemleistung auswirken.