XML 入力ファイルを使用したチューニング
データベース エンジン チューニング アドバイザのグラフィカル ユーザー インターフェイス (GUI) および dta コマンド ライン ユーティリティを使用して実行できるチューニング操作は、すべてデータベース エンジン チューニング アドバイザの XML 入力ファイルに定義できます。ただし、XML 入力ファイルは、GUI およびコマンド ライン ユーティリティで使用できないチューニング オプションもサポートしています。
XML 入力ファイルは、パブリッシュされたデータベース エンジン チューニング アドバイザ XML スキーマを使用します。このスキーマは、SQL Server 2008 のインストール ディレクトリの次の場所にあります。
C:\Program Files\Microsoft SQL Server\10\Tools\Binn\schemas\sqlserver\2004\07\dta\dtaschema.xsd
また、次の URL からダウンロードすることもできます。
https://schemas.microsoft.com/sqlserver/2004/07/dta
XML 入力ファイルによって、データベースのチューニング時に、使い慣れた XML ツールを使用できます。また、熟練データベース管理者に対してより高い柔軟性を提供します。たとえば、XML 入力ファイルを使用すると、既存の物理デザイン構造と仮定の物理デザイン構造 (インデックス、インデックス付きビュー、およびパーティション) の組み合わせを含む構成を指定できます。その後で、dta コマンド ライン ユーティリティを使用して、あたかも既存の物理デザイン構造と仮定の物理デザイン構造の組み合わせが既に実装されているかのようにデータベースをチューニングできます。この機能によって、実際の構成を実装する際のオーバーヘッドを負うことなく、チューニング前の "what-if" 分析を行えます。
次のサブセクションでは、データベース エンジン チューニング アドバイザの XML 入力ファイルを使用した場合にのみ実行できるチューニング操作について説明します。このファイルとその使用方法の詳細については、「XML 入力ファイル リファレンス (データベース エンジン チューニング アドバイザ)」を参照してください。
Configuration 要素による構成の指定
データベース エンジン チューニング アドバイザの GUI を通じて使用できるユーザー指定の構成機能は限られています。この機能は、コマンド ラインの dta ユーティリティで XML 入力ファイルを使用した場合のみ完全にサポートされます。XML 入力ファイルを使用するときは、まったく仮定の構成を指定することも、既存の物理デザイン構造と仮定の物理デザイン構造の組み合わせを含む構成を指定することもできます。その後、データベース エンジン チューニング アドバイザの XML スキーマに対して入力ファイルを検証してから、dta コマンド ライン ユーティリティの入力としてファイルを使用できます。データベース エンジン チューニング アドバイザでチューニング セッションを開始すると、データベースに対して指定したワークロードが実行されます。ただし、データベース エンジン チューニング アドバイザでは、インデックス、インデックス付きビュー、およびパーティションの既存の構成は評価されません。代わりに、データベース エンジン チューニング アドバイザでは、既存の構造と仮定の構造を組み合わせた構成が使用されます。仮定の構成を使用することで、実際の構成を実装する際のオーバーヘッドを負うことなく、特定の構成がデータベースのパフォーマンスに及ぼす影響を分析できます。
既存の物理デザイン構造と仮定の物理デザイン構造を含む構成を指定するには、データベース エンジン チューニング アドバイザの XML 入力ファイルで、TuningOptions 要素の後に Configuration サブ要素を使用します。詳細については、「予備分析を実行する方法」および「ユーザー指定の構成を指定した XML 入力ファイルのサンプル (DTA)」を参照してください。
EventString 要素によるインライン ワークロードのチューニング
データベース エンジン チューニング アドバイザで XML 入力を使用する場合は、ワークロード ファイルをまったく使用しなくてもかまいません。代わりに、XML 入力ファイルにワークロードとその関連付けられた加重インラインを指定できます。別のワークロード ファイルまたはテーブルの使用を回避する利点は次のとおりです。
別のファイルまたはテーブルがデータベース エンジン チューニング アドバイザで使用できるかどうかを心配する必要がないので、リモート サーバーをより簡単にチューニングできます。
スクリプトをエンタープライズ環境全体に移植する場合でも、データベース エンジン チューニング アドバイザの機能を簡単に取り込むことができます。
インライン ワークロードを指定するには、EventString サブ要素を使用します。このワークロードでは、オプションで、関連付けられた加重を指定できます。このサブ要素を使用するときは、別のワークロード ファイルまたはテーブルを指定するのではなく、Workload 親要素に対して指定します。次のコード例では、XML 入力ファイルを伴う EventString 要素の使用を、XML 入力ファイルを伴う一般的なワークロード ファイルの使用と比較しています。
例
A. Workload 要素を持つ別のワークロード ファイルを指定する場合
<DTAInput>
...code removed
<Workload>
<File>MyWorkload.sql</File>
</Workload>
...code removed
</DTAInput>
B. EventString 要素を持つインライン ワークロードを指定する場合
<DTAInput>
...code removed
<Workload>
<EventString Weight="100">
SELECT * FROM MyTable1
WHERE MyColumn1 > 200
ORDER BY MyColumn1
</EventString>
<EventString Weight="1">
SELECT * FROM MyTable2
WHERE MyColumn2 > 200
ORDER BY MyColumn2
</EventString>
</Workload>
...code removed
</DTAInput>
この例では、100 および 1 という異なる加重が EventString 要素内の各クエリに指定されています。つまり、データベース エンジン チューニング アドバイザがこれらのクエリをチューニングする場合、アプリケーションは、100 の加重のあるクエリでは、1 の加重のあるクエリの 1 インスタンスと比較して、あたかもそのクエリが 100 インスタンスあるかのように処理します。上記の例では、データベース エンジン チューニング アドバイザの評価のために、最初のクエリが 2 番目のクエリよりも 100 倍重要であることを示しています。また、大なり (>) 記号が > に変換されていることに注意してください。これは、大なり (>) 記号が XML 内で特別な意味を持つ記号として予約されているためです。
EventString 要素を持つインライン ワークロードを指定する例については、「インライン ワークロードを使用した XML 入力ファイルのサンプル (DTA)」を参照してください。
IgnoreConstantsInWorkload 要素を持つワークロードでの定数の無視
ワークロードには定数に関するステートメントを含めることができます。データベース エンジン チューニング アドバイザは、ワークロード内の定数を使用して、選択条件のあるインデックス付きビューまたはパーティション インデックス用の範囲パーティション関数を含む推奨設定を生成することができます。
ただし、データベース エンジン チューニング アドバイザがワークロード内の定数を考慮することが効果的ではない場合もあります。たとえば、次のステートメントを含むワークロードを考えます。
UPDATE BankAccountTable
SET AccountBalance = AccountBalance - 1000.00
WHERE CustomerID =
(SELECT CustomerID FROM Customer WHERE CustomerName = 'Alice')
このワークロードは Alice がトランザクションを実行したときにキャプチャされたため、'Alice' という定数を含みます。データベース エンジン チューニング アドバイザがこの定数を使用すると、効果的なチューニング推奨設定を生成できない場合があります。この場合、データベース エンジン チューニング アドバイザがこのワークロードを使用してデータベースをチューニングするときに定数を無視するように指定すると効果的です。
XML 入力ファイルの TuningOptions 要素の下に IgnoreConstantsInWorkload 要素を指定すると、データベース エンジン チューニング アドバイザがワークロード内の定数をすべて無視することができます。この要素を指定すると、データベース エンジン チューニング アドバイザが推奨するインデックス付きビューには選択条件が含まれません。さらに、パーティション関数で使用される定数はデータのみから派生し、ワークロード内に含まれる定数からは派生しません。
テスト サーバーを使用して稼働サーバーのワークロードをチューニングする
大きなワークロードのチューニングでは、チューニング対象のサーバーに多大なオーバーヘッドを引き起こす可能性があります。これは、チューニング プロセス中にデータベース エンジン チューニング アドバイザがクエリ オプティマイザに対して通常実行する多数の呼び出しが原因です。稼働サーバーに加えてテスト サーバーを使用すると、この問題を解消できます。データベース エンジン チューニング アドバイザは、このシナリオを次のような特別な方法でサポートしています。
チューニングを実行するユーザーが稼働サーバーとテスト サーバーの両方に存在することを確認してください。sysadmin 固定サーバー ロールのメンバの場合、この手順は必要ありません。
チューニング用のテスト サーバーを XML 入力ファイルに指定するときに、チューニング セッションを定義する他のパラメータも指定します。
dta コマンド ライン ユーティリティを使用して、チューニング セッションを開始し、ワークロード分析を開始します。
このテスト サーバーによるチューニング セッション中に、データベース エンジン チューニング アドバイザは稼働サーバーに対して最低限の呼び出しを実行します。これらの呼び出しは、テスト サーバー上でクエリ オプティマイザが正確にクエリを最適化するために必要な、稼働サーバーのハードウェア プロファイル、データベース メタデータ、および統計についての情報を入手するために実行されます。
このシナリオでは、実際には、稼働サーバーの環境を複製したテスト サーバーがチューニングされます。テスト サーバーをチューニングした結果としてデータベース デザイン構成のアドバイスを受け取ったら、メンテナンス時に稼働サーバーにその推奨設定を実装できます。このプロセスを使用することで、データベース エンジン チューニング アドバイザによるパフォーマンスの低下を最小限に抑えることができます。さらに、このプロセスでは、データを稼働サーバーからテスト サーバーにコピーする時間を節約できます。また、テスト環境に強力な稼働サーバー ハードウェアを複製するための費用も削減できます。
テスト サーバーを指定するには、次の例で示したように TuningOptions の下の TestServer サブ要素を使用します。
例
<DTAInput>
...code removed
<TuningOptions>
<TestServer>MyTestServer</TestServer>
<FeatureSet>IDX_IV</FeatureSet>
<Partitioning>NONE</Partitioning>
<KeepExisting>NONE</KeepExisting>
</TuningOptions>
...code removed
</DTAInput>
この機能の使用方法および別のコード例の詳細については、「実稼動サーバーのチューニング負荷の軽減」を参照してください。