Esta parece ser una pregunta común en la mayoría de los foros y en toda la web, se hace aquí en muchos formatos que generalmente suenan así:

En SQL Server:

• ¿Cuáles son algunas razones por las que el registro de transacciones crece tanto?
• ¿Por qué mi archivo de registro es tan grande?
• ¿Cuáles son algunas formas de evitar que ocurra este problema?
• ¿Qué hago cuando me encamino con la causa subyacente y quiero poner mi archivo de registro de transacciones a un tamaño adecuado?

Una respuesta más corta:

Es probable que tenga una transacción de larga ejecución (¿Mantenimiento del índice? ¿Eliminación o actualización de lotes grandes?) O está en el modo de recuperación "predeterminado" (más abajo sobre lo que se entiende por defecto) Fully no ha realizado una copia de seguridad del registro (o no los tomas con la suficiente frecuencia).

Si se trata de un problema del modelo de recuperación, la respuesta simple podría ser Cambiar al Simplemodo de recuperación si no necesita una recuperación puntual y copias de seguridad de registros regulares. Sin embargo, muchas personas responden sin comprender los modelos de recuperación. Sigue leyendo para entender por qué es importante y luego decide lo que haces. También podría comenzar a tomar copias de seguridad de registros y permanecer en Fullrecuperación.

Podría haber otras razones, pero estas son las más comunes. Esta respuesta comienza a sumergirse en las dos razones más comunes y le brinda información básica sobre el por qué y cómo detrás de las razones, así como también explora otras razones.

Una respuesta más larga: ¿Qué escenarios pueden hacer que el registro siga creciendo? Hay muchas razones, pero generalmente estas son de los siguientes dos patrones: hay un malentendido sobre los modelos de recuperación o hay transacciones de larga duración. Sigue leyendo para más detalles.

Razón principal 1/2: no entender los modelos de recuperación

( Estar en modo de recuperación completa y no realizar copias de seguridad de registros : esta es la razón más común: la gran mayoría de las personas que experimentan este problema lo están ) .

Si bien esta respuesta no es una inmersión profunda en los modelos de recuperación de SQL Server, el tema de los modelos de recuperación es fundamental para este problema.

En SQL Server, hay tres modelos de recuperación :

• Full,
• Bulk-Logged y
• Simple.

Ignoraremos Bulk-Loggedpor ahora, diremos que es un modelo híbrido y la mayoría de las personas que están en este modelo están allí por una razón y entienden los modelos de recuperación.

Los dos que nos importan y su confusión son la causa de la mayoría de los casos de personas que tienen este problema Simpley son Full.

Intermedio: recuperación en general

Antes de hablar sobre los modelos de recuperación: hablemos sobre la recuperación en general. Si quieres profundizar aún más en este tema, solo lee el blog de Paul Randal y todas las publicaciones que quieras sobre él. Para esta pregunta, sin embargo:

1. Recuperación
   por bloqueo / reinicio Uno de los propósitos del archivo de registro de transacciones es la recuperación por bloqueo / reinicio . Para el avance y retroceso del trabajo realizado (avance / rehacer) antes de un bloqueo o reinicio y el trabajo que se inició pero que no terminó después de un bloqueo o reinicio (retroceso / deshacer). El trabajo del registro de transacciones es ver que una transacción se inició pero nunca se terminó (retrocedió o se produjo un bloqueo / reinicio antes de que se confirmara la transacción). En esa situación, el trabajo del registro es decir "Hey ... esto nunca terminó realmente, vamos a retroceder" durante la recuperación. También es el trabajo del registro ver que usted terminó algo y que su aplicación cliente fue informada que estaba terminada (incluso si aún no se había endurecido en su archivo de datos) y decir"Oye ... esto realmente sucedió, avancemos, hagamos que las aplicaciones piensen que fue" después de un reinicio. Ahora hay más, pero ese es el objetivo principal.

