Configurando o comando BUFFERCOUNT, BLOCKSIZE e MAXTRANSFERSIZE para BACKUP

Eu estou procurando prático de orientação para definir os valores para o BUFFERCOUNT, BLOCKSIZEe MAXTRANSFERSIZEdo BACKUPcomando. Pesquisei um pouco (veja abaixo), fiz alguns testes e tenho plena consciência de que qualquer resposta realmente valiosa começará com "Bem, depende ...". Minhas preocupações com os testes que eu fiz e os testes mostrados em qualquer um dos recursos que encontrei (veja o caminho abaixo) são que os testes são feitos no vácuo, provavelmente em um sistema sem outra carga.

Estou curioso sobre as orientações / melhores práticas adequadas a respeito dessas três opções baseadas em experiências de longo prazo: muitos pontos de dados ao longo de semanas ou meses. E não estou procurando valores específicos, já que isso é principalmente uma função do hardware disponível, mas gostaria de saber:

• Como vários fatores de hardware / carga influenciam o que deve ser feito.
• Existem circunstâncias em que nenhum desses valores deve ser substituído?
• Existem armadilhas para substituir qualquer uma dessas que não são imediatamente óbvias? Utilizando muita memória e / ou E / S de disco? Complicando operações de restauração?
• Se eu tiver um servidor com várias instâncias do SQL Server em execução (uma instância padrão e duas instâncias nomeadas) e se eu executar os backups de todas as três instâncias simultaneamente, isso afeta a maneira como eu defino esses valores além de garantir que o coletivo ( BUFFERCOUNT* MAXTRANSFERSIZE) não excede a RAM disponível? Possível contenção de E / S?
• Nesse mesmo cenário de ter as três instâncias em um servidor e executar novamente os backups em todos os três simultaneamente, como a execução dos backups de vários bancos de dados simultaneamente em cada instância afetaria a configuração desses valores? Ou seja, se cada uma das três instâncias tiver 100 bancos de dados cada, executando 2 ou 3 backups por cada instância simultaneamente, de modo que haja entre 6 e 9 backups sendo executados simultaneamente. (Nesta situação, tenho muitos bancos de dados pequenos a médios, em vez de alguns grandes.)

O que eu reuni até agora:

• BLOCKSIZE:

  • Os tamanhos suportados são 512 bytes, 1024, 2048, 4096, 8192, 16384, 32768 e 65536 (64 KB). ^[1]
  • O padrão é 65536 para dispositivos de fita e 512 caso contrário ^[1]
  • Se você estiver executando um backup que planeja copiar e restaurar de um CD-ROM, especifique BLOCKSIZE = 2048 ^[1]
  • Quando você grava em discos únicos, o padrão 512 é bom; se você usa matrizes RAID ou SAN, deve testar se o padrão ou 65536 é melhor. ^{[13 (página 18)]}

  • Se estiver configurando manualmente, o valor precisará ser> = o Tamanho do bloco usado para criar o (s) arquivo (s) de dados, caso contrário, você receberá o seguinte erro:

    Msg 3272, Nível 16, Estado 0, Linha 3
    O dispositivo 'C: \ Arquivos de Programas \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' possui um tamanho de setor de hardware de 4096, mas o parâmetro tamanho do bloco especifica um valor de substituição incompatível de 512. Emita novamente a instrução usando um tamanho de bloco compatível.

• BUFFERCOUNT:

  • Padrão ^{[2], [8]} :

    SQL Server 2005 e versões posteriores:
    (NumberofBackupDevices * [mistério_multiplicador]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mistério_multiplicador]: Existe alguma inconsistência em relação a esse valor. Eu já vi isso expresso em 3 formas:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    O teste que mostra o multiplicador a ser 3realizado no SQL Server 2005 SP2 ^[9] .

    Meus testes no SQL Server 2008 R2 e 2012 e um comentário do usuário sobre o SQL Server 2014 ^[8] mostram o multiplicador 4. Significado, dado o valor relatado para GetSuggestedIoDepth(diretamente abaixo):

    • GetSuggestedIoDepthé agora 4ou
    • o multiplicador é agora GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthretorna 3para dispositivos DISK ^[9]
  • Nenhum valor máximo definido, mas dado que a memória é necessária = ( BUFFERCOUNT* MAXTRANSFERSIZE), parece que um valor máximo prático seria: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Os valores possíveis são múltiplos de 65536 bytes (64 KB), variando até 4194304 bytes (4 MB). ^[1]
  • Valores padrão: se o dispositivo estiver no modo de leitura (restauração) ou se for um Desktop ou Express Edition, use 64K, caso contrário, use 1 MB. ^[9]
