Considerações para usar servidores de teste

Usar um servidor de teste para ajustar um banco de dados em um servidor de produção é um benefício importante do Orientador de Otimização do Mecanismo de Banco de Dados. Usando esse recurso, você pode descarregar a sobrecarga de ajuste para um servidor de teste sem copiar os dados reais para o servidor de teste do servidor de produção.

Para usar esse recurso com êxito, examine as considerações listadas nas seções a seguir.

Configurando o ambiente do servidor de teste/servidor de produção

• O usuário que deseja usar um servidor de teste para ajustar um banco de dados em um servidor de produção deve existir em ambos os servidores ou esse cenário não funcionará.

• O procedimento armazenado estendido, xp_msver, deve ser habilitado para usar o cenário de servidor de teste/servidor de produção. O Orientador de Otimização do Mecanismo de Banco de Dados usa esse procedimento armazenado estendido para buscar o número de processadores e a memória disponível do servidor de produção a ser usada durante o ajuste do servidor de teste. Se xp_msver não estiver habilitado, o Orientador de Otimização do Mecanismo de Banco de Dados assumirá as características de hardware do computador em que o Orientador de Otimização do Mecanismo de Banco de Dados está em execução. Se as características de hardware do computador em que o Orientador de Otimização do Mecanismo de Banco de Dados estiver em execução não estiverem disponíveis, um processador e 1024 megabytes (MBs) de memória serão assumidos. Esse procedimento armazenado estendido é ativado por padrão quando você instala o SQL Server. Para obter mais informações, consulte Configuração da Área de Superfície e xp_msver (Transact-SQL).

• O Orientador de Otimização do Mecanismo de Banco de Dados espera que as edições do SQL Server sejam as mesmas no servidor de teste e no servidor de produção. Se houver duas edições diferentes, a edição no servidor de teste terá precedência. Por exemplo, se o servidor de teste estiver executando o SQL Server Standard, o Orientador de Otimização do Mecanismo de Banco de Dados não incluirá exibições indexadas, particionamento e operações online em suas recomendações, mesmo que o servidor de produção esteja executando o SQL Server Enterprise.

Sobre o comportamento do servidor de teste/servidor de produção

• O Orientador de Otimização do Mecanismo de Banco de Dados leva em conta as diferenças de hardware entre a produção e o servidor de teste ao criar recomendações. A recomendação é a mesma como se o ajuste tivesse sido feito apenas no servidor de produção.

• O Orientador de Otimização do Mecanismo de Banco de Dados pode impor alguma carga ao servidor de produção para coletar metadados, bem como a criação de estatísticas necessárias para ajuste.

• O Orientador de Otimização do Mecanismo de Banco de Dados não copia dados reais do servidor de produção para o servidor de teste. Ele copia apenas os metadados dos bancos de dados e as estatísticas necessárias.

• Todas as informações de sessão são armazenadas no msdb no servidor de produção. Isso permite que você explore qualquer servidor de teste disponível para ajuste e as informações sobre todas as sessões estão disponíveis em um só lugar (o servidor de produção).

Problemas relacionados ao banco de dados do Shell

• Após o ajuste, o Orientador de Otimização do Mecanismo de Banco de Dados deve remover todos os metadados criados no servidor de teste durante o processo de ajuste. Isso inclui o banco de dados do shell. Se você estiver executando uma série de sessões de ajuste com os mesmos servidores de produção e teste, convém manter esse banco de dados shell para economizar tempo. No arquivo de entrada XML, especifique o subelemento RetainShellDB com os outros subelementos sob o elemento pai TuningOptions. Usar essas opções faz com que o Orientador de Otimização do Mecanismo de Banco de Dados mantenha o banco de dados do shell. Para obter mais informações, consulte Referência de arquivo de entrada XML (Orientador de Otimização do Mecanismo de Banco de Dados).

• Os bancos de dados shell podem ser deixados para trás no servidor de teste após uma sessão de ajuste bem-sucedida do servidor de teste/servidor de produção, mesmo que você não tenha especificado o subelemento RetainShellDB . Esses bancos de dados de shell indesejados podem interferir nas sessões de ajuste subsequentes e devem ser descartados antes de executar outra sessão de ajuste do servidor de teste/servidor de produção. Além disso, se uma sessão de ajuste for encerrada inesperadamente, os bancos de dados do shell no servidor de teste e os objetos dentro desses bancos de dados poderão ser deixados para trás no servidor de teste. Você também deve excluir esses bancos de dados e objetos antes de iniciar uma nova sessão de ajuste de servidor de teste ou servidor de produção.

Problemas relacionados ao processo de ajuste

• O usuário deve verificar o log de ajuste em busca de erros de ajuste resultantes de diferenças entre os servidores de produção e de teste e se há erros resultantes da cópia de metadados da produção para o servidor de teste. Por exemplo, um logon de usuário pode não existir no servidor de teste. Se um logon de usuário não existir no servidor de teste, os eventos na carga de trabalho emitidos por esse logon de usuário podem não ser configuráveis. Use a GUI do Orientador de Otimização do Mecanismo de Banco de Dados para exibir o log de otimização. Para obter mais informações, consulte Exibir e trabalhar com a saída do Orientador de Otimização do Mecanismo de Banco de Dados

• Se o Orientador de Otimização do Mecanismo de Banco de Dados não puder ajustar muitos eventos porque os objetos estão ausentes no banco de dados do shell que o Orientador de Otimização do Mecanismo de Banco de Dados cria no servidor de teste, o usuário deverá verificar o log de ajuste. Os eventos que não podem ser ajustados são listados no log. Para ajustar com êxito o banco de dados no servidor de teste, o usuário deve criar os objetos ausentes no banco de dados do shell e iniciar uma nova sessão de ajuste.

• Se um banco de dados com o mesmo nome já existir no servidor de teste, o Orientador de Otimização do Mecanismo de Banco de Dados não copiará metadados, mas continuará ajustando e coletará estatísticas conforme necessário. Isso será útil se o usuário já tiver criado um banco de dados no servidor de teste e copiado os metadados apropriados antes de invocar o Orientador de Otimização do Mecanismo de Banco de Dados.

• Se a opção DATE_CORRELATION_OPTIMIZATION estiver ativada para um banco de dados no servidor de produção, os metadados e os dados associados a essa opção não serão completamente scriptados durante o ajuste do servidor de teste. Quando o ajuste é executado para um cenário de servidor de teste/servidor de produção, os seguintes problemas podem ser aplicados:

  • Os usuários podem ter planos de consulta diferentes nos servidores para consultas que usam a opção DATE_CORRELATION_OPTIMIZATION.

  • O Orientador de Otimização do Mecanismo de Banco de Dados pode sugerir a remoção de exibições indexadas que impõem a opção DATE_CORRELATION_OPTIMIZATION no script de recomendação.

  Portanto, talvez você queira ignorar as recomendações que o Orientador de Otimização do Mecanismo de Banco de Dados faz sobre as exibições indexadas que contêm estatísticas de correlação porque o Orientador de Otimização do Mecanismo de Banco de Dados conhece seus custos, mas não seus benefícios. O Orientador de Otimização do Mecanismo de Banco de Dados pode não recomendar a seleção de certos índices, como índices agrupados em colunas datetime, o que pode ser benéfico quando DATE_CORRELATION_OPTIMIZATION estiver habilitado.

  Para determinar se uma exibição é baseada em estatísticas de correlação, selecione a coluna is_date_correlation_view da exibição do catálogo sys.views .