| 交換モジュールでの監査の使用法 |  |
| 監査サーバでは、いわゆる監査ファイルのテーブルの内容を変更するデータベース処理をすべてログに記録します。これらの監査ファイルは交換モジュールで使用できます。監査ファイルはマルチサイト環境で役立ちます。これは、すべてのサイトのデータベースのデータが同一でなければならないからです。監査ファイルはデータ変換にも使用できます。 特定期間中の更新のみを交換すると、パフォーマンスが改善されます。この期間は、Export Data (Non-Regular) (daxch0233m000) およびExport Data (on a Regular Basis) (daxch0234m000) の各セッションで指定します。挿入、更新、および削除などの変更が処理されると、ASCII ファイルに書き出されます。テーブルの削除、消去、および作成などの処理は無視されます。 監査管理データは、結果として得られる ASCII ファイルに追加され、batchline-id、transaction-id、sequence-id、および指標を構成します。管理データは各行の最初に追加され、囲み文字や区切り文字など、その他のデータフィールドのようにフォーマット設定されます。 更新によって、ASCII ファイルに 2 行が書き出されます。1 つの行には、更新フィールドのキーフィールドと旧値が含まれています。もう 1 つの行には、キーフィールドを変更しない場合でも、キーフィールドと更新フィールドの新しい値が含まれています。 batchline-id は、ASCII ファイルの処理時に認識のために使用します。transaction-id と sequence-id は、トランザクションがエクスポートサイトと同じ順序で再生されていることを確認するために使用します。指標は、テーブルで実行される処理のタイプを定義するために使用します。旧値の挿入には文字 I、削除には文字 D、更新には文字 U、そして新しい値の更新には文字 N を使用します。 この機能を有効にするには、Exchange Schemes (daxch0101s000) セッションでBased on Auditチェックボックスをオンにします。 監査構成 データ交換に監査ファイルを使用する場合は、確実に以下を実行します。 関連するすべてのエクスポートテーブルを、監査プロファイルを定義して監査します。Generate Audit Configuration (daxch1201m000) セッションを使用して、交換スキームに監査プロファイルを生成することができます。このセッションは、Exchange Schemes (daxch0501m000) セッションの特定メニューから使用できます。 $BSE_TMP ディレクトリに十分なスペースを持たせます。これは、インポート中にすべての ASCII ファイルが 1 つのファイルにマージされるからです。このファイルには監査管理データが含まれており、transaction-id と sequence-id を基準にしてソートされています。 データベース内で行われた変更がすべて監査されたことを確認するため、データベース内で、監査中の各データベーストランザクションに関するトランザクション通知が作成されます。トランザクション通知はユーザトランザクション内に挿入され、交換で監査データの収集に使用されます。このように、常にすべての変更が処理されていることを確認します。 監査にもとづく交換 (XCH) モジュールに関する制限事項 概要 監査を基準にした交換を行っている場合、データベース処理がインポートされる順序は、終了ユーザがオリジナルのデータベースで実行したデータベース処理の順序と同じであることが重要です。監査にもとづいた交換モジュールでは、トランザクションの順序と各トランザクションでのデータベース処理の順序の保存が保証されます。このことは、複数のテーブルにかかわるトランザクションにも該当します。 交換モデルに関する制限事項 batchline-id は、エクスポートサイトとインポートサイトで同一でなければなりません。2 つのフィールドを 1 つのフィールドに統合する更新では、条件は使用しないでください。監査サーバではキーフィールドと変更済フィールドのログのみを記録するので、一方のフィールドのみを変更しても、もう一方の値は ASCII フィールドに表示されません。 監査に使用する交換モデルのインポート部分で条件を使用する場合には、注意してください。解決不可能な問題が作成される可能性があります。たとえば、2 つのフィールドを 1 つのフィールドに統合する条件は、更新には使用できません。監査サーバではキーフィールドと変更済フィールドのログのみを記録するので、一方のフィールドのみを変更しても、もう一方の値は ASCII フィールドに表示されません。 エクスポート テーブルと ASCII ファイルの定義が一致している必要はありません。ASCII フィールドに添付されていないテーブルフィールドは無視され、テーブルフィールドに添付されていない ASCII フィールドは空のままになります。 (以前のリリースのように) これらの名前を一致させる必要はなくなり、フィールドの関係 (エクスポート) (daxch0132s000) セッションでメンテナンスしたデータを使用して、テーブルフィールドを ASCII フィールドにリンクします。 条件を使用することはできません。 (この段階では) 定数を使用することはできません。 インポート (以前のリリースのように) これらの名前を一致させる必要はなくなり、フィールドの関係 (インポート) (daxch0122s000) セッションでメンテナンスしたデータを使用して、テーブルフィールドを ASCII フィールドにリンクします。 挿入については、定数、条件、関係などのすべての機能が利用可能です。 上書き (既存のレコードを挿入する場合) についても、Overwrite Conditionフィールドで true が返される場合に限り、同様です。 削除についても同様ですが、キーフィールドにしか値が割り当てられないことに注意してください (したがって、非キーフィールドに添付される条件には副次的な影響があり、おそらく正しく機能しません)。 Incrementにもとづく関係は、削除に関しては意味が無いことに注意してください。 更新については、すべての機能を使用するのは困難です。 [基準] フィールドが ｢デフォルト｣、｢固定値｣、または ｢増分｣ に定義されている関係は、有用でないため無視されます。 Field valueまたはConv. tableにもとづいた関係は、何も制約を受けずに使用できます。ただし、これらの関係が適用されるのは、キーフィールド (旧値) と変更済フィールド (新しい値) だけです。 監査サーバは、更新ごとにキーフィールドと変更済フィールドをログに記録するだけなので、その他のフィールドは不明です。したがって、ASCII ファイルの多数のフィールドが空のままになります。条件を使用する場合、アクセスしたすべてのフィールドに有効な値が入力されているかどうかは不明です。値が有効でない場合は、おそらく条件は実行されません。監査を使用する場合でも条件に柔軟性を持たせるために、Update Conditionフィールド条件を使用して条件を保護することができるようになっています。これは、(フィールド値レベルの) 条件が適切な値を返せるかどうかを、この条件で判断できることを前提としています。そのために、関数 changed ( <ascii_file>_<フィールド>) を条件内で使用できます。 条件別パラメータを導入すると、アクセスしたすべての ASCII フィールドが識別されるので、すべての ASCII フィールドに有効な値があるかどうかを判断できます。ただし、この認識は現行バージョンではまだ検討されていません。 ascii フィールドの旧値にアクセスするには、 not.curr(<ascii_file>_<フィールド>) old.value = <ascii_file>_<フィールド> not.curr(<ascii_file>_<フィールド>) | 新しい値を回復。 を使用します。テーブルフィールドの旧値は、tablefield の中にあります。(まず条件が実行され、値が返される場合にのみ tablefield に値が代入されます。) 注意 監査をマニュアルで構成する必要はありません。その代わりに、必要な監査プロファイルを生成することができます。この場合、Generate Audit Configuration (daxch1201m000) セッションを使用します。これはExchange Schemes (daxch0501m000) セッションの特定メニューから利用できます。 変更されていない値のログについては、監査サーバの動作を適合させることができます。1 つ以上のテーブルフィールドの値が更新処理で変更されなかったとしても、監査プロファイルを変更することで、監査サーバで強制的にそれらをログに記録させることができます。詳細については、監査構成管理ヘルプトピックを参照してください。 関連トピック 監査手順での複数行テキストの使用法 監査構成管理 |