管理の手引き


監査機能の動作

監査機能は、データベースのインスタンスに作用を及ぼすものを含む監査可能なイベントを記録します。 この理由で、監査機能は DB2 インスタンスが停止されるとしても動作可能な DB2 の独立した部分となっています。 監査機能が活動状態である場合、そして停止されたインスタンスが開始されるとき、 インスタンスにあるデータベース・イベントの監査が再開します。

監査ログへの監査レコードの書き込みタイミングは、 インスタンスのデータベースのパフォーマンスに有効な影響を与えます。 監査レコードの書き込みは、 そのレコードの生成をもたらすイベントの出現により同期的にまたは非同期的に行われます。 AUDIT_BUF_SZ データベース・マネージャーの構成パラメーター値は、 いつ監査レコードの書き込みが行われるかを決定します。

このパラメーターの値がゼロ (0) であると、書き込みは同期的に行われます。 監査レコードを生成しているイベントは、 そのレコードがディスクに書き込まれるまで待機します。 それぞれのレコードに関連したこの待機は、DB2 のパフォーマンスを減少させます。

AUDIT_BUF_SZ の値がゼロより大きい場合、レコードの書き込みは非同期で行われます。 ゼロより大きいとき AUDIT_BUF_SZ の値は、 内部バッファーの作成に使用される 4 KB ページの数値となります。 その内部バッファーは、 一群の監査レコードをディスクに書き込む前にいくつかの監査レコードを保持するために使用されます。 監査イベントの結果として監査レコードを生成するステートメントは、 レコードがディスクに書き込まれるまで待機することなく、その動作を継続できます。

非同期のケースでは、 監査レコードを空があるバッファーにしばらくの間とどめておくこともできないわけではありません。 これを拡張期間の間に起きることを防ぐには、 データベース・マネージャーが監査レコードの書き込みを定期的に行わせるようにします。 さらに監査機能の許可ユーザーの、 明示的な要求により監査バッファーをフラッシュすることができます。

同期のレコード書き込みか、非同期のレコード書き込みかによって、 エラーが発生したときに違いが出てきます。 非同期モードでは、監査レコードがディスクに書き込まれる前にバッファーに入れられるので、 いくつかのレコードが失われる可能性があります。 同期モードでは、エラーが書き込みを防ぐことのできる監査レコードは多くて 1 つなので、 レコードが 1 つ失われる可能性があります。

ERRORTYPE 監査機能パラメーターの設定により、 どのように DB2 と監査機能の間でエラーを管理するかを制御します。 監査機能が活動状態にあり、監査機能パラメーター ERRORTYPE の設定が AUDIT であるとき、 その監査機能は DB2 の他の部分と同じように扱われます。 監査レコードを、正常に考慮され、 ステートメントに関連した監査イベント (同期モードではディスク、 非同期モードでは監査バッファー) に書き込まなければなりません。 このモードで実行時にエラーに遭遇したときはいつでも、 1 つの負の SQLCODE を、監査レコードを生成するステートメントのアプリケーションに戻します。 エラー・タイプが NORMAL にセットされると、 次に db2audit にあるエラーが無視され、その操作の SQLCODE が戻されます。 ERRORTYPE の監査機能パラメーター (および他の関連するパラメーター) に関する付加情報については、 監査機能使用のシナリオを参照してください。

API または SQL ステートメントおよび DB2 インスタンスの監査設定に応じて、 特定のイベントに対して監査レコードが何も生成されなかったり、 1 つまたはいくつかの監査レコードが生成されたりします。 たとえば、SELECT 副照会による SQL UPDATE ステートメントは、 結果として 1 つの監査レコードを生じ、 そこには表の UPDATE 特権に対する許可検査の結果を含んでいます。 さらに、別の監査レコードには、表の SELECT 特権に対する許可検査の結果が含まれています。

動的なデータ操作言語 (DML) のステートメントの場合、 ステートメントが準備された時点ですべての許可検査の監査レコードが生成されています。 同一ユーザーによるステートメントの再使用では、 その時に許可検査が行われないため再度監査されることはありません。 しかしながら、特権情報を含んでいるカタログ表のいずれかに変更が行われた場合には、 次の作業単位において、 キャッシュされた動的 SQL ステートメントのステートメント特権は検査され、 1つ以上の新規監査レコードが作成されます。

静的 DML ステートメントだけを含んでいるパッケージの場合、 監査レコードを生成する可能性のある監査可能なイベントだけが、 ユーザーの特権でそのパッケージを実行できるかどうかを調べるために許可検査となります。 パッケージがプリコンパイルされるかまたはバインドされる時、 パッケージにおける静的な SQL ステートメントのために必要とされる許可検査および考えられる監査レコードの作成は実行されます。 パッケージ内部の静的 SQL ステートメントの実行は、監査することはできません。 ユーザーにより明示的に、またはシステムにより暗黙的に 1 つのパッケージがバインドされるとき、 静的 SQL ステートメントにより必要とされる許可検査のために複数の監査レコードが生成されます。

許可検査が実行時間に行われるステートメント (たとえば、 データ定義言語 (DDL)、GRANT、および REVOKE ステートメント) の場合、 これらのステートメントが使用されるときにはいつでも監査レコードが生成されます。
注:DDL を実行するとき、 監査レコードのすべてのイベント (コンテキスト・イベントを除く) のために記録されたセクション数は、 ステートメントの実際のセクション数がどんなものであってもゼロ (0) にリセットされます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]