¿Es seguro tener activado el encogimiento automático de SQL Server?

Hay muchas opciones de SQL Server que pueden habilitarse para bases de datos, y una de las más incomprendidas es la reducción automática. ¿Es seguro? ¿Si no, porque no?

(Originalmente hice una pregunta regular pero luego descubrí el método correcto, gracias BrentO)

No nunca.

Me he encontrado con esto varias veces en ServerFault y quiero llegar a un público amplio y agradable con buenos consejos. Si la gente frunce el ceño ante esta forma de hacer las cosas, vota a favor y lo eliminaré con gusto.

La reducción automática es una configuración de base de datos muy común que se ha habilitado. Parece una buena idea: eliminar el espacio extra de la base de datos. Hay muchos 'DBA involuntarios' (piense en TFS, SharePoint, BizTalk o simplemente en el antiguo SQL Server normal) que tal vez no sepan que la reducción automática es realmente mala.

Mientras estaba en Microsoft, era propietario del motor de almacenamiento de SQL Server y traté de eliminar la función de reducción automática, pero tenía que mantener la compatibilidad con versiones anteriores.

¿Por qué el autoencogimiento es tan malo?

Es probable que la base de datos vuelva a crecer, entonces, ¿por qué reducirla?

1. Shrink-grow-shrink-grow causa fragmentación a nivel del sistema de archivos y requiere muchos recursos.
2. No puedes controlar cuándo se activa (aunque sea normal)
3. Utiliza muchos recursos. Mover páginas en la base de datos requiere CPU, muchas E / S y genera muchos registros de transacciones.
4. Aquí está el verdadero truco: la reducción del archivo de datos (ya sea automático o no) causa una fragmentación masiva del índice, lo que conduce a un bajo rendimiento.

Hice una publicación en el blog hace un tiempo que tiene un script SQL de ejemplo que muestra los problemas que causa y explica con un poco más de detalle. Consulte Reducción automática: ¡apáguelo! (sin publicidad o basura como esa en mi blog). No se confunda con reducir el archivo de registro, que en ocasiones es útil y necesario.

Así que hágase un favor: busque en la configuración de su base de datos y desactive la reducción automática. Tampoco debería reducir sus planes de mantenimiento, exactamente por la misma razón. Corre la voz a tus colegas.

Editar: debería agregar esto, recordado por la segunda respuesta: hay una idea errónea común de que interrumpir una operación de reducción puede causar corrupción. No, no lo hará. Solía ​​tener el código de reducción en SQL Server: revierte el movimiento de la página actual que está haciendo si se interrumpe.

¡Espero que esto ayude!

Por supuesto, Paul tiene razón.

Vea todos los DB y su configuración de autoencogimiento. Si tienes muchas bases de datos, una se colará.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

¿Está esto en el dmv en alguna parte ... Me pregunto.

No es "inseguro", no dañará nada.

Pero no se recomienda para entornos de producción en los que la base de datos puede decidir salir y comenzar un costoso ejercicio de reorganización justo antes de que llegue un montón de solicitudes, lo que hace que esas solicitudes tarden más en ser atendidas. Es mucho mejor utilizar las operaciones de reducción de la programación junto con otras operaciones de mantenimiento, como las copias de seguridad (en realidad, después de las copias de seguridad, de ese modo, será más del registro de transacciones). O simplemente no se reduce en absoluto a menos que haya un problema de crecimiento: siempre puede configurar un monitor para informarle cuándo el espacio asignado no utilizado crece más allá de una cierta proporción o tamaño fijo.

IIRC la opción está desactivada por defecto para todas las bases de datos en todas las ediciones de MSSQL, excepto Express.

Hay un documento técnico disponible en TechNet que explica el mantenimiento de SQL con más detalle.

http://technet.microsoft.com/en-us/library/cc262731.aspx

He visto un servidor SQL con Autogrow y Autoshrink habilitados. Este servidor (relativamente potente) era terriblemente lento, porque todo lo que hizo todo el día fue reducir y hacer crecer los archivos de la base de datos. Autoshrink puede ser útil, pero recomendaría dos cosas:

1. Desactivar Autoshrink de forma predeterminada.
2. Documente las configuraciones de su servidor, de modo que sepa dónde Autogrow y Autoshrink están habilitados y dónde no.

La única vez que me vi obligado a reducir una base de datos fue actualizar una copia en un servidor de prueba con menos espacio en disco (insuficiente para contener la base de datos de producción).

Los archivos de la base de datos de producción tenían un espacio libre generoso, desafortunadamente tiene que restaurar una base de datos con el mismo tamaño de archivo que la copia de seguridad. Así que no tuve más remedio que reducir la producción antes de respaldarla. (La reducción tomó años, se consumieron muchos recursos y el posterior crecimiento del registro de transacciones fue problemático).

También mira este video tutorial ...

Observe cómo Paul Randal demuestra cómo la reducción y la reducción automática pueden causar serios problemas de fragmentación en su base de datos http://wtv.watchtechvideos.com/topic194.html