2. Recuperación de un punto en el tiempo
   El otro propósito para un archivo de registro de transacciones es poder darnos la capacidad de recuperar un punto en el tiempo debido a un "¡Uy" en una base de datos o garantizar un punto de recuperación en caso de una falla de hardware involucrando los datos y / o archivos de registro de una base de datos. Si este registro de transacciones contiene los registros de las transacciones que se han iniciado y finalizado para la recuperación, SQL Server puede y luego utiliza esta información para obtener una base de datos donde estaba antes de que ocurriera un problema. Pero esa no siempre es una opción disponible para nosotros. Para que eso funcione, tenemos que tener nuestra base de datos en el modelo de recuperación correcto , y tenemos que tomar copias de seguridad de registros .

Modelos de recuperación

Sobre los modelos de recuperación:

• Modelo de recuperación simple
  Entonces, con la introducción anterior, es más fácil hablar sobre el Simple Recoverymodelo primero. En este modelo, le está diciendo a SQL Server: "Estoy de acuerdo con que use su archivo de registro de transacciones para bloquear y reiniciar la recuperación ..." (Realmente no tiene otra opción allí. Busque las propiedades de ACID y eso debería tener sentido rápidamente). "... pero una vez que ya no lo necesite para ese propósito de recuperación de bloqueo / reinicio, continúe y reutilice el archivo de registro".

  SQL Server escucha esta solicitud en Simple Recovery y solo mantiene la información que necesita para realizar la recuperación de bloqueo / reinicio. Una vez que SQL Server está seguro de que puede recuperarse porque los datos se han endurecido en el archivo de datos (más o menos), los datos que se han endurecido ya no son necesarios en el registro y están marcados para truncamiento, lo que significa que se reutilizan.

• Modelo de recuperación completa
  Con Full Recovery, le está diciendo a SQL Server que desea poder recuperarse en un punto específico en el tiempo, siempre que su archivo de registro esté disponible o en un momento específico que esté cubierto por una copia de seguridad de registro. En este caso, cuando SQL Server llegue al punto en el que sería seguro truncar el archivo de registro en el Modelo de recuperación simple, no lo hará. En cambio , permite que el archivo de registro continúe creciendo y permitirá que siga creciendo, hasta que realice una copia de seguridad del registro (o se quede sin espacio en su unidad de archivo de registro) en circunstancias normales.

Cambiar de Simple a Completo tiene un Gotcha.

Hay reglas y excepciones aquí. Hablaremos de las transacciones de larga duración en profundidad a continuación.

Pero una advertencia a tener en cuenta para el modo de recuperación completa es la siguiente: si solo cambia al Full Recoverymodo, pero nunca realiza una copia de seguridad completa inicial, SQL Server no cumplirá su solicitud de estar en el Full Recoverymodelo. Su registro de transacciones continuará funcionando como lo ha hecho Simplehasta que cambie al Modelo de recuperación completa Y tome el primero Full Backup.

El modelo de recuperación completa sin copias de seguridad de registros es malo.

Entonces, ¿esa es la razón más común para el crecimiento descontrolado de troncos? Respuesta: Estar en modo de recuperación completa sin tener ninguna copia de seguridad de registro.

Esto le sucede todo el tiempo a las personas.

¿Por qué es un error tan común?

¿Por qué sucede todo el tiempo? Porque cada nueva base de datos obtiene su configuración de modelo de recuperación inicial mirando la base de datos modelo.

La configuración inicial del modelo de recuperación del modelo es siempre Full Recovery Model, hasta y a menos que alguien cambie eso. Entonces podría decir que el "Modelo de recuperación predeterminado" es Full. Muchas personas no son conscientes de esto y tienen sus bases de datos ejecutándose Full Recovery Modelsin copias de seguridad de registros y, por lo tanto, un archivo de registro de transacciones mucho más grande de lo necesario. Es por eso que es importante cambiar los valores predeterminados cuando no funcionan para su organización y sus necesidades)

El modelo de recuperación completa con muy pocas copias de seguridad de registros es malo.

