KB4338890: CORRECCIÓN: Error "Programador no rendto" y SQL Server no responde en SQL Server 2014, 2016 y 2017

Se aplica a
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Síntomas

Suponga que tiene instalado Microsoft SQL Server 2014, 2016 o 2017.  Puede experimentar uno o varios de los siguientes problemas:

  • La instancia de SQL Server no responde y se produce un error "Programador de rendimiento no". 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 hay 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 más información sobre la supervisión de las reversiones antes de intentar reiniciar.
  • Es posible que vea altas esperas en espines como SOS_OBJECT_STORE.

Resolución

Este problema se ha corregido en las siguientes actualizaciones acumulativas para SQL Server:

Actualización acumulativa 9 de SQL Server 2017

Actualización acumulativa 2 para SQL Server 2016 SP2

Acerca de las actualizaciones acumulativas para SQL Server:

Cada nueva actualización acumulativa de SQL Server contiene todas las revisiones y todas las correcciones de seguridad que se incluyeron con la actualización acumulativa anterior. Echa un vistazo a las últimas actualizaciones acumulativas de SQL Server:

Actualización acumulativa más reciente de SQL Server 2017

Actualización acumulativa más reciente de SQL Server 2016

Actualización acumulativa más reciente de SQL Server 2014

Información del Service Pack para SQL Server

Esta actualización se ha corregido en el siguiente Service Pack para SQL Server:

Service Pack 3 para SQL Server 2014

Acerca de los Service Pack para SQL Server:

Los Service Packs son acumulativos. Cada Service Pack nuevo contiene todas las revisiones que se incluyen en los anteriores, además de otras nuevas. Nuestra recomendación es aplicar el Service Pack más reciente y la actualización acumulativa más reciente para ese Service Pack. No necesita instalar un Service Pack anterior antes de instalar el 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 actualización acumulativa más reciente.

Cómo determinar la versión, la edición y el nivel de actualización de SQL Server y sus componentes

Más información

Hay muchas razones por las que una reversión puede tardar mucho tiempo, como una transacción de larga duración, un gran número de VLFs en el archivo de registro de transacciones, E/S lenta, etc. Para comprobar que el problema descrito en este artículo es la causa raíz de una reversión lenta, sugerimos que se usen las siguientes técnicas para supervisar el progreso de la operación de reversión:

  • Desde sys.dm_exec_requests, identifique el session_id cuyo comando se establece en "KILLED/ROLLBACK" y asegúrese de que la sesión está acumulando tiempo de IO y CPU que indica el progreso. Si IO no cambia, puede ser una indicación de que se encuentra con el problema descrito en este artículo.
  • La consulta sys.dm_tran_database_transactions para identificar el estado actual de la reversión con una consulta como la siguiente:

Nota

  • SELECT 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)
  • FROM sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Nombre de 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 inicial de la transacción en el registro de transacciones.

database_transaction_next_undo_lsn debería disminuir con cada instantánea de esta consulta. La reversión se completará correctamente cuando el database_transaction_next_undo_lsn llegue a 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 los LSN procesados en database_transaction_next_undo_lsn dentro de ese intervalo y redistribuir el tiempo tomado con el fin de estimar el tiempo que tardará la database_transaction_next_undo_lsn en llegar a la database_transaction_begin_lsn.

Si la reversión está progresando a una tasa decente entre cada instantánea, sugerimos que la reversión se pueda completar por su cuenta sin reiniciar la SQL Server instancia.

Consulte los siguientes artículos para obtener más información sobre la recuperación de larga ejecución:

Estado

Microsoft ha confirmado que se trata de un problema de los productos de Microsoft que se enumeran en la sección "Aplicable a".

Referencias

Obtenga información sobre la terminología que usa Microsoft para describir las actualizaciones de software.