Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Systemumgebung

&pagelevel(3)&pagelevel

Auswirkungen auf den Datenbankbetrieb

Greift BCHECK bei dem Prüflauf auf die Originaldatenbank zu, so spricht man von einem Online-Prüflauf, der parallel zu einem SHARED-RETRIEVAL-Datenbankbetrieb möglich ist.

Wenn BCHECK nicht auf die Originaldatenbank zugreift, spricht man von einem Offline-Prüflauf, der parallel zu jedem Datenbankbetrieb stattfinden kann.

Prüfläufe können zueinander parallel ablaufen.

Vor jedem BCHECK-Prüflauf müssen Sie die zu prüfende Datenbank bzw. Schattendatenbank mit folgendem Kommando zuweisen:

/ADD-FILE-LINK LINK-NAME=DATABASE,FILE-NAME=dbname.DBDIR[.copyname]

BCHECK berücksichtigt beim Start ggf. eine zugewiesene UDS/SQL-Pubset-Deklaration (siehe Handbuch „Datenbankbetrieb“, Pubset-Deklarations-Jobvariable). Eine fehlerhafte Zuweisung führt zum Programmabbruch.

Kohärenzprüfung

BCHECK prüft bei jedem Prüflauf die Datenbanken auf Kohärenz, auf deren DBDIR er zugreifen kann. Er prüft auf Kohärenz:

  • bei Totalprüfung:
    die Originaldatenbank bzw. die Schattendatenbank

  • bei Inkrementalprüfung Original <-> Schattendatenbank:
    die Originaldatenbank und die Schattendatenbank, falls deren DBDIR vorhanden ist

  • bei Inkrementalprüfung Schattendatenbank-neu <-> Schattendatenbank-alt: die neuere Schattendatenbank und die ältere Schattendatenbank, falls deren DBDIR vorhanden ist

Im Folgenden sind die bei den verschiedenen Prüfläufen benötigten Datenbankdateien dargestellt:

Totalprüfung Original

Original jedes zu prüfenden Realm

Original des DBDIR

Bild 5: Systemumgebung bei einer Totalprüfung von Originalrealms

Totalprüfung Schattendatenbank

zu prüfende Realms der Schattendatenbank

DBDIR der Schattendatenbank

Bild 6: Systemumgebung bei einer Totalprüfung der Schattendatenbank

Inkrementalprüfung Original <-> Schattendatenbank

Original jedes zu prüfenden Realm

Original des DBDIR

Realms der Schattendatenbank

evtl. DBDIR der Schattendatenbank (siehe "Systemumgebung")

Bild 7: Systemumgebung bei einer Inkrementalprüfung Original <-> Schattendatenbank

Inkrementalprüfung Schattendatenbank-neu <-> Schattendatenbank-alt

die zu prüfenden Realms jeder Schattendatenbank

DBDIR zur älteren Schattendatenbank oder beide DBDIR’s (siehe "Systemumgebung")

Bild 8: Systemumgebung bei einer Inkrementalprüfung Schattendatenbank <-> Schattendatenbank

Benötigte Arbeitsdateien

BCHECK benötigt für einen Prüflauf zwei Arbeitsdateien, die er automatisch unter der Benutzerkennung, unter der Sie BCHECK gestartet haben, auf gemeinschaftlicher Platte anlegt und nach normaler Beendigung des Laufs wieder löscht. Die Dateien haben standardmäßig die Dateikettungsnamen SCRTCH1 und SORTWK:

SCRTCH1

benötigt BCHECK bei jedem Prüflauf zum Speichern eines Seitenverzeichnisses.

SORTWK

benötigt der von BCHECK benutzte SORT bei einer Sortierungsprüfung und beim Prüfen von Indexwerten zum Sammeln und Sortieren der Prüfsätze. Siehe auch Handbuch „SORT (BS2000)“.

Wollen Sie die beiden Arbeitsdateien explizit einrichten, so müssen diese folgende Eigenschaften besitzen:

Arbeitsdatei-1

Dateikettungsname SCRTCH1

Zugriffsmethode=SAM, feste Satzlänge

Das Mengengerüst der zwischenzuspeichernden Daten ergibt sich aus der Formel:

seitenanzahl x 16 Bytes

seitenanzahl

Anzahl relevanter Seiten aller zu prüfenden Realms, d.h. Summe der Realm-Größen in Datenbankseiten, abzüglich der Act-Key-0-Seiten, FPA-Seiten und leeren Seiten.

Die Primärzuweisung für die Arbeitsdatei-1 sollte sich am Mengengerüst der zwischenzuspeichernden Daten orientieren. Es sollte immer eine angemessene Sekundärzuweisung erfolgen für den Fall, dass der Speicherplatz erweitert werden muss.

Arbeitsdatei-2

Dateikettungsname SORTWK

Zugriffsmethode=PAM

Das Mengengerüst der zu sortierenden Daten ist bei Totalprüfung mit den beiden folgenden Formeln ermittelbar:

  • Formel RSQ-Prüfung:

    26 x anzahl-prüfsätze Bytes

  • Formel Indexwertprüfung und Schlüsselwertprüfung:

    schlüssellänge x anzahl-prüfsätze Bytes

Sie können das Mengengerüst bei einem SORTING-Lauf ermitteln, indem Sie zunächst CHECK SUMMING ausführen, die verdoppelte Summe der unter „DIAGNOSTIC SUMMARY OF BCHECK“ ausgewiesenen Prüfobjekte aus RECORD/TABLE-OCCURRENCES, CHAIN-SET-MEMBERSHIPS, REFERENCES BETWEEN TABLE-OCCURRENCES und REFERENCES FROM TABLES TO MEMBER-RECORDS bilden und diesen Wert als anzahl-prüfsätze in der Formel RSQ-Prüfung nutzen.

Bei einem SORTING-Lauf mit Schlüsselwertprüfung addieren Sie auf den so ermittelten Wert noch den Wert aus der Formel Schlüsselwertprüfung, wobei Sie als anzahl-prüfsätze den doppelten Wert von USERKEYS BETWEEN TABLES AND MEMBER-RECORDS einsetzen.

Bei einem SORTING-Lauf mit Indexwertprüfung addieren Sie auf den bisher ermittelten Wert noch den Wert aus der Formel Indexwertprüfung, wobei Sie als anzahl-prüfsätze den doppelten Wert von REFERENCES BETWEEN TABLE-OCCURRENCES einsetzen.

Als Schlüssellänge nutzen Sie jeweils die mittlere, mit der Satzanzahl gewichtete Schlüssellänge aller Schlüssel, wobei Sie bei der Indexwertprüfung für Schlüssel mit Duplikaten jeweils zusätzlich 6 Byte berücksichtigen müssen. Zur Vereinfachung können Sie mit der Nutzung der maximalen Schlüssellänge und evtl. zusätzlichen 6 Byte, falls Duplikate erlaubt sind, sicherstellen, dass es zu keinem Ressourcenengpass bei der Sortierung kommt.

Bei Inkrementalprüfungen bezieht sich das Mengengerüst auf die Änderungen, die gegenüber dem Vergleichsstand erfolgt sind.

Die Arbeitsdatei-2 wird vom SORT benötigt, wenn der Arbeitsspeicher, der durch die Anweisung SORTCORE beeinflusst werden kann, nicht ausreicht. Die Primärzuweisung sollte sich daher am Mengengerüst der zu sortierenden Daten orientieren. Es sollte immer eine angemessene Sekundärzuweisung erfolgen, für den Fall, dass der Speicherplatz erweitert werden muss.