アーカイブ |一般的な概要Summaryアーカイブアプリケーションは、毎日不要になったデータをプライマリテーブルから一連のアーカイブテーブルに移動します。アーカイブテーブルはフラット化されたテーブルです。ベーステーブルと子テーブルは単一のテーブルにフラット化され、参照フィールドは文字列に変換されます。 プラグイン： データアーカイブプラグインは、OOTBインスタンス上にデフォルトでアクティブになっています。 プラグインの詳細： 名前：Data Archiving ID：com.glide.auxdb ドキュメントへのリンク： データアーカイブ アーカイブルール： 「アーカイブルール」を作成して、アーカイブするデータを構成できます。アプリケーションには、これを設定できる [アーカイブルール] モジュールがあり、ルールの名前とテーブル名は必須フィールドです。ルールに条件を追加することをお勧めします。ルールが作成されると、[非アクティブ] ステータスに設定されます。[アクティブ] を [true] に設定してください。 ナビゲーション： [システムアーカイブ] > [アーカイブルール] アクティブか非アクティブかにかかわらず、テーブルごとに設定できるアーカイブルールは 1 つだけです。 どの SYS テーブルに対してもアーカイブルールを定義することはできません。例外はプロパティ glide.ui.permitted_tables にリストされています。 テーブルローテーションが有効になっているテーブルはアーカイブできません。 アーカイブルールの即時アクティブ化 スケジュール設定済みジョブがアーカイブルールを実行するまで待機しない場合は、アーカイブルールを手動で開始できます。 [システムアーカイブ] ➔ [アーカイブルール] に移動します。実行するアーカイブルールを選択します。[今すぐアーカイブを実行] 関連リンクをクリックします。 アーカイバージョブ： アーカイブルールが設定され、有効なアーカイブルールがある場合、アーカイバージョブはこれらのルールを処理してレコードをアーカイブします。[アーカイブ] スケジュール設定済みジョブは、1 時間の繰り返し間隔ジョブとして設定されます。glide.db.archiver と呼ばれるバックグラウンドスレッドにスレッドを渡すクラスを呼び出します。 アーカイブプロセスがシステムリソースを消費しすぎないようにするために、以下のアーカイブプロパティを使用して、アーカイブルールが 1 回の間隔で処理するレコードの数を制御できます。ただし、これらのプロパティを変更することはお勧めしません。 上記のプロパティを変更することで、アーカイバージョブが 1 時間を超えることができ、複数のアーカイブジョブを実行できます。 アーカイブプロセスは次の順序で行われます。 アーカイブルール基準を満たす N 件のレコードをロード (N はバッチサイズプロパティ)ar_* テーブルに挿入元のテーブルからレコードを削除するsys_archive_log エントリの作成 レコードがアーカイブされると、アーカイブログ (sys_archive_log) テーブルにエントリが作成され、レコードの xml がペイロードとして保存されます。デバッグに役立つ列がいくつかあります。[アーカイブ実行]、[アーカイブ]、[復元済み、ID]、[テーブルから] です。 アーカイブ実行：このレコードがアーカイブされた特定のアーカイブ実行の詳細が表示されます。 アーカイブ：条件を満たすアーカイブルール。 復元済み：レコードが復元されていない場合、このフィールドは空白になります。レコードが復元された場合、このフィールドにはレコードが復元された日時が含まれます。 移動元テーブル：レコードが削除されたテーブル。 アーカイブログは消去されないため、このテーブルからレコードを削除することはお勧めしません。アーカイブログエントリを削除すると、アーカイブされたレコードのデータを復元できなくなります。 [アーカイブログ] にエントリが存在することだけで、レコードが一度アーカイブされたこと (復元されたかどうかにかかわらず) をシステムが把握する必要があります。その場合、そのレコードはスキップされます。つまり、アーカイブエンジンは復元されたものを再アーカイブしません。 アーカイブルールでは、アーカイブする関連レコードを指定できるため、関連レコードと添付ファイルもアーカイブできます。元のレコードを復元する場合は、関連レコードも復元する必要があります (関連レコードテーブルはアーカイブ後に独立しているため、これは自動的には行われません)。 手動でレコードをアーカイブ： 各フォームビューに移動し、[レコードのアーカイブ] 関連リンクをクリックすると、各レコードを手動でアーカイブできます。 リストアクション [レコードをアーカイブ] を選択すると、リストビューから複数または単一のレコードを手動でアーカイブできます。 次のドキュメントへのリンク：クラシック環境の クラシック環境のリスト レコード推定値： アーカイブルールごとに、ジョブの次回実行時にアーカイブされるレコードの数を決定できます。これを行うには、各アーカイブルールの UI アクション [Record Estimate] をクリックします。 UI アクションがクリックされると、フォームに 2 つのフィールド [レコード推定値] と [推定日] が入力されます。 レコード推定値は、次回の実行でアーカイブされる推定レコードを提供します。 推定日は、推定実行が実行された現在の日時で更新されます。 アーカイブ破棄ルール： アーカイブ破棄ルールは、指定された期間が経過するとアーカイブされたデータを削除します。アーカイブ破棄者バッチプロセスは、アーカイブされたデータに対してアーカイブ破棄ルールを実行します。バッチプロセスの一部のパラメーターを設定できます。 ナビゲーション: [System Archiving] > [Archive Destroy Rules] 次のスクリプトを使用して、実行する破棄ルールごとにジョブスケジュールを作成します (注意：最初に準本番インスタンスでテストしてください)。new GlideArchiver().archiveDestroyByRule(xxxx);xxxx は破棄ルールの sys_id です。 ドキュメントへのリンク： 破棄ルールの作成 アーカイブ診断ページ： UI ページにアクセスするためのリンク：https://<your-instance>.service-now.com/ui_page.do?sys_id=71681edc9f3120007aaa207c7f4bcc2b このページには、アクティブなアーカイブルールの数の詳細、アーカイブされた合計レコード、およびアーカイブジョブの前回の実行が表示されます。 Related Linksデータのアーカイブブログ：データアーカイブのチュートリアル 既知の問題： PRB608048 - アーカイブスレッドは、長時間実行されるアーカイブプロセスのために別々のノードで並列実行できるため、パフォーマンスが低下し、ログにノイズエラーが追加されます。 PRB1296280/KB0695364 ： CI レコードがアーカイブされている場合、すべての cmdb_rel_ci レコードをアーカイブすることはできず、CMDB 識別エンジンが CI がアーカイブされている可能性を考慮せずにエラーをスローすると、CompactRelation エラーが発生するSyslog テーブルの主要な増加 PRB1164902/KB0780321 - アーカイブされたレコードがスコープ対象のアプリケーションからのものである場合、アーカイブ破棄ルールが機能しない PRB592993/KB0791832 - 復元されたレコードが多すぎるためにアーカイブスループットが妨げられている FAQ： 質問： ローテーションされたテーブルに対してアーカイブを有効にすることはできますか？いいえ、ローテーションされたテーブルに対してアーカイブを有効にすることはできません。 質問：関連レコードをアーカイブできますか？はい。[アーカイブ関連レコード] 関連リストを使用して、関連レコードをアーカイブルールに追加します。 質問：すべてのユーザーがアーカイブされたレコードを表示できますか？デフォルトでは、アーカイブされていない同じ名前のテーブルの ACL が使用されます。たとえば、アーカイブされたインシデント [ar_incident] テーブルは、アーカイブされていないインシデント [incident] テーブルに対して定義された ACL を使用します。詳細については、 データのアーカイブ を参照してください。 質問： 破棄ルールを使用してアーカイブログからレコードを削除できますか？破棄ルールは、アーカイブテーブル(ar*)からのみレコードを削除するために使用できます。 質問： テーブルクリーナーを使用してアーカイブログから を削除できますか？まだ破棄されていないアーカイブログからレコードを削除すると、復元できなくなります。