レコードのアーカイブ

  • リリースバージョン: Zurich
  • 更新日 2025年07月31日
  • 所要時間:6分
  • レコードをアーカイブすることで、テーブルサイズの増加を管理し、クエリのパフォーマンスを向上させます。

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

    • 構成管理データベース (CMDB) CI レコードをアーカイブするには、CMDB データマネージャーを使用します。「Working with CMDB Data Manager」を参照してください。
    • メールをアーカイブするには、メールの保持プラグインをアクティブ化し、プラグインに付属するアーカイブルールと破棄ルールを使用します。アーカイブ機能を使用してメールテーブルに独自のアーカイブルールを作成しないでください。

    アーカイブのアクティブ化

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

    • データベースにアーカイブテーブルを作成します。アーカイブテーブルには、プリフィックス「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>
    • 複数の結合されたテーブルを単一のフラットファイルアーカイブテーブルに変換します。アーカイブテーブルは、ベーステーブルと拡張テーブルで構成されなくなりました。
      図 : 1. 複数の結合されたテーブルのフラットアーカイブテーブルへの変換
      複数の結合されたテーブルのフラットアーカイブテーブルへの変換
    • 参照フィールド値 (他のテーブルのレコードへの参照によって設定された値) を文字列値に変換します。アーカイブレコードには、アーカイブ時の参照フィールドの表示値が含まれています。
    • [システムアーカイブ] アプリケーションの [アーカイブテーブル] リストにモジュールを追加します。モジュール名は、「アーカイブ」という単語とアーカイブされたテーブルの表示名の組み合わせです。たとえば、添付ファイル [sys_attachments] テーブルのアーカイブモジュールは [アーカイブ添付ファイル (Archive Attachment)] です。
    • デフォルトのリストビューを使用してアーカイブテーブルのリストを作成します。
    • デフォルトのフォームビューを使用して、アーカイブテーブルのフォームを作成します。フォームでは、[Caller ID.Email] などのドット連結フィールドは除外されます。

    文字列に変換された参照値

    アーカイブされたデータは、他のテーブルへの参照フィールドを持たないフラットファイルとして格納されます。アーカイブプロセスは、他のテーブルへの参照を文字列値に変換します。

    参照フィールドの場合、文字列は発信者のユーザー名などの表示値を使用します。たとえば、インシデントの [発信者] 参照フィールドには、文字列「ITIL User」が表示されます。参照がドキュメント ID で、アーカイブルールに関連ドキュメント ID をアーカイブするオプションが含まれていた場合、この文字列は関連レコードのドキュメント ID になります。

    参照値に対する以後の変更は、アーカイブされたレコードには反映されません。たとえば、「John Smith」のユーザー名を「John A Smith」に変更すると、インシデントテーブルとユーザーテーブル間の参照により、すべてのアクティブなインシデントレコードで発信者が自動的に「John A Smith」と表示されます。ただし、アーカイブされたすべてのインシデントレコードには、アーカイブ時に存在していたユーザー名が表示されます。同様に、システムからユーザーを削除すると、現在のインシデントでは削除されたユーザーは発信者として表示されなくなります。ただし、アーカイブされたインシデントには、文字列「John Smith」が引き続き表示されます。これは、レコードがアーカイブされたときにこの値が使用されたためです。

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

    アーカイブされたテーブルは、アドホッククエリ用に最適化されていません。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] に設定します。

    アーカイブされた文字列の言語の設定

    国際化されたインスタンスでは、アーカイブプロセスは SYSTEM ユーザーの言語を使用して表示値の文字列を選択します。

    SYSTEM ユーザーがいない場合、インスタンスではデフォルトの言語設定を使用して表示値となる文字列が選択されます。特定の言語設定で SYSTEM ユーザーを作成するか、システムのデフォルト言語を設定してアーカイブされた文字列の言語を選択することができます。