Rastrear sinalizador 4199 - ativar globalmente?

Isso pode estar na categoria de opinião, mas estou curioso para saber se as pessoas estão usando o sinalizador de rastreamento 4199 como parâmetro de inicialização do SQL Server. Para aqueles que o usaram, sob quais circunstâncias você experimentou regressão de consulta?

Certamente parece ser um benefício potencial de desempenho em geral, estou pensando em habilitá-lo globalmente em nosso ambiente de não produção e deixá-lo descansar por alguns meses para descobrir quaisquer problemas.

As correções no 4199 foram lançadas no otimizador por padrão em 2014 (ou 2016)? Embora eu entenda o motivo de não introduzir alterações inesperadas no plano, parece estranho manter todas essas correções ocultas entre as versões.

Estamos usando 2008, 2008R2 e principalmente 2012.

Pessoalmente, sempre que construo um novo servidor para um novo projeto, sempre ativei o TF4199 globalmente. O mesmo se aplica quando atualizo instâncias existentes para versões mais recentes.

O TF permite novas correções que afetariam o comportamento do aplicativo, mas para novos projetos o risco de regressão não é um problema. Para instâncias atualizadas a partir de versões anteriores, as diferenças entre a versão antiga e a nova são uma preocupação por si só, e é necessário ter que lidar com a regressão planejada de qualquer maneira, portanto, prefiro lutar com o TF4199 ativado.

No que diz respeito aos bancos de dados existentes, existe apenas uma maneira de saber: testá-lo. Você pode capturar uma carga de trabalho na configuração existente e reproduzi-la após ativar o sinalizador. Os Utilitários RML podem ajudá-lo a automatizar o processo, conforme descrito nesta resposta .

Obviamente, o sinalizador afeta toda a instância, então você terá que testar todos os bancos de dados que estão lá.

Minha pesquisa no tópico me trouxe aqui, então eu gostaria de compartilhar minha experiência recente no tópico.

Eu estava executando o SQL 2014, então achei que estaria seguro de ter que me preocupar com o 4199 por um tempo ... mas isso não era verdade ...

Como diagnosticar se você precisar de 4199

Se sua consulta parecer mal executada , principalmente quando você acha que não deveria, tente adicionar o seguinte ao final dela para ver se resolve todos os seus problemas, pois você pode precisar do 4199 ("Ativar todas as correções do Query Optimizer". )

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

Na minha situação, eu tinha uma cláusula do top 10 que explodiu uma consulta que correu bem sem ela, que foi o que me fez pensar que algo suspeito estava acontecendo e que o 4199 poderia ajudar.

Sobre 4199

Qualquer correção de bug / desempenho do SQL Server Query Optimizer criada após o lançamento da nova versão principal fica oculta e bloqueada. Isso pode prejudicar algum outro programa teoricamente perfeitamente otimizado. Portanto, instale as atualizações como desejar, as alterações reais do otimizador de consulta não são ativadas por padrão. Portanto, uma vez que uma única correção ou aprimoramento tenha sido feita, o 4199 se tornará uma necessidade, se você quiser tirar vantagem disso. Como muitas correções aparecem, você acaba ativando isso quando uma delas afeta você. Essas correções geralmente estão vinculadas a seus próprios sinalizadores de rastreamento, mas 4199 é usado como o mestre "Ative todas as correções".

Se você souber de quais correções você precisa, poderá habilitá-las em pedaços, em vez de usar 4199. Se desejar habilitar todas as correções, use 4199.

Ok, então você quer 4199 globalmente ...

Basta criar um trabalho do agente SQL que é executado todas as manhãs com a seguinte linha para ativar o sinalizador de rastreamento globalmente. Isso garante que, se alguém os desligou ou etc, eles serão novamente ativados. Esta etapa do trabalho possui um sql bastante simples:

DBCC TRACEON (4199, -1);

Onde -1 especifica a parte Global no DBCC TRACEON. Para mais informações, consulte:

https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396

"Recompilar" planos de consulta

Na minha tentativa mais recente, tive que ativar o 4199 globalmente e também remover os planos de consulta em cache existentes :

sp_recompile 'dbo.SomeTable'

https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396

Onde o procedimento de recompilação armazenado encontra quaisquer planos de consulta relacionados ao objeto de banco de dados (como uma tabela) e exclui esses planos de consulta, exigindo a próxima tentativa de executar uma consulta semelhante para compilá-los.

Portanto, no meu caso, o 4199 impediu a criação de planos de consulta incorretos, mas também tive que remover aqueles que ainda estavam em cache via sp_recompile. Escolha qualquer tabela da consulta conhecida afetada e convém tentar novamente, supondo que você tenha ativado o 4199 globalmente e limpo o plano de consulta em cache ofensivo.

Em conclusão em 4199

À medida que você utiliza índices, uma otimização inteligente do plano de consultas se torna importante para realmente usá-los de maneira inteligente e, assumindo que, com o tempo, alguma correção no processo de otimização de consultas será lançada, você geralmente está em água potável para executar apenas com o 4199 ativado globalmente, desde que você perceba que alguma nova correção pode não funcionar tão bem com um banco de dados altamente otimizado que foi tão otimizado no ambiente anterior antes da referida correção. Mas o que o 4199 faz? Apenas permite todas as correções.

Queria compartilhar minha experiência com o sinalizador de rastreamento 4199.

Acabei de diagnosticar um problema de desempenho em um sistema de cliente executando o SQL Server 2012 SP3. O cliente estava movendo um banco de dados de relatórios do servidor OLTP de produção para um novo servidor. O objetivo do cliente era remover a competição por recursos com as consultas OLTP. Infelizmente, o cliente disse que o novo servidor de relatórios estava muito lento.

Uma consulta de amostra executada no sistema OLTP foi concluída em 1,6 segundos. O plano de consulta fez uma pesquisa de índice em uma tabela de ~ 200 milhões de linhas que fazia parte de uma exibição.

No novo servidor, a mesma consulta foi concluída em 10 minutos e 44 segundos. Ele executou uma verificação de índice na mesma tabela de ~ 200 milhões de linhas.

Os dados do servidor de relatório eram uma cópia dos dados OLTP, portanto, não parecia haver diferença nos dados.

Fiquei perplexo até lembrar que nosso software (que executa o sistema OLTP) ativou alguns sinalizadores de rastreamento na inicialização. Lembrei-me de um deles, 4199, que era uma correção do otimizador de consultas.

Testei a ativação do sinalizador de rastreamento 4199 no novo servidor de relatórios do cliente e a consulta de relatórios foi concluída em 0,6 segundos. (Uau!) Desativei o sinalizador de rastreamento e a consulta voltou a ser concluída em 10 minutos e 44 segundos. Ativado o sinalizador: volta para 0,6 segundos. Aparentemente, ativar o sinalizador de rastreamento permitiu que o otimizador usasse uma pesquisa de índice na exibição na tabela de 200 milhões de linhas.

Nesse caso, as otimizações de consulta ativadas pelo sinalizador de rastreamento 4199 fizeram uma enorme diferença. Suas experiências podem variar. No entanto, com base nessa experiência, definitivamente vale a pena me permitir.