4

Oracle11gR1をベースにした新しいシステムのデータベーススキーマを設計しています。100近くのテーブルを持つメインスキーマを特定しました。これらはフロントエンドJavaアプリケーションからアクセスされます。

50近くのテーブルで変更された値を監査する必要があります。これは、すべての行で実行する必要があります。

つまり、1つの行の場合、テーブルMYSYS.T1に50（またはそれ以上またはそれ以下ですが、最小1）の行が存在する可能性がありMYSYS_AUDIT.T1_AUDます。すべての列エントリの古い値と、から利用可能な新しい値がある可能性がありますT1。

DBAは観察を行い、この方法に反対するようアドバイスしました。彼が言ったのは、個別のスキーマはすべての操作に対して追加のI/Oを意味するからです。基本的に、AUDITスキーマは、値の分析と入力を行うためにのみ使用されます（したがってSELECT、INSERT）。

「別個のスキーマは追加のI/Oを意味する」というのは本当ですか？正当な理由が見つかりませんでした。

AUDITデータは改ざんされるべきではないので、私には論理的に見えます。したがって、別のスキーマです。

また、からいくつかのテーブルをアーカイブするための別のスキーマを設計しましたMYSYS。テーブルからMYSYS_ARCテープにバックアップされるか、十分な時間が経過すると削除される可能性があります。

いくつかの統計：
スキーマ 内のいくつかのテーブル（20、30に近い）がMYSYS約5,000万行に拡大する可能性があります。
合計4TBのディスク容量を要求しました。
MYSYS_AUDITスキーマはその10倍になる可能性がありますがMYSYS、3か月以上保持することはありません。
MYSYSのいくつかのテーブルには、次のトランザクション/分があります。

  • テーブルへの同じ数の挿入を意味するINSERT100 。MYSYSMYSYS_AUDIT
  • テーブル内の1000UPDATEは、MYSYSテーブル内の同じ数の挿入を意味しMYSYS_ADITます。

質問：
これらすべてを踏まえて、改善点を提案していただけますか？

  1. 別のスキーマはディスクI/Oに影響しますか？（スキーマごとに1つの追加I / O？）
  2. 一般的な提案はありますか？

形：

+-------------------+          +-------------------+
|       MYSYS       |          |     MYSYS_AUDIT   |
|                   |          |                   |
|    1. T1          |          |     1. T1_AUD     |
|    2. T2          |          |     2. T2_AUD     |
|    3. T3          |--------->|     3. T3_AUD     |
|    4. T4          |(SELECT,  |     4. T4_AUD     |
|     .             | INSERT)  |      .            |
|     .             |          |      .            |
|     .             |          |      .            |
|  100. T100        |          |    50. T50_AUD    |
+-------------------+          +-------------------+
        |
        |
        |
        |
        |(INSERT)
        |
        |
        |
        *
+-------------------+
|   MYSYS_ARC       |
|                   |
|    1. T1_ARC      |
|    2. T2_ARC      |
|    3. T3_ARC      |
|    4. T4_ARC      |
|     .             |
|     .             |
|     .             |
|  100. T100_ARC    |
+-------------------+

これとは別に、読み取り専用の権限のみを持つスキーマがさらに2つありますが、主にそれらはアドホックな目的であり、それらのパフォーマンスは気にしません。

提案：
いくつかの提案があります。私たちは次のことに同意します。

  1. 論理的分離のスキーマ。
  2. TRIGGERAUDITテーブルにデータを挿入するため。
  3. _AUDテーブル名にはサフィックスはありません。:)
  4. ARCHIVEスキーマテーブルにデータを入力する手順。
  5. 間隔に基づいて分割します。

私たちは分析しています...

  1. ワークスペースマネージャーオプション。

APCまたはdpbradelyのソリューションを受け入れる前に、質問はまださらなる提案のために開かれています。

4

5 に答える 5

3

個別のスキーマを持つことは間違いなく進むべき道です。他のものとは別に、同じテーブル名を使用できることを意味しますMYSYS.T1。MYSYS_AUDIT.T1これは、長い名前 (> 25 文字) のテーブルがある場合に役立ちます。

しかし、個別のスキーマの主な利点は、監査テーブルを偶発的またはいたずらな改ざんから保護できることです。

トリガーなどからの監査行の挿入の影響は、テーブルの所有者に関係なく残ります。

一般的なテーブル設計のアドバイス

監査テーブルをメイン テーブルと同じ構造にすることをお勧めします。したがって、リビジョン番号など、監査に必要なメタデータ列がある場合は、それらをメイン テーブルに含めます。また、監査テーブルに古い値ではなく新しい値を入力します。つまり、新しいレコードが に挿入されるとMYSYS.T1、一致するレコードが に挿入されMYSYS_AUDIT.T1ます。既存のレコードが更新されたときにMYSYS.T1、新しいレコードを に挿入しMYSYS_AUDIT.T1ます。監査テーブルの最新のレコードがメイン テーブルの現在のレコードと同じである場合、監査テーブルの検証とレポート作成がはるかに簡単になります。

トリガーの使用

監査は複雑である必要はありません。必要なのは、 内の挿入ステートメントだけですbefore insert or update or delete trigger。これらは、データ ディクショナリ ビュー USER_TAB_COLUMNS から簡単に生成できます。

于 2010-04-27T11:00:07.033 に答える
3

オブジェクトを別のスキーマに配置しても余分な I/O は発生しません。おそらく誤解があり、DBA が言いたかったのは、監査が存在すると余分な I/O が発生するということでした。あなたはそれを実装します。

于 2010-04-27T10:38:27.130 に答える
1

また、お金があれば、OracleのTotalRecallを見てください。

于 2010-04-27T23:49:46.033 に答える
1

APCの答えに加えて。

Workspace Managerを見てみると、失敗したり無効になったりする可能性があるため、トリガーよりも優れている可能性があります。

于 2010-04-27T11:19:44.597 に答える
1

監査データの範囲分割を見てみましょう。監査データをより安価なストレージに送りたい場合があります。パーティショニングにより、たとえば 1 か月分のデータを別のサーバーに簡単に送信できます。または、1 か月以上前の監査レコードを削除します。

http://www.orafaq.com/wiki/Interval_partitioning

于 2010-04-27T11:17:22.457 に答える