データベース監査ログを取得すると、その分マシンリソースを消費してしまいます。 その負荷が、ログ取得方法を選択する最大の要因になることがあります。 業務処理以外にリソースを使いたくないので、ログ取得によるリソース消費の少ないやり方を選択したい、というのはもっともなことでしょう。 しかし、例えば、「監査ログを取るとCPU負荷が30%上昇する」などと言われる通説は本当に正しいのでしょうか。

答えは"NO"です。

　その理由は単純です。
　それは「すべての操作のログ」を取得した場合の値だからです。 「すべての操作のログ」を取得する、これは一見正しいことのように思えます。 本記事などでも、ログの完全性を提言しています。

しかし、ここで言うログの完全性とは「必要なログに漏れがない」ことであり、 必要のないログもすべて取得する、ということとは違うのです。

　私たちが多くのお客様のシステム監査の支援をしていく中で、最も多いニーズは、アカウント管理、そして特権ユーザー操作に関わる監査ログを取得し、モニタリングするというものです。 この場合、取得する監査ログの種類は管理者権限による全操作、ユーザー作成・削除・権限変更操作のみです。 これだけなら、データベース操作のうち、0.1%にも満たない割合でしかありません。 さらに、SOX法対策として財務系のマスタテーブルなど重要オブジェクトに対する、アプリケーションを介さない操作を加えても、あわせて2～3%以下になることがほとんどです。

であれば、監査ログ取得によるCPUリソースの消費は、30%*(3/100)=0.9% 1%に満たない数値でしかない、となるのです。

　前提条件を、コントロールの視点で押さえることが重要なのです。 コントロールを効かせるための監査ログは、100%取得することが必要です。 言い換えれば、必要でないものは取得しなくてよい。 つまり、必要なログを100%取得できることが本質であり、要件です。

　少し脱線しますが、 リスクコントロールとしてのログの役割、あるいは要件を考えると、 すべてのログがあることと、必要十分なログがあることでは、監査業務の実効性に違いが出てきます。
　すべてのログがあったとしても、モニタリングしないようなログはただストレージを食いつぶしているだけで意味がありませんし、余計なデータが膨大にあると本来行うべき監査業務の妨げにしかなりません。 自社で求められるコントロールに必要な監査ログがすべて取得できていて、不要な監査ログがない状態が理想なのです。 アプリケーションで担保している、もしくはアプリケーションやネットワーク上でログ取得している操作については、あえてデータベースでの監査ログを取得する必要はありません。

　内部統制におけるログの役割を正しく認識し、リスクに対するコントロールとして監査ログを取得する。と考えると、おのずとデータベース監査ログの範囲が決まってきます。 その上で、ログ取得範囲を元に負荷を検証していけばいいのです。

　いわゆる負荷として標榜される値は、正しい数値ではあるでしょうが、机上の計算値であり、現実に則していない前提＝全操作のログ取得という条件下のものであることがご理解いただけたでしょうか。
各RDBMSベンダーも監査ニーズの高まりに応えて、バージョンアップ毎に監査ログ取得のCPUコストを下げる対応を行ってきていることも付け加えたいと思います。