数据库引擎优化顾问与索引优化向导之间的差别
除了可以处理 MicrosoftSQL Server 的新数据库功能以外，数据库引擎优化顾问在具体操作方面也不同于 MicrosoftSQL Server 2000 索引优化向导。尽管这两个工具都提供了图形用户界面 (GUI) 和命令提示符界面，但熟悉索引优化向导的用户应注意以下更改。
有关数据库引擎优化顾问的新功能的完整列表，请参阅数据库引擎优化顾问功能。
优化数据库所需的权限
在 SQL Server 2000 中，只有 sysadmin 固定服务器角色的成员可以使用索引优化向导来优化数据库。在 SQL Server 中，通过使用数据库引擎优化顾问，sysadmin 角色的成员仍可以优化数据库，但目前 db_owner 固定数据库角色的成员同样可以优化自己所拥有的数据库。
.gif "注意") 注意 |
|---|
首次使用时，必须由具有系统管理员权限的用户启动数据库引擎优化顾问以初始化应用程序。初始化后，sysadmin 固定服务器角色的成员和 db_owner 固定数据库角色的成员都可以使用数据库引擎优化顾问来优化数据库。但请注意，db_owner 角色成员只可以优化自己所拥有的数据库。有关详细信息，请参阅初始化数据库引擎优化顾问。 |
工作负荷上下文
索引优化向导使用选定要优化的数据库来评估工作负荷中的每条语句，而不管该语句最初是否是在该数据库的上下文中执行的。索引优化向导在一个优化会话中只能优化一个数据库。数据库引擎优化顾问可以在一个优化会话期间优化多个数据库。数据库引擎优化顾问使用脚本中的信息确定语句运行所在的数据库，并针对该数据库评估此语句。选定要优化的数据库不会影响评估语句的方式。
例如：
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 中的每条语句均针对 AdventureWorks 数据库（因为命令行 -D AventureWorks 中指定了它）进行了分析。TuneQuery.sql 在 AdventureWorks 数据库中有效，优化继续进行，并且未出现任何问题。
使用数据库引擎优化顾问时，命令行语法为：
dta -s Session1 –D AdventureWorks –if TuneQuery.sql –of rec.sql –U username –P password
由于默认情况下，User1 连接到 MyDB 数据库，因此系统将数据库上下文设置为 MyDB。然后，对 MyDB 数据库而不是对 AdventureWorks 分析 Transact-SQL 语句。该语句在 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 文件/内联工作负荷
正如在前面部分中提到的，数据库引擎优化顾问使用 USE <database> 语句（位于 Transact-SQL 查询之前）标识对其执行查询的数据库。数据库引擎优化顾问从 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 列值的改变而改变。
| 注意 |
|---|
如果跟踪文件中存在的登录不再出现在系统中，则数据库引擎优化顾问将忽略该登录，并在默认情况下使用当前正在执行优化过程的登录。如果出现这种情况，则系统将在数据库引擎优化顾问的优化日志中写入一条消息。 |