Compartilhar via


Diferenças entre o Orientador de Otimização do Mecanismo de Banco de Dados e o Assistente de Ajuste do Índice

Além de controlar os novos recursos de banco de dados do MicrosoftSQL Server, o Orientador de Otimização do Mecanismo de Banco de Dados também se comporta de forma diferente do Assistente de Ajuste do Índice do MicrosoftSQL Server 2000. Embora ambas as ferramentas forneçam uma interface gráfica do usuário (GUI) e uma interface de prompt de comando, usuários que estão familiarizados com o Assistente de Ajuste do Índice devem levar em conta as alterações a seguir.

Para obter uma lista completa dos novos recursos do Orientador de Otimização do Mecanismo de Banco de Dados, consulte Recursos do Orientador de Otimização do Mecanismo de Banco de Dados.

Permissões exigidas para ajustar bancos de dados

No SQL Server 2000, apenas os membros da função de servidor fixa sysadmin podem usar o Assistente de Ajuste do Índice para fazer ajustes nos bancos de dados. No SQL Server, usando o Orientador de Otimização do Mecanismo de Banco de Dados, os membros da função sysadmin ainda podem ajustar bancos de dados, mas agora, os usuários que são membros da função de banco de dados fixa db_owner também podem ajustar os bancos de dados que eles possuem.

ObservaçãoObservação

No primeiro uso, o Orientador de Otimização do Mecanismo de Banco de Dados deve ser iniciado por um usuário com permissões de administrador de sistema para inicializar o aplicativo. Depois da inicialização, tanto os membros da função de servidor fixa sysadmin como os da função de banco de dados fixa db_owner podem usar o Orientador de Otimização do Mecanismo de Banco de Dados para ajustar os bancos de dados. No entanto, lembre-se de que os membros da função db_owner só podem ajustar os bancos de dados que eles possuem. Para obter mais informações, consulte Iniciando o Orientador de Otimização do Mecanismo de Banco de Dados.

Contexto de carga de trabalho

O Assistente de Ajuste do Índice avaliava cada instrução na carga de trabalho usando o banco de dados selecionado para ajuste, independentemente de a instrução ter sido executada originalmente no contexto daquele banco de dados. O Assistente de Ajuste do Índice só podia executar ajustes em um banco de dados durante uma sessão de ajuste. O Orientador de Otimização do Mecanismo de Banco de Dados pode executar ajustes em vários bancos de dados em uma sessão de ajuste. O Orientador de Otimização do Mecanismo de Banco de Dados usa as informações do script para determinar o banco de dados em que a instrução é executada e avalia a instrução em relação ao banco de dados. Os bancos de dados selecionados para ajuste não afetam a forma de avaliação das instruções.

Por exemplo:

  • O banco de dados AdventureWorks possui uma tabela Person.Contact com as colunas FirstName e LastName.

  • A carga de trabalho TuneQuery.sql contém a seguinte consulta:

    SELECT FirstName, LastName
    FROM Person.Contact
    WHERE LastName = 'Abercrombie';
    GO
    
  • User1 se conecta ao banco de dados MyDB por padrão.

No SQL Server 2000, o User1 emitiu os itens a seguir a partir da linha de comando ou executou etapas semelhantes usando a interface de usuário do Assistente de Ajuste do Índice:

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

Essa abordagem funcionou, pois cada instrução em TuneQuery.sql foi analisada em relação ao banco de dados AdventureWorks porque foi especificada na linha de comando (- D AventureWorks). O TuneQuery.sql era válido no banco de dados AdventureWorks e os ajustes continuaram sem problemas.

Usando o Orientador de Otimização do Mecanismo de Banco de Dados, a sintaxe da linha de comando é:

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

Como User1 se conecta por padrão ao banco de dados MyDB, o sistema define o contexto do banco de dados como MyDB. Em seguida, a instrução Transact-SQL é analisada em relação ao banco de dados MyDB e não em relação ao AdventureWorks. A instrução não é válida em MyDB, sendo, desta forma, ignorada.

Por que isso aconteceu? Se o User1 executasse o TuneQuery.sql usando sqlcmd ou SQL Server Management Studio sem especificar um banco de dados de destino, o TuneQuery.sql seria executado contra MyDB e retornaria uma falha. O Orientador de Otimização do Mecanismo de Banco de Dados imita esse mesmo comportamento.

O que deveria ser feito? Adicionar uma instrução USE <database> ao script TuneQuery.sql, conforme segue:

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

