Início / dba / Perguntas / 125038
Accepted
Victor Barajas
Asked: 2016-01-03 12:11:55 +0800 CST

Quantos dispositivos de backup são recomendados para melhorar o desempenho do backup?

  • 772

Para melhorar o desempenho de nossos backups do SQL Server, fazemos backup em vários arquivos de backup.

  • Na maioria das postagens de blog sobre esse tópico, eles dizem para usar vários arquivos de backup, mas existe um ponto em que você pode ter muitos arquivos que, em vez de melhorar o desempenho, obtém um desempenho pior devido à grande quantidade de threads em espera?
  • Existe alguma recomendação geral baseada, por exemplo, no número de núcleos no servidor? Para ser mais específico, um de nossos servidores mostra BACKUPIOe BACKUPBUFFER, como os 2 principais infratores, aguardam estatísticas.

Estamos fazendo backup de um grande banco de dados (vários TBs) usando 10 arquivos de backup, mas notei que o servidor tem apenas 4 núcleos e 32 GB de RAM. Alterei o número de arquivos de backup para usar 4 arquivos de backup. Verei como será na próxima semana no próximo ciclo de backup, mas, enquanto isso, estava tentando encontrar recomendações sobre quantos arquivos de backup usar, dependendo das especificações do servidor.

sql-server backup

2 respostas

  1. Para melhorar o desempenho de nossos backups do SQL Server, fazemos backup em vários arquivos de backup

    Geralmente não, não. Essa é uma técnica de propósito especial que pode ajudar.

    grande quantidade de threads esperando

    Por que isso causaria uma perda de throughput? Threads são normalmente um amplo recurso. Os problemas surgem em certas configurações em que você queima centenas e milhares de threads.

    com base no [o] número de núcleos no servidor

    Isso faria sentido se a operação de backup fosse vinculada à CPU. Esse pode ser o caso. Enquanto estiver vinculado a E/S, não ajudará a definir o número de núcleos com qualquer configuração.

    um de nossos servidores mostra BACKUPIO e BACKUPBUFFER como estatísticas de espera dos 2 principais infratores

    Isso aponta para um processo de backup vinculado a E/S. De acordo com minha experiência, isso é muito mais comum do que a limitação da CPU.

    um grande banco de dados (vários TBs)

    O tamanho do backup não desempenha um papel nas considerações de taxa de transferência. O throughput é o desempenho por unidade de tempo.

    A mera presença de threads em espera normalmente não afeta outros threads e operações no servidor. Os threads em espera não fazem nada.

    então mudei o número de arquivos de backup para usar 4 arquivos de backup

    Isso foi infundado porque o backup está vinculado ao IO. Segmentar o número de núcleos não é um bom alvo.

    Se você adicionasse 128 núcleos de CPU, seu backup não ficaria um segundo mais rápido.

    Você pode ter aumentado o desempenho, mas apenas acidentalmente.

    A quantidade de arquivos de backup a serem usados ​​é influenciada por muitas coisas. Uma maneira fácil de encontrar um bom número é simplesmente testar valores diferentes, incluindo 1 (o valor mais provável para sistemas comuns).

    • 4
  2. Best Answer

    Vamos tirar suas dúvidas primeiro...

    existe um ponto em que você pode ter muitos arquivos que, em vez de melhorar o desempenho, obtém um desempenho pior devido à grande quantidade de threads em espera?

    O número de encadeamentos de backup depende do número de volumes lógicos usados ​​para os arquivos de banco de dados e do número de dispositivos de backup. O SQL Server oferece suporte a um máximo de 64 dispositivos de backup para uma única operação de backup.

    Então, quando você está distribuindo seus backups, está aumentando a taxa de transferência. Esta é uma boa jogada.

    Existe alguma recomendação geral baseada, por exemplo, no número de núcleos no servidor?

    Um exemplo de arquivos e discos balanceados para um bom desempenho de backup do whitepaper de otimização de backup (cuidado: é um documento de palavras) .

    insira a descrição da imagem aqui

    Coisas a considerar :

    • Ative a inicialização instantânea do arquivo.
    • Use compactação de backup (sql server 2008 R2 e superior possui compactação de backup na edição padrão). A compactação aumentará o uso da CPU, portanto, certifique-se de não haver saturação da CPU.
    • Mude/ajuste sua estratégia de backup. Em vez de fazer backup completo diário de um banco de dados de vários Terabytes, pense em fazer backups diferenciais junto com os logs.
    • Em um ambiente de teste, jogue com BUFFERCOUNT(número total de buffers de E/S) e MAXTRANSFERSIZE(maior unidade de transferência em bytes entre o servidor sql e a mídia de backup) os parâmetros de backup junto com os sinalizadores de rastreamento 3605 e 3213.
    • Consulte minha resposta SQL Backup ajustando bancos de dados grandes

    Aconselhamento amigável

    Percebi que o servidor tem apenas 4 núcleos e 32 GB de RAM.

    Como você está executando um grande banco de dados (vários TBs), 4 núcleos e 32 GB de RAM parece muito baixo. Aumente seu hardware.

    Referir :

    • 4

relate perguntas