Für den Administrator, Performance

Update-Events der Datenbank

Änderungen im Datenbestand führt der Datenbankserver immer zuerst im Hauptspeicher (Datenbankpuffer) durch. Sinnvollerweise müssen diese Änderungen auch irgendwann in die Datenbank gelangen, dies erfolgt durch periodische Update-Ereignisse. Diese sind das Thema meines heutigen Blog-Beitrags.


Jede Änderung von Daten in der Datenbank, egal ob Einfügen, Modifizieren oder Löschen von Datensätzen, Texten, Blobs oder Parametern findet immer innerhalb einer – meist impliziten – Transaktion statt. Nach Abschluss einer Transaktion liegt das Resultat dann in einem oder mehreren veränderten Datensegmenten im Datenbankcache vor.

Die Übertragung dieser Segmente in die Datenbank erfolgt nicht sofort. Dadurch können die Daten mehrerer Transaktionen in einem Updatevorgang zusammengefasst werden, um die Anzahl von Schreibvorgängen auf die Datenbank zu reduzieren. Der Updatevorgang wird durch ein Update-Ereignis vorgenommen, welches unabhängig von angemeldeten Benutzern ausgeführt und zeitgesteuert ausgelöst wird.

Ein Update-Ereignis wird alle 60 Sekunden gestartet, wobei die Zeit ab dem Ende des letzten Updates gezählt wird. Zusätzlich wird ein Update ausgelöst, wenn der Datenbankpuffer zu mindestens 80% mit geänderten Segmenten belegt ist, dadurch soll eine Auslagerung dieser Segmente in die .trs-Datei der Datenbank vermieden werden (dies würde zusätzliche I/O-Last generieren). Letztendlich wird auch vor dem Schließen der Datenbank oder dem Wechsel in den Read-Only-Modus in jedem Fall ein Update durchgeführt.

Vor dem Schreiben in die Datenbank werden alle veränderten Segmente zunächst in eine der Transaktionslogdateien (.tl1, .tl2, .tl3) gesichert, um den Update der Datenbank auch bei einem Serverausfall später erneut durchführen zu können. Die Sicherungsoperation schreibt die Datensegmente sequentiell und daher mit hoher Geschwindigkeit in die .tl-Datei. Anschließend erfolgt die Übertragung in die Datenbank. Die Segmente werden dabei in einer aufsteigend sortierten Reihenfolge geschrieben, um eine möglichst hohe Übertragungsrate zu erreichen.

Dabei ensteht bei jedem Updatevorgang eine Lastspitze auf dem Storage-System, was bei ausreichender I/O-Leistung unkritisch ist. Besteht jedoch während des Update schon eine hohe I/O-Last durch Leseanforderungen, so verlangsamt dies den Updateprozess unter Umständen erheblich.

Der Datenbankserver bietet die Möglichkeit, Umfang und Dauer jedes Updates im Datenbanklog (.lgb) zu protokollieren. Dazu muss bei den DebugOptions der Wert 100 gesetzt werden. Anhand der Protokolleinträge kann so die I/O-Leistung des Systems während eines Updates ermittelt werden:

Database update time 6.1 seconds, 120 MB

Dieser Eintrag ergibt beispielsweise einen Durchsatz von 20 MB/s. Die Durchsatzrate wird von vielen Faktoren beeinflusst, dazu gehören die Cachegröße und der Schreibmodus des RAID-Controllers, RAID-Level, Anzahl der Datenträger, HDD oder SSD, parallel stattfindende I/O-Vorgänge etc. Die Datenrate ist daher ein Indikator für die I/O-Performance und kann zur Erkennung von Engpässen herangezogen werden.

Unabhängig vom Updatevolumen sollte ein Update der Datenbank idealerweise in weniger als 10 Sekunden stattfinden, längere Updatezeiten können zu einer spürbaren Verlangsamung von Leseoperation führen, die Datenbankperformance verschlechtert sich:

Database update time 110.5 seconds, 17 MB

Ein solcher Wert von 150 KB/s bedeutet ein unzureichend schnelles System. Dies kann entweder durch eine dauerhafte Überlastung – beispielsweise bei einem unterdimensionierten RAID-1 aus 2 HDDs mit 5400/min am Onboard-Controller – oder durch eine temporäre Überlastung enstehen. Im Fall einer vorübergehenden Überlastung erreicht das System zu anderen Zeiten einen erheblich höheren Durchsatz.

Update:

Ab der Version 5.7.07 des CONZEPT 16-Servers erfolgen die Update-Intervalle alle 30 Sekunden.

5 Kommentare

5 Kommentare “Update-Events der Datenbank”

  1. Nein, ich brauche keine spezielle Einstellung im Moment, aber gut zu wissen, dass das möglich wäre.

    Ich fand den Artikel interessant und war bloss neugierig bzgl. Updatefrequenz und Sicherheit der Transaktionslogs.

    Danke für die Informationen.

  2. Die Updatezeit war in früheren Serverversionen für jede Datenbank einstellbar. Aufgrund von einigen Fehlkonfigurationen haben wir diese Einstellungmöglichkeit aus der Webadministration entfernt.

    Falls in speziellen Fällen ein anderes Updateintervall notwendig wird, bitte unseren Support direkt kontaktieren.

  3. Aha, bei DtaCommit() wird also auf jeden Fall ein Transaktionslog geschrieben, das leuchtet mir ein.

    Allerdings ist die Datensicherheit zwischen den Update-Zyklen dann abhängig von der Art wie die auf der DB laufende Software programmiert ist.

    Die DB-Admins, die ich bisher so kennen gelernt habe, misstrauen jedem Softwareentwickler 😉 und könnten daher auch auf die Idee kommen, die Update-Frequenz (gemäss Artikel = 60 sec.) zu reduzieren (etwa auf 30 sec. oder so), um die Datensicherheit zu erhöhen (auf Kosten der Performance natürlich, aber das ist ja immer Abwägungssache). Dies ist derzeit allerdings wohl nicht möglich, wenn ich den Artikel richtig verstanden habe, oder?

  4. Aktuell wird das Transaktionslog aus Peformancegründen nicht nach jeder einzelnen abgeschlossenen Transaktion geschrieben, wodurch bei einem Ausfall Datenänderungen der letzten 60 Sekunden vor dem Absturz verloren gehen können. Daten aus nicht abgeschlossenen Transaktionen gehen in jedem Fall verloren.

    Grundsätzlich wäre bei expliziten Transaktionen auch ein DtaCommit() mit zwangsweisem Schreiben des Transaktionslogs möglich (das dauert natürlich länger). Ob das notwendig ist, hängt von der Anwendung ab.

  5. Danke, das ist mal ein interessanter Einblick in die Speicherstrategie des Datenbanksystems.

    Da schon von Serverausfall usw. die Rede ist, drängt sich für mich folgende Frage auf:

    Ist die Erstellung der Transaktionslogs unabhängig von den Update-Events?

    Dies geht aus der hier gewählten Formulierung "vor dem Schreiben in die Datenbank" nicht ganz klar hervor, wird aber sicherlich so sein, denn sonst wären ja alle Daten zwischen zwei Update-Events im Falle eines Serverausfalls verloren, oder?

Kommentar abgeben