ServiceNow のデータ管理をマスター:成長の追跡から効率的なクリーンアップまで このナレッジベース記事では、データベースの増加の監視から大きなテーブルの最適化まで、ServiceNow でデータを管理するための包括的なガイド説明します。自己管理型データクリーンアップのベストプラクティスを確認し、利用可能なツールと機能について学び、最大のテーブルに効果的に取り組む方法に関する洞察を得ます。データ管理について十分な情報に基づいた意思決定を行うための知識を自分とチームで身に付け、運用を円滑化します。 目次 自己管理データのクリーンアップと削除のベストプラクティス データ削除のベストプラクティス テーブルの増加とデータベース全体のフットプリントの追跡 キーリソース 利用可能なデータ管理製品と機能 データベースの圧縮 – テーブルの空き領域の再利用ジョブを削除テーブルクリーナーデータのアーカイブ 破棄ルールのアーカイブ CMDB Data Managerクローンスクリプト化されたメソッド 最大のテーブルを管理するための戦略 sys_attachment/sys_attachment_docsys_auditsys_audit_deletesys_emailar_* テーブルとsys_archive_logsyslog*CMDB*sh* および sys_rollback* テーブルpa_scores* および pa_snapshots テーブル 自己管理データのクリーンアップと削除のベストプラクティス ほとんどの場合、ServiceNow カスタマーサポートは顧客のインスタンスからのデータの削除を支援しません。その理由とできることは次のとおりです。 完全性と説明責任:データ削除に直接介入すると、顧客固有のセットアップとデータの完全性が危険にさらされる可能性があります。データの安全性と一貫性を優先します。OOTB 機能:ServiceNow には、データのクリーンアップに役立つ標準提供 (OOTB) 機能が用意されています。ただし、大規模なデータセットは処理に数週間から数か月かかる場合があります。この期間により、徹底的かつ体系的な削除が保証され、操作の中断が最小限に抑えられます。セルフサービスツール:ユーザーがデータを効率的かつ安全に管理およびクリーニングできるようにするツールとドキュメントを提供します。推奨事項:重要なデータのクリーンアップを試みる前に、以下を実行してください。 テスト: 実際の環境で実行する前に、同様のサイズのデータセットを持つ準運用環境でクリーンアップ プロセスをテストします。相談:データ管理の経験を持つ ServiceNow コンサルタントまたはパートナーにガイダンスを求めることを検討してください。完了時間:データ削除のプロセスにはかなりの時間がかかる場合があるため、それに応じて計画してください。大規模なデータセットは、処理に数週間から数か月かかる場合があります。 データ削除のベストプラクティス データを知る: 問題: データベースのフットプリント、最大のテーブル、およびデータの本質的な価値を包括的に理解せずにデータ削除プロセスを開始すると、情報に基づいた意思決定が行われず、データ損失のリスクが発生する可能性があります。推奨事項: データ削除を開始する前に、データベースの全体的な状況を把握しておいてください。どのテーブルが最大であるかを特定し、そのテーブルが保持するデータの価値を理解します。この予備分析により、どのデータを安全に削除でき、運用上または分析上のメリットのために保持する必要があるかについて、情報に基づいた戦略的な決定を下すことができます。 広範なテストの実行: 問題: 同様のサイズのデータセットを持つ準本番インスタンスでソリューションが完全にテストされていません。 推奨事項:常に本番インスタンスによく似た準本番環境でテストを実施してください。 ブレークダウンクエリ: 問題: 1 つの GlideRecord クエリでデータセット全体をターゲットにすると、クエリが応答しなくなることがあります。推奨事項:クエリを細分化します。何年にもわたるデータを一度に取得しようとするのではなく、一度に 1 日または 1 時間分のデータを目指してから反復します。複雑なクエリは通常低速になるため、避けてください。 シングルスレッドアプローチ: 問題: スクリプト化されたシングルスレッド方式を使用すると、非効率的になる場合があります。推奨事項:ターゲットデータセットをセグメント化します。重複していない 4 つまたは 6 つのセグメントに分割し、複数のジョブで処理してパフォーマンスを向上させます。 冗長な GlideRecord クエリ: 問題: GlideRecord クエリがターゲットデータセットをフェッチするのに数秒以上かかる場合は、システムパフォーマンスの問題が発生するリスクがあります。推奨事項:常に効率的なクエリクエリを目指してください。取得が遅い場合は、データセットクエリをさらに絞り込むかセグメント化します。 タイムラインを計画する: 問題: 一部のお客様は、データ削除のタイムラインがテストされていないか、過度に楽観的です。推奨事項:現実的になりましょう。データの蓄積に何年もかかった場合、その削除には数週間から数か月かかる可能性があります。忍耐力により、安全で徹底的なクリーンアップが保証されます。 テーブルの増加とデータベース全体のフットプリントの追跡 このセクションでは、クラウドストレージとデータベースのフットプリントを効果的に監視するための重要なインサイトを提供します。これは、当社のツールとリソースをナビゲートし、コンプライアンスと最適なストレージ使用率を確保できるように設計されています。 キーリソース クラウドストレージのコンプライアンスとレポート (KB1177521) 目的:ストレージ制限、コンプライアンス要件、およびストレージ使用率レポートへのアクセス方法に関する包括的な詳細を提供します。特定のインスタンスの上位 10 〜 100 個の最大のテーブルに関する詳細なレポートを提供します。よくある質問をカバー ストレージの制限はどのくらいですか？顧客は、どこでストレージ使用率を確認できますか？顧客は、各インスタンスのデータベースフットプリントに関する追加の詳細をどこで入手できますか 推定テーブルサイズテレメトリ:テーブル増大ダッシュボード 目的:インスタンスのテーブルの推定サイズと全体的なデータベースフットプリントを提供します。注:見積もりは毎日更新されるため、請求/コンプライアンスには使用しないでください。正確なレポートについては、 KB1177521を参照してください。アクセスパス:セルフサービス>ダッシュボード>すべての>「テレメトリ - テーブルの拡張」。 ストレージ使用率とテーブルの増加の表示 テーブルサイズに関するプラットフォーム上のメトリクスにアクセスするには、「テレメトリー - テーブルの増加」ダッシュボードに移動します。このダッシュボードには、インスタンスの推定サイズと上位 20 個のテーブルが表示されます。すべてのテーブルの包括的なリストについては、 /sys_physical_table_stats_list.doを参照してください。これらは推定値であり、コンプライアンスの目的では正確ではない可能性があることに注意してください。 空き領域とデータベースの圧縮 再利用可能なスペース:各テーブルの [再利用の推定 (GB)] には、回復可能な潜在的な空きスペースが表示されます。データベーステーブルの再構築 - いつ行う必要がありますか? データベーステーブル内の空きスペースと、手動でテーブルを再構築する必要がない理由 データベースの圧縮:Utah リリース以降、この自動化機能は適格なテーブルを再ビルドしてスペースを解放します。 関連ジョブ ジョブ:物理テーブル統計収集 >毎日実行します。このデータにより、sys_physical_table_stats で見つかったメタデータが入力されます。 利用可能なデータ管理製品と機能 データ管理の複雑さを乗り越えるには、選択肢を知ることが非常に貴重です。以下は、セルフサービス方式でデータを効果的に管理およびクリーニングするために利用できる機能と製品です。 データベースの圧縮 – テーブルの空き領域の再利用 ServiceNow で使用されるプライマリデータベースタイプの MariaDB は、追加のデータをサポートするためにテーブルのサイズを自動的に増やします。この領域は、データベースエンジンによってテーブルから大量のデータが削除されても、自動的に再利用されません。Utah リリースには、データベース圧縮と呼ばれる新機能が導入されました。この機能により、この状況について夜間にテーブルをチェックし、必要に応じてテーブルを自動的に再構築します。テーブルの空きスペース情報は、[テレメトリ - テーブルの増加] ダッシュボードからテーブルごとに表示するには、テーブル内をクリックするか、/sys_physical_table_stats_list.do の [推定再利用 (GB)] フィールドからテーブルごとに表示できます。 データベーステーブルの再構築 - いつ行う必要がありますか? - データベーステーブル内の空き領域と、手動でのテーブル再構築が必要ない理由。 機能の概要ビデオ ### テーブルの再ビルドの要件 (Washington 以降のリリース)### 関連するsys_physical_table_statsレコードに示されているように、[再利用の推定 (GB)] が 10GB を超えています。関連するsys_physical_table_statsレコードから [推定再利用 (GB)] と [テーブルサイズ (GB)] を除算して計算された、 50% を超える空きスペース 。たとえば、[テーブルサイズ (GB)] が 100 GB の場合、テーブルが圧縮の対象と見なされるには、[推定再利用 (GB)] が 50 GB を超える (つまり、100 GB の 50% を超える) 必要があります。 この要件は 50% から 30% に調整できます (500 GB を超えるテーブルがある場合は、この 15% を調整して強制的に再構築することを検討してください)。再構築は必要ないかもしれません データベーステーブルの再ビルド - いつ行うべきですか?)。 プロパティを追加:glide.db.compaction.criteria.reclaim_percentageタイプ：整数値:30 テーブルの行数が 億行未満。テーブルサイズは 100GB (102400 MB) 未満です。 この要件は、最大 2TB(2097152 MB)まで安全性を調整できます。オープンディスク容量関連の P2 アラートケースがある場合は、十分な空き容量があるかどうかを尋ねてください。 プロパティ glide.db.compaction.criteria.max_table_size_mb を追加しますタイプ：整数値: 2097152 ### テーブル再ビルドの要件 (Washington リリース以前)### この機能は Utah で導入されました。テーブルにテーブルクリーナールールがある (詳細は後述の「テーブルクリーナールールがないが、他のすべての要件を満たすテーブルの再ビルド」を参照)[推定再利用 (GB)] が 10 GB を超えています圧縮の対象となるには、関連するsys_physical_table_statsレコードの [推定再利用 (GB)] 値で示されているように、テーブルに 50% を超える空きスペースが必要です。たとえば、[テーブルサイズ (GB)] が 100 GB の場合、テーブルが圧縮対象と見なされるには、[推定再利用 (GB)] が 50 GB を超える (つまり、100 GB の 50% を超える) 必要があります この要件は、50% から 30% に調整できます。 プロパティを追加:glide.db.compaction.criteria.reclaim_percentageタイプ：整数値:30 テーブルの行数が 5,000 万行未満。注:テーブルクリーナールールがなく、他のすべての要件を満たすテーブルを再構築する方法 (Washington より前のリリース)。 テーブルクリーナールールを持つテーブルの要件はバイパスできます。これには、属性「最適化を実行」(do_optimize=true) をsys_dictionaryテーブルのテーブルのコレクションレコードに追加する必要があります。 属性の追加テーブルクリーナーと「最適化を実行」属性は、Washington 以降のリリースで削除されました。 除外されたテーブル データベースローテーション/拡張 のテーブルは再構築できませんシャドウ/ロールバック テーブル 注 :シャドウテーブルの圧縮は、Washington パッチ 8 からサポートされていますタスク、CMDB、sys_user、sys_emaillsys_metadataから拡張されるテーブル 関連ジョブ ジョブ:DB 圧縮>毎日実行されるこのジョブは、圧縮の要件を満たすテーブルの再構築をトリガーします。このジョブはsys_physical_table_stats内のデータに依存せず、データテーブルを個別にプルします。テーブル:[alter_type] フィールドが [compact_table] であるテーブルレコードの /sys_schema_change_list.do を確認します フィールド:reclaim_size_estimate > 圧縮前の推定再利用サイズフィールド:table_size_before > 圧縮前のテーブルサイズ ジョブを削除 レコードを安全に削除する - 製品ドキュメント ** この機能は注意して使用してください。レコードは削除されます。必ず最初に準本番インスタンスでテストしてください。 この機能は、UI (ユーザーインターフェイス) 主導のエクスペリエンスを通じてレコードを安全に削除するように設計されています。 使い方: 任意のリストビューから、ユーザーが削除するレコードを返すフィルターを追加します。次に、リストヘッダーを右クリックし、[データ管理] > [すべて削除] (プレビューあり) を選択します。[プレビュー] をクリックして、削除対象が希望どおりであることを確認します (プレビューは 25 万レコードに制限されています)条件を確認[ビジネスルールとエンジンを実行] はデフォルトでオンになっていますが、パフォーマンスを向上させるために削除が遅くなります。このオプションをオフにすると、関連するビジネスロジックが実行されない可能性があります。スケジュールを設定する場合は、[実行場所] フィールドに入力してレコードを更新するか、[今すぐ実行] をクリックします 利点： 使いやすい条件ビルダーのコントロールまたはリストビューから削除する前にレコードをプレビュー (プレビューは 25 万レコードに制限されています)カスケード削除のプレビュー後で実行するか、今すぐ実行するスケジュールロールバックオプション 欠点： 数千万のレコードを削除しません (テーブルクリーナーを使用) テーブルクリーナー テーブルクリーナー - 製品ドキュメント ** この機能は注意して使用してください。レコードは削除されます。必ず最初に準本番インスタンスでテストしてください。 この機能は、シングルスレッド方式でプラットフォーム内のほとんどのテーブルからデータを削除し、データを削除してもインスタンスの安定性に影響を与えないように設計されています。 この機能の構成は、条件ビルダーフィルターを使用したルールの作成に基づいています。複数年または数百万件のレコードのバックログがあるデータセットにルールを適用する場合は、より短い期間 (データセットが及ぶ期間を年、月、または週単位で設定するなど) をターゲットにすることをお勧めします。これは、テーブルのクリアルールで条件ビルダーを使用して制御できます。 機能の構成:この機能は、テーブルクリーナールールを作成することによって設定され、これらのルールは「条件ビルダーフィルター」を使用して定義されます。大規模なデータセットの推奨事項:ルールを適用するときは、一度に 1 年間のデータをターゲットにすることをお勧めします。これは、大きなタスクをより小さく、より管理しやすい部分に分割することでパフォーマンスを向上させることを目的としています。 これは一例であり、データセットは 6 か月に及ぶ可能性がありますが、そのシナリオでは一度に 1 か月をターゲットとしており、数百万のレコードが含まれていることに注意してください。 パフォーマンス:テーブルクリーナー製品はシングルスレッドジョブであり、現実的には数か月の間に数百万件のレコードを削除できます。バックログが大きい場合、これらのレコードの削除に時間がかかることが予想されます。テスティング： 常に、同等のサイズのデータセットを持つ最新のクローンである準本番インスタンスでテストします。 リストビューから、同じフィルター条件に加えて、一致フィールド (sys_created_on/sys_updated_on) 設定の秒前 (相対) を使用して、リストがターゲットテーブルに正常にロードされることを確認します。リストが読み込まれない場合、このルールはそのままでは機能しません。フィルター条件を調整してデータセットを減らしてみてください。上記の「大規模なデータセットの推奨事項」の詳細を確認してください。 ルールのテスト後に、遅いクエリーモジュールを使用して、テーブルクリーナーからのクエリーで「平均実行時間 (ミリ秒)」が 20 秒を超えるクエリーパターンを検索します。 [すべての>システム診断>統計情報>遅いクエリに移動し、サンプルの URL をフィルターします テーブルクリーナーで始まる URL > INSTANCENAME.service-now.com/sys_query_pattern_list.do?sysparm_query=urlSTARTSWITHTable%20Cleaner 次に、 インデックス提案エンジン を使用して、クエリを改善できるかどうかを判断します。クエリを改善できない場合は、フィルター条件に再度アクセスしてください。遅いクエリ (60+ 秒) のテーブルクリーナールールを本番環境に移動しないでください。 参照 製品ドキュメント「テーブルクリーナー」を使用して不要なデータを削除する方法 テーブルクリーナーに関する情報テーブルクリーナーが正常に機能しているかどうか、およびテーブルクリーナールールによって削除されるデータの量を確認します データのアーカイブ ドキュメントサイト アーカイブ |一般的な概要 - サポートとトラブルシューティング この機能は、データベースのフットプリントを削減するようには設計されていませんが、ベーステーブルでアクティブなデータセットを維持するように設計されています。アーカイブすると、アーカイブ先のテーブルのレコード数が減るだけです。アーカイブされたレコードは、プリフィックス ar_ が付いたアーカイブ済みテーブルに移動されます。 この機能を使用すると、構成可能な時間が経過するとレコードがar_テーブルから消去されるアーカイブ破棄ルールという 2 つ目の機能と組み合わせてデータ保持ポリシーを適用できます。機能としてのアーカイブでは、レコードは削除されず、元のテーブルからアーカイブテーブルに移動されるだけなので、インスタンスの全体的なデータベースフットプリントは削減されません。実際、レコードは関連するアーカイブログレコードにも XML ペイロードとして保存されるため、アーカイブするとインスタンスの全体的なデータベースフットプリントが増加する可能性があります。 これら両方の機能の目的は、ベーステーブルで構成可能なアクティブなデータセットを維持し、データ保持ポリシーを適用することです。理想的には、バックログが複数年分のデータにならないように、新製品の本稼働前後にこれらの機能を有効にする必要があります。 バックログが複数年のデータセットに適用する場合、一度に 1 年分のデータを顧客ターゲットにすることをお勧めします。これは、アーカイブルールの条件ビルダーを使用して制御できます。 一般的な例:1 年のみを保持することを目標に、sys_email テーブルに 5 年分のレコードがあります。最初に 4 年以上前のレコードをターゲットとするようにアーカイブルールを調整し、アーカイブルールの 3 年以上前のアーカイブルールターゲットレコードを調整する前にそれらのレコードのアーカイブを許可し、目的の保持期間が満たされるまでこのプロセスを続行します。また、これらのアーカイブされたレコードを破棄することが目的である場合は、関連するアーカイブ破棄ルールが有効になっていることを確認してください。構成管理データベース (CMDB) CI レコードをアーカイブするには、 CMDB データマネージャーを使用します。 アーカイブ機能はマルチスレッドであり、何百万ものレコードを数週間から数か月にわたって移動できます。バックログが大きい場合、アーカイブに時間がかかることが予想されます。 ServiceNow カスタマーサポートでは、アーカイブおよび破棄する内容に関するガイドラインを提供できないことに注意してください。 破棄ルールのアーカイブ これは、アーカイブされたレコードを構成可能な期間保持するように設計されたセカンダリ機能です。アーカイブされたレコードをインスタンスから消去できると顧客が判断した場合、顧客はこの機能を使用してこのタスクを実行できます。 破棄ルールは、アーカイブルールを最初に実装するときに有効にする必要があります。これにより、ar_* および sys_archive_log テーブルの増加が制限されます。 何百万ものレコードがアーカイブされている場合、バックログの処理にかなりの時間がかかりますが、これは予期されたことです。 CMDB Data Manager CMDB データマネージャー - 製品ドキュメント CMDB データマネージャーは、構成アイテム (CI) の一括削除やアーカイブなど、ライフサイクルの管理に役立ちます。これは、大規模なデータベースで適切に機能し、顧客が作成したポリシーに基づいて迅速に適応できる完全なソリューションです。 顧客が数百万件のレコードをターゲットとしている場合、バックログの処理にはかなりの時間がかかりますが、これは予期されたことです。 クローン クローンの要求 - 製品ドキュメント アカウントレベルでの合計データフットプリントを削減することが目標である場合は、本番環境のフルクローンである複数の準本番インスタンスの必要性を確認してください。これらのインスタンスはテラバイト単位のデータを占める可能性があり、多くのシナリオでは、アクティブな開発のユースケースをサポートするためにフルクローンは必要ありません。 アーカイブテーブル (ar_* および sys_archive_log) はデフォルトでは除外されません。このデータのビジネス上または機能的なユースケースが準本番環境に存在しない場合は、これらのテーブルを除外するようにクローンエンジンを構成する方法について クローン作成からテーブルを除外する を確認してください。 スクリプト化されたメソッド ServiceNow プラットフォーム内のスクリプティングに精通しているお客様は、スケジュール済みジョブ、修正スクリプトの一部として、または [スクリプト - バックグラウンド] モジュールから GlideRecord delete() および deleteMultiple() メソッドを利用できます。スクリプト化された手法では、ターゲットデータセットの異なるサブセットで並列ジョブ (最大 4 つ) を実行して削除率を向上させるなど、柔軟性が向上します。 テスティング： 本番インスタンスでスクリプト化されたメソッドを実行する前に、同等サイズのデータセットを使用して準本番環境でテストしてください。テスト後、遅いクエリーモジュールでクエリーのパフォーマンスを確認します。特にこれらのスクリプト化されたメソッドで、「平均実行時間 (ミリ秒)」が 5 秒を超えるクエリパターンをフィルタリングします。 この情報を見つけるには、[All > System Diagnostics > Stats > Slow Queries (遅いクエリー)] に移動し、次のフィルターを適用します。 「The Name Scripted Methods」で始まる URL の例。 URL > INSTANCENAME.service-now.com/sys_query_pattern_list.do?sysparm_query=urlSTARTSWITHScripted%20Methods 次に、 インデックス提案エンジン を使用して、クエリを改善できるかどうかを判断します。クエリを改善できない場合は、フィルター条件に再度アクセスしてください。 クエリのパフォーマンスが低下した場合は、スクリプトまたは使用した条件を調整することを検討してください。sys_created_on列またはsys_update列に基づいて 30 秒のウィンドウでテーブルを反復処理すると、クエリのパフォーマンスの低下を回避できます。 最大のテーブルを管理するための戦略 このセクションでは、顧客の注意を頻繁に引く最も一般的な大きなテーブルに関するインサイトを提供します。データの蓄積の問題に対処している場合でも、単にストレージを最適化しようとしている場合でも、これらのヒントは、最大のテーブルを効果的に管理および合理化するのに役立ちます。 sys_attachment/sys_attachment_doc 目的:ServiceNow Platform では、添付ファイルは sys_attachment (メタデータ) と sys_attachment_doc (データ) の 2 つのテーブルに保存されます。 仕組み:ユーザーがレコード (インシデントや要求など) にファイルを添付すると、メタデータ (ファイル名、タイプ、関連レコードなど) はsys_attachmentテーブルに格納され、実際のバイナリデータ (ファイルのコンテンツ) はsys_attachment_docテーブルに格納されます。 sys_attachment:このテーブルには、添付ファイルに関するメタデータと情報が含まれていますsys_attachment_doc:このテーブルには、親sys_attachmentレコードに関連する添付ファイルのバイナリコンテンツ (データ) が含まれています。 このテーブルのサイズは、インスタンスデータベースフットプリントツールを使用して決定および監視できます。ただし、これはデータのブレークダウンを提供するものではありません。このスクリプト (sys_attachment_aggregated_script) を準本番インスタンスで実行すると、添付ファイルの合計サイズのブレークダウンと、上位 10 件のテーブルの添付ファイル数を合計サイズ別に取得できます。 この表の内容は顧客主導型であり、顧客タイプのビジネスとユースケースに固有のものです。ただし、多くのお客様にとって、メールの添付ファイルが添付ファイルデータに最も貢献しています。デフォルトでは、すぐに利用可能な メール保持プラグイン は、メールとメールの添付ファイルデータを維持するように設計されています。 添付ファイルデータを削除するときは、常にターゲットをsys_attachmentします。 親 sys_attachment レコードが残るため、sys_attachment_doc で直接削除しないでください。 sys_attachment_docテーブルは、リストビューから探索するように設計されておらず、ほとんどの場合ロードされません。関連するすべてのメタデータを含むsys_attachmentを使用します。KB1228793 - 添付ファイルの管理 KB0563399 - 大きな添付ファイルの管理 - ベストプラクティス KB0995336:削除の可能性がある添付ファイル sys_audit 目的:ServiceNow のsys_auditテーブルを使用して、システム内のレコードに加えられた変更を追跡します。これは、誰がいつ何を変更したかを追跡し、説明責任とトレーサビリティを提供する詳細なログブックのようなものです。 仕組み: 変更の記録:監査対象に設定されているレコードのフィールドに変更が加えられるたびに (インシデントステータスの更新やユーザーのロールの変更など)、sys_auditテーブルにエントリが作成されます。 詳細の保存:このエントリには、変更が発生したテーブルの名前、変更された特定のレコード、変更されたフィールド、古い値と新しい値、変更を加えたユーザー、変更時刻などの詳細が含まれます。監査構成:すべての変更がログに記録されるわけではありません。アドミニストレーターは、組織のニーズとコンプライアンス要件に応じて、監査対象のテーブルとフィールドを設定できます。変更のレビュー:sys_auditテーブルの情報には、[監査履歴] 関連リストまたはその他のレポートツールからアクセスでき、経時的な変更のレビューと分析が可能です。注意:2017 年より前のインスタンスでは、sys_auditテーブルがデフォルトで テーブル拡張 で構成されていたため、テーブルクリーナールールを使用できなくなります。このテーブルからレコードを削除するには、親レコードをアーカイブして破棄するか、スクリプト化された方法で行う必要があります。 Xanadu より前のリリース:sys_audit がテーブル拡張 上にある場合、以前のsys_auditテーブル拡張のレコードを削除すると、現在のsys_audit拡張に新しい sys_audit DELETE レコードが作成されます。このシナリオを回避するには、sys_dictionary テーブルのすべての sys_audit* (sys_audit を含む) テーブルのコレクションレコードに属性「no_audit_delete=true」を追加します。属性の追加 このテーブルのサイズを管理する方法: このテーブルのサイズは、インスタンスデータベースフットプリントツールを使用して決定および監視できます。ただし、テーブルのサイズが大きいため、プロファイリングが困難になります。 このスクリプト (sys_audit_sampling_script) は、最近のクローンである準本番インスタンスの スクリプト - バックグラウンド から実行でき、監査対象テーブルの上位 15 件と上位 3 件のテーブルのフィールド名名のサンプリングに基づくブレークダウンを提供する監査データが含まれています。 監査対象のテーブルとフィールドの決定は、顧客のビジネス上の決定です。ServiceNow カスタマーサポートはガイドラインを提供しません。 ヒント:テーブルまたはフィールドの監査がビジネスにどのような価値を提供しているのか疑問に思うと、多くの顧客はユースケースなしですべてを監査します。 監査を有効にする方法を制限または制御するには、 監査」のテーブルセクションを確認してください。 新規顧客または顧客が新製品をオンボーディングする場合は、製品ライフサイクルの早い段階で議論を強制するため、除外リストをオプションとしてご検討ください除外リスト 監査:特定のテーブルまたはフィールドの監査をアクティブ化/非アクティブ化する方法 一部のsys_auditデータは不要であるが、親レコードをインスタンスに残す必要があると顧客が判断した場合は、以下の方法を使用できます。本番インスタンスで試す前に、同様のサイズのsys_auditテーブルを使用して準本番インスタンスでテストします。 スクリプト化された方法:sys_created_on列に基づいて、このテーブルを 30 秒のウィンドウで反復処理することをお勧めします。 最初に次のインデックスが存在することを確認します。テーブルインデックスの作成方法 インデックス>テーブル:sys_audit列:sys_created_on GlideRecord を介して実行されたクエリが迅速に返されるようにして、パフォーマンスと安定性の問題を回避します。 テーブルクリーナーメソッドでは、最初に次のインデックスが存在することを確認します。詳細については テーブルクリーナー セクションを参照してください。テーブルインデックスの作成方法 インデックス>テーブル:sys_audit列:tablename、sys_created_onインデックス>テーブル:sys_audit列:fieldname、tablename、sys_created_on 監査と履歴セット |連携の仕組み 除外リスト 監査:特定のテーブルまたはフィールドの監査をアクティブ化/非アクティブ化する方法 ** 有効なフィルターなしでsys_auditからデータを削除すると、タスクレコードのアクティビティ履歴 (インシデント、変更、問題など) に問題が発生する可能性があります。など) と CMDB レコードです。*datetime* 値よりも古いsys_auditデータを一括削除すると、アクティビティ履歴の欠落に関連するデータ損失の問題が発生する可能性があります。sys_auditの削除アクティビティは注意して処理する必要があり、影響について本番インスタンスの完全なコピーでテストする必要があります。また、これはインスタンスで最大のテーブルの 1 つであり、クリーンアッププロセスには数週間から数か月かかることが予想されます。試行する前に、正しいインデックスが設定されていることを確認してください。 sys_audit_delete 目的:ServiceNow のsys_audit_deleteテーブルを使用して、監査対象のレコードの削除を記録します。このデータは、削除を追跡するために使用でき、削除の回復機能 (ロールバックではない) に部分的に使用されます。 削除されたレコードモジュールを使用して削除されたレコードを復元聴講 仕組み: 記録の削除:監査対象のレコードがシステムから削除されるたびに、sys_audit_deleteテーブルにエントリが作成されます。 詳細の保存:このエントリには、レコードが削除されたテーブルの名前、削除されたレコードの一意の識別子 (Sys ID)、削除したユーザー、削除時刻など、削除されたレコードに関する重要な情報が含まれています。構成可能な監査:sys_auditテーブルと同様に、アドミニストレーターはどの削除を記録するかを設定して、特定の組織またはコンプライアンスのニーズに合わせて削除監査を調整できます。 このテーブルのサイズを管理する方法: このテーブルのサイズは、インスタンスデータベースフットプリントツールを使用して決定および監視できます。ただし、テーブルのサイズが大きいため、プロファイリングが困難になります。 このスクリプト (sys_audit_delete_sampling_script) は、最近のクローンである準本番インスタンスの スクリプト - バックグラウンド から実行でき、上位 15 件の監査削除テーブルのサンプリングに基づいてブレークダウンを提供する監査データが含まれています。 参照 KB0725007:特定のテーブルで削除されたレコードの監査を無効にするこのテーブルのサイズを管理するために推奨されるアプローチは、監査、削除を無効にするか、「 KB0724183 - sys_audit_deleteおよびsys_audit_relation レコードを一定期間削除または維持することを希望する場合に、これらのレコードを自動的にクリーンアップするスクリプト」で説明されている方法に従うことです。顧客は、監査削除を有効にする必要があるテーブルを決定する必要があります。 sys_email 目的:ServiceNow のsys_emailテーブルには、プラットフォームがすべてのメールアクティビティの記録を保持します。これは、通常のメールクライアントで結合された「送信済み」フォルダと「受信ボックス」フォルダのようなものと考えてください。ただし、ServiceNow システム用です。 仕組み: メールのログ記録:ServiceNow がメールを送受信するたびに、対応するエントリがsys_emailテーブルに作成されます。 詳細の保存:このエントリは、送信者、受信者、件名、メッセージ本文、タイムスタンプ、エラーメッセージ、ステータス(送信済み、受信済み、エラーなど)などのさまざまな詳細をキャプチャします。 このテーブルのサイズを管理する方法: sys_emailテーブルのサイズを管理するには、すぐに利用可能な メール保存プラグインを使用することをお勧めします。 年の範囲にバックログレコードsys_emailがある場合は、関連するアーカイブルールの条件を調整して、一度に 1 年ずつアーカイブします。データのアーカイブセクションの例を参照してください。 ar_* テーブルとsys_archive_log 目的:これらのテーブルはデータアーカイブ製品の一部です。ar_* テーブルにはアクティブなテーブルからアーカイブされたテーブルに移動されたレコードが含まれ、sys_archive_logテーブルにはメタデータと、必要に応じてレコードを復元するためのペイロードが含まれます。 これらのテーブルのサイズを管理する方法:これらのテーブルのサイズは、有効な アーカイブ破棄ルールによって管理されます。 ServiceNow カスタマーサポートは、破棄するレコードに関するガイドラインを提供できません。これはお客様による決定です。 アーカイブされた CMDB 関連レコードは、CMDB データマネージャー製品を使用して管理する必要があります syslog* 目的:ServiceNow の syslog テーブルはシステムログをキャプチャします。建物のセキュリティカメラが何が起こったかを記録するのと同じように、このテーブルは特定のシステムイベント、操作、およびエラーの記録を保持し、アドミニストレーターがシステムのアクティビティと健全性を理解するのに役立ちます。このテーブルは、最大 7 〜 8 週間 (約 2 か月) 分のデータを保持します。 仕組み: イベントのログ記録:システムエラー、操作、情報メッセージ、警告など、ServiceNow インスタンス内でさまざまなイベントや操作が発生すると、syslog テーブルにエントリとして記録されます。 詳細の保存:このテーブルの各エントリには、イベントのタイプ、発生時のタイムスタンプ、イベントを説明するメッセージ、イベントをトリガーしたユーザーまたはプロセスなどの重要な詳細が含まれています。 重大度レベル:この表では、多くの場合、重大なエラーから情報メッセージまで、重大度別にメッセージが分類されるため、アドミニストレーターは問題の優先順位を付けることができます。 ログの確認:アドミニストレーターと必要な権限を持つユーザーは、syslog テーブルにアクセスして、システムアクティビティの監視、問題の診断、または履歴イベントの分析を行うことができます。 これらのテーブルのサイズを管理する方法:データは数週間以内にシステムによって削除されるため、syslog からのレコードの削除は必須ではなく、推奨されていません。 システム管理者は、このテーブルを定期的に (毎週) レビューする必要があり、これらのテーブルが大きい場合、これはアクティブに発生していません。 これらのテーブルを確認するには、[instancename.service-now.com/syslog_list.do?sysparm_filter_only=true] に移動し、30 秒のウィンドウ (テーブルが 50 GB 未満の場合は 15 分) にわたる 2 つの日時値の間で作成されました。このサンプリングを複数のウィンドウで繰り返します。繰り返されるメッセージを確認し、対処する必要があります。 過剰なログ記録 (syslog) のトラブルシューティング アクティブなプロパティやデバッグプロパティを検索し、不要な場合は無効にするとログ記録と syslog データが減少するためです。これらのデバッグプロパティを見つけるには instancename.service-now.com /sys_properties_list.do?sysparm_query=nameLIKEdebug%5EORvalue%3Ddebug リンクを使用します。 gs.log と gs.info の使用も syslog の増加につながる可能性があります。これらに対処するための推奨事項は、上位のログに記録されたメッセージに基づいてケースバイケースです。 注:syslogテーブルは7〜8週間(約2か月)にわたって毎週ローテーションされるため、アクションによってこれらのテーブルのフットプリントがすぐには削減されません。 CMDB* これらのテーブルのサイズを管理する方法は、 CMDB データマネージャー製品を使用して処理する必要があります。ただし、小さいデータセットは ジョブの削除 機能を使用して削除でき、大きなデータセットは テーブルクリーナーを使用して削除できます。 データセットの削除は、処理に数週間から数か月かかる場合があります。 sh* および sys_rollback* テーブル ドキュメントサイト 目的: sh* テーブルと sys_rollback* テーブルは、必要に応じてこれらの変更をロールバックできるように、テーブルとデータに加えられた変更を追跡するために使用されます。 テーブル名の例: sh@0024table_name/sh$table_name (シャドウテーブル)np@0024*/np$* (テーブルが削除されるとスナップショットテーブルが作成されます)sys_rollback* テーブル レコードがテーブルから削除されると、sh$table_name テーブルが作成され、ロールバックが有効になっている場合に使用するためにすべてのレコードがそこに保存されます。 ロールバックと削除の復旧 スケジュール済みジョブ「期限切れロールバックコンテキストの消去」を作成してテーブルをクレンジングするロールバック有効期限プロパティ (glide.rollback.delete.expiration_days) があります インスタンスでtable_nameレコードが頻繁に削除される場合、有効期限に達する前に新しいデータが入力され、その情報が同じ sh$テーブルに追加されるため、sh$table_nameテーブルは永久にそこに残ります。 ロールバックを無効にするには、 シャドウテーブルの削除に従います。ただし、このアクションはお勧めしません。お客様は、続行する前に、データ保持ポリシーを確認し、その影響を検討する必要があります。 ServiceNow 内でデータを復元する方法の詳細については、以下を参照してください。 ServiceNow インスタンスから削除されたデータを復元する方法準本番インスタンスまたは非本番インスタンスでのデータ損失 pa_scores* および pa_snapshots テーブル ドキュメントサイト pa_scores* および pa_snapshots テーブルのレコードは、システムのプロパティ com.snc.pa.dc.keep_scores_for.frequency および com.snc.pa.dc.keep_snapshots_for.frequency で定義された保持期間に基づいて、Clean PA コレクションジョブによって定期的にクリーニングされます。 pa_snapshotsレコードのサイズは pa_snapshots.sys_ids フィールドのサイズに直接関係することに注意してください。このフィールドには、[レコードの収集] オプションのスコアに寄与したレコードがインジケーター レベルで有効になっているかどうかのsys_idsが保存されます。保存できるsys_idsの数は、システムプロパティ com.snc.pa.dc.max_records によって制限されます。 詳細については、 KB0721309 を参照してください。