メモ
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。
データ移行は、ほとんどすべての実装で重要な成功要因です。 一部のお客様は、特に大量のデータと小さなカットオーバー ウィンドウがある場合に、データ移行の速度について主に懸念しています。 データ 移行フレームワーク を使用して、ビジネス要件と運用の一部としてデータを移動することもできます。
この記事の情報では、データ移行のパフォーマンスを最適化するために使用できる手順とアクションについて説明します。
メモ
Tier-1 環境のテスト結果を、Tier-2 以上のサンドボックス環境のパフォーマンスと比較したり、推定したりしないでください。
すべての標準エンティティがデータ移行用に最適化されているわけではありません。 一部のエンティティは、Open Data Protocol (OData) との統合用に最適化されています。 必要なエンティティをパフォーマンス要件を満たすように最適化できない場合は、 新しい最適化されたエンティティを作成します。 開発者は、既存のエンティティを複製することで、このプロセスを迅速化できます。
データのサブセットを使用して最適化フェーズを開始します。 たとえば、100 万のレコードをインポートする必要がある場合は、1,000 レコードから始めて、10,000 レコードに増やし、その後 100,000 レコードに増やすことを検討してください。
使用するエンティティを特定したら、次のセクションを参照して、最適化の機会を確認します。
変更追跡を無効にする
エンティティの一覧から変更追跡を有効化または無効化 できます。
- データ管理ワークスペースで、データ エンティティ タイルを選択します。
- [ ターゲット エンティティ ] ページで、グリッド内のエンティティを選択します。 [操作ウィンドウ] の [ 変更の追跡 ] タブで [ 変更の追跡 を無効にする] を選択します。
セットベースのプロセスを有効にする
エンティティがセット ベースの処理をサポートしていることを確認するには、次の手順に従います。
- データ管理ワークスペースで、データ エンティティ タイルを選択します。
- ターゲット エンティティ ページで、グリッドでエンティティを検索し、セットベースのプロセス列の値を確認します。
一般仕訳帳エンティティに対してセットベースの処理を有効にする方法を示す例については、「一般仕訳帳エンティティを使用して伝票をインポートするためのベスト プラクティス」を参照してください。 すべてのエンティティがセットベースのプロセスをサポートしているわけではありません。 たとえば、 Customer 定義 (CustCustomerBaseEntity) エンティティに対してセットベースの処理を有効にして変更を保存しようとすると、次の警告メッセージが表示されます。
セット操作は「顧客の定義」エンティティではサポートされていません。
セットベースの処理をサポートするエンティティを作成する必要がある場合の重要な考慮事項を次に示します。
- データ ソースは読み取り専用に設定できません。
- データ エンティティ ビューの ValidTimeStateEnabled プロパティは いいえ に設定する必要があります。
- データ ソース上のすべてのテーブルには、 TableType プロパティが Regular に設定されている必要があります。
- 使用されているクエリの QueryType プロパティを Union に設定することはできません。
- 主要データ ソースは会社間でデータが保存されるのを防ぐことができません。 ただし、埋め込みデータソースは可能です。
- 主要データ ソースはパーティション間でデータが保存されるのを防ぐことができません。 ただし、埋め込みデータ ソースは可能です。
データ移行バッチ グループの作成
切替中は、他の活動がほとんどないか全くない時にデータ移行を実行します。 ほとんどまたはすべての計算ノードが割り当てられているバッチ グループを構成して使用すると便利です。
バッチ グループは、[ バッチ グループ ] ページ (システム管理>Setup>Batch グループ) で構成できます。
優先順位に基づくバッチ スケジューリングを有効にする
プラットフォーム更新プログラム 31 では、新しい 優先順位ベースのバッチ スケジュール 機能によって、バッチ ジョブの実行方法が最適化されます。 バッチ プラットフォームで競合が識別される場合は、優先順位ベースのバッチ スケジュールを有効にすることを検討してください。
バッチ スレッドの最大数を構成する
並列処理とマルチスレッドをより適切に使用するには、[サーバーの構成] ページで [バッチ スレッドの最大数 ] フィールドを設定して、アプリケーション オブジェクト サーバー (AOS) のインスタンスあたりのバッチ スレッドの最大数を 構成 します (システム管理 > セットアップ > サーバー構成)。 このフィールドの値を変更するときは注意してください。 値が大きすぎると、パフォーマンスに悪影響を及ぼす可能性があります。 現在、既定値は 8 です。 値を 12 または 16 に増やします。 ただし、重要なパフォーマンス テストを行わない限り、フィールドを 16 を超える値に設定しないでください。
バッチ モードでのインポート
バッチ モードでインポート ジョブを実行します。 それ以外の場合、1 つのスレッドがジョブを実行します。 この場合、システムはこれらの最適化構成を最大限に活用できません。
ステージング テーブルをクリーンにする
ステージング テーブルをクリーンアップします。 ジョブ履歴のクリーンアップ ジョブ をスケジュールすることでこの最適化を実現できます。 このジョブをスケジュールするには、データ管理ワークスペースのジョブ履歴クリーンアップ タスクを選択します。
メモ
最初に機能管理ワークスペースの実行履歴のクリーンアップ機能を有効にする必要があります。
統計の更新
大量のデータが関係するデータ移行ジョブを実行する前に、関連するテーブルの統計の更新を検討してください。 この最適化は、運用環境で自動的に処理されるため、サンドボックス環境に特に適用されます。 LCS から特定のテーブルの統計を更新 できます。 または、サンドボックス環境では、直接 SQL を介して sp_updatestats ストアド プロシージャを使用できます。
データのクリーンアップ
検証とエラー報告にかかる時間は、移行の合計時間を増やします。 量の多い無効または不整合なデータをインポートする場合は、この点を考慮してください。 検証とエラー処理の不要な実行を防ぐために、データ品質に関連するエラーを修正して減らします。
データ移行のテストの実行中にテストする構成
パフォーマンスに影響を与える可能性がある構成は次のとおりです。 シナリオに適したさまざまな値を使用して変更をテストします。
エンティティの実行パラメーターを構成します
すべてのエンティティまたは特定のエンティティの実行パラメーターを変更するには、次の手順に従います。
- データ管理ワークスペースで、フレームワーク パラメーター タイルを選択します。
- エンティティ設定タブのデータのインポート/エクスポート フレームワーク パラメーター ページで、エンティティの実行パラメーターを構成するを選択します。
- エンティティ インポートの実行パラメーター ページで、インポートのしきい値レコード数およびインポート タスク数フィールドを目的のエンティティに適切に設定します。
インポートしきい値レコード数
この値は、スレッドごとに処理するレコードの数を決定します。 インポートしきい値レコード数を変更することで、インポートをより小さなタスクに分割する方法を制御できます。
インポート タスク数
このフィールドは、特定のエンティティのデータ移行ジョブに使用するスレッドの数を定義します。 たとえば、各サーバーの最大バッチ スレッド フィールドが 8 に設定され、データ移行バッチ グループに 4 つのサーバーが割り当てられます。 この場合、インポート タスク数フィールドの合計最大値は 32 (= 8 × 4) になります。
データ エンティティがマルチスレッドをサポートしない場合、エンティティを構成しようとする場合にエラー メッセージが表示されます。 例:
カスタム シーケンスはエンティティ「顧客 V3」に対して定義されています。複数のタスクはサポートされていません。
検証
システムには、レコードの挿入または更新の検証ロジックが含まれている場合や、個々のフィールドを検証する場合があります。 データ移行プロセスが成熟している場合は、この検証を無効にすることで、インポートにかかる時間を短縮できます。
次の手順に従って、各エンティティの設定を変更します。
- データ管理ワークスペースで、データ エンティティ タイルを選択します。
- [ ターゲット エンティティ ] ページで、グリッド内のエンティティを選択します。 アクション ウィンドウで、[ エンティティ構造] を選択します。
- エンティティ構造ページで、ビジネス検証および挿入または更新メソッドでのビジネス ロジックの実行フィールドを適切に設定します。
業務検証の実行
このチェック ボックスをオンにすると、テーブルの validateWrite() メソッドに書き込まれたロジックがシステムによって実行されます。 また、関連するイベント ハンドラーも実行されます。
挿入方法または更新方法のビジネス ロジックを実行
このチェック ボックスをオンにすると、テーブルの insert() メソッドまたは update() メソッドに書き込まれたロジックがシステムによって実行されます。 また、関連するイベント ハンドラーも実行されます。
ターゲットの validateField メソッドを呼び出す
フィールド検証を実行するには、次の手順を実行します。
- データ管理ワークスペースで、データ エンティティ タイルを選択します。
- [ ターゲット エンティティ ] ページで、グリッド内のエンティティを選択します。 アクション ウィンドウで、[ ターゲット マッピングの変更] を選択します。
- ステージングをターゲットにマップ ページで、検証を実行するフィールドのフィールドの検証メソッドの呼び出しチェック ボックスをオンにします。 その後、そのフィールドに対して validateField(FieldId p1) メソッドが呼び出されます。
データ移行のパフォーマンスを最適化するための推奨事項
データ移行のパフォーマンスを最適化するには、次の方法を使用します。
- 大きなファイルを小さいチャンクに分割します。 この方法により、SQL オプティマイザは、新しいクエリ プランが最適かどうかを判断するための時間を確保できます。
- 適切なレベル 2 以上の環境でパフォーマンスをテストします。
- 本番稼働前に、模擬的な切替作業でのパフォーマンスをテストします。
データ移行のパフォーマンスのテストは反復的なプロセスです。 各テストに関する情報を収集して比較し、特定のエンティティに最適な構成を決定します。 次の設定の一部を収集して確認します。
- 使用するバッチ グループ
- 各バッチ グループに割り当てるバッチ サーバーの数
- バッチ サーバーごとのバッチ スレッドの最大数
エンティティごとに収集できる情報の例を次に示します。
| 情報 | 説明 |
|---|---|
| エンティティ | テストするエンティティの名前 |
| レコード数 | インポートするレコードの数 |
| ソース形式 | インポートするデータのソース形式 |
| 無効にされた変更追跡 | はい/いいえ |
| セットベース処理 | はい/いいえ |
| インポートしきい値レコード数 | レコード数 |
| インポート タスク数 | タスク数 |
| 業務検証の実行 | はい/いいえ |
| 挿入方法または更新方法のビジネス ロジックを実行 | はい/いいえ |
| "フィールドの検証" メソッドの呼び出し | はい/いいえ (潜在的なフィールドのリスト) |
| 必要なパフォーマンス | 切替ウィンドウを達成するためにインポートを完了する必要がある時間 |
| 実際のパフォーマンス | レコードのインポートに必要な実際の時間 |
他の領域でパフォーマンスを最適化できます。 たとえば、特定のクエリおよびクエリ プランを分析できます。 ただし、これらのプロセスについては他のトピックで説明します。
パフォーマンスのトラブルシューティングおよび最適化の詳細については、次のトピックを参照してください。