Log Analysis

Das Db2-Log ist nicht nur ein wichtiger Teil der Db2-Wiederherstellungsstrategie, es ist auch eine Fundgrube für eine Vielzahl anderer wichtiger Zwecke. Datenbankadministratoren, Anwendungsentwickler und Wartungsprogrammierer können das Db2-Log verwenden, um die Ergebnisse fehlerhafter Programmausführungen, falsch geplanter Jobs oder Benutzerfehler zu reparieren. In vielen Fällen ist eine Standard-Wiederherstellung auf der Grundlage von Image-Kopien ungeeignet, da sie zu viel zurücksetzt.

Verwandte
Produkte

Zugehörige Produkte:

ULT4DB2

ULT Logo
Bereitstellung von REDO- und UNDO-SQL zur Datenreparatur oder Datenweitergabe. Finden Sie Quiet Punkte für die Wiederherstellung und unterstützen Auditing-Aufgaben.

Log Analysis & Tracking unterstützt Sie in folgenden Bereichen:

Da das Db2 Log alle Datenänderungen aufzeichnet, eignet es sich ideal als Basis für die Bereitstellung von Audit Reports. Die Nutzung des Db2-Logs macht nachträgliche Änderungen und Ergänzungen an etablierten Anwendungen überflüssig, auch die bekannten betrieblichen Nachteile von Triggern werden vermieden. Im Vergleich zur Einrichtung eines kostspieligen Mechanismus, der kontinuierlich alle Datenänderungen extrahiert und überwacht, kann daher eine laufende Log-Analyse für die betroffenen Tabellen die bessere Lösung sein.

Ein Log-Analyse- oder Log-Extraktionsprogramm benötigt als Steuerdaten zumindest die Zeitstempel von Beginn und Ende des Beobachtungszeitraums und den Namen des zu beobachtenden Objekts. Das klingt recht einfach. In der Praxis könnte sich herausstellen, dass der Teufel, wie so oft, im Detail steckt. Einen Prozess zu spezifizieren und auszuführen, der kontinuierlich Änderungen an einer Reihe von Tabellen oder Datenbanken vornimmt, ist mit einigem Aufwand verbunden. Es ist vorzuziehen, ein Werkzeug mit einer Online-Schnittstelle einzusetzen, das die Definition des Prozesses unterstützt und den Betrieb und das Housekeeping erleichtert.

Das Tool sollte eine flexible Möglichkeit bieten, den Umfang des Prozesses zu spezifizieren, d. h. die Menge der zu überwachenden Objekte auszuwählen, am besten durch generische Deklaration von Datenbanken, Tablespaces, Paketen. Für jede der überwachten Tabellen wird eine Datei benötigt, die die extrahierten Informationen entweder als SQL oder als LOAD-Input formatiert enthält. Als nächstes müssen die Zieltabellen erstellt werden, in die die festgestellten Änderungen eingefügt/geladen werden sollen. Die regelmäßige planmäßige Ausführung eines Prozesses, der eine wachsende Menge von Objekten überwacht, muss Namenskonventionen, mögliche Neustarts (Datensatz voll), Housekeeping (leere Dateien), das mögliche Auftreten neuer Tabellen (Überwachung der gesamten Datenbank), strukturelle Änderungen der betroffenen Tabellen usw. berücksichtigen. Ein Log-Analyse-Tool, das diese Dinge automatisiert und z.B. automatisch am Endpunkt des vorangegangenen Laufs fortfährt, ist für die üblichen Anforderungen in Rechenzentren bestens geeignet.

Es gibt viele Anlässe, Daten von einer Datenbank in eine andere weiterzuleiten: Nutzung kostengünstigerer Plattformen für die untergeordnete Verarbeitung, verbesserte Zugänglichkeit, Fehlertoleranz, Konvertierungsprojekte usw. Im Allgemeinen ist die Weitergabe eine klar definierte Aufgabe; zu Beginn müssen die Daten vollständig in das Zielsystem kopiert und danach periodisch synchronisiert werden, d.h. die Änderungen, die auf der Quellseite auftreten, müssen von Zeit zu Zeit an das Ziel weitergeleitet oder weitergegeben werden. Der Vorgang ist natürlich asynchron, die Quelle wartet nicht auf die Bestätigung durch das Ziel.

