一括削除と過剰データ管理に関する推奨事項Issue テーブルからデータを一括削除することが望ましい、または必要な場合があります。この削除は、事前定義された一連の条件で実行するか、または単にテーブルをきれいにワイプすることができます。破損したデータやアクセスできないデータを除いて、状況に関係なく、ニーズに合った削除方法があります。この記事で概説するデータ削除方法は、最も単純なアプローチから最も高度なアプローチの順に並べられています。 UI アクション除外ルールをクローンテーブルのクリーンアップポリシーJavaScript 最適なアプローチの決定はケースバイケースで異なり、特定の状況で最適なオプションを決定するのはあなた次第です。大量のレコードの場合、クローン除外ルール以外の高速オプションはありませんが、これらは状況に適していない可能性があります。テーブルから数百万件のレコードを削除するビジネスクリティカルな場合で、この記事のメソッドに必要な時間を待つことができない場合は、ServiceNow でケースをオープンしてテクニカルサポートエンジニアに相談できます。 データ削除要求に関する ServiceNow のポリシー:プラットフォームデータの関係は非常に複雑で、単純なデータベーステーブル管理をはるかに超えています。拡張されたテーブルモデル、参照フィールド、ビジネスロジック、ワークフロー、およびカスタマイズにより、「バックエンド」からデータを簡単に削除することは不可能になります。ServiceNow は、影響およびそのようなアクションを説明することができません。一見無害に見えるレコードを削除しただけでも、プラットフォームの安定性に影響し、以前は問題なく動作することがわかっていたビジネスロジックから予期しない動作が発生する可能性があります。ServiceNow は、これらのレコードの存在によりビジネスクリティカルな操作が使用できなくなる場合、そのデータの存在により機能停止が発生したか、またはそれが機能停止を引き起こす可能性がある場合、またはそれらのレコードが欠陥/問題の結果である場合を除き、データの削除に介入することはできません。 免責事項: この記事のどの部分も、徹底的な検証とテストなしにライブインスタンスにそのまま実装することを意図したものではありません。この記事の内容は、特定の状況への適合性を保証または保証するものではありません。この記事で提供されているスクリプトまたは実装の使用は、自己責任で行ってください。 計画 データを一括で削除する方法を決定する前に、いくつかの重要なポイントを考慮することが重要です。 どのようなカスケード削除が行われるか?(子/関連レコード)どの参照が壊れる/クリアされるか?どのようなビジネスルールがトリガーされるか?どのようなワークフローが実行されるか?他にどのような機能が影響を受ける可能性があるか?(クロススコープ権限生成など)削除内容は更新セットによって追跡されるか? 事前に適切な調査を行うことで、削除の潜在的な副作用を判断するのに役立ち、必要に応じて後で片付けるための適切な計画を立てるのに役立ちます。たとえば、壊れた参照を置き換える計画を立てることができます。関係する可動部分を適切に理解することで、計画を進めることが安全で責任があるかどうかについて、より知識に基づいた決定を下すことができます。また、可能なバックアウト計画を検討することも重要です。ほとんどの場合、大量のレコードをエクスポートおよびダウンロードすることは実行不可能であるため、一括削除の切り戻しオプションは限られています。London リリースで利用できる削除回復ツールは、削除を記録してロールバックし、壊れた参照を復元できるため、これに対する優れた答えです。削除復旧ツールについては、こちらを参照してください: ロールバックと削除復旧 そうは言っても、 魔法の「元に戻す」ボタンはありません。London リリースの高度な削除回復ツールを使用しても、計画を策定して実行する際には細心の注意を払う必要があります。 UI アクションによる削除 長所： とてもシンプル 短所： 低速UI トランザクションクォータルールによるキャンセル脆弱性柔軟性 これは「簡単な」アプローチと見なすことができます。テーブルからすべてのレコードを削除する場合は、そのテーブルのsys_db_objectレコードを開き、[すべてのレコードを削除] UI アクションをクリックするだけです。既定では、このような UI トランザクションは約 5 分に制限されています。その期間を超えると、自動的にキャンセルされます。したがって、テーブルに大量のデータや、大量のビジネスルールやカスケード削除をトリガーするデータが含まれている場合は、操作を一度に実行するためにトランザクションクォータを増やす必要があります。リストビューを使用して、テーブルをフィルタリングし、複数のレコードを選択して、[削除] UI アクションをクリックすることもできます。ただし、ページネーションのため、一度に選択して削除できるレコードの数には制限があります。したがって、多数のレコードの場合、リストビューのアプローチは実行不可能な場合があります。この方法で削除を行うと、ビジネスルールとワークフローがトリガーされ、更新セットによって追跡されます。これらの UI アクションは、内部的に GlideRecord オブジェクトと deleteMultiple() 関数の使用に依存しています。したがって、これらのメソッドのパフォーマンスはこのスクリプトに匹敵します。 var gr = new GlideRecord("table_name"); gr.query(); gr.deleteMultiple(); クローン除外ルールを使用して削除 長所： 非常に速い 短所： 柔軟性が非常に低く、テーブル全体がトランケート (truncate)されます。破損した参照や、場合によっては孤立したレコードを残す可能性があります。インスタンスはクローンを作成する必要があり、本番環境では実行できません。 クローンによってデータが除外されると、除外されたテーブルは切り捨てられます。テーブルの切り捨ては比較的低コストの操作であり、テーブルからすべてのレコードを削除するよりもはるかに高速です。ただし、他のテーブル上の除外されたレコードへの参照は壊れます。つまり、参照元フィールドには、存在しなくなったレコードのSys ID が引き続き含まれます。これにより、意図しない結果が生じる可能性があるため、その点を考慮することが重要です。直接テーブルの切り捨てのもう 1 つのリスクは、孤立したデータです。Table-Per-Class (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 アクションを作成することもできます。重要: テストされていないスクリプトを、徹底的にテストせずに本番インスタンスに実装しないでください。列名のスペルが間違っているなど、小さな間違いでも、意図しない結果につながる可能性があります。Sandbox またはテストインスタンスでクローンを作成して実験に使用すると、失われたデータを再度クローン作成することで簡単に回復できます。 維持と予防 大量削除の必要性を回避する最善の方法は、そもそもデータが管理不能なサイズに増大するのを防ぐことです。これを行う最善の方法は、上記のようにテーブルクリーンアップポリシーを使用することです。JavaScript を使用して削除を実行するスケジュールスクリプト実行ジョブを作成することもできますが、ほとんどの場合、テーブルクリーナーの方がパフォーマンスが高くなります。データベースを可能な限り無駄のない状態に保つことで、パフォーマンスと使いやすさが大幅に向上し、データへのアクセスと管理が容易になります。データベースを高速に維持しながら、コンプライアンス規制を満たす古いデータを廃止するための統制の取れた戦略を立てることは、ServiceNow プラットフォームでの会社の運用に大きなプラスの影響を与えます。Related Linksロールバックと削除の復旧テーブルクリーナー - Vancouver ドキュメントKB0694151 - テーブルクリーナーを使用して不要なデータを削除する方法KB1518213 - ServiceNow でのデータ管理の習得:増加の追跡から効率的なクリーンアップまで