データのアーカイブ

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む6読むのに数分
  • データのアーカイブでは、テーブルサイズの増加を管理し、古いデータをアーカイブします。不要になったデータをプライマリテーブルから一連のアーカイブテーブルに移動します。

    インスタンスの実行時間が長くなるほど、関連性がなくなったデータが蓄積される可能性が高くなります。たとえば、2 年前のタスクレコードは、通常、現在アクティブなタスクよりも関連性が低くなります。古いデータは、システムリソースを消費し、クエリとレポートの速度を低下させるため、最終的にパフォーマンスの問題を引き起こす可能性があります。

    監査または履歴の目的でこのデータを削除できない場合:
    1. データをアーカイブし、すぐにアクセスできないようにするアーカイブルールを設定して、システムリソースを解放します。
    2. 指定された期間が経過するとデータを削除する破棄ルールを設定します。
    3. アーカイブおよび破棄ルールのバッチ処理をコントロールするアーカイブおよび破棄ルールのプロパティを設定します。

    Now Platform で作成したタスク [task] テーブルなどのコアテーブルのレコードとカスタムテーブルのレコードをアーカイブできます。

    構成管理データベース (CMDB) CI レコードをアーカイブするには、Working with CMDB Data Manager を使用します。

    図 : 1. データをアーカイブするメリットの例
    データをアーカイブするメリットの例

    データのアーカイブではサービスプロバイダーのドメイン分離をサポートしています。たとえば、ドメインに属するインシデントは、アーカイブされた後でもドメイン指定を保持します。

    注:
    メールをアーカイブする場合は、メールの保持プラグインをアクティブ化し、プラグインに付属するアーカイブルールと破棄ルールを使用します。アーカイブ機能を使用してメールテーブルに独自のアーカイブルールを作成しないでください。

    アーカイブルールによって作成されたテーブルとモジュール

    アーカイブルールを初めてアクティブ化すると、次のアクションが実行されます。

    • データベースにアーカイブテーブルを作成します。アーカイブテーブルには、プリフィックス「ar_」が付いたプライマリテーブルと同じ名前が付いています。たとえば、インシデント [incident] テーブルをアーカイブすると、アーカイブテーブルは [ar_incident] になります。
    • アーカイブされた各レコードの XML バージョンをsys_archive_logテーブルに格納します。このアーカイブログはすべてのアーカイブルールに対して同じテーブルであり、この動作を変更することはできません。また、これは sys_id が参照フィールドの表示値とともに格納される唯一の場所です。
    例:<assigned_to>Fred Luddy</assigned_to> の場合、sys_archive_log レコードは次のとおりです。
    
    <assigned_to display_value="Fred Luddy">5137153cc611227c000bbd1bd8cd2005</assigned_to>
    • 複数の結合されたテーブルを単一のフラットファイルアーカイブテーブルに変換します。アーカイブテーブルは、ベーステーブルと拡張テーブルで構成されなくなりました。
    • 参照フィールド値 (他のテーブルのレコードへの参照によって設定された値) を文字列値に変換します。アーカイブレコードには、アーカイブ時の参照フィールドの表示値が含まれています。
    • [システムアーカイブ] アプリケーションの [アーカイブテーブル] リストにモジュールを追加します。モジュール名は、「アーカイブ」という単語とアーカイブされたテーブルの表示名の組み合わせです。たとえば、添付ファイル [sys_attachments] テーブルのアーカイブモジュールは [アーカイブ添付ファイル (Archive Attachment)] です。モジュール名をクリックすると、アーカイブテーブルのレコードが表示されます。
    • デフォルトのリストビューを使用してアーカイブテーブルのリストを作成します。
    • デフォルトのフォームビューを使用して、アーカイブテーブルのフォームを作成します。フォームでは、[Caller ID.Email] などのドット連結フィールドは除外されます。
    図 : 2. 複数の結合されたテーブルのフラットアーカイブテーブルへの変換
    複数の結合されたテーブルのフラットアーカイブテーブルへの変換

    アーカイブされたデータのクエリ

    アーカイブされたテーブルは、アドホッククエリ用に最適化されていません。sys_id の表示値、作成日、およびプライマリキーのインデックスエントリのみが含まれています。

    このため、すべての優先度 1 のアーカイブ済みインシデントを検索するなど、アーカイブされたテーブルに対してオンデマンドクエリを実行しないでください。代わりに、インデックス付きフィールドに対してのみ検索します。たとえば、インシデント INC100001 または特定の日付に作成されたインシデントを検索します。

    アーカイブテーブルと ACL

    デフォルトでは、アーカイブされていない同じ名前のテーブルの ACL が使用されます。たとえば、アーカイブされたインシデント [ar_incident] テーブルは、アーカイブされていないインシデント [incident] テーブルに対して定義された ACL を使用します。

    特定のアーカイブテーブルの ACL を作成し、glide.security.enable_archive_table_acls プロパティを [true] に設定することで、アーカイブテーブルへのアクセスを明示的に管理できます。その後、システムは次の 2 つのパスのいずれかに従います。
    1. アーカイブテーブルに対して 1 つ以上のアクティブな ACL が定義されている場合、それらの ACL がアーカイブテーブルへのアクセスをコントロールします。
    2. アーカイブテーブルに ACL が定義されていない場合、システムはデフォルトの動作に戻り、アーカイブされていないバージョンのテーブルに ACL を使用します。
    注:
    2 つのパスは相互に排他的です。アーカイブテーブルの ACL がアクセスを拒否した場合、システムはデフォルトの動作に戻そうとしません。

    読み取り操作の読み込み のみが評価され、他の操作 は実行されません。

    実行計画 UI はこのロジックを認識し、それに応じて情報を表示します。たとえば、最初の ACL をアーカイブテーブルに追加すると、アーカイブテーブルの ACL がアーカイブされていない (元のデータ) テーブルの ACL を「マスク」していることが示されます。

    アーカイブされたテーブルに既存の ACL がある場合、glide.security.enable_archive_table_acls プロパティを [true] に設定しない限り、それらは無視されます。これらの新しくアクティブ化された ACL は、アクセスの問題を引き起こす可能性があります。この発生を防ぐために、システムは glide.security.enable_archive_table_acls プロパティを次のように設定します。
    • glide.security.enable_archive_table_acls プロパティのないインスタンスでは、デフォルト値の [false] が使用されます。
    • アップグレードされたインスタンスはプロパティをインストールしません。アーカイブテーブルの ACL の動作を有効にするには、プロパティを手動で追加して [true] に設定する必要があります。
    • zboot インスタンスは、 プロパティをインストールし、[true] に設定します。