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

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.

sql-server backup best-practices maintenance Solomon Rutzky
fonte

Apenas curioso, você está tentando resolver um problema de backup lento? Normalmente, os padrões funcionam bem na maioria dos ambientes. Além disso, a opção de energia está definida como alto desempenho - já que o backup usa ciclos da CPU.

Kin Shah

@ Kin Não, os backups não são especificamente lentos. Mas, se fazer uma pequena alteração os tornasse / poderia torná-los 20% (ou mais) mais rápidos, eu certamente aceitaria. Para 206 bancos de dados, leva cerca de 62 minutos para backups COMPLETOS (uma vez por semana) e entre 7 e 20 minutos para backups DIFF nos dias restantes. E isso é executá-los sequencialmente (thread único). Quando comecei com este cliente, a configuração anterior era usar 4 MB para MaxTransfer e 50 para BufferCount. No momento, estou apenas usando os padrões, tão inseguro se desfiz um ganho de desempenho, que queria aprender mais antes de fazer alterações.

Solomon Rutzky

@srutzky Apenas um ponto rápido do seu último comentário, eu economizei um tempo considerável dividindo meus backups em vários arquivos no mesmo volume. Eu só queria compartilhar isso com você para o caso de não ter sido algo que você tentou ainda. Se os seus 206 DBs executam um backup em paralelo em vários DBs, talvez você não tenha os benefícios de multiencadeamento.

Ali Razeghi

@MaxVernon "Os backups da interface de dispositivo virtual (VDI) permitem que soluções de backup de terceiros se integrem ao SQL Server", retiradas do Recurso 10 na minha pergunta :). Eu não estava querendo passar por isso muito esforço ;-)

Solomon Rutzky

@srutzky, caso você queira se divertir: leia Backups do MSSQL - verifique o tamanho máximo de transferência do HBA - o cara é brilhante e realmente completo em seus testes. E algo que provavelmente corresponde aos seus testes: o ajuste automatizado de backup do SirSQL .

Marian

Configurando o comando BUFFERCOUNT, BLOCKSIZE e MAXTRANSFERSIZE para BACKUP

Respostas: