¿Cuándo está bien reducir una base de datos?

Sé que el encogimiento es el demonio: invierte el orden de las páginas y es responsable del cáncer de piel, la fragmentación de datos y el calentamiento global. La lista continúa ... Dicho esto, digamos que tengo una base de datos de 100 GB y elimino 50 GB de datos, no en una tabla, sino una poda general de datos antiguos en un nivel amplio de base de datos, que cubre el 90% de los datos tablas: ¿esto constituye un caso de uso apropiado para reducir la base de datos?

Si no, ¿cuáles son los pasos apropiados para limpiar la casa después de eliminar un porcentaje tan alto de datos de una base de datos? Se me ocurren dos: reconstruir índices y actualizar estadísticas. ¿Qué más?

Realmente nunca se recomienda una reorganización y reducción.

Si puede quitar las aplicaciones que la base de datos sirve fuera de línea, puede acelerar el proceso y reducir la fragmentación del índice eliminando todos los índices y las restricciones de clave principal / externa antes de la reducción (esto significará que hay menos datos para mover, ya que solo las páginas de datos se barajarán, no las páginas de índice que ahora no existen, acelerando el proceso) y luego se recrearán todos los índices y claves.

Volver a crear los índices después del encogimiento significa que no deben fragmentarse significativamente, y que desaparezcan durante el encogimiento significa que reconstruirlos no dejará muchos pequeños "agujeros" en la asignación de páginas dentro de los archivos que pueden invitar a la fragmentación más adelante.

Otra opción si puede desconectar las aplicaciones es migrar todos los datos a una nueva base de datos de la misma estructura. Si su proceso de compilación es sólido, debería poder compilar esa base de datos en blanco rápidamente, si no crear una desde la base de datos actual (restaurar una copia de seguridad de la actual, truncar / eliminar todo el contenido de las tablas y realizar una reducción completa).

Es posible que aún desee eliminar todos los índices en el destino y volver a crearlos después, ya que esto puede ser mucho más eficiente al cambiar una gran cantidad de datos indexados (100% de ellos en este caso). Para acelerar el proceso de copia, tenga los archivos de datos de la base de datos de destino en diferentes unidades físicas a la fuente (a menos que esté utilizando SSD, en cuyo caso no necesita preocuparse por reducir los movimientos de la cabeza), puede moverlos a la ubicación de origen cuando haya terminado.

Además, si crea el destino como nuevo (en lugar de borrar una copia de la fuente) créelo con un tamaño inicial que contendrá todos los datos actuales más algunos meses de crecimiento, lo que hará que los datos se copien un poco más rápido nuevamente. no asignará nuevo espacio de vez en cuando durante todo el proceso.

Esto podría ser mejor que usar la reducción porque la migración de los datos a una nueva base de datos replica la acción prevista de la operación de reducción, pero potencialmente con mucha menos fragmentación (que es la consecuencia no intencional de una reorganización y reducción). Un encogimiento simplemente toma bloques cerca del final del archivo y los coloca en el primer espacio más cerca del comienzo sin hacer ningún esfuerzo por mantener juntos los datos relacionados.

Sospecho que el resultado también será más eficiente en cuanto al espacio, ya que es probable que después haya páginas menos utilizadas. Un encogimiento solo moverá páginas parcialmente utilizadas, es más probable que mover los datos dé como resultado páginas completas, especialmente si inserta en el destino en el orden de la clave / índice agrupado de una tabla (donde una tabla tiene uno) y crea otros índices después de que todos los datos hayan migrado.

Por supuesto, si no puedes desconectar las aplicaciones, solo realizar una reducción es tu única opción, así que si realmente necesitas recuperar el espacio, ve con eso. Dependiendo de sus datos, patrones de acceso, tamaño de conjunto de trabajo común, cuánta RAM tiene el servidor, etc., la fragmentación interna adicional puede no ser tan significativa al final.

Para la operación de copia, SSIS o T-SQL base funcionarían igual de bien (la opción SSIS podría ser menos eficiente, pero potencialmente más fácil de mantener más adelante). Si crea las relaciones FK al final junto con los índices, puede hacer un simple "para cada tabla, copiar" en cualquier caso. Por supuesto, para una única vez, una reducción / reorganización probablemente también esté bien, ¡pero me gusta asustar a las personas para que nunca consideren reducciones regulares! (He conocido personas que los programan a diario).

¿La base de datos va a crecer nuevamente? Si es así, entonces el esfuerzo que va a poner en las operaciones de reducción será un desperdicio, porque cuando baje el tamaño del archivo y luego agregue más datos, el archivo tendrá que volver a crecer, y las transacciones tienen que esperar a que ocurra ese crecimiento. Si tiene una configuración de crecimiento automático subóptima y / o un impulso lento, esta actividad de crecimiento será bastante dolorosa.

