Level1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。ベロいよいよ、AUDIT_TRAIL最終回となりました。今まで、いくつかの監査を検証してきましたが、最後に監査について押さえておくべきポイントをまとめてみたいと思います。オブジェクト監査オラクルへのログイン、ログアウトといったアカウンタビリティの監査は文監査を実施することで対応可能です。パフォーマンスに与える影響もほとんど無いことが分かった。視することにより、「いつ」「だれが」「どこから」「どのくらい」オラクルに接続したかを分析することが可能となり、その間発行したSQLもある程度絞ることが可能となる。歩と言うことができると思います。特定のオブジェクトを対象に監査を実施するためにはオブジェクト監査を行う。アカウンタビリティといった広範なものではなく、ターゲットを絞り、オブジェクトへのアクションを監査する。全てのオブジェクトを監査対象にするとレスポンスに大きく影響する。監査をセッション毎に行った場合、監査を実施しない場合と比べ約18%のレスポンスダウンとなった。アクション毎に監査を実施した場合だと約30%のレスポンスダウンとなった。(Audit_Trail第3回参照)さらに、オラクルに標準的に実装されている監査機能に加えユーザ自身がカスタマイズできる監査としてファイングレイン監査がオラクル9iから実装されている。(Audit_Trail第5回参照)3)監査実施後の運用についてパフォーマンスを考慮して、監査を実施してもその後の運用をしっかり行っていかなければ、無用なエラーを引き起こしてデータベース管理者の手を煩わすことになる。今回は初期化パラメータをAUDIT_TRAIL=DBとして運用してみたが、SYSTEM表領域にAUD$というテーブルを作成し、そこに全ての監査レコードが格納されていく。監査を実施したけれど、その後の運用は行っていないサイトではAUD$表が一杯になることが予想される。「監査は付加的なものだから、放っておいても大丈夫」などと考えていると痛い目に会うかも知れない。AAA;でAAAユーザのログイン/ログアウトの監査を実施している場合を考えてみる。AUD$表が一杯で拡張不可能な状態にしてみる。エラーが発生しました」といったエラーでログインできなくなる。ここで、SESSION監査を実施していることすらデータベース管理者が知らなければ、原因究明に無駄な時間が割かれてしまう。今、データベースにどのような監査が実施され、監査レコードがどの程度なのかをしっかり把握し、定期的にメンテナンスすることが重要となる。初期化パラメータAUDIT_TRAIL=OSとした場合もAUDIT_FILE_DESTに指定したディレクトリにora_.audもしくはsxxx_.oraというファイルが大量に作成される。ora_.audは専用接続sxxx_.audはMTS接続これらのファイルのメンテナンスを定期的に行うことが重要となる。範なセキュリティについて述べることができませんでしたが、機会があれば、セキュリティについて検証してみたいと思います。reserved.トップページ企業概要プライバシーポリシ。