O Orientador de Otimização do Mecanismo de Banco de Dados vê primeiro a instrução USE AdventureWorks e usa essa informação para definir o banco de dados atual como AdventureWorks. Em seguida, quando ele vê a instrução SELECT FirstName, LastName FROM Person.Contact WHERE LastName = 'Abercrombie', ele analisa a instrução em relação ao AdventureWorks, porque o contexto de banco de dados atual é AdventureWorks. Isso permite que o Orientador de Otimização do Mecanismo de Banco de Dados ajuste o banco de dados com êxito. Observe que se você executar o script anterior que usa sqlcmd ou SQL Server Management Studio, a instrução será executada em relação ao AdventureWorks, porque a primeira instrução USE <database> altera o contexto do banco de dados de MyDB para AdventureWorks.

As instruções USE <database> podem ser usadas para especificar o banco de dados em relação à instrução que deve ser executada. Em geral, isso não será necessário se cada instrução usar nomes de tabela totalmente qualificados.

Como o Orientador de Otimização do Mecanismo de Banco de Dados tenta achar o respectivo banco de dados em relação ao qual cada instrução é executada (para imitar o ambiente de execução), as informações a seguir são cruciais para entender como o Orientador de Otimização do Mecanismo de Banco de Dados trata tipos diferentes de entrada.

Arquivo SQL/Carga de trabalho embutida

Como mencionado na seção anterior, o Orientador de Otimização do Mecanismo de Banco de Dados usa instruções USE <database> que precedem uma consulta Transact-SQL para identificar o banco de dados em que a consulta deve ser executada. O Orientador de Otimização do Mecanismo de Banco de Dados olha para a entrada a partir da primeira instrução no arquivo de script Transact-SQL. Ele parte do pressuposto de que o banco de dados atual é o banco de dados padrão. A presença de instruções USE <database> altera o contexto do banco de dados atual em relação a quais instruções são analisadas.

Arquivos e tabelas de rastreamento

O Orientador de Otimização do Mecanismo de Banco de Dados imita a reprodução de SQL Server Profiler quando ele passa pelo arquivo de rastreamento. Ele usa as seguintes informações de arquivos de rastreamento na ordem listada:

  • Se o arquivo de rastreamento tiver eventos com a coluna DatabaseName populada, o Orientador de Otimização do Mecanismo de Banco de Dados usará isso para achar o banco de dados contra o qual aquele evento foi executado.

  • Se o arquivo de rastreamento tiver a coluna DatabaseName populada, o Orientador de Otimização do Mecanismo de Banco de Dados usará isso para achar o banco de dados em relação ao qual aquele evento foi executado. Ele examina o catálogo do sistema para encontrar o nome do banco de dados que corresponde a DatabaseID.

ObservaçãoObservação

Se um banco de dados foi desanexado, anexado, derrubado ou criado após a coleta de um rastreamento, os mapeamentos DatabaseID e DatabaseName poderão não permanecer iguais ao da criação do arquivo de rastreamento. O Orientador de Otimização do Mecanismo de Banco de Dados não pode determinar essas informações. Se isso acontecer, remova o DatabaseID completamente do rastreamento para impedir que o Orientador de Otimização do Mecanismo de Banco de Dados ajuste um banco de dados incorreto.

  • Se DatabaseName ou DatabaseID não estiverem presentes como colunas no rastreamento, o Orientador de Otimização do Mecanismo de Banco de Dados decidirá qual banco de dados usará para cada instrução, como faz com scripts Transact-SQL para cada coluna SPID no arquivo de rastreamento. Se a coluna SPID não estiver presente, então a determinação será feita exatamente da mesma forma que ocorre nos arquivos de script Transact-SQL.

O Orientador de Otimização do Mecanismo de Banco de Dados também usa as informações de logon (como na reprodução do SQL Server Profiler) durante a análise de cada instrução. Os bancos de dados padrão do servidor podem mudar dependendo dos valores da coluna LoginName exibidas no arquivo de rastreamento.

ObservaçãoObservação

Se um logon presente no rastreamento não aparecer mais no sistema, o Orientador de Otimização do Mecanismo de Banco de Dados ignorará esse fato e, por padrão, usará o logon que esteja executando o processo de ajuste atualmente. Se isso acontecer, uma mensagem será gravada no log de ajuste do Orientador de Otimização do Mecanismo de Banco de Dados.

Ajustando limites de tempo

O Orientador de Otimização do Mecanismo de Banco de Dados permite a especificação de um tempo de ajuste ou a especificação de um tempo de ajuste ilimitado. Esse recurso não estava disponível no Assistente de Ajuste do Índice. Para obter mais informações, consulte Limitando eventos e duração de ajuste.