Considerações para usar servidores de teste

Aplica-se a: SQL Server

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

Para usar esse recurso com sucesso, verifique as considerações listadas nas seções seguintes.

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

• O usuário que deseje usar um servidor de teste para ajustar um banco de dados em um servidor de produção deve existir em ambos os servidores ou este 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 efetuar fetch do número de processadores e da memória disponível do servidor de produção a serem usados durante o ajuste do servidor de teste. Se o xp_msver não estiver disponível, o Orientador de Otimização do Mecanismo de Banco de Dados assumirá as características de hardware do computador no qual o Orientador de Otimização do Mecanismo de Banco de Dados está sendo executado. Se as características de hardware do computador onde o Orientador de Otimização do Mecanismo de Banco de Dados está sendo executado não estiverem disponíveis, supõe-se um processador e 1024 megabytes (MBs) de memória. Esse procedimento armazenado estendido é ativado por padrão quando você instala o SQL Server. Para obter mais informações, veja 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 iguais 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, particionamentos 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 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 o servidor de 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 no servidor de produção para reunir metadados, assim como para a criação de estatísticas necessárias para o 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. Apenas copia os metadados dos bancos de dados e as estatísticas necessárias.

• Todas as informações da sessão são armazenadas no msdb do servidor de produção. Isso permite explorar qualquer servidor de teste disponível para o 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 shell

• Depois de ajustar, o Orientador de Otimização do Mecanismo de Banco de Dados deverá remover quaisquer metadados que criou no servidor de teste durante o processo de ajuste. Isso inclui o banco de dados shell. Se você estiver executando uma série de sessões de ajuste com os mesmos servidores de produção e de teste, poderá desejar reter esse banco de dados shell para economizar tempo. No arquivo de entrada XML, especifique o subelemento RetainShellDB com os outros subelementos no elemento pai TuningOptions . Usar essas opções faz com que o Orientador de Otimização do Mecanismo de Banco de Dados retenha o banco de dados shell. Para obter mais informações, veja Referência do Arquivo de Entrada XML (Orientador de Otimização do Mecanismo de Banco de Dados).

• Os bancos de dados shell poderão ser deixados no servidor de teste após uma sessão bem-sucedida de ajuste do servidor de teste/servidor de produção mesmo que você não tenha especificado o subelemento RetainShellDB . Esses bancos de dados de shell não desejados podem interferir com sessões de ajuste subsequentes e podem ser cancelados 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 fechar inesperadamente, os bancos de dados de shell poderão ser deixados no servidor de teste e os objetos dentro desses bancos de dados deixados no servidor de teste. Você também deverá excluir esses bancos de dados e objetos antes de iniciar uma nova sessão de ajuste do servidor de teste/servidor de produção.

Problemas relacionados ao processo de ajuste

• O usuário deve verificar o log de ajuste para ajustar erros resultantes de diferenças entre os servidores de produção e de teste, e para os erros resultantes da cópia de metadados do servidor de produção para o 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, esses eventos na carga de trabalho emitidos por esse logon de usuário poderão não ser ajustáveis. Use a GUI do Orientador de Otimização do Mecanismo de Banco de Dados para exibir o log de ajuste. Para obter mais informações, veja 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 shell que o Orientador de Otimização do Mecanismo de Banco de Dados criou no servidor de teste, o usuário deve verificar o log de ajuste. Os eventos que não podem ser ajustados são listados no log. Para ajustar o banco de dados com êxito no servidor de teste, o usuário deve criar os objetos ausentes no banco de dados shell e então 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á os metadados, mas continuará o ajuste e reunirá as estatísticas se for necessário. Isso é útil se o usuário já criou um banco de dados no servidor de teste e copiou os metadados adequados antes de invocar o Orientador de Otimização do Mecanismo de Banco de Dados.

• Se a opção DATE_CORRELATION_OPTIMIZATION for ativada para um banco de dados no servidor de produção, os metadados e os dados associados com essa opção não serão totalmente incluídos no script durante o ajuste do servidor de teste. Quando o ajuste é executado para um cenário de servidor de teste/servidor de produção, os problemas seguintes podem ser aplicáveis:

  • 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 poderá sugerir a remoção das exibições indexadas que impõem a opção DATE_CORRELATION_OPTIMIZATION no script de recomendação.

  Por isso, você pode querer ignorar as recomendações que o Orientador de Otimização do Mecanismo de Banco de Dados fizer 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 os seus custos mas não os seus benefícios. O Orientador de Otimização do Mecanismo de Banco de Dados pode não recomendar a seleção de alguns índices, como índices clusterizados em colunas datetime, que podem ser benéficos quando DATE_CORRELATION_OPTIMIZATION está habilitado.

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