4. Folge

18. Planung Notmaßnahmen

Notmaßnahmen sind dann erforderlich, wenn über das normale Recovery- und Restartverfahren der Betrieb nicht wieder aufgenommen werden kann. Dieser Fall liegt dann vor, wenn z. B.

- das letztgültige Datensicherungsband nicht mehr vorhanden ist bzw nicht mehr lesbar ist,

- die letzten Logbänder ganz oder teilweise nicht mehr vorhanden oder nicht mehr lesbar sind,

- Datensicherungs- und/oder Logbänder bereits bei der letzten Erstellung falsch waren,

- die Anwendung über längere Zeiträume unbemerkt fehlerhaft arbeitete,

- das eingesetzte Release des Betriebssystems fehlerhaft arbeitet,

- die Hardware Fehler verursacht bzw. nicht vollständig verfügbar ist,

- die Restartprozeduren fehlerhaft sind.

Der Datenbankadministrator sollte einen Katalog aller Situationen aufstellen, die Notmaßnahmen erfordern und diese dann, soweit das möglich ist, auch vorplanen. Zweckmäßig ist es, wenn dieser Katalog in zwei Abschnitte geteilt wird, wobei der eine Abschnitt Situationen beinhaltet, die durch das Anwendungssystem verursacht werden können und der andere solche, die durch die Datenbanksoftware, das Betriebssystem oder durch die Hardware hervorgerufen werden können. Die Notmaßnahmen sollten so ausgelegt werden, daß damit der jeweils nächstmögliche normale Restartpunkt erreicht werden kann. Diese Vorgehensweise ist deshalb angezeigt, weil die Möglichkeit negativer Auswirkungen durch die Ergreifung von Notmaßnahmen dadurch minimiert wird.

19. Rückweisung unrealistischer Forderungen.

Der Datenbankadministrator hat nicht nur die Pflicht, das vorhandene Datenbanksystem bestmöglichst einzusetzen, sondern es ist auch seine Aufgabe, Forderungen entgegenzutreten die aus der Sicht des Datenbanksystems nicht realisierbar sind. Darunter fallen z. B.

- zu kurze Antwortzeitforderungen

- zu kurze Implementierungszeit

- Anforderungen für ein Datenbankdesign mit ungenügenden Spezifikationen hierfür

Im Zusammenhang mit der Rückweisung solcher oder ähnlicher Forderungen sollte er jedoch Alternativen mit aufzeigen, so daß die Organisatoren der entsprechenden Anwendung oder der Fachbereich, für den die Anwendung entwickelt wird, entscheiden kann, was daraufhin zu geschehen hat. In keinem Fall darf der Datenbankadministrator solche Entscheidungen selbst treffen, da letztlich durch seine Arbeit die Wirtschaftlichkeit der Anwendung erheblich beeinflußt wird und somit eine Abstimmung unumgänglich ist.

20. Alternativen zu unrealistischen Forderungen.

Um Alternativen anbieten zu können, ist es erforderlich, daß man sich mit den Ursachen beschäftigt, welche dazu führten, Forderungen als unrealistisch zu bezeichnen. Im Falle des Antwortzeitproblems wäre es denkbar, daß im Zusammenhang mit der Datenstrukturierung zu komplizierte Zugriffsstrukturen im Wege stehen. Hier wäre es notwendig, den Design nochmals zu überprüfen um feststellen zu können, ob Vereinfachungen noch möglich sind. Eine weitere Ursache kann jedoch auch eine zu geringe Auslegung der verfügbaren Hardware, dort speziell des Hauptspeichers, sein. Als weiterer Faktor muß noch genannt werden, daß bei der Konzeption der Anwendung zu viele Funktionen in eine Transaktion eingebaut wurden. Eine Aufgliederung in einzelne Transaktionen kann in manchen Fällen ebenfalls das Problem mildern oder beseitigen. In bezug auf die Implementierungszeit gibt es prinzipiell nur eine Möglichkeit der Problemlösung. Sie besteht darin, daß mehr Mitarbeiter der Anwendung zugeordnet werden, wobei zu unterscheiden ist, ob der Engpaß beim Datenbankadministrator liegt oder bei den Organisatoren und/oder Programmierern der Anwendung. Dieser Weg ist nicht ohne weiteres gangbar, wenn bestimmte fachliche Qualifikationen vorausgesetzt werden müssen, diese im vorhandenen Mitarbeiterstab jedoch nicht verfügbar sind. Einen Ausweg könnte es in solchen Fällen noch dadurch geben, daß man die Anwendung in mehrere Stufen aufgliedert und daraus die wichtigste zuerst realisiert und einführt.

21. Performanceschätzung.

Zumindest für die Beurteilung der geforderten Antwortzeit ist es mit Voraussetzung, daß eine Schätzung des Performanceverhaltens durchgeführt wird. Diese ist nicht nur für die oben genannte Beurteilung der Antwortzeit erforderlich, sondern sie ist auch ausschlaggebend für die Überprüfung der Wirtschaftlichkeit, wenn das Anwendungssystem im laufenden Betrieb einmal eingeführt wurde. Folgende Punkte sollten bei der Performanceschätzung mit berücksichtigt werden:

- Strukturierung des Datenbanksatzes.

- Strukturierung der Zugriffspfade.

- Wahl der Zugriffsform.

- Wahl der Speicherungsform.

- Effektivität eines möglichen Umrechnungsalgorithmus.

- Komplexität der Anwendung, der Anwendungssteuerung sowie der zugehörigen Anwendungsmodule.

- Rechnergeschwindigkeit.

- Hauptspeichergröße.

- Puffergröße.

- Laufwerkbelegung.

- Hard- und Softwarerestriktionen, soweit sie vorhanden und wirksam sind.