Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

DA-LOG-Aufbereitung durch SEDI70

Das Programm SEDI70 bereitet entsprechend der Eingabeparameter die Dateien der Mediarecovery, CAT-LOG- und DA-LOG-Dateien (Logging-Dateien für den Catalog-Space und die Anwender-Spaces) für den Druck auf.

Für die Interpretation der Ausgabe sind die folgenden Informationen wesentlich:

  • Die CAT-LOG-Datei enthält alle Änderungen der Metadaten, die während einer DBH-Session auf dem Catalog-Space durchgeführt werden. Da die Metadaten im Catalog-Space als Tabellen hinterlegt sind, werden diese Änderungen als DMLs (INSERT, UPDATE, DELETE) protokolliert.
    Änderungen der Metadaten können von folgenden Quellen stammen:

    • von einem Anwender (z.B. durch CREATE TABLE, ALTER TABLE ...)

    • vom System (z.B. durch Eintragen der DA-LOG-Dateien in den SYS_INFO_SCHEMA.SYS_DA_LOGS oder durch Modifizieren des Änderungszeitstempels in der SYS_INFO_SCHEMA.SYS_SPACES beim ersten Update innerhalb einer DBH-Session auf einen Space)

  • Alle Änderungen der Anwender-Tabellen, die während einer DBH-Session auf Anwender-Spaces mit eingeschalteter logischer Datensicherung durchgeführt werden, sind auf der DA-LOG-Datei protokolliert.
    Auf dem Anwender-Space existiert eine System-Tabelle mit der Table-ID 1. Sie dient zur Gewährleistung der Konsistenz zwischen Catalog-Space und Anwender-Space.

  • CAT-LOG- und DA-LOG-Dateien sind in sogenannte Units unterteilt. Welche Units in einer CAT-LOG- bzw. DA-LOG-Datei enthalten sind, steht in der CAT-REC-Datei bzw. in der SYS_INFO_SCHEMA.SYS_DA_LOGS. Neue Units werden z.B. in folgenden Fällen angelegt:

    • bei einem Eröffnen einer Datei (Sessionbeginn, CAT-/DA-LOG-Wechsel, COPY CATALOG)

    • bei logischen Aufsatzpunkten (COPY SPACE)

    • bei Markierungen (LOAD)

  • Änderungen werden in der Reihenfolge protokolliert, in der sie anfallen. Endgültig festgeschrieben wird eine Änderung nur durch COMMIT WORK. Die Identifikation zwischen Änderung und zugehörigem COMMIT WORK erfolgt über die 28 Byte lange Benutzeridentifikation. Ist zwischen der Änderung und einem nachfolgenden COMMIT WORK ein Wiederanlaufkennsatz (Unitsatz) vorhanden, so ist die Änderung zurückgesetzt..
  • Änderungen, die die gleiche Benutzeridentifikation und die gleiche Statement-ID haben, stammen von einer externen Anweisung. So erzeugt z.B. eine Mengenupdate-Anweisung mit 100 Treffern 100 Updatesätze auf den Loggingdateien. Trat bei dem n-ten Treffer ein Fehler auf (z.B. Datenfehler), so tritt eine Cancel-Anweisung in Kraft. D.h. alle n Update-Schritte mit der gleichen Benutzeridentifikation und der gleichen Statement-ID sind nicht gültig. Die Transaktionsklammer ist hiervon nicht betroffen, d.h. sie ist weiterhin offen, ein späterer COMMIT WORK schreibt alle übrigen Änderungen des Auftraggebers fest.
Grundsätzlich gilt: Ausgaben auf SYSOUT und SYSLST unterliegen nicht der Aufwärtskompatibilität. Das Layout der Ausgabe kann sich bei Versionswechsel ändern.