DB2 Universal Database - Systemverwaltung


Arbeitsweise der Prüffunktion

Die Prüffunktion zeichnet überprüfbare Ereignisse auf, einschließlich solcher, die sich auf Datenbankexemplare auswirken. Aus diesem Grund ist die Prüffunktion eine unabhängige DB2-Komponente, die auch ausgeführt werden kann, wenn das DB2-Exemplar gestoppt ist. Wenn die Prüffunktion aktiv ist, wird beim Starten eines gestoppten Exemplars die Protokollierung der Datenbankereignisse dieses Exemplars wieder aufgenommen.

Der zeitliche Ablauf beim Schreiben von Prüfsätzen in das Prüfprotokoll kann sich deutlich auf die Verarbeitungsleistung der Datenbanken in dem betreffenden Exemplar auswirken. Das Schreiben der Prüfsätze kann synchron oder asynchron zum Auftreten der Ereignisse erfolgen, die die Generierung dieser Prüfsätze auslösen. Der Wert des Konfigurationsparameters AUDIT_BUF_SZ des Datenbankmanagers legt fest, wann das Schreiben der Prüfsätze stattfindet.

Wenn der Wert dieses Parameters Null (0) ist, wird der Schreibvorgang synchron ausgeführt. Das den Prüfsatz auslösende Ereignis bleibt im Wartestatus bis der Prüfsatz auf die Platte geschrieben ist. Die Wartezeit beim Schreiben der einzelnen Prüfsätze wirkt sich nachteilig auf die Verarbeitungsleistung von DB2 aus.

Wenn der Wert des Parameters AUDIT_BUF_SZ größer als Null ist, wird der Schreibvorgang asynchron ausgeführt. Wenn der Parameterwert für AUDIT_BUF_SZ größer als Null ist, entspricht er der Anzahl 4 KB-Seiten, die zum Erstellen eines internen Puffers verwendet wird. In dem internen Puffer werden Prüfsätze zwischengespeichert, bis sie gruppenweise auf die Platte geschrieben werden. Die Anweisung, die den aus einem Prüfereignis resultierenden Prüfsatz generiert, wartet nicht, bis der Prüfsatz auf die Platte geschrieben ist, sondern kann die Verarbeitung ohne Verzögerung fortsetzen.

Beim asynchronen Schreiben verbleiben die Prüfsätze gegebenenfalls für einige Zeit in einem nur teilweise gefüllten Puffer. Damit dies nicht über zu lange Zeiträume der Fall ist, erzwingt der Datenbankmanager das regelmäßige Schreiben der Prüfsätze auf die Platte. Ein berechtigter Benutzer der Prüffunktion kann den Prüfpuffer auch mit einer expliziten Anforderung leeren.

Je nachdem, ob der Schreibvorgang synchron oder asynchron erfolgt, ergeben sich Unterschiede beim Auftreten von Fehlern. Im asynchronen Modus gehen möglicherweise einige Datensätze verloren, da die Prüfsätze gepuffert werden, bevor sie auf die Platte geschrieben werden. Im synchronen Modus geht, wenn überhaupt, ein Datensatz verloren, da durch den Fehler höchstens ein Prüfsatz nicht geschrieben werden kann.

Die Einstellung des Prüffunktionsparameters ERRORTYPE legt fest, wie auftretende Fehler zwischen DB2 und der Prüffunktion behandelt werden. Wenn die Prüffunktion aktiv und der Prüffunktionsparameter ERRORTYPE auf AUDIT gesetzt ist, wird die Prüffunktion genau so behandelt wie jede andere DB2-Komponente. Ein Prüfsatz muß geschrieben werden (im synchronen Modus auf die Platte, im asynchronen Modus in den Prüfpuffer), damit ein Prüfereignis, das sich auf eine Anweisung bezieht, als erfolgreich eingestuft wird. Bei jedem in diesem Modus festgestellten Fehler wird für die Anweisung, die einen Prüfsatz ausgelöst hat, ein negativer SQLCODE-Wert an die Anwendung zurückgegeben. Ist der Parameter ERRORTYPE auf NORMAL gesetzt, werden alle von db2audit gemeldeten Fehler ignoriert und der SQLCODE der Operation wird zurückgegeben. Weitere Einzelheiten zum Parameter ERRORTYPE der Prüffunktion (und weiteren zugehörigen Parameter) finden Sie in Anwendungsszenarios der Prüffunktion.

Je nach der API- oder SQL-Anweisung und den Prüfeinstellungen des DB2-Exemplars können für ein bestimmtes Ereignis keine, eine oder mehrere Prüfsätze generiert werden. Beispiel: Eine SQL-Anweisung UPDATE mit einer Unterabfrage SELECT kann zur Generierung eines Prüfsatzes mit den Ergebnissen der Berechtigungsprüfung für das Zugriffsrecht UPDATE einer Tabelle und zur Generierung eines weiteren Prüfsatzes mit den Ergebnissen der Berechtigungsprüfung für das Zugriffsrecht SELECT einer Tabelle führen.

Für dynamische DML-Anweisungen (DML = Data Manipulation Language) werden Prüfsätze für alle Berechtigungsprüfungen zum Zeitpunkt der Anweisungsvorbereitung (Prepare) generiert. Die erneute Verwendung dieser Anweisungen durch den selben Benutzer wird nicht erneut überprüft, weil zu diesem Zeitpunkt keine Berechtigungsprüfung stattfindet. Wenn jedoch eine der Katalogtabellen mit Berechtigungsinformationen geändert wurde, werden in der nächsten Arbeitseinheit die Berechtigungen für die zwischengespeicherten dynamischen SQL-Anweisungen erneut geprüft und ein oder mehrere neue Prüfsätze erstellt.

Für ein Paket, das ausschließlich statische DML-Anweisungen enthält, ist die Berechtigungsprüfung, mit der geprüft wird, ob ein Benutzer die erforderliche Berechtigung zum Ausführen des Pakets hat, das einzige prüfbare Ereignis, das einen Prüfsatz generieren könnte. Die Berechtigungsprüfung und die gegebenenfalls erforderliche Prüfsatzerstellung für die statischen SQL-Anweisungen des Pakets werden beim Vorkompilieren oder Binden des Pakets durchgeführt. Die Ausführung der statischen SQL-Anweisungen in dem Paket ist nicht prüfbar. Wird ein Paket entweder explizit vom Benutzer oder implizit vom System erneut gebunden, werden Prüfsätze für die von den statischen SQL-Anweisungen benötigten Berechtigungsprüfungen generiert.

Für Anweisungen, bei denen die Berechtigungsprüfung zum Zeitpunkt der Ausführung erfolgt (z. B. Data Definition Language (DDL) oder GRANT- und REVOKE-Anweisungen), werden bei jeder Verwendung dieser Anweisungen Prüfsätze generiert.
Anmerkung:Bei der Ausführung von DDL lautet die aufgezeichnete Abschnittsnummer für alle Ereignisse (ausgenommen Kontextereignisse) im Prüfsatz Null (0), und zwar unabhängig von der tatsächlichen Abschnittsnummer der Anweisung.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]