Db2 ist verantwortlich, in einem Log alle Datenänderungen und vieles mehr zentral aufzuzeichnen.
Alle Änderungen werden dorthin geschrieben, neben der normalen Arbeit des Datenbankmanagementsystems. Mehrere große VSAM-Dateien werden zu diesem Zweck allokiert und stehen als Active Logs zur Verfügung. Sind diese gefüllt, werden die Daten auf Archive Logs 1-N geschrieben.
Die goldene Regel ist zeitbasiert und verlangt wenigstens eine Abdeckung von 24 Stunden für die Active Logs und wenigstens 30 Tage für die Archive Logs.
Das Tagesgeschäft erfordert, diese Logs zeitnah in Augenschein zu nehmen und zu pflegen.
Das Geschäft des Db2 Archive LOG Viewers ist nicht in dieser Art und Weise zu verstehen.
Er liest soviele Archive Logs wie ihm gegeben werden und reported in seinem Output nach absoluter Häufigkeit des Auftretens und seiner Größendimension.
Der Hauptgrund für diesen „light-weight Db2 Archive Log-Viewer“ war, mit einer einfachen und einzigen Methode Einblick zu Mengengerüsten und Häufigkeiten zum aktuellen Status des untersuchten DB2-Systems zu geben – ohne die produktiven Db2-Systeme zu gefährden. Der verantwortliche Db2-Experte erhält eine einfache, transparente neue Sichtweise über das aktuelle Geschehen und kann beurteilen, wer verantwortlich ist für die geschriebenen Daten.
Der gelieferte Output listet physisch und logische Log Reads.
Die folgenden Record und Event Types werden in Count und Lengh berücksichtigt:
Type 0002 Page Set Control Record
Type 0004 SYSCOPY utility
Type 0008 Non UR Control Record
Type 0010 System Event Record
Type 0020 UR Control Record
Type 0100 Checkpoint Record
Type 0200 UR-UNDO Record
Type 0400 UR-REDO Record
Type 0800 Archive Quiesce Record
Type 1000 Resource MGR assigned 1
Type 2000 Resource MGR assigned 2
Type 4000 Resource MGR assigned 3
Type 8000 Resource MGR assigned 4
Unknown Record Type
Manche Kunden stellen bei Tests Ungereimtheiten fest:
| Count | Length | |
| 1. Begin abort record | 8 | 1K |
| 2. Update space map bits | 141K | 17M |
| 3. Lock ptr if overflow updated | 3K | 469K |
| 4. Type 2 index update | 6M | 1G |
Ad 1
Aborts are never good. This is not just a negative SQLCODE. It is normally a program Abend and of course never good news to see.
Ad 2
This is a vast amount of spacemap updates. This raises the question „Are incremental Image Copies being taken?“ And the beneficial usage of TRACKMOD NO tablespace definition.
Ad 3
This is an awful lot of pointer records being created in a short period of time. This is hinting at the need to raise the FREEPAGE, PCTFREE and /or PCTFREE FOR UPDATE of the tablespaces.
Ad 4
This is a massive amount of data being logged. These index updates must be investigated and checked for VARCHAR columns being PADDED/NOT PADDED or inappropriate usage of columns or even excess indexes. The spectre of INDEX Splits is also present. Here the SOFTWARE ENGINEERING/SEGUS Product Workload Expert (WLX) Use Case „Index Split“ would greatly help.