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 Schattendatenbankbei Inkrementalprüfung Original <-> Schattendatenbank:
die Originaldatenbank und die Schattendatenbank, falls deren DBDIR vorhanden istbei 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.