Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.10.1990 - 

Schnelle Analyse notwendig

Viele DB2-Routinearbeiten lassen sich automatisieren

Ein wesentliches Merkmal von DB2 ist nach Einschätzung von Helmut Haase* die Eigenschaft, sich dynamisch und fortlaufend zu ändern. Während Anwender dieses Merkmal schätzen, sehen sich die Systemverantwortlichen mit einem erhöhten Aufwand beim Handling konfrontiert. Der Autor erörtert wie DB2-Routinearbeiten zu automatisieren sind.

Zwar stellen sowohl DB2 als auch die Tools der verschiedenen Drittanbieter eine Vielzahl von Pflegehilfsmitteln zur Verfügung, aber es fehlt an der nötigen Unterstützung, Routinearbeiten zur DB2-Pflege automatisiert und in einer konsistenten Form durchzufahren. Im Rahmen dieses Aufsatzes möchte ich über DB2-Routinearbeiten für das Space- und Utility-Management schreiben.

Ziel eines automatisierten Space-Managements ist die tägliche Kontrolle aller DB2-Objekte und die automatische Ausführung sämtlicher durch die Analyse erkannter Pflegemaßnahmen. Um dieses Ziel zu erreichen, sind folgende Forderungen aufzustellen:

1. Notwendige Informationen für das Space-Management müssen verfügbar sein. Diese Aussage klingt zwar trivial, ist es aber keineswegs. Sieht man sich an, was DB2 bietet, zum Beispiel die Hauptfunktion des DB2-Kataloges, so liegt diese in der Beschreibung und dem Navigieren der bestehenden DB2-Daten. Der DB2-Katalog ist nicht als Space-Management-System gedacht, weil unter anderem wichtige Informationen zum Beispiel über Extents oder Volumes fehlen.

Warum nicht eine Stufe höher ansetzen und den ICF-Katalog befragen? Das LISTC steht dafür ja zur Verfügung. Da aber der ICF-Katalog lediglich zum jeweiligen Close-Zeitpunkt aktualisiert wird, ist klar, daß neben aufwendiger Listenverarbeitung möglicherweise keine aktuellen Werte durch LISTC geliefert werden. Diesen Nachteil hat auch das Stopspace-Utility, das eine weitere Möglichkeit darstellt, Informationen aus dem ICF-Katalog zu beschaffen. Zudem liefert Stopspace lediglich Aussagen über allokierten Space, wobei nicht alle DB2-Cluster erfaßt werden.

2. Die Analyse muß so schnell sein, daß sie auch für wachsende DB2-Systeme täglich durchgeführt werden kann. Auch diese Aussage ist eigentlich so selbstverständlich, daß wir hierzu das Umfeld etwas näher beleuchten wollen.

Sicherlich ist die Möglichkeit der Informationsbeschaffung durch einen Full-Scan-Prozeß gegeben. Dabei ist unerheblich, ob diese Funktion von den DB2-Utility-Runstats oder von beliebig anderen Runstats ersetzenden Werkzeugen (... Stats, und so weiter) wahrgenommen wird.

Fest steht, daß die Hauptbedeutung dieser Full-Scanner in der Analyse der Daten von Tablespace/Indexes, also letztlich in der Pfadoptimierung der DB2-Pläne liegt und nicht im Space-Management. Insbesondere ist es in der Praxis so nicht möglich, das gesamte DB2-System täglich zu kontrollieren. Gefragt ist in diesem Zusammenhang eher folgendes: Wann ist der optimale Zeitpunkt für einen Full-Scan-Prozeß (Runstats, ... Stats, und so weiter) gekommen?

3. Die Space-Analyse-Ergebnisse müssen so aufbereitet werden, daß sie den Systemverantwortlichen rechtzeitig auf potentielle Probleme aufmerksam machen. Aus diesen Überlegungen resultiert unsere Lösung für das Space-Management. Als eingehende Daten werden

- der DB2-Katalog,

- die VSAM-Cluster-Spacemaps und

- die VTOC DSCBs gelesen.

Überwachung mit High-Speed-Scan-Analyse

