Diferenças entre o Orientador de Otimização do Mecanismo de Banco de Dados e o Assistente de Ajuste do Índice
Além de tratar dos novos recursos de banco de dados do SQL Server, o Orientador de Otimização do Mecanismo de Banco de Dados também se comporta de maneira diferente do Assistente de Ajuste do Índice do Microsoft SQL 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 ajustar 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 de sua propriedade.
Observaçã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 Inicializando 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 maneira como as instruções são avaliadas.
Por exemplo:
O banco de dados AdventureWorks2008R2 possui uma tabela Person.Person com as colunas FirstName e LastName.
A carga de trabalho TuneQuery.sql contém a seguinte consulta:
SELECT FirstName, LastName FROM Person.Person WHERE LastName = 'Abercrombie'; GO
User1 se conecta ao banco de dados MyDB por padrão.
No SQL Server 2000, o User1 emitia o seguinte a partir da linha de comando ou executava etapas semelhantes usando a interface de usuário do Assistente de Ajuste do Índice:
Itwiz -D AdventureWorks2008R2 -I TuneQuery.sql –o rec.sql –U <username> –P <password>
Essa abordagem funcionava, pois cada instrução em TuneQuery.sql era analisada em relação ao banco de dados AdventureWorks2008R2 porque era especificada na linha de comando (-D AventureWorks2008R2). O TuneQuery.sql era válido no banco de dados AdventureWorks2008R2 e os ajustes continuavam sem problemas.
Usando o Orientador de Otimização do Mecanismo de Banco de Dados, a sintaxe da linha de comando é:
dta -s Session1 –D AdventureWorks2008R2 –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 AdventureWorks2008R2. A instrução não é válida em MyDB e, portanto, é ignorada.
Por que isso aconteceu? Se o User1 executasse TuneQuery.sql usando sqlcmd ou SQL Server Management Studio sem especificar um banco de dados de destino, o TuneQuery.sql seria executado em relação ao 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, da seguinte maneira:
USE AdventureWorks2008R2;
GO
SELECT FirstName, LastName
FROM Person.Person
WHERE LastName = 'Abercrombie';
GO
O Orientador de Otimização do Mecanismo de Banco de Dados vê primeiro a instrução USE AdventureWorks2008R2 e usa essa informação para definir o banco de dados atual como AdventureWorks2008R2. Em seguida, quando ele vê a instrução SELECT FirstName, LastName FROM Person.Person WHERE LastName = 'Abercrombie', ele analisa a instrução em relação ao AdventureWorks2008R2, porque o contexto de banco de dados atual é AdventureWorks2008R2. 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 usando sqlcmd ou SQL Server Management Studio, a instrução será executada em relação ao AdventureWorks2008R2, porque a primeira instrução USE <database> altera o contexto do banco de dados MyDB para AdventureWorks2008R2.
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çã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çã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.
Consulte também