Audit Trailについての検証 その２
Oracleデータベースの監査機能である、Audit Trail に関する性能検証、機能検証をLevel1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。
Level 1）Audit sessionなどによる文監査
Level 2）オブジェクト監査
Level 3）ファイングレイン監査 Basic
Level 4）ファイングレイン監査 Advanced
*eBook版のダウンロードをご希望の方は、画像をクリック
＜Audit Trailについての検証 ～その２～＞
ペンネーム ベロ
では、今週から本格的に監査を実行していこと思います。
先週は、audit_trail=dbと設定し、全てのセッション確立をSYS.AUD$に格納する
ように設定してある。
また、LPS（Logon Per Second）を計測してパフォーマンスに与える影響を確認
してみた。
今回は、このセッション監査をもう少し掘り下げていこうと思います。
□■ セキュリティー編 □■□■□■□■□■□■□■□■□■□■□■□■□■
では、セッション監査を行った後、セキュリティーに関して見るべき項目をあげ
てみる。使うディクショナリは先週同様「DBA_AUDIT_SESSION」
（DBA_AUDIT_SESSION内の見るべきポイント）
-------------------------- ------------------------------------------------
TIMESTAMP,LOGOFF_TIME : ログイン - ログオフの時間が長いセッションが
いないか監視することが大事。
-------------------------- ------------------------------------------------
LOGOFF_LREAD,LOGOFF_PREAD : セッション内での論理読込、物理読込の量を監視
し、大量の読込であればそのオペレーションの妥
当性を確認しなければならない。
-------------------------- ------------------------------------------------
RETURNCODE : 0以外のものを監視する必要がある。
-------------------------- ------------------------------------------------
SESSION_CPU : セッション内でのCPU使用時間を監視することに
より、ループプロセスなどの発見に繋がる可能性
がある。
select os_username osuname
,username dbuname
,sessionid sesid
,(logoff_time-timestamp)*24*60*60 conn_time
,logoff_lread lread
,logoff_pread pread
,action_name act_name
,returncode retcd
,session_cpu ses_cpu
from dba_audit_session;
OSUNAME DBUNAME SESID CONN_TIME LREAD PREAD ACT_NAME RETCD SES_CPU
------- ------- ----- --------- -------- -------- -------- ----- -------
kshin SYSTEM 32857 4546 221647 12726 LOGOFF 0 2418 <-(1)
・・・ ^^^^
oracle ORABM 32856 2330 12392624 1 LOGOFF 0 230963
select vs.sql_text
,du.username
,vs.executions execs
,vs.loads loads
,vs.disk_reads d_reads
,vs.buffer_gets buf_gets
,vs.rows_processed row_proc
,vs.cpu_time cpu_t
from v$sql vs, dba_users du, dba_audit_session da
where da.sessionid in (32856,32857)
and vs.parsing_user_id = du.user_id
and du.username = da.username
and vs.last_load_time between to_char(da.timestamp
,'yyyy-mm-dd/hh24:mi:ss')
and to_char(da.logoff_time
,'yyyy-mm-dd/hh24:mi:ss');
SQL_TEXT DBUNAME EXECS LOADS D_READS BUF_GETS ROW_PROC CPU_T ------------------ ------- ----- ----- ------- -------- -------- ------ declare a varchar2 ORABM 1 1 1 12392590 0 230961 SELECT * FROM DBA_ SYSTEM 4 1 3955 4016 132 220 SELECT * FROM V$SE SYSTEM 1 1 1 60 1 4 ・・・ （省略）
このSQLでは、セッションを特定してSQLを検索することはできない。あくまでも、
SQLのロードされた時間とユーザを指定していることに注意してほしい。
DBA_AUDIT_SESSIONだけの情報では、セッション内で行った操作を追跡すること
はできない。
（ちなみにLAST_LOAD_TIMEは最後にロードされた時間なので、上記SQLでは、取得
できないSQL文もでてくる）
+-------------------------------------------------------------------------+ | 結局、ユーザのアカウンティング（誰が、いつ、どこからログインしたのかを | | 監視）以外に、セッション内での操作履歴を見ようとするとセッション監査だ | | けでは無理ということ! | +-------------------------------------------------------------------------+
アカウンティング以外であれば、監査レベルを上げ、特定オブジェクトに対する
SQLを監査するオブジェクト監査を実施する必要がありそうだ。
ということで、次週からはオブジェクト監査について検証していきます。
□■ パフォーマンス編 □■□■□■□■□■□■□■□■□■□■□■□■□■
前回のLPSでは、ある瞬間にLogonが集中した場合のLogon限界値を示しています。
だから、Logonが集中するという特別な状況以外は役に立たない指標と言えるかも
知れない。
そこで、TPC-Cのベンチマークプログラムにより50セッションでの負荷テストを実
施してみよう。監査有り / 無しそれぞれ、ベンチマークを5回実行して、その平均
TPS（Transaction Per Second）を算出する。
（ちなみに、このTPC-CベンチマークによりOracleサーバは高負荷（特にCPUが100%
で振り切った状態）になる）
では、ベンチマークスタート！！
(1) 監査無しの場合・・・・・・・131 TPS (2) 監査有りの場合・・・・・・・131 TPS
うーん。計ったように同じ値になってしまった。
+--------------------------------------------------------------------------+ | 普通のOLTP処理においてセッション監査を実行しても、パフォーマンスには影響 | | を与えないということ！ | +--------------------------------------------------------------------------+
では、次週からはオブジェクト監査について検証していきます。
やっと、梅雨明けでいきなり夏＆夏ばての茅ヶ崎より