一括削除および過剰データ管理に関する推奨事項Descriptionテーブルからデータを一括削除することが望ましい場合や必要な場合があります。事前定義された一連の条件を使用してこの削除を実行することも、単にテーブルを消去することもできます。状況に関係なく、破損したデータやアクセスできないデータを除き、ニーズに合った削除方法があります。この記事で説明するデータ削除方法は、最も簡単な方法から最も高度な方法まで、次のとおりです。 UI アクションクローン除外ルールテーブルクリーンアップポリシーJavaScript 最適なアプローチの決定はケースバイケースであり、特定の状況で最適なオプションを決定するのはユーザーの責任です。大量のレコードの場合、クローン除外ルール以外の高速オプションはありませんが、これらは状況に適していない場合があります。テーブルから数百万件のレコードを削除するビジネスクリティカルなニーズがあり、この記事の方法で必要な時間だけ待つことができない場合は、ServiceNow でケースをオープンしてテクニカルサポートエンジニアに相談できます。 データ削除の要求に関する ServiceNow のポリシー:プラットフォームのデータ関係は非常に複雑であり、単純なデータベーステーブル管理をはるかに超えています。拡張されたテーブルモデル、参照フィールド、ビジネスロジック、ワークフロー、およびカスタマイズにより、「バックエンド」からデータを簡単に削除することはできません。ServiceNow では、影響やそのようなアクションを考慮することができません。一見無害に見えるレコードを削除しても、プラットフォームの安定性に影響し、以前は問題なく動作していることがわかっていたビジネスロジックから予期しない動作が発生する可能性があります。これらのレコードの存在によってビジネスクリティカルな操作が使用できなくなる場合、そのデータの存在によって機能停止が発生するか、または発生する可能性がある場合、またはそれらのレコードが欠陥/問題の結果である場合を除き、ServiceNow がデータ削除に介入することはできません。 免責事項: この記事のどの部分も、徹底的な検証とテストを行わずにライブインスタンスにそのまま実装することを意図したものではありません。この記事の内容は、特定の状況に対する保証または適合性を保証するものではありません。この記事で提供するスクリプトまたは実装の使用は、自己責任で行ってください。 計画 データを一括削除する方法を決定する前に、次の重要な点を考慮することが重要です。 どのカスケード削除が発生しますか?(子/関連レコード)どの参照が壊れるか、またはクリアされますか?どのビジネスルールがトリガーされるか?どのワークフローが実行されますか?他にどのような機能が影響を受ける可能性がありますか?(クロススコープ権限の生成など)削除は更新セットによって追跡されますか? 事前に適切な調査を行うことで、削除の潜在的な副作用を判断し、必要に応じて後で整理するための適切な計画を立てることができます。たとえば、壊れた参照を置き換える計画を立てることができます。関連する変動要素を十分に理解することで、計画を進めることが安全で責任があるかどうかについて、より多くの情報に基づいた意思決定を行うことができます。考えられる切り戻し計画を検討することも重要です。ほとんどの場合、多数のレコードのエクスポートとダウンロードは実行できないため、一括削除の切り戻しオプションは制限されています。London で利用可能な Delete Recovery ツールは、削除を記録してロールバックし、壊れた参照を復元することもできるため、これに対する優れた回答です。削除復旧ツールについては、 ロールバックと削除の復旧を参照してください。 とはいえ、魔法の [元に戻す] ボタンはありません。 London の高度な削除復旧ツールを使用しても、計画を策定して実行するときは細心の注意を払う必要があります。 UI アクションによる削除 長所: 非常にシンプル 短所: 低速UI トランザクションクォータルールによるキャンセルに対して脆弱性柔軟性がない これは「簡単な」アプローチと見なすことができます。テーブルからすべてのレコードを削除する場合は、そのテーブルの sys_db_object レコードを開き、[すべてのレコードを削除] UI アクションをクリックするだけです。デフォルトでは、このような UI トランザクションは約 5 分に制限されています。その期間を超えると、自動的にキャンセルされます。したがって、テーブルに大量のデータまたは多くのビジネスルールまたはカスケード削除をトリガーするデータが含まれている場合は、操作を一度に実行するためにトランザクションクォータを増やす必要があります。リストビューを使用してテーブルをフィルタリングし、複数のレコードを選択して、[削除] UI アクションをクリックすることもできます。ただし、ページネーションにより、一度に選択して削除できるレコードの数には制限があります。したがって、多数のレコードの場合、リストビューアプローチは実行できない場合があります。この方法で削除すると、ビジネスルールとワークフローがトリガーされ、更新セットによって追跡されます。これらの UI アクションは、GlideRecord オブジェクトと deleteMultiple() 関数の使用に内部的に依存しています。したがって、これらのメソッドのパフォーマンスは、次のスクリプトに匹敵します。 var gr = new GlideRecord("table_name"); gr.query(); gr.deleteMultiple(); クローン除外ルールによる削除 長所: 非常に高速 短所: 非常に柔軟性がなく、テーブル全体が切り捨てられる壊れた参照と孤立レコードが残る可能性があるインスタンスのクローンを作成する必要があり、本番環境では実行できない クローンによってデータが除外されると、除外されたテーブルは切り捨てられます。テーブルの切り捨ては比較的コストのかかる操作であり、テーブルからすべてのレコードを削除するよりもはるかに高速です。ただし、他のテーブルの除外されたレコードへの参照は壊れます。つまり、参照元フィールドには、存在しなくなったレコードの sys ID が引き続き含まれます。意図しない結果が生じる可能性があるため、その点を考慮することが重要です。直接テーブルの切り捨てのもう 1 つのリスクは、孤立データです。クラスごとのテーブル (TPC) 階層の場合、各拡張テーブルはデータベース上に個別のテーブルとして存在します。階層内の個別の物理テーブルが結合されて、完全な行が形成されます。階層内のテーブルを切り捨てると、その物理テーブルからデータが削除されますが、親テーブルや子テーブルの結合された行は残ります。この方法で破損したデータは孤立していると見なされ、プラットフォームレベルで通常の方法ではアクセスできなくなります。したがって、(タスクおよび CMDB 階層とは異なり) TPC 階層の一部であるテーブルを除外する場合は、孤立データの作成を避けるために、すべての親テーブルと子テーブルも除外する必要があります。 テーブルクリーンアップポリシーによる削除 長所: Set-it-and-forget-it 機能。スケジュールに従ってバックグラウンドで実行柔軟な構成オプションビジネスルール/ワークフローをトリガーしない (テーブルに iterativeDelete 属性がある場合を除く)参照カスケードルールを優先 短所: 低速メンテナンス用に設計されており、1 回限りの削除には適していません これは、特定の時間が経過しても更新されていないクローズ済みタスクなど、いくつかの単純な基準に適合するレコードを定期的に削除する場合に適したソリューションです。テーブルクリーナージョブは 1 時間に 1 回実行されます。テーブルの iterativeDelete 属性が true に設定されていない限り、基になるコードは GlideRecord に依存して削除を実行しません。これは、削除によってビジネスルールまたはワークフローがトリガーされないことを意味し、パフォーマンスを大幅に向上させることができます。これは、更新セットによって削除が監査または追跡されないことも意味します。ただし、前述の属性が存在し、true に設定されている場合、これらのエンジンはトリガーされます。テーブルにテーブルクリーンアップポリシーを実装する場合は、特に大規模なテーブルで、クリーンアップ条件を支援するサポートインデックスがあることを確認する必要があります。 30 日間更新されていない「クローズ済み」ステータスのインシデントレコードを削除するテーブルクリーンアップポリシーの例を次に示します。 JavaScript による削除 長所: ほぼ無制限の柔軟性ビジネスルール、ワークフロー、およびその他のエンジンをバイパスできる直接実行することも、ビジネスルール、UI アクション、ジョブスケジュールなどに変換することもできます。トランザクションクォータルールに対して脆弱ではない (バックグラウンドで実行されている場合) 短所: 低速リスクありスクリプティングの知識が必要 JavaScript コードは、 スクリプト - バックグラウンド モジュールを介して直接実行できます。このモジュールには、[4 時間後にキャンセル] というラベルの付いた重要なチェックボックスがあり、デフォルトでオンになっています。ほとんど の場合、一括削除スクリプトでは、これがオフになっていることを確認する必要があります。また、スコープ対象のテーブルからデータを削除する場合を除き、ドロップダウンで「グローバル」スコープが選択されていることを確認することもできます。スクリプトのスコーピング要件を決定するのはユーザーです。 スクリプト化された削除の設計とロジックは、要件によって異なります。ビジネスルールやワークフローをトリガーせずにテーブルからすべてのレコードを削除するだけの簡単な場合もあれば、高度な条件付きロジックを含めて追加のクリーンアップ操作を実行する場合もあります。指定されたテーブルのすべてのレコードを削除する前者の例を次に示します。 var gr = new GlideRecord("table_name"); gr.query(); gr.setWorkflow(false); // Bypass business rules and workflows gr.deleteMultiple(); 条件付きロジックを適用すると、削除をより具体的にすることができます。特定の条件に一致するレコードのみを削除するように変更された同じスクリプトの例を次に示します。 var gr = new GlideRecord("table_name"); gr.addQuery("state", "closed"); gr.addQuery("category", "4ca01be0db31eb009540e15b8a961936"); gr.addNullQuery("user"); gr.query(); gr.setWorkflow(false); // Bypass business rules and workflows gr.deleteMultiple(); setWorkflow(false) を使用すると、更新セットの追跡も抑制されます。これらのエンジンを必要とせず、単にデータをできるだけ早く削除したい場合は、これを使用することをお勧めします。また、スクリプトにログ記録を追加して、デバッグと結果の評価を容易にすることもお勧めします。このようなスクリプトをスケジュール設定済みスクリプト実行ジョブに入れ、スケジュールに従って実行できます。特定のロジックに基づく一括削除が一般的なエンドユーザー要件であるテーブルに対して、カスタム UI アクションを作成することもできます。重要: 徹底的なテストなしで、テストされていないスクリプトを本番インスタンスに実装しないでください。列名のスペルが間違っているなどの小さな間違いでも、意図しない結果につながる可能性があります。サンドボックスまたはテストインスタンスでクローンを作成して実験に使用することをお勧めします。この場合、失われたデータは再度クローンを作成することで簡単に復旧できます。 メンテナンスと防止 一括削除の必要性を回避する最善の方法は、最初にデータが管理不可能なサイズにならないようにすることです。これを行う最善の方法は、前述のテーブルクリーンアップポリシーを使用することです。JavaScript を使用して削除を実行するスケジュール設定済みスクリプト実行ジョブを作成することもできますが、ほとんどの場合、テーブルクリーナーの方がパフォーマンスが高くなります。データベースを可能な限り無駄のない状態に保つことで、パフォーマンスとユーザビリティが大幅に向上し、データのアクセス性と管理性が向上します。データベースを高速に保ちながら、コンプライアンス規制を満たす古いデータを廃止するための十分に訓練された戦略を持つことは、ServiceNow プラットフォームでの会社の運用に大きなプラスの影響を与えます。Additional InformationDelete RecoveryテーブルクリーナーKB0694151 - How to use Table Cleaner to remove unwanted data