Da das Db2 Log alle Datenänderungen protokolliert, eignet es sich ideal als Basis für die Bereitstellung der auf der Quellseite des Prozesses erfolgten Aktualisierungen in den betreffenden Tabellen. Die Herausforderung liegt in der Synchronisation des initialen Load und der anschließenden kontinuierlichen Propagierung der Deltas und wie immer in den betrieblichen Anforderungen an einen robusten, leicht wieder startbaren und flexiblen Prozess. Flexibel z. B. in Bezug auf Scope-Änderungen, d. h. zusätzliche oder andere Tabellen und auch in Bezug auf Tabellenstrukturänderungen.

Am besten geeignet für eine robuste Propagierung ist ein Tool, das bei der Automatisierung von Erstkopie und Synchronisierung, bei Umfangsänderungen und Strukturänderungen hilft und nicht zuletzt eine lückenlose Aktualisierung der Zieltabellen gewährleistet.

Die Informationen im Db2-Log können Ihnen helfen, Wiederherstellungsprobleme zu erkennen. Die ULT4DB2™-Protokollanalyse kann Protokollereignisse, lang laufende Updater, Programme, die Updates zurücksetzen, Aktivitäten für Benutzer, Pläne oder Objekte und Punkte ohne Aktivität melden. Es ermöglicht Ihnen, die Ausführung der Berichte zu automatisieren. Darüber hinaus werden die Aktivitätsdaten in einem Repository gespeichert, damit Sie die Daten abfragen, Änderungen untersuchen und Protokollpunkte für die Wiederherstellung identifizieren können.

Rollbacks-Bericht
Änderungen werden rückgängig gemacht, wenn Programme abbrechen oder explizite Rollbacks durchführen. Mit ULT4DB2 können Sie die Protokolle analysieren und Stabilitätsprobleme in Ihren Anwendungen identifizieren. Wenn Programme zu viele Rollbacks auslösen, kann dies mit einem Anwendungsfehler zusammenhängen, der durch Korrektur der Programmlogik behoben werden kann.

Die Identifizierung von Programmen, die nur selten Daten übertragen, ist eine wichtige Aufgabe, da diese Programme die Wiederherstellbarkeit und Verfügbarkeit von Tabellen beeinträchtigen. Werden diese Programme übersehen, kann es zu Verzögerungen bei der Wiederherstellung kommen, wenn ein beträchtlicher Protokollbereich gelesen werden muss, um die Protokolländerungen erneut anzuwenden. Außerdem kann es die Db2-Neustartzeit beeinflussen. Der LONGRUNNERS-Report von ULT4DB2 kann Ihnen helfen, diese Programme zu identifizieren. Sie können dann in Erwägung ziehen, die Programme zu ändern und eine Logik hinzuzufügen, um die Änderungen häufiger zu übertragen. Es könnte erforderlich sein, diesen Bericht kontinuierlich auf Ihren kritischen Tabellen auszuführen, um sicherzustellen, dass die Wiederherstellbarkeit und Verfügbarkeit nicht gefährdet ist.

ULT4DB2 kann logische Wiederherstellungseinheiten und Ruhepunkte erkennen, d.h. Zeiträume ohne Aktivität gegenüber einer Gruppe von Objekten, die als Konsistenzpunkte verwendet werden können. Wenn Sie QUIESCE vermeiden, kann ULT4DB2 verwendet werden, um einen ruhigen Punkt zu finden, der als Point-in-Time für den Wiederherstellungsprozess verwendet werden kann, so dass das Wiederherstellungstool ein konsistentes Objekt ohne QUIESCE erstellen kann.

Aktivitätsberichte können bei der Identifizierung der Arbeitslast für Objekte, Benutzer, Programme und Jobs helfen. ULT4DB2 ermöglicht es dem Benutzer, die Protokollanalyse nach bestimmten Autorisierungs-IDs, Korrelationsnamen, Plänen und Objekten zu filtern. Die Aktivitätsberichte liefern auch Statistiken über die Anzahl der Einfügungen, Aktualisierungen, Löschungen und Protokolleinträge, die durch die Aktivität aufgezeichnet wurden.

