Der letzte Update enthält einige Neuerungen und wichtige Fehlerkorrekturen, die die Zuverlässigkeit des Datenbankservers erhöhen.
An dieser Stelle sei nochmals erwähnt, das der aktuelle Server auch zusammen mit älteren Clients wie 5.5 oder 5.6 eingesetzt werden kann (mit allen Client-Versionen ab 4.7).
Verkürztes Update-Intervall
Zwischen zwei Update-Ereignissen, bei denen geänderte Daten aus dem Cache in die Datenbank geschrieben werden, lag bisher standardmäßig ein Abstand von 60 Sekunden. Die Verkürzung dieses Intervalls auf 30 Sekunden führt zu einer besseren zeitlichen Verteilung der Schreiboperationen. Das I/O-Volumen pro Update-Ereigniss sinkt dabei, dadurch entstehen weniger starke Lastspitzen auf der Storage-Einheit.
Beschleunigung der Cache-Wiederherstellung
Das Einlesen des Cache-Inhalts nach dem Öffnen der Datenbank wurde beschleunigt. Durch die Zusammenfassung von I/O-Operationen wird in den meisten Fällen eine Geschwindigkeitssteigerung um den Faktor 3 bis 10 erreicht. Während eines längeren Einlesevorgangs finden jetzt auch Update-Ereignisse statt, bisher blockierte die Cache-Wiederherstellung die Updates.
Preload des Caches
Sofern für die Cache-Wiederherstellung keine gültige .cache-Datei gefunden wird, kann optional die komplette Datenbank in den Puffer eingelesen werden. Diese Option muss gesondert in der Datenbank-Konfiguration des Servers gesetzt werden (defaultmäßig ist die Option ausgeschaltet). Falls der Puffer kleiner als der Datenbankinhalt ist, werden in den Puffer vorrangig Segmente mit höherer Zugriffswahrscheinlichkeit geladen (Baumwurzeln und –knoten). Die Option ist sinnvoll, wenn entweder der Cache ähnlich groß wie die Datenbank ist, oder die Cachegröße mehrere Gigabytes beträgt – in diesem Fall kann die Befüllung des Caches durch normale Datenbankoperationen Stunden oder Tage dauern.
Hot-Standby-Synchronisation
Auch während der HSB-Synchronisation sind jetzt Update-Ereignisse aktiv. Da sich die Datenbank während der Synchronisation im Read-Only-Modus befindet, werden die Update-Daten in die aktuelle .tl-Datei geschrieben (genauso wie während eines Backup-Events). Diese Verbesserung ist vor allem bei einer länger andauernden Synchronisation wichtig, um Datenverluste bei einem Serverausfall während dieses Vorgangs zu vermeiden.
Wird eine Synchronisation direkt nach dem Öffnen der Datenbank gestartet, wird die Cache-Wiederherstellung dabei gleich miterledigt, da ja sowieso die gesamte Datenbank gelesen wird.
Bei einer HSB-Konfiguration wird die Datenbank jetzt immer zuerst im Read-Only-Modus geöffnet. Erst nach Prüfung des Synchronisations-Zustands erfolgt die Umschaltung in den Schreibmodus. Dadurch werden überflüssige Synchronisations-Vorgänge vermieden, die dann auftreten konnten, wenn die Datenbank nach dem Öffnen im Read-Write-Modus sofort in den Read-Only-Zustand versetzt wurde.
Fehlerkorrektur bei Rollback
Bei allen vorherigen 5.7-Serverversionen konnte es nach dem Öffnen einer nicht abgeschlossenen Datenbank beim Rollback zum Fehlereintrag „Transaction log file TL? has no valid blocks“ kommen, obwohl gültige Daten in der .tl-Datei vorhanden sind. Im Extremfall konnten bei der anschließenden Diagnose mit Recover Datenbankfehler festgestellt werden oder ein Datenverlust auftreten. Daher ist dieser Fehler als kritisch einzustufen. Zur Vermeidung einer solchen Situation empfehlen wir, ein Update aller installierten 5.7-Server auf die Version 5.7.07 durchzuführen.