sql-server - transaction - try catch sql server

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, descubrí 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.

¿Son precisas las configuraciones en la columna log_reuse_wait? ¿Hay transacciones que no son detectables usando los métodos que describí anteriormente? ¿Me estoy perdiendo algo obvio?

Answer 1

Hay un par de enlaces a herramientas / referencias adicionales que puede usar para ayudar a solucionar este problema en el enlace de Referencias para este video:
Administrar los archivos de registro de SQL Server 2005 y 2008

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

Answer 2

Hm, complicado. ¿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 3

La información es probablemente exacta. 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 4

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 claros, y para mis propósitos, no muy relevantes. Además, descubrí que ejecutar DBCC OPENTRAN, o el código "select open_tran from sysprocess", es mucho menos informativo que usar las declaraciones siguientes al buscar información de transacciones:

select * from sys.dm_tran_active_transactions

select * from sys.dm_tran_session_transactions 

select * from sys.dm_tran_locks

Answer 5

Mi respuesta de The Log File for Database está completa :

Tan pronto como realiza una copia de seguridad completa de la base de datos, y la base de datos no utiliza el modelo de recuperación Simple, SQL Server mantiene un registro completo de todas las transacciones 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 respaldando el 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 realizar 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 6

Aquí hay explicaciones sobre cómo funciona log_reuse_wait_desc:

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.

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