インポートセットのパフォーマンスのトラブルシューティング
これらのパフォーマンスの問題を確認して、インポートセットジョブのトラブルシューティングを行い、パフォーマンスを向上させます。
変換中のビジネスルールの実行
変換中にビジネスルールを実行すると、変換に予想以上の時間がかかったり、インスタンスの速度が低下したりする可能性があります。
問題になる場合：大量のデータをインポートする場合。たとえば、古いシステムからすべてのデータをインポートする場合です。
症状：変換に予想よりも時間がかかります。また、その間、インスタンス全体が遅くなる可能性があります。
遅い変換スクリプト
複数の GlideRecord クエリまたは大きなループを使用すると、変換スクリプトの処理速度が低下する可能性があります。
問題になる場合：変換スクリプトが複数の GlideRecord クエリを使用しているか、各行のオブジェクトの大規模なコレクションをループしている場合。この問題は、変換スクリプトが効率的でない場合に発生する可能性があります。ほとんどの場合、インポートセットアプリケーション内のビルトイン機能を使用してスクリプトの目標を達成できます。たとえば、GlideRecord クエリを使用するスクリプトを記述する代わりに、大文字と小文字を区別する結合スクリプトを作成できます。通常、GlideRecord クエリによりインポート速度は低下します。
症状：変換に予想以上の時間がかかります。スクリプトによっては、その間、インスタンス全体が遅くなる場合があります。
これを回避する方法：カスタムスクリプトを記述する代わりに、可能な限り基本システム機能を使用します。スクリプトを記述する場合は、GlideRecord クエリを使用する複雑なスクリプトを記述しないようにします。
変更されていないデータのインポート
変更されていないデータを繰り返しインポートすると、多くの行がスキップされます。
問題になる場合：非常に大きなテーブルからデータをインポートし、ほとんどのレコードが定期的に更新されていない場合。
症状：インポートセットに予想以上の時間がかかります。[ では、 合計数 が非常に多く、 スキップ数 も非常に多いインポートが表示されることが予想されます。これは [メッセージ ] 列の下にあります。インポートされたレコードのほとんどが実際に変更されていないことを示します。これらのレコードはインポートする必要がありませんでした。
これを回避する方法：JDBC インポートを実行している場合は、インポートセットの [データソース] で [前回実行日時] オプションを使用します。ファイルインポートのタイプでは、ファイルを生成しているものが新しいデータまたは変更されたデータのみを追加していることを確認してください。
インデックス付けされていないフィールドの結合
大量のデータを含むインデックス付けされていないフィールドを結合させると、変換の速度が低下する場合があります。
問題になる場合：インデックス付けされていないフィールドを照合すると、インポートの変換ステージの実行が遅くなります。ただし、これは十分な量のデータがある場合にのみ問題になります。極端な場合、負荷が増加するため、データベースでパフォーマンスの問題が発生します。
症状：データのロードにかかる時間に比べて、インポートの変換ステージにかかる時間が長くなります。変換時間が長くなることが予想されます。
これを回避する方法：可能であれば、一意で既にインデックス付けされているフィールドで結合する必要があります。フィールドが既にインデックス化されているかどうかを確認するには、 テーブルを見つけます。そのテーブルの列のリストでインデックス付けされている場合、インデックス付けされた列の横に i が付いた青色のアイコンが表示されます。フィールドのインデックス付けについては、ServiceNow テクニカルサポートにお問い合わせください。
インポートの同時実行
インポートを同時に実行すると、データベースに過度の負荷がかかる可能性があります。
問題になる場合：大量のデータをインポートすることでデータベースに追加の負荷がかかる場合。たとえば、500,000 人のユーザーをインポートし、同時に 200,000 の構成アイテムをインポートします。これにより、データベースの負荷が増加するため、システム上のすべてのクエリのパフォーマンスに大きな影響を与える可能性があります。この問題は、2 つのインポートが同じテーブルにインポートされている場合に特に発生します。このような場合は、テーブルに競合が発生している可能性があります。また、処理に関与するテーブルによっては、インポートとインスタンスのパフォーマンスが大幅に低下する可能性があります。
症状：複数の同時インポートの実行が遅くなり、データベースの負荷がかかります。多数の挿入と更新が表示されます。十分な負荷または競合がある場合は、IO 待ち時間が長くなります。
これを回避する方法：インポートをずらして重複しないようにします。
大規模なインポートセットテーブル
インポートセットテーブルのクリーニングに失敗すると、テーブルが乱雑になり、処理が遅くなる可能性があります。
問題になる場合：[インポートセット削除ツール] ジョブが実行されていない場合。
症状：これはサイズの問題です。インポートセットが定期的にクリーニングされない場合 (7 日分のデータの後にクリーンアップを推奨)、テーブルがいっぱいになり、インポートが停止します。
これを回避する方法：[インポートセット削除ツール] ジョブが実行されていることを確認します。現在実行されていない場合は、このジョブを有効にする前にすべてのインポートセットテーブルが切り捨てられるため、カスタマーサービス & サポート にお問い合わせください。
インポート中のテーブルスキーマの変更
新しい列をインポートするなどしてテーブルスキーマを変更すると、インポートセットテーブルがロックされます。
問題になる場合：新しい列がインポートされるたびに、そのスキーマの変更中にインポートセットテーブル全体がロックされ、テーブルのサイズに応じて 5 〜 10 分かかる場合があります。その間、データの選択や挿入はできません。そのテーブルが頻繁に使用されない場合は、問題が発生することはありません。ただし、そのテーブル (LDAP インポートテーブルなど) が頻繁に使用されると、問題が発生する可能性があります。
症状：この問題の症状はさまざまです。LDAP インポートテーブルの例では、LDAP インポートテーブルのクエリを必要とするトランザクションは、スキーマの変更が完了するまで待機する必要があります。
これを回避する方法：インポートする前に、新しい列があるインポートテーブルを切り捨てます。
非常に大きなデータセットのインポート
非常に大きなデータセットをインポートする場合は、複数の小さなデータセットをインポートする場合よりも時間がかかります。
問題になる場合：非常に大きなデータセットが単一のジョブにインポートされる場合。
症状：インポートジョブの完了に時間がかかります。
これを回避する方法：非常に大きなデータセットを複数の小さなジョブに分割して、結果を迅速に作成します。10 万レコード未満のインポートセットを指針として検討してください。たとえば、インポートされる合計データは同じでも、10 万レコードを 10 セットインポートする方が、100 万レコードを 1 回インポートするよりも早く完了します。
多数の参照フィールドを含む大規模なデータのインポート
解決する参照が多数ある大容量データをインポートすると、予想以上に時間がかかったり、データベースの速度が低下したりすることがあります。
問題になる場合：多数の参照フィールドがある大容量データのインポートに変換マップを使用する場合。
症状：変換に予想よりも時間がかかります。インポート中は、データベース全体の速度が低下します。
これを回避する方法：セカンダリストレージを使用して参照を検索します。セカンダリストレージは、参照の解決にセカンダリデータベースを使用します。これにより、一部の読み取りクエリをセカンダリデータベースにリダイレクトできるため、プライマリデータベースの負荷が軽減されます。
- Secondary Database Pool [com.glide.secondary_db_pools] プラグインを有効にします。詳細については、「Request a plugin」を参照してください。
- セカンダリデータベースカテゴリ [sys_db_category] テーブルの import_reference_resoultion カテゴリが構成され、有効になっていることを確認します。プラグインを要求すると、ServiceNow サポートがこのカテゴリを構成します。
プラグインを有効にし、セカンダリストレージカテゴリを構成して有効にすると、変換マップを作成 へのフォームに[参照用のセカンダリストレージの使用 (Use Secondary Storage for References)] チェックボックスが表示されます。このチェックボックスを使用して、セカンダリストレージを有効または無効にします。
セカンダリストレージを使用する場合は、フィールドマップの [選択肢アクション] フィールドを [無視] または [拒否] に設定します。[作成] に [選択肢アクション] を設定すると、参照解決では新しく作成されたレコードがすぐに検出されないため、レコードの複数のコピーが作成される可能性があります。選択肢アクションの詳細については、「フィールドマップの作成」を参照してください。
セカンダリデータベースは、プライマリデータベースに比べて常に少し古くなります。すべて最新のデータがインポートに必要な場合は、セカンダリストレージを使用しないでください。