Automatisiertes Caching (AutoDAB)

Durch das automatisierte Caching wird die Systembetreuung einerseits von den bisherigen Aufgaben der Cache-Administrierung wesentlich entlastet, andererseits wird der zur Verfügung stehende Cache optimal ausgenutzt.

Der AutoDAB übernimmt im Einzelnen die nachfolgend beschriebenen Aufgaben.

Automatische Selektion geeigneter Dateien auf einer gegebenen Menge von Datenträgern

Die Dateien werden beim Öffnen in die Cache-Konfiguration aufgenommen. Für Dateien, die beim Einrichten eines Cache-Bereichs bereits geöffnet waren, geschieht dies während der ersten I/O auf den Cache-Bereich.

Dateien, die mit dem Kommando /MODIFY-DAB-CACHING der Datenbasis hinzugefügt bzw. daraus entfernt werden, können nicht von der Dateiüberwachung des AutoDAB aus der aktuellen Konfiguration der gepufferten Dateien entfernt bzw. in diese eingefügt werden.

Klassifizierung der Dateien auf Grund ihres Zugriffsprofils

Die Dateien werden auf Grund ihres Zugriffsprofils in eine der folgenden drei Klassen eingeteilt:

• sequenziell bearbeitete Datei

• nicht-sequenziell (random) bearbeitete Datei mit zeitlicher Lokalität

• nicht-sequenziell (random) bearbeitete Datei ohne zeitliche Lokalität.

Durchführung des Cachings auf Grund der Analyse-Ergebnisse

• Sequenziell bearbeitete Dateien eignen sich sehr gut für ein Caching, wenn beim Lesen ein großer Prefetch durchgeführt wird und beim Schreiben die Daten in großen Blöcken auf die Platten zurückgeschrieben werden. Mit AutoDAB werden deshalb beim Lesen mehrere kleine Cache-Segmente mit einer Einlagerungs-I/O gefüllt (Multi-Segment-Prefetch), beim Zurückschreiben werden mehrere kleine Segmente mit benachbarten Daten mit einer I/O geschrieben (Multi-Segment-Destage).

  Zusätzlich wird bei Lese-Zugriffen eine asynchrone Einlagerung angestoßen, falls die Datenbereiche der nächsten nötigen Prefetch-I/O noch nicht im Cache eingelagert sind. Damit wird die Wartezeit für die Einlagerung weiter verringert, im Idealfall sind die Daten bereits eingelagert, bevor darauf zugegriffen wird.

  Wenn der dem Cache-Bereich zugewiesene Platz bereits vollständig belegt ist und der unterstützte Datenbereich eine in der Subsystem-Initialisierungs-Datei festgelegte Größe überschreitet, wird eine minimale Belegung von Cache-Segmenten für das Caching von Dateien mit dieser Klasse angestrebt. So wird ein Datensegment, das für ein Daten-Prefetching (von der Platte) infolge eines Read-Miss belegt worden ist, wieder für eine neue Dateneinlagerung freigegeben, wenn alle PAM-Seiten des Segments bereits referenziert wurden.

• Nicht-sequenziell (random) bearbeitete Dateien mit zeitlicher Lokalität eignen sich gut für ein Caching, wenn möglichst nur die referenzierten Daten (die wegen der zeitlichen Lokalität ja mit hoher Wahrscheinlichkeit demnächst nochmals referenziert werden) in den Cache eingelagert werden, um den Cache-Bereich gut auszunutzen. AutoDAB berücksichtigt dies bei Dateneinlagerungen und führt einen minimalen Prefetch durch (so genanntes Record Level Caching).

