データの削除/更新の防止と復旧<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事の目的は、顧客を教育し、データ操作に関する包括的な情報を提供することです。これには、意図しない一括削除や更新が含まれます。 ServiceNow / ITIL データ操作のベストプラクティス 不要な削除の理由 データ削除の代替手段 削除操作の予期しない 結果 失われたデータの復旧 本番インスタンスのデータ復元プロセス ServiceNow / ITIL データ操作のベストプラクティス 顧客は、データが不要になったと感じた場合、インスタンスからデータを削除する傾向があります。準本番インスタンスで適切なテストを行わずに本番インスタンスのデータが直接削除され、削除する必要のない重要なデータが削除されてしまうことがあります。これにより、本番インスタンスはデータが失われ、インスタンス (テーブル) にデータがないためにエンドユーザーがインスタンスを使用できなくなることがあります。 インスタンスからのデータの削除は、最後のオプションとして検討する必要があります。もしある場合、顧客がデータを削除する以外に選択肢がない場合は、ITIL が推奨するベストプラクティスに従う必要があります。 準本番インスタンス上で PROD のフルクローンを実行します。データを削除します。関連するすべてのテーブルを確認し、アクションが意図したデータのみを削除したか、他の重要なデータも削除したかどうかを確認します。 すべて問題がなければ、本番インスタンスで同じプロセスに従います。 お客様は、データを削除するときに有効になるカスケード削除ルールに留意する必要があります。構成されたカスケード削除ルールに従って、関連データは削除される場合と削除されない場合があります。カスケードルールをご存じない場合は、以下のドキュメントを参照してください。 https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/field-administration/task/t_CascadeDeleteRules.html?cshalt=yes スクリプトを使用してデータを操作する場合は、常にテスト実行を行い、操作するレコードの数を確認してください。同じことにgetRowCountメソッドを使用できます。 不要な削除/更新の理由 1.カスケード削除ルール: レコードが削除されたときに、削除されたレコードを参照するレコードに削除がどのように影響するかについて、さまざまなオプションがあります。レコードが削除されたときに、そのレコードを参照するレコードがどうなるかを構成できます。顧客は、データを削除する前にカスケード削除ルールを確認する必要があります。 2.スクリプトのクエリが正しくありません: 顧客がデータを操作する最も一般的な方法の 1 つはスクリプトを使用することです。ただし、スクリプト内のクエリが正しくない場合、削除を意図していないすべてのデータが操作されてしまう可能性があります。この問題を回避するために、実際にレコードを削除する前に、スクリプト内のクエリで処理されるレコードの数を確認できます。 無効なフィールド名やスペルミスを含めるなど、エンコードされたクエリが正しく構築されていないと、無効なクエリが生成されます。無効なクエリが実行されると、クエリ条件の無効な部分が削除され、結果はクエリの有効な部分に基づいて生成されます。これにより、テーブルからすべてのレコードが返される可能性があります。無効なクエリ結果で insert()、update()、deleteRecord()、または deleteMultiple() メソッドを使用すると、データが意図せずに削除/変更される可能性があります。 注: deleteMultiple() または updateMultiple() を使用してデータを操作する場合は、スクリプトがループ内にないことを確認し、スクリプトのテストには特に注意してください。 例： var test = new GlideRecord('problem');test.addEncodeddQuery('active=true');test.query();while(test.next()){ test.active =false;test.update();} 上記のシナリオでは、2 行目のスペルミスが原因で、スクリプトによってすべてのレコードが誤って更新されます。このシナリオは、次のスクリプトを使用してテスト実行することで回避できます。 var count = 0;var test = new GlideRecord('problem');test.addEncodeddQuery('active=true');test.query();while(test.next()){count++ test.active =false;test.update();}gs.print("Number of records : " + count); インスタンスからデータを削除しても、インスタンス内のメモリ/スペースはクリーンアップされません。以下は、ServiceNow からデータを削除する代わりに顧客が検討できるいくつかの代替手段です。 データを削除する代替案 データを削除する代替手段を検討してください。以下にいくつかのテクニックを示しますが、独自の方法がある場合があります。 レコードを非アクティブにするオプションがある場合、これは顧客が従うことができる最善のアプローチです。レコードを非アクティブにし、非アクティブなレコードを除外するための適切なフィルター条件を設定します。不要になったレコードをアーカイブします。データがインスタンスから削除されず、実際のテーブルにデータが存在しなくなるため、これも最良のアプローチの1つです。データを削除すると、元に戻すことはできません。データがアーカイブされている場合は、必要に応じて後でアーカイブされたテーブルを参照できます。不要なレコードリストに特殊文字をプリフィックスとして追加し、フィルター条件を使用してレコードを除外します。例:接頭辞として「zz」を追加し、条件「zz で始まらない」を追加します。 巨大なテーブルによって影響を受ける唯一の領域は、巨大なテーブルからのレコードのレポートまたは取得です。これは、適切な条件を与えることで対処できます。 削除操作の予期しない結果 1.カスケード削除 レコードが削除されたときに、削除されたレコードを参照しているレコードに削除がどのように影響するかについて、さまざまなオプションがあります。レコードが削除されたときに、そのレコードを参照するレコードがどうなるかを構成できます。 たとえば、構成アイテムレコードが削除されると、その CI を参照するすべてのタスクも削除されます。カスケード削除が実行されることをユーザーが理解できるように、警告!このメッセージは、ユーザーが削除を続行する前に表示されます。データが削除されるすべてのテーブルがこのメッセージに一覧表示されます。アドミニストレーターと開発者は、このメッセージが表示される削除の影響を認識して理解できる必要があります。 開発者は、削除アクティビティが更新セットに追加され、本番環境に昇格されて、削除基準に一致するすべてのレコードが削除されることに留意する必要があります。 注:カスケード削除ルールに関するドキュメントは、ServiceNow の標準ドキュメント ( https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/field-administration/task/t_CascadeDeleteRules.html) に記載されています 例 1:KB0715787 - カタログ変数が削除された場合の予期しない結果 例 2:ユーザーレコードを削除すると、関連するグループ、ロール、およびその他のテーブルが削除される可能性がある i.削除オプションの代わりに、プラットフォーム全体でアクティブフラグを使用します。 ii.警告を認識してください!ダイアログとその意味 iii.カスケード削除ルールを理解する 2.参照 1 つのレコードが削除されると、数百、場合によっては数千の他のレコードが更新され、削除されたレコードへの参照が削除されます。これは、ほとんどすべてのデータ回復ケースで見られる最も一般的な問題です。最善のポリシーは、UI であろうとスクリプトであろうと、プラットフォームからデータを削除しないことです。アクティブフラグを使用します。削除すると、壊滅的な DL イベントが発生する可能性があります。 3.ワークフロー/承認 ワークフローは通常、タスクタイプレコードに関連付けられています。意図しない削除により、WF が誤って更新される可能性があります。WF をすぐに修正する直接的な方法はなく、WF を正しくない状態に設定するには、複数のテーブルを復元する必要があります。このようなシナリオでは、サポートチームが SOT インスタンスから手動で復元する必要があり、WF/承認の復元に時間がかかります。 4.SLA SLA (task_sla) がタスクレコードに添付されています。意図しないタスク削除またはステータスの更新により、SLA が誤ったステータスに設定される可能性があります。SLA レコードを直接復旧する方法はありません。これらのレコードを復元するには、手動で復元を実行する必要があります。これは時間のかかるプロセスです。 失われたデータの復旧 レコードを復元/削除取り消す場合は、以下のドキュメントに従ってください。レコードの削除を取り消す場合は、参照オプションも考慮することが非常に重要です。ご不明な点がございましたら、テクニカルサポートにお問い合わせください。 1.ロールバックと削除の復旧 ロンドンからは、 ロールバックと削除の復旧と呼ばれる新機能があり 操作されたデータの復元に役立ちます。これは、[削除取り消し] オプションのより高度なバージョンです。このツールは継続的に進化しており、そこで見つけた問題に対処しようと努めてきました。意図しないデータ操作トランザクションに関連するロールバックコンテキストが見つかった場合は、それをロールバックできます。このツールは New York 以降のバージョンではより高度であり、PROD で直接ロールバックできるはずです。 2.削除されたレコードとその参照を復元 このオプションは注意して使用してください。「復元を削除」オプションは、常にデータを復元するための迅速、安全、最良の方法です。 3.削除された設定レコードの復元 ただし、提案やサポートが必要な場合は、データが削除されて復元する必要がある場合は、いつでもケースを作成できます。データを復元するには別のチームの介入が必要であり、適切な詳細がない場合やすぐに報告されない場合は困難な作業になります。意図しないデータの削除/変更に気付いた場合に最初に行う必要があるのは、カスタマーサポートに連絡して、自分で復元を開始する前に次のステップを提案してもらうことです。 KB0748445 削除の追跡と問題をトラブルシューティングする方法についての詳細 本番インスタンスのデータ復元プロセス お客様の本番インスタンスで意図しないデータの削除/変更が発生した場合は、次のプロセスに従います。 2 つの新しい一時インスタンスをプロビジョニングします 1 つは、欠落/影響を受けるレコードを取得するためのデータの削除/変更前の標準的なバックアップ復元または「ポイントインタイム復元」用です。これは、 信頼できる情報源 インスタンスと呼ばれます。これは、データ操作が発生する前の顧客のインスタンスのステータスを表します。これは、データの削除/更新イベントから 3 日以内にケースが通知された場合にのみ使用できます。1つは、データを復元するソリューションをテストするものです。これは、 テストベッド インスタンスと呼ばれます。このインスタンスは、影響を受ける本番インスタンスの削除後イベントのコピーになります。 テクニカルサポートがデータ操作が発生した正確な時刻を特定するには、ある程度の時間がかかります。ポイントインタイムリストアを要求するには、このタイムスタンプが必要です。時間が決定し、一時インスタンスを要求すると、インスタンスサイズに基づいてインスタンスをプロビジョニングするのに時間がかかります。インスタンスが大きすぎると、インスタンスのプロビジョニングに 1 日以上かかることさえあります。 データの削除/変更が準本番インスタンスで発生した場合、データは復元されません。「 KB0813303「準本番インスタンスでのデータ復旧の処理」を参照してください。 したがって、結論は、インスタンスを意図しないデータの削除/変更の状態にせず、意図しないデータの削除/変更をできる限り防止することです。