Tamaño de la copia de seguridad inestable, dónde buscar causas


2

Tengo un nuevoSQL Server 2014 (12.0.2000)instancia con aproximadamente 50 bases de datos, se actualizó recientemente desde SQL Server 2005.

Estaban usando una gran cantidad de espacio de respaldo, por lo que el antiguo plan de mantenimiento fue reemplazado por un enfoque diferente:

Verificar Db Integrity->Copia de seguridad de la base de datos (completa) (con compresión)->Índice de reconstrucción->Limpieza de mantenimiento

Eso sucede todos los días, mientras que las bases de datos no se utilizan y conserva las copias de seguridad durante 5 días.

Al principio funcionó bien y se guardó una gran cantidad de unidades de respaldo, pero luego algunas de las bases de datos comenzaron a hacer copias de seguridad con tamaños de archivo erráticos.

Algunas imágenes que muestran el tamaño del archivo cambian:

Este bajó mucho, eso se esperaba.La cosa es, entonces cuando baja otras dos veces (?)

Este otro cuando bajó un poco y luego bajó de tamaño y finalmente se hizo más grande que la primera vez que hizo una copia de seguridad con compresión.

enter image description here

Finalmente, éste bajó de tamaño, más al día siguiente y luego subió ese lugar en el que fue el primer día.

enter image description here


En este caso:

enter image description here

En la restauración, el tamaño del archivo aumenta un poco:

enter image description here

Así que restauran la forma en que se supone que deben hacerlo, pero aquí estoy preguntándome: ¿por qué varían en tamaño? Puedo entender totalmente el cambio después de la compresión, pero después (?).

¿Por qué la copia de seguridad se comportaría de esta manera?¿Alguna razón conocida?

Además: nada realmente está pasando en los registros.

+1

Si no espera que ocurra mucho en la base de datos, ¿por qué reconstruir los índices diariamente?¿Estás reconstruyendo todos los índices?Eso es, efectivamente, un cambio del 100% de los datos a diario (en relación con la reescritura de los mismos datos todos los días). 22 sep. 162016-09-22 12:49:20

2

Cuando se utiliza la compresión de copia de seguridad, el tamaño de la copia de seguridad variará bastante, suponiendo que los datos se cambien en la base de datos.

Realizar el mantenimiento de índices cada noche se moverá de datos por el interior de la base de datos mucho, dando como resultado cambios impredecibles en la cantidad de páginas asignadas dentro de la base de datos.La desfragmentación del índice no es perfecta y no garantiza que el índice se haya desfragmentado completamente, es simplemente una forma de reducir la fragmentación.

La cantidad de cambio que está viendo no es nada de qué preocuparse, especialmente cuando ve que los tamaños de sus archivos se miden en kilobytes .


0

Bueno, si este fuera yo, creo que primero descartaría REBUILD consolidando datos en un número significativamente menor de páginas activas (ya que BACKUP solo realiza copias de seguridad de las páginas activas)

Creo que restauraría una copia de seguridad 'grande' en un servidor de prueba y ejecutaría la siguiente consulta para identificar las páginas utilizadas por objeto.Guarde esa información para compararla con la restauración de una copia de seguridad 'más pequeña'

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;

Puede que esto no te diga nada nuevo, pero es donde empezaría.