Início / dba / Perguntas / 150399
Accepted
Nelson
Asked: 2016-09-23 04:01:11 +0800 CST

Tamanho de backup instável, onde procurar as causas

  • 772

Eu tenho uma nova instância do SQL Server 2014 (12.0.2000) com cerca de 50 bancos de dados, ela foi atualizada recentemente do SQL Server 2005.

Eles estavam usando muito espaço de backup, então o antigo plano de manutenção foi substituído por uma abordagem diferente:

Verifique a integridade do banco de dados -> faça backup do banco de dados (completo) (com compactação) -> reconstrua o índice -> limpeza de manutenção

Isso acontece todos os dias enquanto os bancos de dados não estão sendo usados ​​e preserva os backups por 5 dias.

No início, funcionou bem e muitas unidades de backup foram salvas, mas alguns dos bancos de dados começaram a fazer backup com tamanhos de arquivo erráticos.

Algumas imagens que exibem a alteração do tamanho do arquivo:

Este caiu muito, isso era esperado. O problema é que, quando desce mais duas vezes (?)

Este outro quando diminuiu um pouco e depois diminuiu de tamanho e finalmente ficou maior do que na primeira vez em que recuou com a compactação.

insira a descrição da imagem aqui

Por fim, este diminuiu de tamanho, diminuiu ainda mais no dia seguinte e depois subiu naquele local em que estava no primeiro dia.

insira a descrição da imagem aqui

Nesse caso:

insira a descrição da imagem aqui

Ao restaurar, o tamanho do arquivo aumenta bastante:

insira a descrição da imagem aqui

Então eles restauram da maneira que deveriam, mas estou aqui me perguntando, como é que eles variam de tamanho, posso entender totalmente a mudança após a compactação, mas depois (?).

Por que o backup se comportaria dessa maneira? Algum motivo conhecido?

Além disso: nada realmente acontecendo nos logs.

backup sql-server-2014

2 respostas

  1. Best Answer

    Ao usar a compactação de backup, o tamanho do backup varia bastante, assumindo que os dados estão sendo alterados no banco de dados.

    Executar a manutenção do índice todas as noites moverá muito os dados dentro do banco de dados , resultando em alterações imprevisíveis na quantidade de páginas alocadas dentro do banco de dados. A desfragmentação do índice não é perfeita e não garante que o índice seja completamente desfragmentado - é apenas uma forma de reduzir a fragmentação.

    A quantidade de alteração que você está vendo não é motivo de preocupação, especialmente quando você vê que os tamanhos dos arquivos são medidos em kilobytes .

    • 2

  2. Bem, se fosse eu, acho que primeiro descartaria a REBUILDconsolidação de dados em um número significativamente menor de páginas ativas (já que BACKUPfaz backup apenas de páginas ativas)

    Acho que restauraria um backup 'grande' em um servidor de teste e executaria a seguinte consulta para identificar used_pages por objeto. Salve essas informações para comparação com a restauração de um backup 'menor'

    SELECT  OBJECT_SCHEMA_NAME(s.object_id) schema_name,
        OBJECT_NAME(s.object_id) table_name,
        SUM(s.used_page_count) used_pages,
        SUM(s.reserved_page_count) reserved_pages
FROM    sys.dm_db_partition_stats s
JOIN    sys.tables t
        ON s.object_id = t.object_id
GROUP BY s.object_id
ORDER BY schema_name,
        table_name;

    Isso pode não dizer nada de novo, mas é por onde eu começaria.

    • 0

relate perguntas