最近リリースした環境に統合監査の設定をしたのですが、色々と問題があったので軽くまとめてみました。
構成は以下の通りです。
１．CPU負荷が高くなる
まず本番環境での設定前に開発環境でテストしたのですが、CPU使用率が10%程、高くなってしまいました。
監査要件が非常に細かくまた対象が多い為、作成した監査ポリシーは全部で20近くあるのですが、数が多いだけでなく、監査条件が複雑です。
以下、一例です（一番、複雑なものの例なので、全てがこんなに複雑という訳ではありませんが・・・）
CREATE AUDIT POLICY AUD_POL_01
ACTIONS all on USER_NAME.TABLE1,
WHEN '(
(instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host1'') <> 1 and instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host2'') <> 1
and instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host3'') <> 1 and instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host4'') <> 1
and instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host5'') <> 1
)
and
(instr(SYS_CONTEXT(''USERENV'',''HOST'') ,''host5'') <> 1
or
(instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER1'') <> 1 and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER2'') <> 1
and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER3'') <> 1 and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER4'') <> 1
and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER5'') <> 1 and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER6'') <> 1
and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER7'') <> 1 and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER8'') <> 1
and instr(SYS_CONTEXT(''USERENV'', ''CURRENT_USER'') , ''USER9'') <> 1
)
or
(instr(SYS_CONTEXT(''USERENV'', ''OS_USER'') , ''osuser1'') <> 1 and SYS_CONTEXT(''USERENV'', ''OS_USER'') <> ''osuser2''
and SYS_CONTEXT(''USERENV'', ''OS_USER'') <> ''osuser3'' and SYS_CONTEXT(''USERENV'', ''OS_USER'') <> ''osuser4''
and SYS_CONTEXT(''USERENV'', ''OS_USER'') <> ''osuser5'' and SYS_CONTEXT(''USERENV'', ''OS_USER'') <> ''osuser6''
)))'
EVALUATE PER STATEMENT;
実はこれでも要件をかなり絞った結果で、最初要件通りにポリシー作成した時には「ORA-46368: 監査ポリシーに簡単なルール条件がありません」が発生してしまいました。
サポートに確認したところ、「隠しパラメータ_re_num_complex_operatorで定義された内部制限があるため、監査ポリシー作成時に その条件の内部転換後の複雑なオペレーターの数がその制限値より多くなると、ORA-46368が発生する動作です」との事で、このパラメータの数値（デフォルト：1000）を増やす事でエラーは回避できますが、複雑なポリシーが多くなることで処理時間が長くなる可能性があるとの回答を得たので、なるべく頑張って簡素化したのです。
それでも開発環境でのテストでCPU使用率が10%上昇してしまったので、WHEN句の条件を削除して、監査結果を加工するツール側で対処する事になりました。
２．AUDIT/NOAUDIT文を同時実行する事でデッドロックまたはハングが発生する
監査ポリシーの内、いくつかは一定の時間帯のみ有効にする要件なので、cronを使用してAUDIT/NOAUDIT文を発行し、有効化/無効化を制御するようにしましたが、ここでAUDIT/NOAUDIT文同士でデッドロック(ORA-60)またはハング(ORA-4021)する状態が発生してしまいました。
サポートに問い合わせた結果、非公開のバグBug 30468833 : AUDIT POLICY CAUSED RC DEADLOCK AND SUBSEQUENT HANGに該当するとの事。
個別パッチは12.2でしか存在していないので運用で回避を図ったのですが、残念ながらエラーが再発しました。
と言うのもBug 30468833はAUDIT/NOAUDIT文同士の間だけで発生するのでは無く、AUDIT/NOAUDIT文と監査対象テーブルにアクセスする処理（SELECT処理など）の間でも発生する為、AUDIT/NOAUDIT文の実行タイミングをずらす運用では回避し切れないのです・・・
仕方無いのでAUDIT/NOAUDIT文の発行は止めて、特定の時間帯のみ監査する要件のものについては、監査結果を加工するツール側で対処する事になりました。
後日、追記。
Bug 30468833ではAUDIT/NOAUDIT文が「X-Mode」でrow cache lockを確保しようとし、Select文が「S-Mode」でrow cache lockを確保しようとする為にデッドロックが発生するのですが、ASH(ActiveSessionHistory)で確認したところ、このrow cache lockの種別はDC_USERSでした。
そこで、AUDIT/NOAUDIT POLICY <policy_name> BY <username>;で有効/無効を切り替える代わりに、alter audit policy <policy_name> condition xxx;で、条件に合致しなくなるように条件を変更する事で事実上、無効にする方式を検討しました。
以下のような条件を指定すれば監査条件に該当しなくなりますし、 BY <username>の指定が無いのでDC_USERSのrow cache lockの確保は不要になりそうです。
instr(SYS_CONTEXT('USERENV','HOST') ,'Dummy') = 1
10046イベントトレースを設定して確認した所、AUDIT/NOAUDIT POLICY文実行時と、alter audit policy実行時では内部で発行されるSQLも異なっていました。
サポートに確認した所
二つの方法は、両方とも監査ポリシーのディクショナリー情報を変更することであり、X-ModeでDC_USERSのrow cache lockを確保する必要があると認識しております
と言われてしまいましたが、alter audit policy方式に変更したところ、ハングは発生しなくなりました。
３．DBMS_AUDIT_MGMT パッケージで監査証跡を削除しても LOB セグメントの領域が解放されない (ドキュメントID 2107762.1)
これは不具合としてドキュメント化されていますが、上記2つの対応の結果、監査証跡が非常に増えてしまった為、領域が解放されない問題も大きくなってしまいました・・・
上記ドキュメントには「回避策なし」と記載されていますが、サポート問い合わせの結果、最新のパーティションのみ削除するように日付指定すれば領域解放される事が判明しました。
ただ運用ルールにそぐわないので、暫定対処的に手動で削除するしかありません。
統合監査は従来型監査に比べてきめ細かな監査条件を設定する事が可能ですが、条件の多いポリシーを多数、作るのは様々な問題を引き起こす原因となり得ます。
まあ、それは予め予想できていたので開発環境またはリリース前の本番環境で本番に近い状況で負荷テストする事や、無用な監査要件が無いか精査して欲しいとのお願いは前々から担当部署に伝えていたのですが……