• Geral / Diversos:
  • O tamanho máximo que pode ser usado é o ( para memória física do conjunto de buffers / 16 ). Conforme retornado da chamada da API GlobalMemoryStatusEx (ullTotalPhys). ^[9]
  • O Sinalizador de Rastreio 3213gera parâmetros de configuração de backup / restauração ao executar operações de backup / restauração e 3605despeja a saída no arquivo ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • Você pode usar DISK = N'NUL:'(equivalente DOS / Windows /dev/nullno UNIX) para testar mais facilmente algumas métricas (mas não terá uma boa noção do tempo total do processo, pois está ignorando a E / S de gravação)

Recursos

1. Página MSDN para o comando T-SQL BACKUP
2. KB904804: Você experimenta desempenho lento ao fazer backup do banco de dados no SQL Server 2000
3. Opções para melhorar o desempenho do backup do SQL Server
4. Backup e restauração
5. Otimizando o backup e a restauração do SQL Server
6. Otimizando o desempenho do backup
7. Como aumentar a velocidade de backup completo do banco de dados SQL usando compactação e discos de estado sólido
8. A opção de transferência de dados BufferCount incorreta pode levar à condição de OOM
9. Como funciona: como o SQL Server Backup and Restore seleciona os tamanhos de transferência
10. Como funciona: Exchange Server Buffer do SQL Server (um foco em VDI)
11. Backup do SQL ajustando bancos de dados grandes
12. Memória do SQL Server para buffer de backup
13. Um estudo de caso: backup e restauração rápidos e confiáveis ​​de um VLDB pela rede (arquivo .docx)
14. Quantos dispositivos de backup são recomendados para melhorar o desempenho do backup?

Eu testei com:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

ATUALIZAR

Parece que às vezes esqueço de adicionar algumas das informações que sempre peço que outras pessoas forneçam quando estou respondendo a uma pergunta ;-). Dei algumas informações acima sobre a minha situação atual, mas posso fornecer mais detalhes:

Estou trabalhando para um cliente que fornece um aplicativo SaaS 24/7 / 365.25. Portanto, existe a possibilidade de os usuários acessarem a qualquer momento, mas, realisticamente, os usuários são todos baseados nos EUA (por enquanto) e tendem a trabalhar principalmente horas "padrão": 7h do Pacífico (ou seja, 10h do leste) e 19h do Pacífico (ou seja, 22:00 do leste), mas 7 dias por semana, não apenas de segunda a sexta-feira, embora a carga de fim de semana seja um pouco mais leve.

Eles são configurados de modo que cada cliente tenha seu próprio banco de dados. Como é um setor de nicho, não há dezenas de milhares (ou mais) de clientes em potencial. O número de bancos de dados do cliente varia por instância, com a maior instância mantendo 206 clientes. O maior banco de dados é de aprox. 8 GB, mas apenas cerca de 30 DBs têm mais de 1 GB. Portanto, não estou especificamente tentando maximizar o desempenho de um VLDB.

Quando eu comecei com esse cliente, seus backups estavam sempre COMPLETOS, uma vez por dia, e nenhum backup de LOG. Eles também haviam definido MAXTRANSFERSIZE como 4 MB e BUFFERCOUNT como 50. Substituí essa configuração por uma versão ligeiramente personalizada do script de backup de banco de dados de Ola Hallengren . A parte um pouco personalizada é que ela é executada a partir de uma ferramenta de multiencadeamento (que eu escrevi e esperamos começar a vender em breve) que descobre dinamicamente os bancos de dados à medida que se conecta a cada instância e permite a otimização por instância (portanto, atualmente estou executando o três instâncias simultaneamente, mas os bancos de dados para cada instância sequencialmente, pois eu não tinha certeza das ramificações de executá-los simultaneamente).

A configuração agora é fazer um backup COMPLETO um dia por semana e backups DIFF nos outros dias; Os backups do LOG são feitos a cada 10 minutos. Estou usando os valores padrão para as 3 opções que estou consultando aqui. Mas, sabendo como eles foram definidos, eu queria ter certeza de que não estava desfazendo uma otimização (apenas porque havia algumas falhas importantes no sistema antigo não significa que tudoestava errado). Atualmente, para os 206 bancos de dados, são necessários 62 minutos para backups COMPLETOS (uma vez por semana) e entre 7 e 20 minutos para backups DIFF nos dias restantes (7 no primeiro dia após o COMPLETO e 20 no último dia antes) o próximo CHEIO). E isso é executá-los sequencialmente (thread único). O processo de backup do LOG, no total (todos os bancos de dados em todas as 3 instâncias), leva de 50 a 90 segundos a cada vez (novamente, a cada 10 minutos).

