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

Respuestas:

70

(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!

Paul Randal
fuente
¿Hay alguna manera de volver a indexar justo después de una reducción?
Lance Roberts
44
No reindexar porque eso volverá a hacer crecer el archivo (construye un nuevo índice antes de descartar el anterior), pero hacer una reorganización (ya sea a través de mi antiguo DBCC INDEXDEFRAG o el nuevo ALTER INDEX ... REORGANIZE) solucionará la fragmentación, a expensas de más IO, cpu, logging ...
Paul Randal
Noté que después de eliminar el autoencogimiento, el uso de memoria del srrver es mayor.
user193655
4

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.

Sam
fuente
2
sys.databases tiene un campo is_auto_shrink (y is_auto-close, is_auto_update_stats, etc.)
Paul Randal
maravillosa im buscando en Google: ¿cómo tengo un informe que nos ayuda a saber qué DBS configura como la reducción automática y su buena ejecución de código y generar buen informe de todo db para nosotros
sable Tabatabaee yazdi
2

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.

David Spillett
fuente
2
Los encogimientos no deberían programarse, deberían ser operaciones realmente raras debido a los problemas que causan. No entiendo su comentario sobre la reducción después de la copia de seguridad: los registros de registro generados por la operación de reducción serán recogidos por la siguiente copia de seguridad del registro de transacciones, independientemente de cuándo lo haga o qué otras copias de seguridad tome. Gracias
Paul Randal
1

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

Jeremy Thake
fuente
Desafortunadamente, el documento técnico está dirigido solo a instalaciones de SharePoint y en realidad tiene algunos errores. Acabo de pasar tiempo enseñando la clase actual de MCM de SharePoint con el autor del documento, Bill Baer.
Paul Randal
3
Una buena introducción general al mantenimiento de la base de datos se encuentra en mi artículo de TechNet Magazine sobre el tema Mantenimiento efectivo de la base de datos: technet.microsoft.com/en-us/magazine/cc671165.aspx .
Paul Randal
1

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.
Carl C
fuente
1

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).

SuperCoolMoss
fuente
1

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

Sakthivel Chidambaram
fuente