実稼働サーバーでテスト サーバーを使用してデータベースをチューニングすることは、データベース エンジン チューニング アドバイザーの重要な利点です。 この機能を使用すると、実稼働サーバーからテスト サーバーに実際のデータをコピーすることなく、チューニング オーバーヘッドをテスト サーバーにオフロードできます。
注
テスト サーバー チューニング機能は、データベース エンジン チューニング アドバイザーのグラフィカル ユーザー インターフェイス (GUI) ではサポートされていません。
この機能を正常に使用するには、次のセクションに記載されている考慮事項を確認してください。
テスト サーバー/運用サーバー環境の設定
テスト サーバーを使用して実稼働サーバー上のデータベースをチューニングするユーザーは、両方のサーバーに存在する必要があります。または、このシナリオは機能しません。
テスト サーバー/運用サーバー シナリオ を使用するには、拡張ストアド プロシージャxp_msverを有効にする必要があります。 データベース エンジン チューニング アドバイザーでは、この拡張ストアド プロシージャを使用して、テスト サーバーのチューニング中に使用するプロセッサの数と、運用サーバーの使用可能なメモリをフェッチします。 xp_msverが有効になっていない場合、データベース エンジン チューニング アドバイザーは、データベース エンジン チューニング アドバイザーが実行されているコンピューターのハードウェア特性を前提としています。 データベース エンジン チューニング アドバイザーが実行されているコンピューターのハードウェア特性を使用できない場合は、1 つのプロセッサと 1024 MB (MB) のメモリが想定されます。 この拡張ストアド プロシージャは、SQL Server をインストールするときに既定で有効になります。 詳細については、「 サーフェス 領域の構成 と xp_msver (Transact-SQL)」を参照してください。
データベース エンジン チューニング アドバイザーでは、SQL Server のエディションがテスト サーバーと運用サーバーの両方で同じであることが想定されています。 2 つの異なるエディションがある場合は、テスト サーバー上のエディションが優先されます。 たとえば、テスト サーバーが SQL Server Standard を実行している場合、実稼働サーバーが SQL Server Enterprise を実行している場合でも、データベース エンジン チューニング アドバイザーの推奨事項にはインデックス付きビュー、パーティション分割、オンライン操作は含まれません。
テスト サーバー/運用サーバーの動作について
データベース エンジン チューニング アドバイザーでは、推奨事項の作成時に運用環境とテスト サーバーのハードウェアの違いが考慮されます。 推奨事項は、運用サーバーのみでチューニングが行われた場合と同じです。
データベース エンジン チューニング アドバイザーでは、メタデータの収集やチューニングに必要な統計の作成のために、運用サーバーに負荷がかかる場合があります。
データベース エンジン チューニング アドバイザーは、実稼働サーバーからテスト サーバーに実際のデータをコピーしません。 データベースのメタデータと必要な統計のみがコピーされます。
すべてのセッション情報は、実稼働サーバー上の msdb に格納されます。 これにより、使用可能なテスト サーバーを利用してチューニングを行うことができます。また、すべてのセッションに関する情報を 1 か所 (運用サーバー) で利用できます。
シェル データベースに関連する問題
チューニング後、データベース エンジン チューニング アドバイザーは、チューニング プロセス中にテスト サーバー上に作成されたすべてのメタデータを削除する必要があります。 これにはシェル データベースが含まれます。 同じ実稼働サーバーとテスト サーバーで一連のチューニング セッションを実行する場合は、このシェル データベースを保持して時間を節約できます。 XML 入力ファイルで、TuningOptions 親要素の他のサブ要素と共に RetainShellDB サブ要素を指定します。 これらのオプションを使用すると、データベース エンジン チューニング アドバイザーはシェル データベースを保持します。 詳細については、「 XML 入力ファイル リファレンス (データベース エンジン チューニング アドバイザー)」を参照してください。
RetainShellDB サブ要素を指定していない場合でも、テスト サーバー/運用サーバーチューニング セッションが成功した後、テスト サーバー上でシェル データベースが残される可能性があります。 これらの不要なシェル データベースは後続のチューニング セッションに干渉する可能性があり、別のテスト サーバー/運用サーバー チューニング セッションを実行する前に削除する必要があります。 さらに、チューニング セッションが予期せず終了すると、テスト サーバー上のシェル データベースと、それらのデータベース内のオブジェクトがテスト サーバーに残される可能性があります。 新しいテスト サーバー/運用サーバー チューニング セッションを開始する前に、これらのデータベースとオブジェクトも削除する必要があります。
チューニング プロセスに関連する問題
ユーザーは、チューニング ログで、運用サーバーとテスト サーバーの違いに起因するチューニング エラー、および運用環境からテスト サーバーへのメタデータのコピーによって発生するエラーを確認する必要があります。 たとえば、テスト サーバーにユーザー ログインが存在しない場合があります。 テスト サーバーにユーザー ログインが存在しない場合、そのユーザー ログインによって発行されたワークロード内のイベントは、チューニングできない可能性があります。 データベース エンジン チューニング アドバイザー GUI を使用して、チューニング ログを表示します。 詳細については、「データベース エンジン チューニング アドバイザーからの出力の表示と操作」を参照してください。
データベース エンジン チューニング アドバイザーがテスト サーバーで作成するシェル データベースにオブジェクトがないため、データベース エンジン チューニング アドバイザーで多くのイベントをチューニングできない場合、ユーザーはチューニング ログを確認する必要があります。 チューニングできないイベントがログに一覧表示されます。 テスト サーバーでデータベースを正常にチューニングするには、不足しているオブジェクトをシェル データベースに作成し、新しいチューニング セッションを開始する必要があります。
テスト サーバーに同じ名前のデータベースが既に存在する場合、データベース エンジン チューニング アドバイザーはメタデータをコピーしませんが、チューニングを続行し、必要に応じて統計を収集します。 これは、ユーザーが既にテスト サーバー上にデータベースを作成しており、データベース エンジン チューニング アドバイザーを呼び出す前に適切なメタデータをコピーしている場合に便利です。
実稼働サーバー上のデータベースに対して DATE_CORRELATION_OPTIMIZATION オプションが有効になっている場合、テスト サーバーのチューニング中に、このオプションに関連付けられているメタデータとデータは完全にはスクリプト化されません。 テスト サーバー/運用サーバー のシナリオに対してチューニングを実行すると、次の問題が発生する可能性があります。
ユーザーは、DATE_CORRELATION_OPTIMIZATION オプションを使用するクエリに対して、サーバー上で異なるクエリ プランを持つことができます。
データベース エンジン チューニング アドバイザーでは、推奨スクリプトで DATE_CORRELATION_OPTIMIZATION オプションを適用するインデックス付きビューを削除することをお勧めします。
そのため、データベース エンジン チューニング アドバイザーが関連付けの統計情報を保持するインデックス付きビューに関してデータベース エンジン チューニング アドバイザーが行う推奨事項は無視する必要があります。これは、データベース エンジン チューニング アドバイザーがコストを把握しているが、その利点は把握していないためです。 データベース エンジン チューニング アドバイザーでは、 datetime 列のクラスター化インデックスなどの特定のインデックスを選択しないことをお勧めします。これは、DATE_CORRELATION_OPTIMIZATIONが有効になっている場合に役立つ可能性があります。
ビューが相関統計に基づいているかどうかを判断するには、sys.views カタログ ビューのis_date_correlation_view列を選択します。