Início / dba / Perguntas / 268099
Accepted
blobbles
Asked: 2020-05-29 22:20:20 +0800 CST

Desempenho do SQL Server 2019 pior que 2012... estou perdendo alguma coisa?

  • 772

Temos um servidor SQL Server 2012 que supera em muito um banco de dados SQL Server 2019 (até onde posso ver) na mesma infraestrutura. Estamos hospedando os dois bancos de dados em uma plataforma de nuvem com os mesmos SLAs. Ambos têm 180 GB de RAM e 16 processadores.

No entanto, existem algumas diferenças importantes.

  1. O servidor de banco de dados de 2012 é Enterprise, o de 2019 é Standard. Até onde eu sei, isso não deve fazer diferença
  2. O banco de dados de 2012 foi restaurado para o servidor de 2019 e sua versão foi alterada para 150 (2019)
  3. MAXDOP no servidor de 2012 era 0, servidor de 2019 está definido como 8 conforme recomendado pela Microsoft e outros
  4. Limite de custo para paralelismo = 5 no servidor de 2012, 20 no servidor de 2019

EDIT: Outra grande diferença que acabei de perceber - um é o Windows Server 2008, o outro é o Windows Server 2019. Também pode ser as configurações do lado do servidor ...

O tamanho da unidade de alocação é definido como 64kb para todos os discos SQL, o SQL tem as permissões certas para poder controlar os tamanhos dos arquivos. O servidor está definido para o modo de alto desempenho. Qualquer outra coisa que eu deveria estar mudando o lado do servidor?

Outras configurações do banco de dados não foram alteradas, portanto, as seguintes configurações são padrão em 2019, acredito:

  • Estimativa de cardinalidade herdada = DESATIVADA
  • Sniffing de Parâmetro = ATIVADO
  • Correções do Otimizador de Consulta = DESATIVADO

Principalmente o tipo de consultas que fazemos são consultas grandes e complexas com várias associações realizando atualizações e inserções, com pequenas seleções ocasionais de usuários. Carregamos arquivos grandes no banco de dados e processamos os dados em consultas grandes, geralmente uma de cada vez. Entre essas grandes "cargas" temos usuários fazendo seleções em outras tabelas de banco de dados que não estão sendo carregadas/processadas em preparação para futuras etapas de carregamento/processo. Geralmente estamos obtendo entre 30% e 50% de redução de desempenho no processamento. Achei que isso era por causa da configuração MAXDOP, mas alterá-lo para 0 não fez diferença em uma série de execuções.

Nosso principal sintoma é que estamos obtendo tempos limite de bloqueio quando tentamos nos conectar ao servidor de 2019 enquanto ele está ocupado processando, enquanto o servidor de 2012 ainda atende conexões, apenas muito lentamente. Eu estava pensando em definir a configuração de tempo limite de conexão no servidor para um valor alto, mas suspeito que ainda não obteremos respostas do servidor. É como se estivesse bloqueando todas as novas conexões, mesmo que estivesse um pouco ocupada.

Existem outras coisas que eu deveria tentar? Vale a pena mexer nessas configurações de banco de dados?

Eu poderia mergulhar mais fundo e começar a olhar para DMVs, no entanto, isso parece estar perto de uma atualização de ambiente "like for like" com quedas consideráveis ​​no desempenho. Apenas verificando se não há mais nada que eu deva verificar antes de fazer uma investigação maior.

sql-server performance

4 respostas

  1. Best Answer

    Acredito que você acabou de descobrir por que o processo de atualização recomendado é atualizar seu banco de dados, habilitar o Query Store e testar antes de aumentar o nível de compatibilidade do banco de dados.

    insira a descrição da imagem aqui Altere o Nível de Compatibilidade do Banco de Dados e use o Repositório de Consultas

    Se você tiver muitas regressões de plano, poderá continuar usando o estimador de cardinalidade mais antigo no nível de compatibilidade de banco de dados mais alto com:

    ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
    • 12

  2. Tivemos um problema semelhante ao atualizar do Sql Server 2012.

    Nossos problemas foram devido às alterações do Estimador de cardinalidade introduzidas no SQL Server 2014

    Tente alterar a configuração Legacy Cardinality para ON em um ambiente de teste e compare o desempenho das cargas de trabalho

    https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/

    • 4

  3. Tivemos um problema semelhante ao atualizar do SQL Server 2008 R2 para o SQL Server 2019 (nível de compatibilidade 150).

    Alguns de nossos trabalhos de atualização noturna de repente levaram de 6 a 7 vezes mais tempo para serem executados (de 4 minutos a 39 minutos e de 1 hora a 6 horas).

    Definir a configuração Legacy Cardinality para ONnos trouxe de volta à nossa velocidade de atualização habitual.

    Foi o que fizemos (fonte: https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinality-estimation/ ):

    USE [YourDB]
GO
ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
    • 3

  4. Outra possibilidade é habilitar o sinalizador de rastreamento global 9481 e toda a carga de trabalho em sua instância usará CE legado

    • 0

relate perguntas