次の方法で共有

移行のパフォーマンス: SQL Server から Azure SQL Managed Instance への場合のパフォーマンス ベースライン

  • [アーティクル]

適用対象:Azure SQL Managed Instance

SQL Managed Instance でのワークロードのパフォーマンスを、SQL Server で実行される元のワークロードのものと比較するためのパフォーマンス ベースラインを作成します。

ベースラインを作成する

移行後のパフォーマンスは同等かそれ以上であることが理想的です。そのため、ソースのベースライン パフォーマンス値を測定して記録してから、それらをターゲット環境と比較することが重要です。 パフォーマンス ベースラインは、ソースの平均ワークロードを定義する一連のパラメーターです。

ビジネス ワークロードを表し、それらにとって重要な一連のクエリを選択します。 これらのクエリの最小/平均/最大期間と CPU 使用率だけでなく、平均/最大 CPU 使用率、平均/最大ディスク IO 待機時間、スループット、IOPS、ページの平均/最大予測保持期間、tempdb の平均最大サイズなど、ソース サーバーのパフォーマンス メトリックを測定して文書化します。

次のリソースは、パフォーマンス ベースラインの定義に役立ちます。

  • CPU 使用率の監視
  • メモリ使用量を監視し、バッファー プール、プラン キャッシュ、列ストア プール、インメモリ OLTP などのさまざまなコンポーネントで使用されるメモリの量を明らかにします。さらに、ページの予測保持期間メモリ パフォーマンス カウンターの平均値とピーク値を調べる必要があります。
  • sys.dm_io_virtual_file_stats ビューまたはパフォーマンス カウンターを使って、ソース SQL Server インスタンスでのディスク IO 使用率を監視ます。
  • 動的管理ビュー (SQL Server 2016 以降から移行する場合はクエリ ストア) を調べることで、ワークロードとクエリのパフォーマンスを監視します。 ワークロード内の最も重要なクエリの平均期間と CPU 使用率を特定します。

移行前に、ソース SQL Server のすべてのパフォーマンスの問題に対処する必要があります。 既知の問題が新しいシステムに移行されると、予期しない結果が発生し、パフォーマンスの比較が無効になる可能性があります。

パフォーマンスを比較する

ベースラインを定義した後、ターゲット SQL Managed Instance で類似したワークロードのパフォーマンスを比較します。 正確性を確保するために、SQL Managed Instance 環境が可能な限り SQL Server 環境に匹敵していることが重要です。

パフォーマンスを完全に一致させられない可能性がある、SQL Managed Instance インフラストラクチャの違いがあります。 クエリには、予想よりも高速に実行されるものもあれば、低速であるものもあります。 この比較の目的は、マネージド インスタンスでのワークロードのパフォーマンスが SQL Server でのパフォーマンスと (平均で) 一致することを確認し、重要なクエリの中にパフォーマンスが元のパフォーマンスに匹敵しないものがあるかどうかを明らかにすることです。

パフォーマンスの比較では、次のような結果になる可能性があります。

  • マネージド インスタンスでのワークロードのパフォーマンスが、ソース SQL Server でのワークロードのパフォーマンスと同等かそれより優れています。 この場合、移行が成功したことを正常に確認しました。

  • ワークロードのパフォーマンス パラメーターとクエリの多くは予期したとおりに実行されていますが、一部の例外によりパフォーマンスが低下しています。 この場合は、相違点とその重要度を特定します。 重要なクエリでパフォーマンスが低下したものがある場合は、基になる SQL プランが変更されたか、クエリでリソースが制限に達しているかを調べます。 重要なクエリ (たとえば、互換性レベル、レガシ カーディナリティ推定機能の変更) に対して、直接またはプラン ガイドを使用して、ヒントをいくつか適用することでこれを軽減できます。 確実に、統計とインデックスが最新であり、両方の環境で同等であるようにします。

  • ほとんどのクエリは、ソース SQL Server インスタンスよりマネージド インスタンスでの方が実行速度が遅くなります。 この場合は、IO、メモリ、インスタンス ログ レート制限のようなリソース制限への到達など、違いの根本原因を明らかにしてみます。 違いを引き起こすリソースの制限がない場合は、データベースの互換性レベルを変更してみるか、レガシ カーディナリティ推定などのデータベース設定を変更して、テストを再実行します。 マネージド インスタンスまたはクエリ ストア ビューによって提供されるレコメンデーションを確認し、パフォーマンスが低下したクエリを特定します。

SQL Managed Instance には、既定で有効になる組み込みの自動プラン修正機能があります。 この機能を使用すると、過去に正常に機能していたクエリのパフォーマンスが今後は低下しないことが保証されます。 この機能が有効になっていない場合は、SQL Managed Instance でパフォーマンス ベースラインを学習できるように、古い設定でワークロードを実行します。 その後、この機能を有効にし、新しい設定でもう一度ワークロードを実行します。

ニーズに合ったワークロードのパフォーマンスが得られるまで、テストのパラメーターを変更するか、上位のサービス レベルにアップグレードして、最適な構成に近付けます。

パフォーマンスの監視

SQL Managed Instance には、監視とトラブルシューティングのための高度なツールが用意されており、それらを使用してインスタンスのパフォーマンスを監視する必要があります。 監視する主なメトリックをいくつか以下に示します。

  • プロビジョニングした仮想コアの数がワークロードに適したものであるかどうかを判断するための、インスタンスの CPU 使用率。
  • 追加のメモリが必要かどうかを判断するための、マネージド インスタンスのページの予測保持期間。
  • ストレージ IO の問題を特定する INSTANCE_LOG_GOVERNOR や PAGEIOLATCH などの統計。特に、IO パフォーマンスを向上させるためにファイルの事前割り当てが必要になる可能性がある General Purpose レベルで当てはまります。

考慮事項

パフォーマンスを比較する場合は、次のことを考慮してください。

  • ソースとターゲットの間で設定は一致します。 2 つの環境の間で、インスタンス、データベース、および tempdb のさまざまな設定が等しいことを確認します。 構成、互換性レベル、暗号化設定、トレース フラグなどの違いはすべてパフォーマンスにずれを生じさせる可能性があります。

  • ストレージはベスト プラクティスに従って構成されます。 たとえば、General Purpose では、パフォーマンスを向上させるためにファイルのサイズを事前に割り当てる必要がある場合があります。

  • マネージド インスタンスと SQL Server の間でパフォーマンスの違いを引き起こす可能性のある重要な環境の違いがあります。 パフォーマンスの問題の要因になる可能性のある環境に関するリスクを特定します。

  • SQL Managed Instance ではクエリ ストアと自動チューニングを有効にする必要があります。これは、ワークロードのパフォーマンスを測定し、潜在的なパフォーマンスの問題を自動的に軽減するのに役立つためです。

次のステップ

新しい Azure SQL Managed Instance 環境を最適化する方法の詳細については、次のリソースを参照してください。