Home 
ORDIX News 1/2008 Datenbanken
ORDIX News 1/2008 Datenbanken
ORDIX News 1/2008 Datenbanken
Entwickler und Entscheider im
Datenbankumfeld.
| RTO Recovery Time Objective. Zielvereinbarung in Sekunden, wie lange der DBServer nach einem Ausfall von der Startphase bis zum Zustand „Online“ benötigen darf. |
| LRU Least Recently Used. Interne Verwaltung einer Pointer-Liste, die auf Daten im Shared Memory verweist. |
| AIO-VP Informix Virtueller Prozess (Asynchronous I/O) für das Schreiben auf Platte. |
Weiterführende Links
KONFIGURATIONSPARAMETER Recovery Time ObjectiveRTO_SERVER_RESTART ## (Angabe in Sekunden) # Zeit, die der Server für einen Recovery aus dem Offline # maximal benötigen darf. # 0=Off, die Angabe erfolgt in Sekunden im Bereich von 60-1800 # Dieser Wert beeinflusst u.a. das Checkpoint-Interval. RAS_PLOG_SPEED ### # Parameter für die Lesegeschwindigkeit des Physical Logs. # Dieser Wert wird vom DB-Server beim Starten automatisch # ermittelt und eingetragen. # Standardwert: 10240 pages/sec (20 Mb/sec) # Wert in pages written/second RAS_LLOG_SPEED ### # Parameter für die Lesegeschwindigkeit des Logical Logs # Dieser Wert wird vom DB-Server beim Starten automatisch # ermittelt und eingetragen. # Wird als 1/8 von RAS_PLOG_SPEED initialisiert. # Standardwert: 1280 pages/sec (2.5 Mb/sec) # Wert in pages written/second |
| Abb. 1: Konfigurationsparameter der RTO-Policy. |
Mit der IDS Version 11 kann sich der Datenbankadministrator das Leben etwas vereinfachen, z. B. mit der so genannten RTO-Policy. RTO steht für Recovery Time Objective und bedeutet soviel wie eine Vereinbarung einer Zielvorgabe für eine garantierte Wiederanlaufzeit (Recovery-Phase) nach einem Datenbankserverausfall.
Die RTO-Policy wird über den neuen Konfigurationsparameter RTO_SERVER_RESTART aktiviert. Mit der Angabe einer Zeitdauer in Sekunden wird festgelegt, wie lange eine Wiederanlaufzeit (Zeitspanne vom Beginn des Starts bis hin zum Zustand „Online“ des Datenbankservers) maximal sein darf. Der Wert kann im Bereich zwischen 60 und 1800 Sekunden liegen.
Sobald dieser Konfigurationsparameter gesetzt ist, aktiviert er automatisch ein Monitoring des Datenbankservers, um die RTO-Richtlinie einzuhalten. Unter der Voraussetzung, dass ein Physical Logfile mit einer Mindestgröße von 10 MB sowie ausreichend große Logical Logfiles zur Transaktionsprotokollierung zur Verfügung stehen, werden, abhängig von der Transaktionslast, Checkpoints durchgeführt, damit die Einhaltung der RTO-Policy garantiert werden kann. Bei aktivierter RTO-Richtlinie wird der Standardparameter für den Checkpoint Intervall CKTINTVL ignoriert.
Die beiden zusätzlichen Konfigurationsparameter RAS_PLOG_SPEED und RAS_LLOG_SPEED regeln die Lesegeschwindigkeit des Physical Logs und des Logical Logs. Beide Werte werden beim Starten vom Datenbankserver automatisch ermittelt und eingetragen. Eine Übersicht über die drei Konfigurationsparameter finden Sie in Abbildung 1.
Zusätzlich zum automatischen Monitoring wird bei Aktivierung einer RTO-Policy auch das dynamische Ressourcen Tuning gestartet. Dabei überprüft der Datenbankserver im laufenden Betrieb ständig die beiden Parameter LRU_MIN_DIRTY und LRU_MAX_DIRTY und führt, je nach Lastsituation, auch selbstständig Anpassungen durch.
Bei Bedarf werden durch den Datenbankserver im laufenden Betrieb weitere AIO_VPs (Informix Virtuelle Prozesse für das Schreiben und Lesen von Platte) und Page Cleaner Prozesse hinzugefügt, die für das Schreiben der geänderten Bufferpool Pages aus dem Shared Memory auf Platte (Synchronisation) verantwortlich sind.
Das Schreiben des Inhaltes eines Shared Memory Buffers auf die Platte (Synchronisation) wird im Englischen als „buffer flushing“ bezeichnet. Die automatische Ausführung dieser Aktion wird anhand der Schwellwerte der beiden LRU-Parameter LRU_MIN_DIRTY und LRU_MAX_DIRTY gesteuert.
Bisher hatten diese beiden Schwellwerte eine feste Größe, die nicht dynamisch angepasst werden konnte. Zukünftig optimiert der Datenbankserver die Werte bei entsprechendem Lastverhalten automatisch. Voraussetzung dafür ist entweder, dass der neue Konfigurationsparameter AUTO_LRU_TUNING = 1 gesetzt ist oder, wie bereits oben erwähnt, der RTO_SERVER_RESTART aktiviert ist.
Automatische Anpassung von LRU_MIN_DIRTY und LRU_MAX_DIRTY12:02:02 Adjusting LRU for bufferpool - id 0 size 2k 12:02:02 Old max 78.4 min 68.6 New max 77.6 min 67.9 |
| Abb. 2: Beispieleintrag im Message Logfile nach dynamischer Anpassung beider LRU-Parameter durch den DB-Server. |
Stellt der Datenbankserver Engpässe in der LRU-Queue Verwaltung fest, dann werden die beiden Schwellwerte der LRU-Parameter LRU_MAX_DIRTY und LRU_MIN_DIRTY automatisch um 1 Prozent nach unten korrigiert. Durch das Herabsetzen der beiden LRU-Schwellwerte werden die geänderten Pages/Datensätze aus dem Shared Memory häufiger auf Platte geschrieben. Diesen Vorgang nennt man auch Synchronisation oder LRU-Flushing. Die Überprüfung der beiden LRU-Parameter erfolgt bei jedem ausgelösten Checkpoint (siehe Abbildung 2).
Die Standardeinstellungen für die Schwellwerte der beiden LRU-Parameter betragen 50 für LRU_MIN_DIRTY und 60 für LRU_MAX_ DIRTY. Bei aktivierter LRU-Optimierung können die Werte höher gesetzt werden. Eine Empfehlung lautet inzwischen, mit den Werten LRU_MIN_DIRTY = 70 und LRU_MAX_ DIRTY = 80 zu starten.
Die Einstellungen der LRU-Schwellwerte regeln das Schreiben der geänderten Daten aus dem Shared Memory Buffer auf die Platte. Wird der Schwellwert von LRU_MAX_DIRTY überschritten, werden solange modifizierte Datenseiten auf die Platte geschrieben, bis der untere Schwellwert LRU_MIN_DIRTY erreicht ist.
Achtung: Die automatischen LRU-Anpassungen sind nicht permanent und werden auch nicht in der ONCONFIG-Datei gespeichert. Falls keine manuelle Änderung der Konfigurationsparameter in der $ONCONFIG erfolgt, wird beim nächsten Neustart des Datenbankservers wieder auf die ursprünglichen Konfigurationswerte, die in der ONCONFIG-Datei enthalten sind, zurückgegriffen.
Voraussetzungen für nicht blockierende Checkpoints:
16:05:17 Performance Advisory: Based on the current workload, the physical log might be too small to accommodate the time it takes to flush the bufferpool. 16:05:17 Results: The server might block transactions during checkpoints. 16:05:17 Action: If transactions are blocked during the checkpoint, increase the size of the physical log to at least 14000 KB. 16:05:17 Performance Advisory: Based on the current workload, the logical log space might be too small to accommodate the time it takes to flush the bufferpool. 16:05:17 Results: The server might block transactions during checkpoints. 16:05:17 Action: If transactions are blocked during the checkpoint, increase the size of the logical log space to at least 14000 KB. |
| Abb. 3: Eintrag im Online Logfile bei zu kleinen Logfiles. |
Mit der Version 11 wurde der bisherige Checkpoint-Algorithmus durch einen praktisch nicht blockierenden Checkpoint-Algorithmus ersetzt. Durch das optimierte LRU-Flushing werden die modifizierten Buffer Pages außerhalb der Checkpointphase auf Platte geschrieben. Das einzige, was den Datenbankserver noch für geringe Sekundenbruchteile blockiert, ist das Schreiben des Checkpoint-Eintrages in das Logical Logfile.
Der Informix Dynamic Server überwacht die Auslastung und die bisherigen Checkpoint-Zeiten und löst Checkpoints bei Bedarf häufiger aus, damit kritische Ressourcen, wie das physische oder das logische Logfile, nicht erschöpft werden. Damit wird sichergestellt, dass Transaktionen während eines Checkpoints nicht blockiert werden.
Bei Anwendungen, die empfindlich auf Reaktionszeiten reagieren, kann die bisherige Methode geändert werden. Bei dieser wurde aggressives LRU-Flushing (Schreiben der Daten aus dem Shared Memory Bereich auf die Platte auf Basis von sehr niedrigen LRU-Parametereinstellungen) verwendet, um die Wartezeiten des Checkpoints zu verringern.
Es ist allerdings darauf zu achten, dass sowohl das Physical Logfile als auch die Transaktionsprotokolle ausreichend groß angelegt sind. Falls dies nicht der Fall sein sollte, werden blockierende Checkpoints durchgeführt. Gleichzeitig wird ein Eintrag in das Message Logfile des Datenbankservers vorgenommen, der auch einen Hinweis mit Empfehlung einer Mindestgröße enthält (siehe Abbildung 3).
Das neue Kommando onstat -g ckp bietet eine
Möglichkeit, die aufgetretenen Checkpoints
zu überwachen und zu analysieren. Es wird
ausgegeben, ob die Funktion AUTO_CKPTS
an- oder ausgeschaltet ist, welcher Wert für
RTO_SERVER_RESTART eingestellt ist, sowie
die aktuell erwartete Restart-Zeit beim
Recovery (siehe Abbildung 4).
mstoeb>onstat -g ckp IBM Informix Dynamic Server Version 11.10.FC1 -- On-Line -- Up 04:18:43 -- 29696 Kbytes AUTO_CKPTS=On RTO_SERVER_RESTART=60 seconds Estimated recovery time 24 seconds
Critical Sections Physical Log Logical Log
Clock Total Flush Block # Ckpt Wait Long # Dirty Dskflu Total Avg Total Avg
Interval Time Trigger LSN Time Time Time Waits Time Time Time Buffers /Sec Pages /Sec Pages /Sec
150 15:35:45 Backup 52:0x1314c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 1
151 15:36:14 Admin 55:0x18 0.0 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 4 0
153 15:36:22 Admin 55:0x203c 0.0 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 0
154 15:36:26 Admin 55:0x303c 0.2 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 0
155 15:36:334 Admin 55:0x403c 0.0 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 0
167 15:38:19 Backup 55:0x1411c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 1
168 15:45:02 RTO 57:0x29015c 4.5 4.2 0.0 1 0.0 0.2 0.2 558 131 2224 5 4570 11
169 15:56:14 RTO 58:0x90d618 7.2 5.9 0.0 1 0.1 1.2 1.2 539 90 1602 2 4439 6
219 11:33:33 *User 93:0x8c6018 0.1 0.1 0.0 1 0.0 0.1 0.1 3 3 20 0 23 0
220 13:04:23 *Backup 98:0x4f1018 1.6 1.3 0.0 0 0.0 0.0 0.0 140 110 2567 0 8519 0
221 13:04:24 Backup 98:0x4f211c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 0 0 0 1 0
222 13:18:01 Plog 102:0x8f44b8 10.9 10.3 0.0 1 0.0 0.5 0.5 755 73 6647 8 11585 14Max Plog Max Llog Max Dskflush Avg Dskflush Avg Dirty Blocked pages/sec pages/sec Time pages/sec pages/sec Time 200 200 6 69 0 0 |
| Abb. 4: Beispielausgabe des Informix Kommandos onstat -g ckp. |
Durch die Erweiterung der sysmaster Datenbank um die beiden Tabellen syscheckpoint und sysckptinfo kann man alternativ auch über ein selbst erstelltes SQL-Statement auf die gewünschten Informationen zugreifen.
Im Folgenden werden nun die wichtigsten Aussagen des Kommandos onstat -g ckp beschrieben, wie in Abbildung 4 zu sehen ist:
Danach folgen einige statistische Werte, wie z. B. Dirty Buffers = Anzahl der Buffer Pages, die auf Platte geschrieben wurden oder Total Time = komplette Dauer eines Checkpoint Requests in Sekunden.
IBM hat den Schwerpunkt der neuen Funktionen der Version 11 ganz gezielt auf Performance und Skalierbarkeit, Reduktion des Administrationsaufwands sowie auf Ausfallsicherheit gelegt. Dadurch kommen die langjährigen, bereits bekannten Stärken des IDS, die effiziente Administration, Zuverlässigkeit und hochskalierbare Architektur besonders den Unternehmen zu Gute, die einen 24x7-Betrieb auf höchstem Niveau benötigen.
Alle hier vorgestellten Erweiterungen des Datenbankservers IDS 11 gehen einher mit einer Arbeitserleichterung für den Datenbankverantwortlichen. Damit ist ein weiterer Schritt in die von IBM propagierte „Administration Free Zone“ getan.
In einer der kommenden Ausgaben beleuchten wir die neuen Hochverfügbarkeitslösungen, die unter dem Codenamen MACH11 in den Informix Dynamic Server 11 integriert wurden.
Manfred Stöb (info@ordix.de).