También puede meterse en problemas aquí si no realiza copias de seguridad de registros con la frecuencia suficiente.
Hacer una copia de seguridad de registro al día puede sonar bien, hace que una restauración requiera menos comandos de restauración, pero teniendo en cuenta la discusión anterior, ese archivo de registro seguirá creciendo y creciendo hasta que realice copias de seguridad de registro.

¿Cómo puedo saber qué frecuencia de respaldo de registro necesito?

Debe tener en cuenta su frecuencia de respaldo de registro con dos cosas en mente:

1. Necesidades de recuperación : es de esperar que esto sea lo primero. En el caso de que la unidad que aloja su registro de transacciones se dañe o reciba una corrupción grave que afecte su copia de seguridad del registro, ¿cuántos datos se pueden perder? Si ese número no es más de 10-15 minutos, entonces debe tomar la copia de seguridad del registro cada 10-15 minutos, al final de la discusión.
2. Crecimiento del registro : si su organización está bien para perder más datos debido a la capacidad de recrear fácilmente ese día, puede estar bien para tener una copia de seguridad del registro con mucha menos frecuencia que 15 minutos. Tal vez su organización esté bien con cada 4 horas. Pero debe ver cuántas transacciones genera en 4 horas. ¿Permitir que el registro siga creciendo en esas cuatro horas hará que un archivo de registro sea demasiado grande? ¿Significará eso que las copias de seguridad de tu registro tardan demasiado?

Razón principal 2/2: Transacciones de larga duración