Aufgrund der High-Speed-Scan-Analyse, die zirka 50 VSAM-Cluster pro Minute verarbeitet, ist es möglich, das gesamte DB2-System täglich zu überwachen. Diejenigen Ausnahmesituationen, die einen unmittelbaren Handlungsbedarf für den Systemverantwortlichen bedeuten, werden über eine mächtige Schwellwertlogik gesteuert. Mittels dieser Logik sowie vordefinierter JCL bestimmt der Anwender den Automatisierungsgrad, das heißt, das selbständige Reagieren auf diese Ausnahmesituation.

Dies geht zum Beispiel soweit, daß erstens bedarfsorientierte Runstats (beziehungsweise... Stats, und so weiter) sowie zugehörige Rebinds, und zweitens bedarfsorientierte Reorgs so aufgebaut werden, daß die auszuführenden Jobs dem Jobsteuerungssystem überstellt und ausgeführt werden, ohne daß auch nur an einer Stelle manuell eingegriffen werden muß.

Das Ziel eines automatisierten Utility-Managements besteht darin, daß ohne manuelle Eingriffe das richtige Utility zum richtigen Zeitpunkt für das richtige Objekt richtig aufgeführt wird. Um das Wesentliche dieser Aussage zu verstehen, sehen wir uns doch einmal DB2-Copy-Management an und fragen, was steht dieser oben definierten Automatisierung entgegen?

1. Die Dynamik von DB2. So führen zum Beispiel gelöschte Tablespaces zu Jobabbrüchen. Neu angelegte Tablespaces sind nicht im Utility-Management aufgenommen. Das heißt: Schlechte Performance wegen fehlender Reorganisation sowie undurchführbare oder fragwürdige Recoveries wegen fehlender Backups.

2. Die Abhängigkeiten der DB2-Utilities. Sollen beispielsweise periodisch sogenannte Incremental-Image-Copies durchgeführt werden, so ist sicherzustellen, daß jedem Reorg beziehungsweise Load eine Full-Image-Copy folgt.

3. Die fehlende Umgebung, um durchgeführte Analysen in Pflegemaßnahmen umzusetzen. So wird zum Beispiel die Reorganisation zu wenig oder zu häufig realisiert. Jobs enthalten Incremental-Image-Copies für Tablespaces, die keine "updated pages" besitzen.

In der Regel haben die oben genannten Punkte zur Folge, daß lediglich ein triviales Utility-Management mit hohem manuellem Pflegeaufwand sowie großem Ressourcenbedarf realisiert ist. Beispiele dafür sind ein Copy-Management, bei dem lediglich Full-Image-Copies verwendet werden, oder ein Reorg-Management, das nicht am Bedarf orientiert ist, sondern periodisch ausgeführt wird.

Diese Überlegungen sind bei uns wie folgt realisiert: Die Steuerung erfolgt durch Strategien und Schwellwerte. Utility-Management wird von Reorg, und Copy-Strategien gesteuert, die auf benutzerfreundliche Weise erlauben, verschiedene Pflegeszenarien für die verschiedenen Tablespaces/Indexes zu definieren.

Während eine Reorg-Strategie lediglich Schwellwerte enthält, um Reorganisationen bedarfsorientiert auszulösen, definiert die Copy-Strategie zusätzlich ein Modell, welche Art von Image-Copy wie oft ausgeführt werden soll. Dabei werden sämtliche Spielarten von Copy-Tablespace bis Mergecopy-Tablespace unterstützt.

Des weiteren ist in diesem Modell enthalten, wieviele Full-Image-Copies stets im DB2-Katalog gelistet sein sollen und damit für ein Recovery zur Verfügung stehen. Wird diese Zahl von Full-Image-Copies überschritten, so werden die nötigen Modify-Recovery-Utilities generiert, um die überzähligen Einträge im DB2-Katalog zu löschen. Die zugehörigen Backups werden über ein spezielles Scratch-Utility aus dem Tape-Management-System entfernt, um dessen Konsistenz mit dem DB2-Katalog sicherzustellen.