TIP : Anti Blocker Strategien
zurück	Autor : Sancho Fock Eine sinnvolle Strategie zur Lösung von konkreten Blocking Problemen kann nur gefunden werden, wenn man sich klar macht, um was für eine Art von Blocksituation es sich handelt. Das offensichtlichste Kriterium, nach denen sich Bocksituationen einteilen lassen, ist ihre durchschnittliche Lebensdauer. Aufgrund dieser Einteilung ergeben sich folgende Kategorien: Kurzlebige Blocksituationen (short time scale blocks): Durchschnittliche Lebensdauer weniger als drei Sekunden Mittellange Blocksituationen (mid time scale blocks): Durchschnittliche Lebensdauer von 3 Sekunden bis maximal 10 Minuten Langlebige Blocksituationen (long time scale blocks): Durchschnittliche Lebensdauer mehr als 10 Minuten Deadlocks: Die Lebensdauer ist theoretisch unbegrenzt Im Folgenden sollen diese vier verschiedenen Arten von Blocksituationen hinsichtlich ihrer möglichen Ursachen und in Bezug auf angemessene Lösungsstrategien erörtert werden. Seitenanfang Short time scale Blocks In Multiuser Datenbanken kommt es zwangsläufig zu solchen Situationen; sie stellen normalerweise kein Problem für den Betrieb einer Anwendung dar. Dieser Art von Blocksituation sollte jedoch dann nachgegangen werden, wenn sie entweder bereits bei wenigen Usern auftritt oder wenn sie sehr häufig auftritt. Treten diese Blocksituationen sehr häufig auf, kann das zu Schneeballeffekten führen und das gesamte System lähmen. Auch wenn das Problem wahrscheinlich nicht vollständig gelöst werden kann, sollte zumindest versucht werden, es zu entschärfen. Ursachen: Short time scale Blocks, welche sehr häufig auftreten, lassen sich auf folgendes Grundproblem zurückführen: Für die vorhandene Userbelastung ist die Gesamtperformance des Systems zu niedrig. Lösungsstrategien: Dieser Problematik kann am besten dadurch begegnet werden, indem ein umfangreiches Performancetuning des Servers und der Applikation durchgeführt wird. Tritt diese Situation erst bei sehr hoher Userlast auf, beginnt man am Server und am Netzwerk mit der Untersuchung. Tritt diese Situation jedoch schon bei niedriger Userlast auf, sollte man untersuchen, ob sich bestimmte Use Cases der Client Anwendung konzeptionell gegenseitig oder selbst blockieren können. Sollte im konkreten Fall herausgefunden werden, daß dies so ist, dann muß untersucht werden, ob sich die Wahrscheinlichkeit des Auftretens dieser unerwünschten Situationen durch atomare Transaktionen, Verwendung von "row level locking" oder ähnlichem verringern läßt. Seitenanfang Mid time scale Blocks Diese Art von Blocksituation ist am schwierigsten zu finden. Sie dauert lange genug, um den Betrieb einer Anwendung zum Erlahmen zu bringen, ist aber meist zu kurz, um sie manuell analysieren zu können. Unterstützung bietet der THS Software SQL Guard 2000. Vom SQL Guard 2000 kann hier eine kostenlose Demoversion heruntergeladen werden. Ursachen: Die möglichen Ursachen für diese Art von Blocks sind die folgenden: (zu) Komplexe Transaktionen Extrem inperformante Abfragen in einer Transaktion Fehlerhafte Abfragen in Transaktionen (z.B. unbeabsichtigte Cross Joins) Userinteraktion innerhalb von Transaktionen (z.B. Messagebox "Daten wirklich löschen?") Unnötig zeitaufwendige Verarbeitung innerhalb von Transaktionen Unnötig verteile Verarbeitung mit hohem Datentransportvolumen Schneeballeffekt von short time scale blocks Lösungsstrategien: Wenn man - z.B. mit Hilfe des SQL Guards - die Transaktionen gefunden hat, welche andere Prozesse blockiert, muß isoliert werden, welche Art von Fehler vorliegt. Bei komplexen Transaktionen ergeben sich die folgenden Fragen: Kann die Transaktion vereinfacht werden? Kann die Transaktion aufgeteilt werden? Kann die Transaktion durch Performanceoptimierung stark beschleunigt werden? Kann die Transaktion zeitversetzt ausgeführt werden(z.B. ein nächtlicher Job)? Kann die Transaktion auch abgetrennte Ressourcen (z.B. temporäre Tabellen) nutzen, um die tatsächlichen Änderungen bei Erfolg konzentriert vorzunehmen? Kann der Datentransport innerhalb der Transaktion verringert werden (z.B. Verarbeitung in SP's auslagern)? Blockiert die Transaktion Ressourcen unnötiger Weise (z.B. select with locks auf Nachschlagetabellen)? Diese Fragen bieten Ansätze zur Lösung des Problems. Werden allerdings alle Fragen verneint, so muß die Situation entweder in Kauf genommen werden, oder es muß über die Geschäftsprozesse nachgedacht werden, do dass die problematischen Transaktionen ggf. ablöst werden könnten. Weitere Lösungsstrategien: Beinhaltet die Transaktion extrem inperformante Abfragen, substituieren sie diese durch schnellere. inden User Interaktionen - wie beispielsweise Messageboxen - während einer Datenbanktransaktion statt, so müssen diese beseitigt werden! User Interaktionen haben innerhalb von Datenbanktransaktionen absolut nichts verloren. Machen sie dies unbedingt auch ihren Clientprogrammierern klar. Insbesondere Programmierer, die von der Desktopdatenbankentwicklung kommen, haben häufig Probleme mit der Unterscheidung von Businesstransaktionen und Datenbanktransaktionen. Für unnötig zeitaufwendige Verarbeitungen innerhalb der Transaktion gilt das gleiche wie für komplexere Transaktionen. Sie können sich aber zusätzlich fragen: Muß diese Verarbeitung wirklich innerhalb der Transaktion stattfinden? Wenn innerhalb einer Transaktion viele Daten vom Server zum Client transportiert werden, kann sollte das minimiert werden. Die Verarbeitung einer Datenmenge x ist grundsätzlich auf dem Client genauso schnell wie auf dem Server. Das Bottleneck ist i.d.R. der Transport über das Netzwerk. Führen sie die Verarbeitungen also immer dort aus, wo die meisten notwendigen Informationen liegen. Beispiele: Braucht man nur die Anzahl bestimmter Datensätze (und nicht die Datensätze selbst) ist ein "select count(*)" immer schneller als der tollste Algorhytmus am Client (Denn der Client muss erst mal alle Daten über das Netzwerk erhalten). Benötigt eine SP hingegen Kilobyteweise Parameter, ist der Client vielleicht deutlich schneller. Liegt ein Schneeballeffekt vor, gehen sie nach den Strategien für short time scale blocks vor. Seitenanfang Long time scale Blocks Diese Blocks sind den mid time scale blocks sehr ähnlich. Grundsätzlich können sie auch die gleichen Ursachen haben, wie die mid time scale blocks. Zusätzlich können sie die folgenden Ursachen haben: Unbeabsichtigt nicht geschlossene Transaktionen und Endlosschleifen innerhalb von Transaktionen Für beide Gründe gilt, dass Ihre Lebensdauer in den Bereich von mid time scale blocks fallen können, wenn beispielsweise Transaktionstimeouts definiert wurden oder der Endanwender seinen Client abschießt. Lösungsstrategie: Die Lösungsstrategie bei den beiden zusätzlichen Ursachen ist klar: Fehler beseitigen. Seitenanfang Sonderfall Deadlocks Da es in der Literatur viel über Deadlocks zu lesen gibt, soll an dieser Stelle nur kurz darauf eingegangen werden: Deadlocks sind ein Sonderfall einer Blocksituation, da es hier keinen eindeutig "Schuldigen" gibt. Der MS SQL Server kann Deadlocks auch sehr gut erkennen und behandeln. Lesen Sie dazu die MS Dokumentation. Im Wesentlichen tut der SQL Server bei Deadlocks das gleiche, das auch der SQL Guard 2000 bei Blocksituationen macht: Er terminiert einen Prozess. Der einzige Unterschied ist, das der SQL Server bei einem Deadlock keinen Schuldigen kennt, und deshalb ein "victim" auserwählt. Man kann Deadlocks in größeren Systemen niemals vollkommen ausschließen. Die Strategien, um Ihre Quantität zu verringern, sind die gleichen, die man anwenden kann, um Blocksituationen allgemein zu vermeiden. Zudem kann man darauf achten, dass es keine Transaktionen gibt, die die gleichen Ressourcen in umgekehrter Reihenfolge benötigen. Seitenanfang Allgemeine Strategien und Richtlinien, um Blocksituationen so selten wie möglich zu machen Userinteraktionen in Transaktion sind verboten. Halten Sie Transaktionen immer so klein und so kurz wie möglich. Benutzen sie keine unnötigen Ressourcen in Transaktionen. Führen Sie so wenig externe Verarbeitungen wie möglich während einer Transaktion durch. Selektieren Sie immer mit der Option "with no locks", es sei denn Sie haben einen wichtigen Grund. Verwenden Sie row level locking. Verwenden Sie "dirty reads" überall dort, wo es möglich ist (Auf keinen Fall diese Option Global setzen, da dies nur bei den wenigsten Abfragen möglich ist). Machen Sie Ihr System so performant wie möglich. Führen Sie notwendige komplexe Transaktionen wie beispielsweise eine Fakturierung zu Zeiten aus, in denen die Userbelastung so gering wie möglich aus. Legen Sie Wartungsarbeiten, die den Server belasten (z.B. Full Backup, Indexe defragmentieren) in Zeiten geringer Userlast (Nachts, Wochenende) Selektieren Sie immer so wenig wie möglich und nur so viel wie nötig. Seitenanfang zurück