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.

Klicken Sie hier, um die Nutzungsbedingungen für unseren Blog zu lesen.

5 Antworten

  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?

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Leave the field below empty!

Wünsche, Fragen oder Feedback sind willkommen:

Nutzungsbedingungen der Kommentarfunktion im Blog

1. Allgemeines

Vectorsoft AG („Anbieter“) stellt für Internetnutzer („Nutzer“) auf der Website
vectorsoft.de einen öffentlichen Blog bereit. Der öffentliche Blog dient dem
Informations- und Gedankenaustausch. Die Nutzer, welche sich mit Beiträgen und
Kommentaren beteiligen, verpflichten sich dazu, die Blog-Nutzungsbedingungen
einzuhalten und tragen die Verantwortung für die Richtigkeit und Angemessenheit
sowie Freiheit von Rechtsverletzungen ihrer Beiträge. Mit Nutzung der
Kommentarfunktion in unserem Blog akzeptieren Sie diese Nutzungsbedingungen.

2. Netiquette

Wir bitten Sie von persönlichen Angriffen und Provokationen aufgrund anderer
Meinungen abzusehen. Bitte argumentieren Sie sachlich und bewegen Sie sich auf
der Basis einer konstruktiven Diskussionskultur. Ihr Kommentar sollte stets im
Zusammenhang mit dem jeweiligen Thema sein, um Ausschweifungen in andere
Themenbereiche zu vermeiden. Das mehrmalige Posten desselben Kommentars
oder mehrerer ähnlicher Kommentare ist nicht erlaubt.

3. Verbot rechtswidriger Inhalte

Mit Absenden Ihres Kommentars bestätigen Sie, dass Sie keine Urheberrechte oder andere Rechte Dritter verletzen. Volksverhetzende, rassistische Äußerungen, Anleitungen zu Straftaten und deren Verherrlichung, Gewaltdarstellungen, pornografische Inhalte und Äußerungen, die Persönlichkeitsrechte verletzen sind untersagt.

4. Keine Werbung

Die Nutzung der Kommentarfunktion ist für kommerzielle oder parteipolitische
Zwecke nicht erlaubt. Werbliche Beiträge aller Art werden von uns umgehend
gelöscht.

5. Angaben zum Namen

Bei der Eingabe Ihres Namens achten Sie auf die zuvor genannten Grundsätze.

6. Quellenangaben

Bitte geben Sie bei der beabsichtigten Veröffentlichung von Zitaten oder Beiträgen
Dritter die jeweiligen Quellen an und erläutern dessen Bezug zum Blogbeitrag.

7. Verstoß gegen die Nutzungsbedingungen

Beiträge, die gegen diese Richtlinie verstoßen werden umgehend gelöscht. Sollten
Sie selbst Verstöße bemerken, so senden Sie uns bitte den Link des betreffenden
Kommentars per E-Mail an . Wir weisen ausdrücklich daraufhin, dass wir einzelne Nutzer bei wiederholten oder schweren Verstößen gegen diese
Nutzungsbedingungen ausschließen werden.

Stand: Sept. 2024

Deine Trial Version - jetzt anfordern!

Teste yeet - unverbindlich und kostenfrei

IHRE EVALUIERUNGSLIZENZ - JETZT ANFORDERN!

TESTEN SIE DIE CONZEPT 16 VOLLVERSION - UNVERBINDLICH und KOSTENFREI

Melden Sie sich bei unserem Newsletter an

Anrede*
     
Zustimmung zur Datenverarbeitung gem. DSGVO*



WordPress Cookie-Hinweis von Real Cookie Banner