Um festgelegte Änderungen rückgängig zu machen, können Sie das Dienstprogramm RECOVER verwenden, um die Tabelle zu dem Zeitpunkt wiederherzustellen, bevor die Änderungen vorgenommen wurden. In vielen Fällen könnten jedoch auch andere legitime Änderungen an der Tabelle vorgenommen worden sein. Wenn Sie die gesamte Tabelle bis zu einem bestimmten Zeitpunkt wiederherstellen, können diese legitimen Änderungen verloren gehen. Um sicherzustellen, dass nach oder während der fehlerhaften Änderungen, die Sie rückgängig machen möchten, keine anderen rechtmäßigen Änderungen vorgenommen wurden, können Sie einen Aktivitätsbericht ausführen, um zu bestätigen, dass die Wiederherstellung keine rechtmäßigen Änderungen rückgängig machen wird. Wenn die Aktivität zeigt, dass die Tabelle mehr rechtmäßige als unrechtmäßige Änderungen aufweist, können Sie UNDO SQL erzeugen, um die unrechtmäßigen Änderungen rückgängig zu machen. Wenn die Aktivität zeigt, dass die Tabelle mehr inkorrekte Änderungen als legitime Änderungen aufweist, kann es sinnvoller sein, die gesamte Tabelle zu einem Zeitpunkt wiederherzustellen, bevor die inkorrekten Änderungen begannen, und dann REDO SQL zu generieren, um alle legitimen Änderungen erneut anzuwenden. Mit ULT4DB2 können Sie einen Aktivitätsbericht ausführen und die Informationen in eine ACTIVITY-Tabelle laden. Anhand der Informationen kann dann entschieden werden, was die beste Vorgehensweise ist.

Wenn Sie beschließen, die Änderungen rückgängig zu machen, müssen Sie UNDO-SQL nur für das spezifische Programm, den Benutzer und den Job generieren, die die Aktualisierungen vorgenommen haben. Die Filterung sollte es Ihnen auch ermöglichen, das generierte SQL auf bestimmte Zeilen in der Tabelle zu beschränken, indem Sie eine WHERE-Klausel angeben. Das generierte SQL kann mit der Option MODE EXEC sofort ausgeführt werden. Wichtig ist, dass das Tool die UNDOs in der richtigen Reihenfolge generiert, z.B. sind Zeilen von Kindtabellen zu löschen, bevor die zugehörige Elternzeile gelöscht werden kann.

Es ist nur dann sinnvoll, RECOVER durchzuführen und legitime Änderungen wiederherzustellen, wenn die Anzahl der Änderungen, die Sie rückgängig machen wollen, relativ hoch ist und die Kosten für die Rückgängigmachung falscher Änderungen höher sind als die Wiederherstellung der gesamten Tabelle. Wenn eine Tabelle beispielsweise eine Million Zeilen hat und 70 Prozent der Zeilen versehentlich gelöscht wurden, während gleichzeitig 5 Prozent der Zeilen rechtmäßige Änderungen aufwiesen, dann ist es sinnvoller, die gesamte Tabelle wiederherzustellen und dann die 50000 Änderungen, die bei der Wiederherstellung verloren gingen, erneut durchzuführen. Das Tool sollte es Ihnen ermöglichen, genau den Protokollpunkt zu identifizieren, der zur Wiederherstellung der Tabelle verwendet werden sollte, bevor die Tabelle fälschlicherweise geändert wurde. Sie können dann REDO SQL für alle rechtmäßigen Änderungen generieren, die seit dem ausgewählten Wiederherstellungszeitpunkt vorgenommen wurden. Das REDO-SQL sollte die Arbeitseinheit ausschließen, die die fehlerhaften Änderungen vorgenommen hat, die Sie rückgängig machen wollen. Wichtig ist auch die flexible Handhabung von Triggern. Wenn auf beiden Seiten die gleichen Trigger implementiert sind, dürfen ausgelöste Änderungen normalerweise nicht weitergeleitet werden.

Mit Image-Kopien verfügt Db2 über ein großartiges Instrument zur Wiederherstellung von Tablespaces zu einem beliebigen Zeitpunkt, wenn etwas mit den Daten schief läuft. Aber wenn der gesamte Tablespace versehentlich gelöscht wird, löscht Db2 auch alle Informationen über die Image-Kopien. Db2 ist nicht in der Lage, die gelöschten Elemente wiederherzustellen. Hier bietet ULT4DB2 eine Lösung, um das Db2-Protokoll und alte Image-Kopien zu verwenden, um gelöschte Tablespaces wiederherzustellen und sie auf den Stand vor dem Löschen zu bringen.