Síntomas
Suponga que tiene instalado Microsoft SQL Server 2014, 2016 o 2017. Es posible que experimente uno o varios de los siguientes problemas:
-
La instancia de SQL Server no se ve respondida y se produce un error de "programador inesperado". Es posible que tenga que reiniciar el servidor para recuperarlo.
-
La reversión de una transacción puede tardar mucho tiempo en completarse. En la mayoría de los casos, reiniciar la instancia permitirá que la base de datos se recupere mucho más rápido que la reversión. Tenga en cuenta que existen muchas razones por las que una reversión puede tardar mucho tiempo en completarse, consulte la sección "más información" a continuación para obtener detalles sobre la supervisión de reversiones anteriores antes de intentar reiniciar.
-
Es posible que vea esperas altas en spinlocks como SOS_OBJECT_STORE.
Resolución
Este problema se ha corregido en las siguientes actualizaciones acumulativas para SQL Server:
Cada actualización acumulativa para SQL Server contiene todas las revisiones y todas las revisiones de seguridad incluidas en la actualización acumulativa anterior. Consulte las últimas actualizaciones acumulativas para SQL Server:
Actualización acumulativa más reciente de SQL Server 2017
Información de Service Pack para SQL Server
Esta actualización se ha corregido en el siguiente Service Pack para SQL Server:
Los Service Pack son acumulativos. Cada nuevo Service Pack contiene todas las revisiones de Service Packs previos junto con revisiones nuevas. Nuestra recomendación es aplicar el último Service Pack y la actualización acumulativa más reciente para ese Service Pack. No es necesario instalar un Service Pack anterior antes de instalar el Service Pack más reciente. Use la tabla 1 del artículo siguiente para obtener más información sobre el Service Pack más reciente y la última actualización acumulativa.
Cómo determinar el nivel de versión, edición y actualización de SQL Server y sus componentes
Más información
Hay muchos motivos por los que una desinstalación puede tardar mucho tiempo, como una transacción de larga duración, una gran cantidad de VLFs en el archivo de registro de transacciones, la e/s lenta, etc. Para comprobar que el problema descrito en este artículo es la causa principal de una reversión lenta, sugerimos que se usen las siguientes técnicas para supervisar el progreso de la operación de reversión:
-
En Sys.dm_exec_requests, identifique la session_id cuyo comando esté establecido en "Killed/rollback" y asegúrese de que la sesión está acumulando tanto IO como el progreso de tiempo de CPU. Si la e/s no cambia, puede indicar que se está encontrando el problema descrito en este artículo.
-
Sys.dm_tran_database_transactions de consultas para identificar el estado actual de la reversión mediante una consulta como la siguiente:
Seleccione getDate () como CurrentTime, database_transaction_next_undo_lsn, database_transaction_begin_lsn, t.transaction_id, database_transaction_begin_time, database_transaction_log_record_count, db_name (t.database_id)
DESDE sys.dm_tran_database_transactions t
UNIRSE a sys.dm_exec_requests s EN t.transaction_id = s.transaction_id
DONDE t.database_id = db_id (' <nombrede la base de datos ') y s.session_id =<Session_id realizar la operación de reversión>
Nota:
En la consulta anterior,
database_transaction_next_undo_lsn es el LSN del siguiente registro que se va a deshacer. database_transaction_begin_lsn es el LSN del registro de inicio de la transacción en el registro de transacciones.
database_transaction_next_undo_lsn se debe reducir con cada instantánea de esta consulta. La reversión se completará correctamente cuando el database_transaction_next_undo_lsn alcance database_transaction_begin_lsn.
El objetivo aquí es tomar algunas instantáneas de la consulta anterior dentro de un intervalo predeterminado y, a continuación, usar el delta de la LSNs procesada en database_transaction_next_undo_lsn dentro de ese intervalo y extrapolar el tiempo que se necesita para estimar el tiempo que tardará la database_transaction_next_undo_lsn en alcanzar el database_transaction_begin_lsn.
Si la reversión está progresando a una tasa decente entre cada instantánea, sugerimos que la reversión se complete por sí solo sin reiniciar la instancia de SQL Server.
Consulte los artículos siguientes para obtener más información sobre la recuperación de ejecución larga:
-
Descripción del rendimiento de la recuperación en SQL Server
-
SQL Server (2000, 2005, 2008): la recuperación/reversión tarda más tiempo de lo esperado
-
Seguimiento del progreso de recuperación de la base de datos con información de DMV
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados en la sección "Se aplica a".
Referencias
Obtenga más información sobre la terminologíaque Microsoft usa para describir las actualizaciones de software.
