次の方法で共有

データベース エンジン チューニング アドバイザとインデックス チューニング ウィザードの相違点

  • [アーティクル]

Microsoft SQL Server 2005 データベース エンジンは、新しいデータベース機能を処理できることに加えて、Microsoft SQL Server 2000 インデックス ウィザードとは異なった動作をします。どちらのツールもグラフィカル ユーザー インターフェイス (GUI) とコマンド プロンプト インターフェイスを提供していますが、インデックス チューニング ウィザードに慣れているユーザーは、次に挙げる変更点を考慮する必要があります。

データベース エンジン チューニング アドバイザの新機能の全一覧については、「データベース エンジン チューニング アドバイザの機能」を参照してください。

データベースのチューニングに必要な権限

SQL Server 2000 では、sysadmin 固定サーバー ロールのメンバだけが、インデックス チューニング ウィザードを使用してデータベースのチューニングを行えました。SQL Server 2005 では、データベース エンジン チューニング アドバイザを使用する場合、sysadmin ロールのメンバがデータベースをチューニングできる点は同じですが、db_owner 固定データベース ロールのメンバも、自分が所有するデータベースのチューニングを行えるようになりました。

ms173448.note(ja-jp,SQL.90).gifメモ :
最初の使用時には、システム管理者の権限を持つユーザーがデータベース エンジン チューニング アドバイザを起動して、アプリケーションを初期化する必要があります。初期化した後は、sysadmin 固定サーバー ロールのメンバと、db_owner 固定データベース ロールのメンバの両方が、データベース エンジン チューニング アドバイザを使用してデータベースのチューニングを行えます。ただし、db_owner ロールのメンバは、自分が所有しているデータベースだけをチューニングできることに注意してください。詳細については、「データベース エンジン チューニング アドバイザの初期化」を参照してください。

ワークロードのコンテキスト

インデックス チューニング ウィザードは、チューニング対象のデータベースを使用しているワークロード内の各ステートメントを評価しますが、そのステートメントが元々そのデータベースのコンテキストで実行されるかどうかは考慮しませんでした。また、インデックス チューニング ウィザードがチューニングできるのは、1 つのチューニング セッション中に 1 つのデータベースだけでした。SQL Server 2005 のデータベース エンジン チューニング アドバイザは、1 つのチューニング セッション中に複数のデータベースのチューニングを行えます。データベース エンジン チューニング アドバイザは、スクリプトの情報を利用してステートメントが実行されるデータベースを判別し、そのデータベースに対してそのステートメントを評価します。チューニング対象としてどのデータベースが選択されているかは、ステートメントの評価方法に影響を与えません。

次に例を示します。

  • AdventureWorks データベース内に Person.Contact テーブルがあり、そのテーブルには FirstName および LastName という列があります。

  • ワークロード TuneQuery.sql には、次のようなクエリが含まれています。

    SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName = 'Abercrombie';
GO

  • User1 は、既定で MyDB データベースに接続します。

SQL Server 2000 で、User1 は、次のコマンドをコマンド ラインから実行するか、インデックス チューニング ウィザードの GUI を使用して同様の手順を実行しました。

Itwiz -D AdventureWorks -I TuneQuery.sql –o rec.sql –U <username> –P <password>

この方法は有効です。TuneQuery.sql 内の各ステートメントは、コマンド ライン (-D AventureWorks) で指定された AdventureWorks データベースに対して解析されるからです。TuneQuery.sql は AdventureWorks データベースで有効なので、チューニングは何の問題もなく実行されます。

SQL Server 2005 では、その動作が変更になりました。データベース エンジン チューニング アドバイザのコマンド ライン構文は、次のとおりです。

dta -s Session1 –D AdventureWorks –if TuneQuery.sql –of rec.sql –U username –P password

User1 は既定で MyDB データベースに接続するので、システムはデータベース コンテキストを MyDB に設定します。次に、Transact-SQL ステートメントは AdventureWorks データベースに対してではなく、MyDB データベースに対して分析されます。そのステートメントは MyDB では有効でないので、無視されます。

なぜこのようなことが起きたのでしょうか。もし User1 が、対象のデータベースを指定せずに sqlcmd または SQL Server Management Studio を使用して TuneQuery.sql を実行したとすると、TuneQuery.sql は MyDB に対して実行され、失敗します。データベース エンジン チューニング アドバイザは、この動作を模倣します。

では、どうすればよいのでしょうか。次のように、USE <database> ステートメントを TuneQuery.sql に追加してください。

USE AdventureWorks;
GO
SELECT FirstName, LastName
FROM Person.Contact
WHERE LastName = 'Abercrombie';
GO

