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

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

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

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

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

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

たとえば、次のような例を考えてみましょう。

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

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

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

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

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

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

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

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

データベース エンジン チューニング アドバイザーを使用する場合のコマンド ライン構文は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• トレース ファイルの DatabaseName 列にデータがあるイベントが含まれている場合、データベース エンジン チューニング アドバイザーはそれを使用して、そのイベントの実行対象だったデータベースを検出します。

• トレース ファイルの DatabaseID 列にデータがあるイベントが含まれている場合、データベース エンジン チューニング アドバイザーはそれを使用して、そのイベントの実行対象だったデータベースを検出します。システム カタログを照会して、DatabaseID に対応するデータベース名を検出します。

注
トレースの収集後にデータベースのデタッチ、アタッチ、削除、または作成が行われた場合、DatabaseID と DatabaseName の対応付けが、トレースの作成時と変わっている可能性があります。データベース エンジン チューニング アドバイザーは、この情報を判別できません。そのような場合には、トレースから DatabaseID をすべて削除することにより、データベース エンジン チューニング アドバイザーが間違ったデータベースをチューニングすることを避けられます。

• トレースの列に DatabaseName および DatabaseID がどちらも存在しない場合、データベース エンジン チューニング アドバイザーは、トレース ファイル内の各 SPID 列に対して、Transact-SQL スクリプトの場合と同じ方法を使用して、各ステートメントでどのデータベースを使用するかを決めます。SPID 列が存在しない場合は、Transact-SQL スクリプトの場合とまったく同じ方法で決定が行われます。

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

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

チューニングの制限時間

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

関連項目

概念

その他の技術情報