Usando um arquivo de entrada XML para ajuste
Todas as operações de ajuste que podem ser executadas com a GUI (interface gráfica do usuário) do Orientador de Otimização do Mecanismo de Banco de Dados e o utilitário de linha de comando dta podem ser definidas em um arquivo de entrada XML do Orientador de Otimização do Mecanismo de Banco de Dados. Porém, o arquivo de entrada XML aceita opções de ajuste além das que estão disponíveis com a GUI e o utilitário de linha de comando.
O arquivo de entrada XML usa o esquema XML publicado no Orientador de Otimização do Mecanismo de Banco de Dados, que pode ser encontrado no local a seguir, no diretório de instalação do SQL Server 2008:
C:\ Arquivos de Programas \Microsoft SQL Server\10\Tools\Binn\schemas\sqlserver\2004\07\dta\dtaschema.xsd
Também pode ter o download efetuado a partir da URL a seguir:
https://schemas.microsoft.com/sqlserver/2004/07/dta
O arquivo de entrada XML permite a utilização de suas ferramentas favoritas XML no ajuste de bancos de dados e proporciona maior flexibilidade aos administradores de banco de dados experientes. Por exemplo, usando-se o arquivo de entrada XML, é possível especificar uma configuração que contenha uma combinação de estruturas de design físicas existentes e hipotéticas (índices, exibições indexadas e partições). Assim, é possível usar o utilitário dta de linha de comando para ajustar um banco de dados como se essa combinação de estruturas de design físicas existentes e hipotéticas já estivesse implementada. Isso habilita a análise hipotética sem impor a sobrecarga que acompanha a implementação de uma configuração real antes dos ajustes.
As subseções a seguir discutem os operações de ajuste que você só pode executar usando o arquivo de entrada XML Orientador de Otimização do Mecanismo de Banco de Dados. Para obter mais informações sobre esse arquivo e como usá-lo, consulte Referência do arquivo de entrada XML (Orientador de Otimização do Mecanismo de Banco de Dados).
Especificando configurações com o elemento de configuração
Embora o recurso de configuração especificado pelo usuário possa ser usado de forma limitada pela GUI do Orientador de Otimização do Mecanismo de Banco de Dados, há suporte total para esse recurso somente quando você usa o arquivo de entrada XML com o utilitário dta de linha de comando. Ao usar o arquivo de entrada XML, é possível especificar uma configuração completamente hipotética, ou especificar uma configuração que contenha uma combinação de estruturas de design físicas existentes e hipotéticas (índices, exibições indexadas e partições). Assim, depois de validar o arquivo de entrada em relação ao esquema XML do Orientador de Otimização do Mecanismo de Banco de Dados, é possível usar o arquivo como entrada para o utilitário dta da linha de comandos. Durante a sessão de ajuste, o Orientador de Otimização do Mecanismo de Banco de Dados executa a carga de trabalho especificada em relação aos bancos de dados. Porém, o Orientador de Otimização do Mecanismo de Banco de Dados não avalia a configuração existente de índices, exibições indexadas e partições. Em vez disso, o Orientador de Otimização do Mecanismo de Banco de Dados usa sua configuração que é uma combinação de estruturas hipotéticas e existentes. O uso da configuração hipotética lhe permite analisar os efeitos de uma determinada configuração em relação ao desempenho de seu banco de dados sem a sobrecarga da implementação da configuração atual.
Para especificar uma configuração que contenha estruturas de design físicas existentes e hipotéticas, use o subelemento Configuração depois do elemento TuningOptions no arquivo de entrada XML do Orientador de Otimização do Mecanismo de Banco de Dados. Para obter mais informações, consulte Como executar análises exploratórias e Exemplo de arquivo de entrada XML com configuração especificada pelo usuário (DTA).
Ajustando cargas de trabalho embutidas com o elemento EventString
É possível evitar completamente o uso de um arquivo de carga de trabalho ao usar a entrada XML com o Orientador de Otimização do Mecanismo de Banco de Dados. Em vez disso, é possível especificar uma carga de trabalho e seu peso embutido no arquivo de entrada XML. Ao evitar um arquivo ou tabela de carga de trabalho separados as vantagens são as seguintes:
É possível ajustar servidores remotos mais facilmente porque você não precisa se preocupar se a tabela ou o arquivo separados estão disponíveis para ajuste pelo Orientador de Otimização do Mecanismo de Banco de Dados.
É possível incorporar a funcionalidade do Orientador de Otimização do Mecanismo de Banco de Dados mais facilmente em scripts portáteis por todo o ambiente de sua empresa.
Para especificar uma carga de trabalho embutida, use o subelemento EventString para o qual você pode especificar, opcionalmente, um peso associado. Ao usar esse subelemento, especifique-o para o elemento pai Workload em vez de especificar um arquivo ou tabela de carga de trabalho separados. Os exemplos de código a seguir mostram como o uso de um elemento EventString com o arquivo de entrada XML se compara ao uso de um arquivo de carga de trabalho regular com o arquivo de entrada XML:
Exemplos
A. Especifique um arquivo de carga de trabalho separado com o elemento de carga de trabalho.
<DTAInput>
...code removed
<Workload>
<File>MyWorkload.sql</File>
</Workload>
...code removed
</DTAInput>
B. Especifique uma carga de trabalho embutida com o elemento EventString
<DTAInput>
...code removed
<Workload>
<EventString Weight="100">
SELECT * FROM MyTable1
WHERE MyColumn1 > 200
ORDER BY MyColumn1
</EventString>
<EventString Weight="1">
SELECT * FROM MyTable2
WHERE MyColumn2 > 200
ORDER BY MyColumn2
</EventString>
</Workload>
...code removed
</DTAInput>
No exemplo anterior, foram especificados pesos diferentes para cada consulta no elemento EventString: um peso de 100 e um peso de 1. Isso significa que quando o Orientador de Otimização do Mecanismo de Banco de Dados ajusta essas consultas o aplicativo tratará a consulta com um peso de 100 como se houvesse 100 instâncias daquela consulta em comparação a uma instância da consulta com um peso de 1. No exemplo anterior, a primeira consulta é 100 vezes mais importante do que a segunda consulta para propósitos de avaliação do Orientador de Otimização do Mecanismo de Banco de Dados. Observe também que o sinal maior que (>) foi convertido em > porque > é um caractere reservado com significado especial em XML.
Para obter um exemplo de especificação de uma carga de trabalho embutida com o elemento EventString, consulte Amostra do arquivo de entrada XML com carga de trabalho embutida (DTA).
Ignorando constantes em uma carga de trabalho com o elemento IgnoreConstantsInWorkload
Cargas de trabalho podem conter instruções que recorrem a constantes. O Orientador de Otimização do Mecanismo de Banco de Dados pode usar constantes em uma carga de trabalho para fazer recomendações que incluem exibições indexadas com condições de seleção ou funções de partição de intervalo para índices particionados.
Porém, às vezes pode não ser vantajoso para o Orientador de Otimização do Mecanismo de Banco de Dados considerar constantes em uma carga de trabalho. Por exemplo, considere uma carga de trabalho com a seguinte instrução:
UPDATE BankAccountTable
SET AccountBalance = AccountBalance - 1000.00
WHERE CustomerID =
(SELECT CustomerID FROM Customer WHERE CustomerName = 'Alice')
Essa carga de trabalho pode incluir a constante 'Alice' porque a carga de trabalho foi capturada quando Alice fez uma transação. Se o Orientador de Otimização do Mecanismo de Banco de Dados usou essa constante, é possível que ele não produza uma recomendação de ajuste efetiva. Nesse caso, pode fazer sentido especificar que o Orientador de Otimização do Mecanismo de Banco de Dados ignore constantes ao usar essa carga de trabalho para ajustar um banco de dados.
O elemento IgnoreConstantsInWorkload, que reside sob o elemento TuningOptions pode ser especificado no arquivo de entrada XML para forçar o Orientador de Otimização do Mecanismo de Banco de Dados a ignorar todas as constantes em uma carga de trabalho. Quando esse elemento é especificado, exibições indexadas que o Orientador de Otimização do Mecanismo de Banco de Dados possa recomendar não conterão condições de seleção. Além disso, as constantes usadas em funções de partição serão derivadas apenas de dados e não das constantes contidas na carga de trabalho.
Usando um servidor de teste para ajustar uma carga de trabalho para um servidor de produção
O ajuste de uma carga de trabalho grande pode criar sobrecarga significativa no servidor que está sendo ajustado devido às muitas chamadas que o Orientador de Otimização do Mecanismo de Banco de Dados normalmente faz ao otimizador de consulta durante o processo de ajuste. Usando um servidor de teste além de seu servidor de produção elimina esse problema. O Orientador de Otimização do Mecanismo de Banco de Dados dá suporte a esse cenário de forma singular:
Verifique se o usuário que quer executar o ajuste existe tanto no servidor de produção quanto no de teste. Se você for que um membro da função de servidor fixa sysadmin, essa etapa é desnecessária.
Você especifica um servidor de teste para ajustar o arquivo de entrada XML juntamente com o restante dos parâmetros que definem sua sessão de ajuste.
Você usa o utilitário de linha de comando dta para iniciar a sessão de ajuste e começar a análise de carga de trabalho.
Durante essa sessão de ajuste do servidor de teste, o Orientador de Otimização do Mecanismo de Banco de Dados faz ligações mínimas a seu servidor de produção para recuperar informações sobre seu perfil de hardware, metadados de banco de dados e estatísticas para ajudar o otimizador de consulta a otimizar com precisão as consultas no servidor de teste.
Nesse cenário, você, na verdade, ajusta o servidor de teste que duplica o ambiente do servidor de produção. Depois de receber uma recomendação de configuração de design de banco de dados como resultado do ajuste de seu servidor de teste, será possível então implementá-la em seu servidor de produção durante uma janela de manutenção. O uso desse processo minimiza o impacto de desempenho criado pelo Orientador de Otimização do Mecanismo de Banco de Dados. Além disso, esse processo lhe poupa o tempo de copiar dados de seu servidor de produção para seu servidor de teste e lhe poupa a despesa necessária para duplicar hardware de servidor de produção poderoso em seu ambiente de teste.
Para especificar um servidor de teste, use o subelemento TestServer no elemento pai TuningOptions conforme o exemplo a seguir:
Exemplo
<DTAInput>
...code removed
<TuningOptions>
<TestServer>MyTestServer</TestServer>
<FeatureSet>IDX_IV</FeatureSet>
<Partitioning>NONE</Partitioning>
<KeepExisting>NONE</KeepExisting>
</TuningOptions>
...code removed
</DTAInput>
Para obter mais informações sobre como usar esse recurso e outro exemplo de código, consulte Reduzindo a carga de ajuste do servidor de produção.