データベース エンジン チューニング アドバイザは、最初に USE AdventureWorks ステートメントを見て、その情報を使用して現在のデータベースを AdventureWorks に設定します。次に SELECT FirstName, LastName FROM Person.Contact WHERE LastName = 'Abercrombie' を見たときには、そのステートメントを AdventureWorks に対するものとして解析します。現在のデータベース コンテキストが AdventureWorks になっているからです。こうして、データベース エンジン チューニング アドバイザは、データベースのチューニングを正常に実行できます。上記のスクリプトを sqlcmd または SQL Server Management Studio を使用して実行すると、ステートメントが AdventureWorks に対して実行されます。最初の USE <database> ステートメントによってデータベース コンテキストが MyDB から AdventureWorks に変更されるからです。

USE <database> ステートメントは、ステートメントの実行対象のデータベースを指定するために使用できます。一般に、各ステートメントで完全修飾テーブル名を使用している場合、これは不要です。

データベース エンジン チューニング アドバイザは、(実行環境を模倣するため) ステートメントごとに実行対象のデータベースを見つけようとするので、この後の情報を読んでデータベース エンジン チューニング アドバイザがさまざまな種類の入力をどのように扱うかについて理解しておくことが重要です。

SQL ファイル/インラインのワークロード

前のセクションで説明したとおり、データベース エンジン チューニング アドバイザは Transact-SQL クエリの前にある USE <database> ステートメントを使用してクエリの実行対象のデータベースを識別します。データベース エンジン チューニング アドバイザは、入力を読み取る際に、Transact-SQL スクリプト ファイルの最初のステートメントから始めます。開始時点では、現在のデータベースが既定のデータベースであると想定します。USE <database> ステートメントがあると、ステートメント分析の対象になる現在のデータベース コンテキストが変更されます。

トレース ファイルとトレース テーブル

データベース エンジン チューニング アドバイザは、トレース ファイルを実行するときに、SQL Server Profiler の再生を模倣します。トレース ファイルにある以下の情報を、次の順序で使用します。

  • トレース ファイルの DatabaseName 列にデータがあるイベントが含まれている場合、データベース エンジン チューニング アドバイザはそれを使用して、そのイベントの実行対象だったデータベースを検出します。
  • トレース ファイルの DatabaseID 列にデータがあるイベントが含まれている場合、データベース エンジン チューニング アドバイザはそれを使用して、そのイベントの実行対象だったデータベースを検出します。システム カタログを照会して、DatabaseID に対応するデータベース名を検出します。
ms173448.note(ja-jp,SQL.90).gifメモ :
トレースの収集後にデータベースのデタッチ、アタッチ、削除、または作成が行われた場合、DatabaseID と DatabaseName の対応付けが、トレースの作成時と変わっている可能性があります。データベース エンジン チューニング アドバイザは、この情報を判別できません。そのような場合には、トレースから DatabaseID をすべて削除することにより、データベース エンジン チューニング アドバイザが間違ったデータベースをチューニングすることを避けられます。
  • トレースの列に DatabaseName および DatabaseID がどちらも存在しない場合、データベース エンジン チューニング アドバイザは、トレース ファイル内の各 SPID 列に対して、Transact-SQL スクリプトの場合と同じ方法を使用して、各ステートメントでどのデータベースを使用するかを決めます。SPID 列が存在しない場合は、Transact-SQL スクリプトの場合とまったく同じ方法で決定が行われます。

また、データベース エンジン チューニング アドバイザは、各ステートメントの分析中に、ログイン情報も使用します (SQL Server Profiler の再生と同様です)。サーバー上の既定のデータベースは、トレース ファイルにある LoginName 列の値に応じて変わることがあります。

ms173448.note(ja-jp,SQL.90).gifメモ :
トレース内にあるログインがシステムに存在しなくなった場合、データベース エンジン チューニング アドバイザはそれを無視し、チューニング プロセスを現在実行しているログインが既定で使用されます。これが行われた場合には、データベース エンジン チューニング アドバイザのチューニング ログにメッセージが書き込まれます。

チューニングの制限時間

SQL Server 2005 では、データベース エンジン チューニング アドバイザで、チューニング時間を指定することも、チューニング時間を無制限にすることもできます。この機能は、インデックス チューニング ウィザードでは使用できませんでした。詳細については、「チューニング時間とイベントの制限」を参照してください。

参照

その他の技術情報

データベース エンジン チューニング アドバイザのチュートリアル
物理データベース デザインのチューニング

ヘルプおよび情報

SQL Server 2005 の参考資料の入手