SQL Server sys.databases log_reuse_wait pregunta

Question

Estaba investigando el rápido crecimiento de un registro de transacciones de SQL Server 2005 cuando descubrí que los registros de transacciones solo se truncarán correctamente, si la columna sys.databases "log_reuse_wait" está configurada en 0, lo que significa que nada impide que el registro de transacciones reutilice el espacio existente.

Un día cuando tenía la intención de hacer una copia de seguridad/truncar un archivo de registro, encontré que esta columna tenía un 4, o ACTIVE_TRANSACTION en el tempdb. Luego revisé si había alguna transacción abierta usando DBCC OPENTRAN ('tempdb') y la columna open_tran de sysprocesses. El resultado fue que no pude encontrar transacciones activas en ninguna parte del sistema.

¿La configuración de la columna log_reuse_wait es precisa? ¿Hay transacciones que no son detectables usando los métodos que describí anteriormente? ¿Me estoy perdiendo algo obvio?

Answer 1

Hm, tramposo. ¿Podría ser que la pregunta a sí mismo a sys.databases está causando la ACTIVE_TRANSACTION? En ese caso, sin embargo, debería estar en el MASTER y no en el TEMPDB.

Answer 2

Hay un par de enlaces a herramientas adicionales/referencias que se pueden utilizar para ayudar a solucionar este problema en el enlace Referencias para este video:
Managing SQL Server 2005 and 2008 Log Files

Dicho esto, la información en log_reuse_wait debe ser exacta. Probablemente haya tenido una transacción estancada o huérfana que de alguna manera no pudo detectar.

Answer 3

My answer de The Log File for Database is Full:

Tan pronto como se toma una copia de seguridad completa de la base de datos y la base de datos no está utilizando el modelo de recuperación simple, SQL Server mantiene un registro completo de todas las transacciones jamás realizadas en la base de datos. Hace esto para que, en caso de una falla catastrófica en la que pierda el archivo de datos, pueda restaurarlo hasta el punto de falla haciendo una copia de seguridad del registro y, una vez que haya restaurado una copia de seguridad de datos anterior, restaure el registro para reproducir el archivo perdido actas.

Para evitar esta acumulación, debe hacer una copia de seguridad del registro de transacciones. O bien, puede romper la cadena en el punto actual utilizando las opciones TRUNCATE_ONLY o NO_LOG de BACKUP LOG.

Si no necesita esta característica, establezca el modelo de recuperación en Simple.

Answer 4

Los datos son probablemente exactos. Lo que necesita hacer es tener una copia de seguridad de registro de transacciones regular. A diferencia de otros consejos, NO deberías utilizar la opción NO_TRUNCATE en 2005, ya que borra el registro de las transacciones comprometidas, pero no realiza una copia de seguridad.

Lo que debe hacer es realizar una copia de seguridad de registro de cola utilizando la instrucción BACKUP LOG con la opción NO_TRUNCATE. También debe aplicar registros de transacciones regulares a lo largo del día. Esto debería ayudar a mantener el tamaño bastante manejable.

Answer 5

Todavía no sé por qué estaba viendo ACTIVE_TRANSACTION en la columna sys.databases log_reuse_wait_desc - cuando no se estaban ejecutando transacciones, pero mi experiencia posterior indica que la columna log_reuse_wait para el tempdb cambia por motivos que no son muy claro, y para mis propósitos, no muy relevante.Además, he encontrado que la ejecución de DBCC OPENTRAN, o el "seleccione open_tran de sysprocess" código, es mucho menos información que el uso de las siguientes afirmaciones en la búsqueda de información de la transacción:

select * from sys.dm_tran_active_transactions 

select * from sys.dm_tran_session_transactions 

select * from sys.dm_tran_locks 

Answer 6

Here hay explicaciones de cómo log_reuse_wait_desc está trabajando :

También debemos entender cómo funciona el mecanismo de informe log_reuse_wait_desc. Da la razón por la cual el truncamiento del registro no pudo ocurrir la última vez que se intentó el truncamiento del registro. Esto puede ser confuso; por ejemplo, si ve ACTIVE_BACKUP_OR_RESTORE y sabe que no se está ejecutando una operación de copia de seguridad o restauración, esto solo significa que hubo uno ejecutándose la última vez que se intentó el truncamiento del registro.

Por lo tanto, en su caso no hay TRANSACCIÓN ACTIVA en este momento, pero fue cuando se intentó el truncamiento del registro la última vez.