O que é hot spotting no contexto da adição de arquivos ao tempdb?

Estou tentando descobrir se é possível adicionar arquivos tempdb a um SQL Server sem precisar reiniciar o serviço do SQL Server. Eu vi essa resposta aqui em Administradores de banco de dados:

• Adicionar arquivos requer reinicialização

E uma resposta afirma:

ADICIONAR - sem interrupção necessária. Embora, como Sean da Microsoft apontou, o SQL prefira usar os arquivos mais baixos. Se você estiver passando de 1 arquivo de dados e adicionando mais, o SQL usará os novos por um tempo, mas seu desempenho não será pior do que ter apenas um arquivo. No entanto, se você já tem mais de 2 anos e adiciona mais um, ele hotspot no novo e diminuirá o desempenho.

No entanto, um comentário adverte o seguinte:

Eu colocaria um adendo na parte "Adicionar": "Adicionar: Não, mas você provavelmente ficará desequilibrado, de modo que estará concentrado em pontos que podem piorar as coisas".

Eu tenho as seguintes perguntas sobre esse comentário, mas fui instruído a fazer essas perguntas em uma nova pergunta minha (esta) em vez de perguntar ao comentarista via comentário nas respostas dessa pergunta.

Especificamente:

1. O que é hot spotting? (Recebi algumas informações pelo Google, mas não detalhadamente o que acontece com o hotspotting no tempdb após adicionar arquivos)
2. E o hot spotting torna as coisas muito piores no tempdb?
3. Que coisas específicas no banco de dados ficariam muito piores?

1. O que é hot spotting?

   "Hot spotting" nesse contexto significa que, embora o tempdb tenha vários arquivos, todo o trabalho de E / S está sendo realizado em um único arquivo. Se o tempdb estiver ocupado o suficiente para justificar a adição de arquivos, o desequilíbrio que leva ao hot spot (devido ao preenchimento proporcional ) terá vida curta, então acho que os avisos podem ser um pouco como Chicken Little. Na minha experiência, de qualquer maneira.

2. E o hot spotting torna as coisas muito piores no tempdb?

   Eu acho que é considerado pior no tempdb porque é necessário um pouco da atividade de gravação na maioria das cargas de trabalho. Você certamente pode sofrer problemas semelhantes nos bancos de dados de usuários, mas como já está tentando resolver um problema no tempdb ...

3. Que coisas específicas no banco de dados ficariam muito piores?

   Escreva vezes, principalmente. Imagine todos tentando usar o mesmo caixa eletrônico, mesmo quando houver outros 7 caixas eletrônicos por perto. Apenas muito pode ser escrito a qualquer momento; tudo o resto tem que esperar. Com mais arquivos (e núcleos suficientes para agendar o trabalho), a E / S pode ser distribuída de maneira mais uniforme.

   Apenas certifique:

   • você tem um número par de arquivos
   • todos os arquivos têm o mesmo tamanho
   • todos os arquivos têm as mesmas configurações de crescimento automático
   • o número de arquivos é de alguma forma impulsionado pelo número de núcleos
   • dependendo da versão (ativada por padrão nas versões mais modernas do SQL Server ), você está usando sinalizadores de rastreamento 1117 (aumente todos os arquivos de dados de uma vez) e 1118 (não use extensões de alocação mistas).

1. O que é hot spotting?

Aaron está correto e não vou repetir o que ele disse acima, no entanto, não se trata apenas de E / S de disco. A parte principal com a qual a maioria das pessoas tem problemas no TempDB é devido à contenção em determinadas estruturas de rastreamento.

Como ter vários arquivos tempdb permite que os algoritmos de preenchimento proporcional e round robin sejam efetivamente "justos" nas alocações, a adição de um novo arquivo sem alocações pode desencadear um pouco isso. Eu discordo que é um aviso "galinha pequena" (consulte as atualizações do produto abaixo) se você começar a ver as PAGELATCH_*esperas no novo arquivo e não em muitos ou nenhum em outros arquivos. Isso geralmente acontece em sistemas com alta atividade TempDB e já com mais de um único arquivo.

Observe que existem opções no SQL Server 2019 para alterar algumas das tabelas subjacentes do sistema para tabelas na memória, o que pode melhorar, pois os objetos na memória são alocados de maneira diferente das tabelas armazenadas em disco. As tabelas baseadas em disco são as tabelas tradicionais com as quais todos trabalhamos ao longo dos anos. O SQL Server 2014 introduziu tabelas com otimização de memória . O SQL Server 2019 pode manipular alguns metadados de alocação em tabelas com otimização de memória.

Outra alteração foi feita no SQL Server 2019 para ajudar nas alterações simultâneas do PFS, que geralmente é o que a disputa pela estrutura na memória na alocação está PAGELATCH_*aguardando.

2. E o hot spotting torna as coisas muito piores no tempdb?

Nada IMHO. Sim, o TempDB possui mais itens que podem causar gravações nele sem serem usados ​​diretamente, o que dificulta alguns itens. No entanto, um banco de dados de usuários muito ocupado em termos de taxa de alteração de dados também é ruim. Não se limita apenas ao TempDB.

3. Que coisas específicas no banco de dados ficariam muito piores?

Eu realmente gosto da analogia de Aaron! Essa é a essência do que está acontecendo. O que realmente piora é a alocação e rastreamento de espaço para objetos no banco de dados. Se o banco de dados do usuário for principalmente estático (baixa taxa de alteração) ou o TempDB não estiver sendo realmente usado, você não notará nada. Se, no entanto, for um servidor bastante ocupado, você poderá iniciar ou agravar as esperas de pagelatch, o que pode levar ao bloqueio de comboios.

Aaron já apontou que, na versão mais antiga, existem sinalizadores de rastreamento para garantir que extensões uniformes sejam usadas e que todos os arquivos em um grupo de arquivos cresçam juntos (Aaron aponta 1117 e 1118, que são NOPs em 2016+). A outra coisa que eu gostaria de salientar novamente é que isso não é apenas para o TempDB, mas para qualquer banco de dados, e o layout físico deve ser pensado dependendo das necessidades.

Isso não é apenas para problemas de hotspotting, mas é aplicável a outras partes do sistema, como backup / restauração, gerenciamento de arquivos, fragmentação de metadados do sistema de arquivos, etc., que podem ser ajudados por vários arquivos.

Você pode ver a contenção da estrutura de alocação procurando uma waitresourceem uma página do PFS (que é a página 1 e, em seguida, a cada 8088 páginas). Se você vir tudo no mesmo arquivo (2: arquivo: página), saberá que isso está ocorrendo.