Faça backup do SQL Server 43% -67% mais rápido gravando em vários arquivos.

Faça backup do SQL Server 43% -67% mais rápido gravando em vários arquivos.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Mesmo se você não estiver gravando em unidades físicas diferentes, você pode obter backups mais rápidos com o Microsoft SQL Server ao fazer backup de vários arquivos. Seus números exatos vão variar de acordo com seu servidor e sua total incapacidade de esfregar dois gravetos para fazer fogo, mas vamos ver como eu faço.

Este é o hardware que estou usando:

O i3en.metal tem 8 SSDs de 7,5 TB NVMe. O banco de dados Stack Overflow vem em 4 arquivos de dados e 1 arquivo de log, então estou colocando cada um dos arquivos de dados em um SSD NVMe separado. Isso significa que o banco de dados desta postagem provavelmente não está configurado exatamente como o seu, mas os resultados ainda são relevantes. Eu vi ganhos de desempenho semelhantes para bancos de dados maiores que têm apenas um arquivo de dados neles.

Durante os testes, eu uso entre 1 e 4 arquivos de backup, e em cada teste, eu explico se todos os arquivos de backup estão na mesma unidade ou em uma diferente – mas em todos os casos, eles estão em unidades diferentes da dados e arquivos de log.

Cada uma das unidades NVMe é bastante rápida por si só:

CrystalDiskMark

Eu queria usar esse hardware monstruosamente grande (especialmente em relação ao tamanho do banco de dados) para ilustrar que não estamos falando sobre limitações de hardware aqui. Mesmo se você estiver trabalhando no big metal, vários arquivos de backup podem ajudar. Além disso, todos esses testes usam compactação de backup ativada e eu queria remover qualquer indício de gargalo de CPU.

Você, caro leitor, vai fazer todos os tipos de perguntas do tipo “mas e quanto a”. Minha função aqui não é fazer seu próprio teste de backup para você: minha função é inspirar você a fazer seu próprio teste em seu próprio ambiente para que você possa encontrar as respostas certas para suas próprias perguntas.

Rodada de teste 1:
Backup de vários arquivos em um volume

Neste teste, os arquivos de backup estavam em um dos SSDs NVMe locais, mas não no mesmo volume em que residiam os arquivos de log e dados do banco de dados.

  • 1 arquivo de backup: 9,1 minutos
  • 2 arquivos de backup: 7,9 minutos (13% mais rápido)
  • 4 arquivos de backup: 5,1 minutos (43% mais rápido)
  • 8 arquivos de backup: 6,2 minutos (32% mais rápido)

Isso não pretende ser um tipo de postagem definitiva, “Sempre use 4 arquivos de backup”, mas apenas um ponto de partida para saber quanto mais rápido seus backups podem ser com essa mudança fácil. Tal como acontece com todas as métricas deste post, a ideia é fazer com que você comece a testar seus backups para obter ganhos rápidos em grandes servidores.

Rodada de teste 2:
Backup para arquivos em volumes diferentes

Nesta rodada, cada arquivo de backup estava em seu próprio SSD NVMe local – até chegarmos a 8 arquivos, já que só tenho 4 drives NVMe extras no i3en.metal:

  • 1 arquivo de backup: 9,1 minutos
  • 2 arquivos, 2 volumes: 6,9 minutos (24% mais rápido)
  • 4 arquivos, 4 volumes: 4,3 minutos (53% mais rápido)
  • 8 arquivos, 4 volumes: 3,0 minutos (67% mais rápido)

Distribuir a carga por diferentes volumes de backup me deu o dobro das melhorias de velocidade que obtive ao gravar em um único volume. Neste exemplo impraticável, estou usando NVMe local e provavelmente o seu servidor não terá isso. No entanto, você pode obter resultados semelhantes gravando seus arquivos de backup em diferentes destinos de armazenamento que têm sua própria taxa de transferência individual que não é regulada coletivamente.

Leia Também  [Video] Mês de treinamento gratuito do DBA: configurando alertas e scripts do Ola
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Na época das pradarias, quando sua avó fazia backup de seu SQL Server, ela hesitava em escrever seus backups pela rede porque sua rede consistia em duas latas conectadas por uma corda. Hoje, graças ao simples ec2instances.info, você pode ver a largura de banda da rede disponível para o seu tipo de instância, e não é uma string:

Latas legais

É por isso que adoro a série i3: toneladas de estado sólido local, além de ótimo rendimento de rede. A largura de banda da rede por si só não é suficiente, é claro: você também precisa provisionar destinos de armazenamento rápido no outro lado se precisar fazer backup de um backup de vários terabytes. Algumas lojas usam servidores i3en como servidores de arquivos de área de teste – colocando seus backups lá para que eles sejam escritos rapidamente e, em seguida, migrando os backups para um armazenamento mais econômico e redundante a longo prazo. (Existem tipos de instância mais econômicos se suas necessidades de backup forem menores, é claro.)

Rodada de teste 3:
Fazendo backup para NUL:

Ao fazer o teste de velocidade do backup, você pode fazer o backup em DISK = ‘NUL:’ e o SQL Server não grava o arquivo de backup no disco – ele apenas descarta os dados. Isso ajuda a medir a rapidez com que os processos de backup do SQL Server podem ler os dados do disco e compactá-los neste servidor específico.

  • 1 arquivo DRAW: 9,4 minutos
  • 2 arquivos NUL: 6,8 minutos (28% mais rápido)
  • 4 arquivos NUL: 4,3 minutos (54% mais rápido)
  • 8 arquivos NUL: 2,9 minutos (70% mais rápido)

Os números aqui são úteis em comparação com os números do teste 2: ao gravar em volumes de backup muito rápidos, você pode realmente aproximar-se da velocidade de simplesmente descartar os dados! No exemplo de 8 arquivos, se eu simplesmente descartar os dados fazendo backup em NUL, concluí em 2,9 minutos. Na verdade, gravar os dados em SSDs NVMe locais me levou até lá em 3,0 minutos. Eu vou levar.

Leia Também  O número RÁPIDO RÁPIDO Dica de consulta - Uma foto do SQLEspresso

Este é o teste de desempenho,
não conselhos de configuração.

Quando seus bancos de dados têm apenas 50-250 GB e sua empresa está ativa apenas das 9h às 17h, esse tipo de coisa não importa muito. À medida que seus bancos de dados crescem e sua empresa exige tempo de atividade constante com curtos tempos de recuperação, essas coisas são muito importantes. É incrível que, com apenas um pouco de esforço, você possa se aprofundar e começar a otimizar seus backups para uma recuperação mais rápida e menos impacto para os usuários finais.

Para iniciar seu próprio projeto de ajuste de backup, verifique os scripts de ajuste de backup automatizado de Nic Cain. Ele automatiza o processo de execução de dezenas de backups com configurações diferentes – muito mais do que apenas contagem de arquivos – a fim de encontrar a combinação de parâmetros que funciona melhor de acordo com o conteúdo de seu banco de dados, onde seus dados e arquivos de log estão e onde você deseja seus backups para ser escrito.

Em lojas com metas ambiciosas de RPO / RTO, você também pode usar esse mesmo nível de ajuste para suas restaurações. Escrevi sobre isso em minha postagem Escolhendo e testando um fornecedor de nuvem, quando ajudei uma empresa a analisar a melhor arquitetura de VM para suas necessidades de hospedagem SaaS.

Não sabia sobre isso? Você pode ter perdido algumas das outras coisas sobre as quais falamos em nossa aula de Fundamentos de Administração de Banco de Dados.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br