皆さま、Oracleデータベース監査証跡のメンテナンスってどうしてますか？

標準監査やファイングレイン監査、統合監査等々の監査証跡を取るだけ取って放って置くととんでもないサイズになって、そのせいで表領域が圧迫されたりと良いことがありません。

メンテナンスのため手動やスクリプトでプロシージャを動作させ不要な監査証跡を削除するのもありなのですが、どうせならOracleの設定だけで自動で削除してくれたほうが何かと手間がなくていいですよね。

そこで監査証跡の自動削除を実施するための「LAST_ARCHIVE_TIMESTAMP」の自動設定と「CLEAN_AUDIT_TRAIL」の自動実行ジョブを作ったので参考にしてみてください。

記載内容の例では「AUDIT_TRAIL_AUD_STD」となっていますが、UnifideAuditであれば「AUDIT_TRAIL_UNIFIED」に変更するなど用途によって変更してください。

また、複数指定できる「AUDIT_TRAIL_DB_STD」等だと、ジョブ作成時に失敗することがありますので、個別指定（AUDIT_TRAIL_AUD_STDなど）で設定されることをお勧めします。

以下の設定例はマルチテナント環境で、CDB/PDBすべてに同一の設定を行う場合の内容となります。

非マルチテナント環境で実行したい場合は「container => DBMS_AUDIT_MGMT.CONTAINER_ALL」とその前の行にある「,」（赤字部分）を削除の上、実行してください。

■監査証跡レコードのデフォルトのクリーンアップ間隔の初期設定

BEGIN
DBMS_AUDIT_MGMT.INIT_CLEANUP(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
default_cleanup_interval => 999,
container => DBMS_AUDIT_MGMT.CONTAINER_ALL);
END;
/

※「AUDIT_TRAIL_UNIFIED」の場合、ORA-46250エラーが発生しますがデフォルトでクリーンアップが実行可能なため、クリーンアップ用の初期化を行う必要はありません。

■LAST ARCHIVE TIMESTAMPの自動設定ジョブ

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'AUDIT_TIMESTAMP_AUD',
job_type => 'PLSQL_BLOCK',
job_action => 'DECLARE
last_timestamp_days NUMBER := <保存期間>;
BEGIN
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
last_archive_time => TRUNC(SYSTIMESTAMP)-last_timestamp_days,
container => DBMS_AUDIT_MGMT.CONTAINER_ALL);
END;',
start_date => to_date('<日時指定> <時刻指定>','yyyy/mm/dd hh24:mi:ss'),
repeat_interval => 'FREQ=DAILY;INTERVAL=1',
end_date => NULL,
enabled => TRUE,
comments => 'Set audit last archive time.');
END;
/

<保存期間>：監査証跡を何日前以降を削除対象とするか指定（数値）　例：90
<日時指定>：ジョブを実行開始する日付を指定　例：2023/02/28
<時刻指定>：ジョブを実行開始する時間を指定　例：00:00:00

このジョブは、毎日ジョブ実行日から<保存期間>を引いた日付をLAST ARCHIVE TIMESTAMPに設定します。
但し、時刻はジョブ実行時間に関わらず、必ず「00:00:00（UTC）」で設定されます。

例として2023/02/28 00:00:00から23:59:59の間にジョブが実行された場合、設定されたLAST ARCHIVE TIMESTAMPは2023/02/28から<保存期間>を引いた日付の 「00:00:00（UTC）」となります。
UTCとJSTには+9:00の差がありますので、UTCの「00:00:00」はJSTの「09:00:00」ですのでご注意ください。

当初、SYS_EXTRACT_UTCでの設定も考慮しましたが、ジョブ実行が何らかの影響でずれてしまったときなどLAST ARCHIVE TIMESTAMPの時刻がずれてしまい解りずらくなるため、TRUNCで日付のみに切り詰め、設定される時間が必ず「00:00:00（UTC）」にすることにしています。

そのため、例にある90日を<保存期間>としたい場合は、1日プラスして「91」としてください。
この場合、JSTで90日プラス15時間前がセットされます。

■CLEAN_AUDIT_TRAILの自動実行ジョブ

BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'AUDIT_DELETE_AUD',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
use_last_arch_timestamp => TRUE,
container => DBMS_AUDIT_MGMT.CONTAINER_ALL);
END;',
start_date => to_date('<日時指定> <時刻指定>','yyyy/mm/dd hh24:mi:ss'),
repeat_interval => 'FREQ=DAILY;INTERVAL=1',
end_date => NULL,
enabled => TRUE,
comments => 'Auto audit delete.');
END;
/

<日時指定>：ジョブを実行開始する日付を指定　例：2023/02/28
<時刻指定>：ジョブを実行開始する時間を指定　例：00:15:00

ジョブの設定が完了したら、以下のコマンドで確認してみましょう。

■設定したジョブの確認

select
JOB_NAME,
OWNER,
ENABLED,
TO_CHAR(START_DATE, 'YYYY-MM-DD HH24:MI:SS.FF6') as START_DATE,
STATE
from DBA_SCHEDULER_JOBS
where JOB_NAME like '%_AUD';

設定したジョブのSTATEが「SCHEDULED」となっているかと思います。

実際にジョブが実行できたかどうかを確認するためには以下のコマンドを実行して確認します。

■設定したジョブの実行確認（初回実行後に実施）

select
JOB_NAME,
TO_CHAR(ACTUAL_START_DATE, 'YYYY-MM-DD HH24:MI:SS.FF6') as ACTUAL_START_DATE,
RUN_DURATION,
STATUS
from DBA_SCHEDULER_JOB_RUN_DETAILS
where JOB_NAME like '%_AUD';

設定したジョブのSTATUSが「SUCCEEDED」となっていればジョブは正常に実行されています。

ジョブの実行が確認出来たら、LAST ARCHIVE TIMESTAMPの設定時刻を確認します。

■設定されたLAST ARCHIVE TIMESTAMPの確認（初回実行後に実施）

select
AUDIT_TRAIL,
TO_CHAR(LAST_ARCHIVE_TS, 'YYYY-MM-DD HH24:MI:SS.FF6') as LAST_ARCHIVE_TS
from DBA_AUDIT_MGMT_LAST_ARCH_TS;

LAST_ARCHIVE_TSを確認して保存期間に設定した日付を差し引いた日の「00:00:00.000000」に設定されているかと思います。
しつこいようですがこれはUTCですので、JSTでは「09:00:00.000000」となりますのでご注意ください。

なお、AUDIT_TRAILカラムに表示されるDBMS_AUDIT_MGMT定数は以下の通りです。

STANDARD AUDIT TRAIL → AUDIT_TRAIL_DB_STD
FGA AUDIT TRAIL → AUDIT_TRAIL_FGA_STD
OS AUDIT TRAIL → AUDIT_TRAIL_OS
XML AUDIT TRAIL → AUDIT_TRAIL_XML
UNIFIED AUDIT TRAIL → AUDIT_TRAIL_UNIFIED

いかがでしたでしょうか？
皆さまの業務の一助になれば幸いです。

それではまた！