移行を監視する
VLDB の移行の最も重要なコンポーネントの 1 つは、開発、テスト、"ドライ ラン" 移行の間に構成される監視、ログ、診断です。
必要な監視のデプロイと、各テスト サイクル後の監視と診断の結果の解釈は必須であり、移行および運用カットオーバーの計画を最適化するために不可欠です。 また、テスト移行で得られる結果は、実際の運用移行がテスト移行と同じパターンとタイムラインに従っているかどうかを判断できるようにするために必要です。 お客様は、SAP パートナーとの定期的なプロジェクト レビュー チェックポイントを要求する必要があります。 プロジェクトの成功に必要な技術スキルと組織スキルを持つことがわかっているコンサルタントの一覧については、Microsoft にお問い合わせください。
包括的な監視とログがない場合、データ損失がないことを保証して、安全に、反復可能で、一貫性があり、ダウンタイムの低い移行を実現することはほぼ不可能です。 一部のパッケージの長時間実行などの問題が発生した場合、監視データと移行設計ドキュメントがなくては、スポット コンサルティングに関して Microsoft や SAP が支援することはほとんど不可能です。
OS と DB の移行の実行時には、次の項目を監視します。
- DB および R3load ホスト上の OS レベルのパラメーター: スレッドあたりの CPU、スレッドあたりのカーネル時間、空きメモリ (GB)、ページ イン/秒、ページ アウト/秒、ディスク IO 読み取り数/秒、ディスク IO 書き込み数/秒、ディスク読み取り KB/秒、ディスク書き込み KB/秒
- SQL Server ターゲットでの DB レベル パラメーター: BCP 行数/秒、BCP KB/秒、トランザクション ログ %、メモリ許可数、メモリ許可保留数、ロック数、ロック メモリ、ロック/ブロック
- ネットワーク監視: 通常、これはネットワーク チームによって処理されます。 ネットワーク監視の正確な構成は、お客様固有の状況によって異なります。
DB インポートの実行中は、次の SQL ステートメントを数分ごとに実行し、すべての異常 (高待機時間など) を文書化することをお勧めします。
select session_id, request_id,start_time, status, command, wait_type, wait_resource, wait_time, last_wait_type, blocking_session_id from sys.dm_exec_requests
where session_id >49 orderby wait_time desc;
すべての移行テスト サイクルの間に、エクスポートおよびインポートされたパッケージの数 (y 軸) を示す "フライト プラン" を、時間 (x 軸) に対してプロットする必要があります。 このグラフの目的は、最終的な運用移行カットオーバーにおいて予想される進行率を確立することです。 テスト移行または最終的な運用移行の間の、予想 "フライト プラン" からのずれ (プラスまたはマイナスのいずれか) は、この方法を使用して簡単に検出できます。 CPU、ディスク、R3load 行数/秒などの他のパラメーターを、"フライト プラン" に重ねて表すことができます。
エクスポートとインポートの最後に、移行時間レポートを収集する必要があります (export_time.html と import_time.html)。