Percebo que posso executar vários arquivos por banco de dados, mas a) não tenho certeza de quanto melhor será o multithreading e o tamanho pequeno e médio dos bancos de dados eb) não quero complicar o processo de restauração ( existem várias razões pelas quais é preferível lidar com um único arquivo).

Também percebo que poderia ativar a compactação (minha consulta de teste a desativou intencionalmente), e eu o recomendei à equipe, mas foi trazido à minha atenção que a compactação interna é meio ruim. Parte do processo antigo era compactar cada arquivo em um RAR, e eu fiz meus próprios testes e constatei que sim, a versão RAR é pelo menos 50% menor que a versão compactada nativamente. Tentei usar a compactação nativa primeiro para acelerar as coisas e, em seguida, RAR os arquivos, mas esses arquivos, embora menores do que aqueles apenas compactados nativamente, ainda eram um pouco maiores que a versão compactada somente para RAR e com diferença suficiente para justificar não usando compactação nativa. O processo para compactar os backups é assíncrono e é executado a cada X minutos. Se encontrar um .bakou.trnarquivo, ele o comprime. Dessa forma, o processo de backup não é mais lento pelo tempo necessário para compactar cada arquivo.

Você abordou um monte de itens na sua pergunta. Obrigado por ser tão completo!

Apenas algumas coisas que noto de imediato:

• Como vários fatores de hardware / carga influenciam o que deve ser feito.

Você está executando uma instância 24x7? Qual é a carga 24 horas por dia? Percebo que você tem a compactação de backup desativada; isso é planejado para o teste ou é desejável, por algum motivo, desativá-lo quando você o coloca em produção? Se você tem toneladas de espaço livre de hardware (CPU / RAM) e a conclusão do backup no menor período de tempo é de suma importância, convém ajustar esses parâmetros para o hardware específico que você tem com esse objetivo em mente. Se você deseja garantir que as cargas de trabalho OLTP sejam atendidas o tempo todo e não deseja que o backup cause impacto, provavelmente será necessário ajustar esses parâmetros de maneira inversa. Você não identificou suas metas de design desde que solicita orientação geral, no entanto, com tanta sabedoria: "depende".

• Existem circunstâncias em que nenhum desses valores deve ser substituído?

Você deseja manter as configurações padrão se estiver preocupado com a capacidade de suporte no futuro depois de deixar de manter a instância e tiver dúvidas sobre as habilidades de sua substituição. Você provavelmente deseja deixar os padrões no lugar, a menos que tenha uma necessidade específica de ajustá-los. Deixe os cães adormecidos mentirem, como eles dizem.

• Existem armadilhas para substituir qualquer uma dessas que não são imediatamente óbvias? Utilizando muita memória e / ou E / S de disco? Complicando operações de restauração?

Como afirmam claramente os documentos que você menciona, aumentar muito esses parâmetros certamente pode ter impactos negativos no tempo de atividade. Como em tudo o que é baseado na produção, você precisa testá-lo completamente antes de implantá-lo e deixar as configurações em paz, a menos que seja absolutamente necessário.

• Se eu tiver um servidor com várias instâncias do SQL Server em execução (uma Instância padrão e duas Instâncias nomeadas) e se eu executar os backups de todas as três instâncias simultaneamente, isso afeta a maneira como eu defino esses valores além de garantir que o coletivo (BUFFERCOUNT * MAXTRANSFERSIZE) não excede a RAM disponível? Possível contenção de E / S?

Você precisará garantir bastante RAM para circunstâncias imprevistas. Eu certamente ficaria preocupado em usar mais de 60% ou 70% da memória RAM disponível para operações de backup, a menos que eu soubesse com 100% de certeza que nada mais aconteceria durante a janela de backup.

Eu escrevi uma postagem no blog com algum código que mostra como eu faço o teste de desempenho de backup no SQLServerScience.com

^{talvez essa não seja a melhor resposta que eu já escrevi, mas, como disse The Great One ™, "você perde 100% das fotos que não tira".}