¿Cómo terminar una transacción suspendida de SQL Server esperando IO_COMPLETION?

8

Tenemos una transacción que se ha estado ejecutando durante más de 5 horas. Nos estamos quedando sin espacio en disco. La sesión se ha cancelado pero todavía está esperando IO_COMPLETION. En realidad, wait_type acaba de cambiar a PAGEIOLATCH_EX. ¿Cómo puedo terminar la transacción suspendida de SQL Server? No me preocupa perder datos, ya que todos pueden repoblarse.

session_id: 54
STATUS: suspended
blocked by: 0
wait_type: PAGEIOLATCH_EX
Elapsed Time (in Sec): 19750.420000
open_transaction_count: 2
sql-server-2012 transaction kill Tarzán
fuente
3
Déjelo terminar ... de lo contrario, si hace un tirón rotundo de desconectar la fuente de alimentación o reiniciar el servicio del servidor sql, llevará tiempo deshacerlo. Dado que no le preocupa perder datos, ¿qué tal si restaura la base de datos desde la última copia de seguridad y luego vuelve a llenar los datos? Además, puede usar KILL 54 WITH STATUSONLYpara averiguar cuánto tiempo llevará la reversión.
Kin Shah
Ejecuté KILL 54 WITH STATUSONLY y recibí esto: SPID 54: reversión de transacción en progreso. Finalización de reversión estimada: 0%. Tiempo estimado restante: 0 segundos. No creo en la parte de 0 segundos.
Tarzán
2
La reversión es una operación de un solo subproceso, por lo que, por ejemplo, si su transacción original se ejecutó con 8 subprocesos paralelos hasta su finalización, la reversión puede demorar 8 veces más.
James Z
@Tarzan KILL .. WITH STATUSONLYno es exacto y veo tu punto. Se puede tratar Alter database .. set OFFLINE or single_User WITH ROLLBACK IMMEDIATE?
Kin Shah
2
Terminé dejándolo correr durante la noche. Finalmente terminó. Woohoo! Gracias por comentar
Tarzán

Respuestas:

1

La próxima vez que esto suceda, ejecute sp_WhoIsActive( descarga / documentación ) y vea quién está ejecutando qué y revise la lógica. Verifique si el TSQL puede optimizarse para ejecutarse más rápido o tal vez dividirlo en transacciones más pequeñas.

He tenido casos en los que el registro de transacciones de una consulta incorrecta realizada por redactores de informes, cargadores de datos, etc., haría que el registro de transacciones fuera más grande que el tamaño del archivo de datos, y generalmente es una consulta mal escrita y mal escrita que no está optimizada ni fragmentada en transacciones más pequeñas para devolver espacio libre una vez que se complete la transacción, esto también estaba en una SIMPLEbase de FULLdatos del modelo de recuperación, las bases de datos del modelo de recuperación necesitarían tener copias de seguridad del registro de transacciones completadas para permitir la reutilización del espacio del registro de transacciones de transacciones comprometidas.

El problema raíz es probablemente la consulta, por lo que determinar quién está haciendo qué y comunicarse con ellos e informar sobre el problema con sus hallazgos los presionaría para que corrijan su lógica para no acumular el espacio en el disco del servidor para esa partición del disco, con suerte es no es su lógica, pero si es así, mire la optimización de la lógica para consultar el rendimiento.

Pimp Juice IT
fuente