• Nicht-sequenziell (random) bearbeitete Dateien ohne zeitliche Lokalität eignen sich kaum für ein Caching, da sie ständig Cache-Einlagerungen (bzw. asynchrones Zurückschreiben) veranlassen, ohne die Daten wieder zu referenzieren. Dabei werden andere Dateien aus dem Cache verdrängt, die eine bessere Cache-Nutzung aufweisen. Aus diesem Grund werden diese Dateien von AutoDAB vom Caching ausgeschlossen, falls ein solches Zugriffsverhalten (nach einer Einschwingphase) feststeht. Diese Klasse von Dateien wird nur dann gepuffert, wenn sie ganz in den Cache aufgenommen werden können, ohne andere Dateien zu verdrängen.

Zyklische Überwachung der gepufferten Dateien bezüglich ihrer Cache-Nutzung

Die ausgewählten Dateien (auch die Dateien, auf die nicht sequenziell, d.h. random zugegriffen wird), werden zuerst eine Zeit lang gepuffert, bevor geprüft wird, ob das Caching dieser Datei (insgesamt) Vorteile bringt. Das heißt, in regelmäßigen Abständen wird geprüft, ob die Performance der unterstützten Dateien des Cache-Bereichs (noch) befriedigend ist. Das Kriterium hierfür ist der aktuelle Cache-Nutzungsgrad. Der Cache-Nutzungsgrad legt fest, in welchem Verhältnis durchgeführte Zugriffe zu den dafür nötigen Segment-Zuordnungen stehen. Ein großer Wert für den Cache-Nutzungsgrad bedeutet auch eine gute Cache-Nutzung.

Ist die Performance für unterstützte Dateien schlecht, wird das Caching für Dateien mit schlechter Cache-Nutzung gestoppt.

Automatische FORCE-OUT-Korrektur

Bei der Definition eines Cache-Bereichs kann von der Systembetreuung im Kommando /START-DAB-CACHING mit dem Operanden FORCE-OUT=... angegeben werden, ab welchem Schwellwert Schreibdaten asynchron aus dem Cache auf die zugehörigen Datenträger zurückgeschrieben werden sollen. Damit wird auch festgelegt, welcher Anteil eines Cache-Bereichs nach Möglichkeit für Lese-Daten bzw. neue Dateneinlagerungen freigehalten werden soll. Ist dieser Wert falsch eingestellt, kann er in Grenzsituationen die Performance eines Cache-Bereichs erheblich beeinträchtigen. Daher wird diese Einstellung beim automatischen Caching überprüft und eventuell korrigiert.

Die möglichen Werte für FORCE-OUT=... werden in folgender Reihenfolge angeordnet:

1. *NO

2. *AT-HIGH-FILLING

3. *AT-LOW-FILLING

Die vom Anwender vorgegebene Operandeneinstellung wird korrigiert, wenn bei der Bearbeitung der Zuweisung eines neuen Cache-Segments ein Cache-Überlauf auftritt. Dann wird, wenn noch möglich, auf die nächst niedrigere Stufe umgeschaltet. Ist ein weiteres Umschalten nicht mehr möglich und treten während mehrerer Überwachungsintervalle Cache-Überläufe auf, wird die Systembetreuung durch eine Konsol-Meldung darauf hingewiesen, dass der Cache-Bereich für die aktuelle Auslastung zu klein angelegt wurde.

Caching von Datenbereichen auf Shared Pubsets

Shared belegte Platten werden durch AutoDAB mit Lese-Caching bedient. Es muss nicht sichergestellt sein, dass von den Platten nur gelesen wird. Die Datenkonsistenz beim Lese-Caching wird hierbei durch DAB garantiert, indem nur lokal genutzte Dateien (entweder ohne Shared-Update oder mit lokalem Shared-Update bearbeitet) bedient werden und der Cache-Inhalt beim Schließen der Dateien invalidiert wird.

So ist sichergestellt, dass nach Updates der Dateien von anderen Systemen aus auf die aktuellen Daten zugegriffen wird. Dateien, die auf Shared Pubsets in einem HIPLEX im Modus Shared-Update und mit LOCK-ENVIRONMENT=*XCS geöffnet werden, d.h. einem System-übergreifenden Shared-Update unterliegen, werden von DAB in diesem Fall nicht bedient.