Si reduce la base de datos, ¿para qué va a utilizar el espacio en disco liberado? Nuevamente, si solo va a mantener ese espacio libre en caso de que esta base de datos vuelva a crecer, entonces solo está girando las ruedas.

Lo que podría considerar hacer, ahora que tiene todo este espacio libre en el archivo, es reconstruir sus índices para que estén mejor optimizados (y será mucho menos doloroso hacerlo cuando tenga espacio libre para hacerlo) piensa en tratar de cambiar un suéter en un armario pequeño frente a una habitación grande).

Por lo tanto, a menos que se trate de una operación de limpieza importante y realmente no vuelva a aumentar el mismo nivel de datos, simplemente lo dejaré como está y me enfocaré en otras áreas de optimización.

Si se está quedando sin espacio, y no se supone que sus datos aumenten tanto, entonces reduzca, pero reconstruya sus índices después con factores de relleno apropiados que permitan el crecimiento típico.

Si su objetivo final es en realidad reducir el tamaño de la copia de seguridad, asegúrese de implementar una estrategia de copia de seguridad integral para borrar el registro de transacciones y cuando realice una copia de seguridad de la base de datos, use las opciones de compresión.

• Crear una copia de seguridad completa de la base de datos (SQL Server)
• Copias de seguridad del registro de transacciones (SQL Server)

No recomendaría el crecimiento automático de 5 GB a menos que normalmente espere crecer 5 GB con frecuencia. De lo contrario, podría tener problemas de rendimiento intermitentes. El tamaño de sus datos primero debe establecerse en lo que cree que se requiere, por ejemplo, un año, y el Crecimiento automático debe establecerse en un tamaño que haya probado no afecta el rendimiento operativo. ¡Vea No toque el botón Reducir la base de datos en SQL Server! por Mike Walsh.

La reconstrucción de índices antes de reducirse hace que los índices estén mal distribuidos. No es bueno reconstruir y luego reducir. La reducción hace que los índices se destrocen para recuperar espacio, por lo que reconstruir de antemano y luego reducir no tiene sentido. Vea Cuándo usar Auto Shrink por Thomas LaRock.

No sé si esto funcionaría mejor que reindexar después de la reducción, pero otra opción sería crear un nuevo archivo de datos con el tamaño adecuado y mover todos los datos a eso. En ese caso, primero haría una reindexación para que sepa cuál es el tamaño real de los datos. Un inconveniente es que si este es el primer archivo en el archivo de datos primario, no creo que pueda vaciarlo. Debería poder reducirlo y luego mover los datos hacia atrás para evitar la inversión de la página. Sin embargo, si está buscando pasar al estado sólido, eso no debería hacer una gran diferencia de todos modos.

Volviendo a esta MANERA tarde. Aún así, también hemos estado reflexionando y probando el uso de la reducción en nuestros entornos de prueba durante mucho tiempo. De acuerdo con el tema, no son momentos en los encogimiento es una opción viable. Pero saber cuándo y cómo aplicarlo es vital para una ejecución adecuada tanto a largo como a corto plazo.

En nuestro escenario, recientemente hemos agregado numerosos cambios a nuestra gran base de datos, incluyendo compresión, particionamiento, archivado y eliminación simple de datos redundantes. Como resultado, la parte utilizada de nuestro archivo de datos primario se ha reducido a menos de la mitad de lo que solía ser. Pero, ¿qué sentido tiene llevar todo ese equipaje? Especialmente porque, al contrario de algunos artículos en la web, el tamaño de sus archivos de datos CORRELA DIRECTAMENTE CON LA DURACIÓN DE RESERVA / RESTAURACIÓN. Esto se debe a que, a diferencia de lo que suponen muchos artículos, los escenarios de la vida real tienen muchos más datos en cualquier página que solo las cosas que quizás haya eliminado.

Más concretamente, esto abre un gran escenario para la reducción:

1. Cree una secuencia de comandos que encuentre todos los objetos y sus grupos de archivos en su base de datos (muchos ejemplos en línea), use esto para crear las cláusulas de caída y crear definiciones para cada uno de sus índices y restricciones.
2. Cree un nuevo archivo y grupo de archivos y haga que sea el predeterminado.
3. Descarte todos los índices no agrupados (tenga en cuenta que algunos índices pueden ser restricciones).
4. Cree sus índices agrupados en el nuevo grupo de archivos con DROP_EXISTING = ON (que, por cierto, es una operación extremadamente rápida y mínimamente registrada para comenzar en comparación con muchas alternativas).
5. Recrea tus índices no agrupados.
6. Finalmente, REDUZCA su antiguo archivo de datos (generalmente PRIMARIO).

De esta manera, los únicos datos que quedarían allí serían los objetos del sistema de su base de datos, estadísticas, procedimientos y demás. El encogimiento debería ser mucho, MUCHO más rápido, y no hay necesidad de ningún mantenimiento adicional del índice en sus objetos de datos principales que se habrán creado de manera ordenada y con un riesgo mínimo de fragmentación futura.