( "¡Mi modelo de recuperación está bien! ¡El registro sigue creciendo! )

Esto también puede ser una causa de crecimiento de registro incontrolado y sin restricciones. No importa el modelo de recuperación, pero a menudo aparece como "Pero estoy en el Modelo de recuperación simple, ¿por qué mi registro sigue creciendo?"

La razón aquí es simple: si SQL está utilizando este registro de transacciones para fines de recuperación como describí anteriormente, entonces debe ver el inicio de una transacción.

Si tiene una transacción que lleva mucho tiempo o hace muchos cambios, el registro no se puede truncar en el punto de control para ninguno de los cambios que todavía están en transacciones abiertas o que han comenzado desde que comenzó esa transacción.

Esto significa que una gran eliminación, la eliminación de millones de filas en una declaración de eliminación es una transacción y el registro no puede truncar hasta que se haya completado la eliminación. En Full Recovery Model, esta eliminación se registra y eso podría ser una gran cantidad de registros. Lo mismo con el trabajo de optimización de índice durante las ventanas de mantenimiento. También significa que una gestión de transacciones deficiente y no vigilar y cerrar transacciones abiertas realmente puede perjudicarlo a usted y a su archivo de registro.

¿Qué puedo hacer con estas transacciones de larga duración?

Puedes salvarte aquí:

• Dimensionar adecuadamente su archivo de registro para tener en cuenta el peor de los casos, como su mantenimiento o grandes operaciones conocidas. Y cuando crezca su archivo de registro, debe consultar esta guía (y los dos enlaces a los que ella lo envía) de Kimberly Tripp. El tamaño correcto es súper crítico aquí.
• Observando su uso de transacciones. No inicie una transacción en su servidor de aplicaciones y comience a tener largas conversaciones con SQL Server y corra el riesgo de dejar una abierta demasiado tiempo.
• Observando las transacciones implícitas en sus declaraciones DML. Por ejemplo: UPDATE TableName Set Col1 = 'New Value'es una transacción. No puse un BEGIN TRANallí y no tengo que hacerlo, todavía es una transacción que solo se confirma automáticamente cuando se hace. Entonces, si realiza operaciones en grandes cantidades de filas, considere agrupar esas operaciones en trozos más manejables y dar tiempo al registro para recuperarse. O considere el tamaño correcto para lidiar con eso. O quizás considere cambiar los modelos de recuperación durante una ventana de carga masiva.

¿Estas dos razones también se aplican al Log Shipping?

Respuesta corta: sí. Respuesta más larga a continuación.

Pregunta: "Estoy utilizando el envío de registros, por lo que mis copias de seguridad de registros están automatizadas ... ¿Por qué sigo viendo el crecimiento del registro de transacciones?"

Respuesta: sigue leyendo.

¿Qué es el envío de registros?

El envío de registros es exactamente lo que parece: está enviando sus copias de seguridad del registro de transacciones a otro servidor para fines de recuperación ante desastres. Hay algo de inicialización, pero luego el proceso es bastante simple:

• Un trabajo para hacer una copia de seguridad del registro en un servidor,
• un trabajo para copiar esa copia de seguridad de registro y
• un trabajo para restaurarlo sin recuperación (ya sea NORECOVERYo STANDBY) en el servidor de destino.

También hay algunos trabajos para monitorear y alertar si las cosas no salen según lo planeado.

En algunos casos, es posible que solo desee realizar la restauración del envío de registros una vez al día o cada tercer día o una vez a la semana. Eso está bien. Pero si realiza este cambio en todos los trabajos (incluidos los trabajos de copia de seguridad y copia de registro), significa que está esperando todo ese tiempo para realizar una copia de seguridad de registro. Eso significa que tendrá un gran crecimiento de registro, porque está en modo de recuperación completa sin copias de seguridad de registro , y probablemente también signifique un gran archivo de registro para copiar. Solo debe modificar la programación del trabajo de restauración y dejar que las copias de seguridad y las copias de registro se realicen con mayor frecuencia, de lo contrario sufrirá el primer problema descrito en esta respuesta.

Solución de problemas generales a través de códigos de estado

Hay otras razones además de estas dos, pero estas son las más comunes. Independientemente de la causa: hay una manera de analizar su razón para este crecimiento de registro inexplicable / falta de truncamiento y ver cuáles son.

Al consultar la sys.databasesvista de catálogo, puede ver información que describe la razón por la cual su archivo de registro puede estar esperando truncarse / reutilizarse.

Hay una columna llamada log_reuse_waitcon un ID de búsqueda del código de razón y una log_reuse_wait_desccolumna con una descripción de la razón de espera. Del artículo en línea de los libros de referencia se encuentran la mayoría de las razones (las que probablemente verá y las que podemos explicar. Las que faltan están fuera de uso o para uso interno) con algunas notas sobre la espera en cursiva :

• 0 = Nada
  Cómo suena ... No debería estar esperando

• 1 = Punto de control
  Esperando a que ocurra un punto de control. Esto debería suceder y debería estar bien, pero hay algunos casos que debe buscar aquí para obtener respuestas o ediciones posteriores.

• 2 = Copia de seguridad del registro
  Está esperando que se realice una copia de seguridad del registro. O los tiene programados y sucederá pronto, o tiene el primer problema descrito aquí y ahora sabe cómo solucionarlo

• 3 = Copia de seguridad o restauración activa
  Se está ejecutando una operación de copia de seguridad o restauración en la base de datos

• 4 = Transacción activa
  Hay una transacción activa que debe completarse (de cualquier manera ROLLBACKo COMMITantes) antes de que se pueda hacer una copia de seguridad del registro. Esta es la segunda razón descrita en esta respuesta.

• 5 = Duplicación de la base de datos
  O bien un espejo se está quedando atrás o bajo alguna latencia en una situación de espejo de alto rendimiento o el espejo está en pausa por alguna razón

• 6 = Replicación
  Puede haber problemas con la replicación que podrían causar esto, como un agente lector de registro que no se ejecuta, una base de datos que cree que está marcada para una replicación que ya no existe y varias otras razones. También puede ver esta razón y es perfectamente normal porque está buscando el momento justo, justo cuando el lector de registro está consumiendo transacciones

• 7 = Creación de
  una instantánea de la base de datos Está creando una instantánea de la base de datos, lo verá si observa el momento justo cuando se está creando una instantánea

• 8 = Exploración de registros
  Todavía no he encontrado un problema con esto funcionando para siempre. Si observa lo suficiente y con la frecuencia suficiente, puede ver que esto suceda, pero eso no debería ser una causa del crecimiento excesivo del registro de transacciones, como he visto.

• 9 = Una réplica secundaria de Grupos de disponibilidad AlwaysOn está aplicando registros de registro de transacciones de esta base de datos a una base de datos secundaria correspondiente. Sobre la descripción más clara hasta ahora ...

Como no estoy realmente satisfecho con ninguna de las respuestas sobre Stack Overflow , incluida la sugerencia más votada, y debido a que hay algunas cosas que me gustaría abordar que la respuesta de Mike no, pensé que podría proporcionar mi entrada aquí también. Puse una copia de esta respuesta allí también.

Hacer un archivo de registro más pequeño realmente debería reservarse para escenarios en los que se encontró un crecimiento inesperado que no espera que vuelva a suceder. Si el archivo de registro volverá a crecer al mismo tamaño, no se logra mucho reduciéndolo temporalmente. Ahora, dependiendo de los objetivos de recuperación de su base de datos, estas son las acciones que debe tomar.

Primero, haga una copia de seguridad completa

Nunca realice cambios en su base de datos sin asegurarse de que pueda restaurarla si algo sale mal.

Si te importa la recuperación en un momento determinado

(Y por recuperación en un momento dado, me refiero a que le importa poder restaurar a otra cosa que no sea una copia de seguridad completa o diferencial).

Presumiblemente su base de datos está en FULLmodo de recuperación. De lo contrario, asegúrese de que sea:

ALTER DATABASE yourdb SET RECOVERY FULL;

Incluso si está realizando copias de seguridad completas regulares, el archivo de registro crecerá y crecerá hasta que realice una copia de seguridad de registro ; esto es para su protección, no para consumir innecesariamente el espacio de su disco. Debe realizar estas copias de seguridad de registros con bastante frecuencia, de acuerdo con sus objetivos de recuperación. Por ejemplo, si tiene una regla comercial que establece que puede permitirse perder no menos de 15 minutos de datos en caso de desastre, debe tener un trabajo que haga una copia de seguridad del registro cada 15 minutos. Aquí hay un script que generará nombres de archivo con marca de tiempo en función de la hora actual (pero también puede hacerlo con planes de mantenimiento, etc., simplemente no elija ninguna de las opciones de reducción en los planes de mantenimiento, son horribles).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Tenga en cuenta que \\backup_share\debe estar en una máquina diferente que represente un dispositivo de almacenamiento subyacente diferente. Hacer una copia de seguridad de estos en la misma máquina (o en una máquina diferente que usa los mismos discos subyacentes, o una máquina virtual diferente que está en el mismo host físico) realmente no lo ayuda, ya que si la máquina explota, ha perdido su base de datos y sus respaldos. Dependiendo de la infraestructura de su red, puede tener más sentido hacer una copia de seguridad local y luego transferirlos a una ubicación diferente detrás de escena; en cualquier caso, desea sacarlos de la máquina de base de datos primaria lo más rápido posible.

Ahora, una vez que tenga copias de seguridad de registro regulares en ejecución, debería ser razonable reducir el archivo de registro a algo más razonable que lo que sea que haya explotado hasta ahora. Esto no significa ejecutar SHRINKFILEuna y otra vez hasta que el archivo de registro sea de 1 MB, incluso si realiza una copia de seguridad del registro con frecuencia, aún necesita acomodar la suma de las transacciones simultáneas que puedan ocurrir. Los eventos de crecimiento automático de archivos de registro son caros, ya que SQL Server tiene que poner a cero los archivos (a diferencia de los archivos de datos cuando la inicialización instantánea de archivos está habilitada), y las transacciones de los usuarios tienen que esperar mientras esto sucede. Desea hacer esta rutina de crecimiento-reducción-crecimiento-reducción lo menos posible, y ciertamente no desea que sus usuarios paguen por ello.

Tenga en cuenta que es posible que deba hacer una copia de seguridad del registro dos veces antes de que sea posible una reducción (gracias Robert).

Por lo tanto, debe encontrar un tamaño práctico para su archivo de registro. Nadie aquí puede decirle qué es eso sin saber mucho más acerca de su sistema, pero si ha estado reduciendo el archivo de registro con frecuencia y ha vuelto a crecer, una buena marca de agua es probablemente un 10-50% más alta que la más grande que ha sido. . Supongamos que llega a 200 MB y desea que cualquier evento de crecimiento automático posterior sea de 50 MB, entonces puede ajustar el tamaño del archivo de registro de esta manera:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Tenga en cuenta que si el archivo de registro es actualmente> 200 MB, es posible que deba ejecutar esto primero:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Si no te importa la recuperación en un momento determinado

Si se trata de una base de datos de prueba y no le importa la recuperación en un momento determinado, debe asegurarse de que su base de datos esté en SIMPLEmodo de recuperación.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Poner la base de datos en SIMPLEmodo de recuperación se asegurará de que SQL Server reutilice partes del archivo de registro (esencialmente eliminando las transacciones inactivas) en lugar de crecer para mantener un registro de todas las transacciones (como lo FULLhace la recuperación hasta que haga una copia de seguridad del registro). CHECKPOINTLos eventos ayudarán a controlar el registro y se asegurarán de que no sea necesario que crezca, a menos que genere mucha actividad t-log entre CHECKPOINTs.

A continuación, debe asegurarse de que este crecimiento del registro se deba realmente a un evento anormal (por ejemplo, una limpieza anual de primavera o la reconstrucción de sus índices más grandes), y no debido al uso diario normal. Si reduce el archivo de registro a un tamaño ridículamente pequeño y SQL Server solo tiene que volver a crecer para acomodar su actividad normal, ¿qué ganó? ¿Pudiste hacer uso de ese espacio en disco que liberaste solo temporalmente? Si necesita una solución inmediata, puede ejecutar lo siguiente:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

De lo contrario, establezca un tamaño y una tasa de crecimiento adecuados. Según el ejemplo en el caso de recuperación en un punto en el tiempo, puede usar el mismo código y lógica para determinar qué tamaño de archivo es apropiado y establecer parámetros de crecimiento automático razonables.

Algunas cosas que no quieres hacer

• Haga una copia de seguridad del registro con la TRUNCATE_ONLYopción y luegoSHRINKFILE . Por un lado, esta TRUNCATE_ONLYopción ha quedado en desuso y ya no está disponible en las versiones actuales de SQL Server. En segundo lugar, si está en el FULLmodelo de recuperación, esto destruirá su cadena de registro y requerirá una nueva copia de seguridad completa.

• Separe la base de datos, elimine el archivo de registro y vuelva a adjuntar . No puedo enfatizar cuán peligroso puede ser esto. Es posible que su base de datos no vuelva a aparecer, puede aparecer como sospechosa, es posible que deba volver a una copia de seguridad (si tiene una), etc., etc.

• Use la opción "reducir base de datos" . DBCC SHRINKDATABASEy la opción del plan de mantenimiento para hacer lo mismo son malas ideas, especialmente si realmente solo necesita resolver un problema de registro. Apunte el archivo que desea ajustar y ajústelo de forma independiente, utilizando DBCC SHRINKFILEo ALTER DATABASE ... MODIFY FILE(ejemplos anteriores).

• Reducir el archivo de registro a 1 MB . Esto parece tentador porque, oye, SQL Server me permitirá hacerlo en ciertos escenarios, ¡y mirar todo el espacio que libera! A menos que su base de datos sea de solo lectura (y lo es, debe marcarla como tal usando ALTER DATABASE), esto solo conducirá a muchos eventos de crecimiento innecesarios, ya que el registro tiene que acomodar las transacciones actuales independientemente del modelo de recuperación. ¿Cuál es el punto de liberar ese espacio temporalmente, solo para que SQL Server pueda recuperarlo lenta y dolorosamente?

• Crea un segundo archivo de registro . Esto proporcionará un alivio temporal para la unidad que ha llenado su disco, pero es como tratar de reparar un pulmón perforado con una curita. Debe tratar el archivo de registro problemático directamente en lugar de simplemente agregar otro problema potencial. Además de redirigir alguna actividad de registro de transacciones a una unidad diferente, un segundo archivo de registro realmente no hace nada por usted (a diferencia de un segundo archivo de datos), ya que solo se puede usar uno de los archivos a la vez. Paul Randal también explica por qué varios archivos de registro pueden morderte más tarde .

Ser proactivo

En lugar de reducir su archivo de registro a una pequeña cantidad y dejar que crezca automáticamente a un ritmo pequeño por sí solo, configúrelo en un tamaño razonablemente grande (uno que acomode la suma de su mayor conjunto de transacciones concurrentes) y establezca un crecimiento automático razonable configurada como una alternativa, para que no tenga que crecer varias veces para satisfacer transacciones únicas y para que sea relativamente raro que alguna vez tenga que crecer durante las operaciones comerciales normales.

Los peores ajustes posibles aquí son 1 MB de crecimiento o 10% de crecimiento. Curiosamente, estos son los valores predeterminados para SQL Server (de los que me he quejado y he pedido cambios en vano ): 1 MB para archivos de datos y 10% para archivos de registro. El primero es demasiado pequeño hoy en día, y el segundo lleva a eventos cada vez más largos (digamos, su archivo de registro es de 500 MB, el primer crecimiento es de 50 MB, el siguiente crecimiento es de 55 MB, el siguiente crecimiento es de 60.5 MB , etc. etc. - y en E / S lenta, créame, realmente notará esta curva).

Otras lecturas

Por favor no pares aquí; Si bien muchos de los consejos que ve sobre la reducción de los archivos de registro son intrínsecamente malos e incluso potencialmente desastrosos, hay algunas personas que se preocupan más por la integridad de los datos que por liberar espacio en disco.

• Una publicación de blog que escribí en 2009, cuando vi algunas publicaciones de "aquí se explica cómo reducir el archivo de registro" .

• Una publicación de blog que Brent Ozar escribió hace cuatro años, señalando múltiples recursos, en respuesta a un artículo de la revista SQL Server que no debería haberse publicado .

• Una publicación de blog de Paul Randal que explica por qué el mantenimiento de t-log es importante y por qué no debe reducir sus archivos de datos tampoco .

• Mike Walsh tiene una excelente respuesta arriba, por supuesto, cubriendo algunos de estos aspectos también, incluidas las razones por las que es posible que no pueda reducir su archivo de registro de inmediato .

También puede ver el contenido de su archivo de registro. Para hacer eso, puede usar el fn_dbloglector de registros de transacciones no documentado , como ApexSQL Log .

No muestra la reorganización del índice, pero muestra todo DML y DDL varios eventos: ALTER, CREATE, DROP, disparador activar / desactivar, concesión / revocar permisos, objeto de cambio de nombre.

Descargo de responsabilidad: trabajo para ApexSQL como ingeniero de soporte

Este es el problema más frecuente para casi todos los DBA donde los registros crecen y llenan el disco.

• ¿Cuáles son algunas razones por las que el registro de transacciones crece tanto?

1. Transacción activa larga
2. Altas transacciones de registro como reconstrucción de índice, reorganización, inserción masiva, eliminaciones, etc.
3. Cualquier HA como Replication, Mirroring configurado que contiene el registro y no le permite liberar el espacio de registro

• ¿Por qué mi archivo de registro es tan grande?

Verifique la log_reuse_wait_descolumna c en la sys.databasestabla para saber qué impide que los registros se trunquen:

select name, log_reuse_wait_desc 
from sys.databases

• ¿Cuáles son algunas formas de evitar que ocurra este problema?

Las copias de seguridad del registro lo ayudarán a controlar el crecimiento del registro a menos que haya algo que impida que los registros se reutilicen.

• ¿Qué debo hacer cuando me encamino con la causa subyacente y quiero poner mi archivo de registro de transacciones en un tamaño adecuado?

Si ha identificado lo que realmente lo está causando, intente solucionarlo en consecuencia como se explica en la página siguiente.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

Tener copias de seguridad de registro adecuadas programadas es la mejor manera de lidiar con el crecimiento del registro a menos que sea una situación inusual.