Los grupos de disponibilidad AlwaysOn se pueden notificar como NO SINCRONIZADOS después de aplicar SQL Server 2014 CU5, SQL Server 2012 SP2 CU4 o SQL Server 2012 SP2 CU3

Se aplica a
SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2012 Enterprise SQL Server 2012 Developer SQL Server 2012 Enterprise Core

Síntomas

Tenga en cuenta el siguiente escenario:

  • Está ejecutando Microsoft SQL Server 2014 o Microsoft SQL Server 2012 Service Pack 2 (SP2) en un servidor que hospeda la réplica secundaria de un grupo de disponibilidad como parte de una actualización gradual.

  • Ha aplicado una de las actualizaciones siguientes a la instalación de SQL Server:

    • Actualización acumulativa 5 de SQL Server 2014
    • Actualización acumulativa 4 de SQL Server 2012 Service Pack 2
    • Actualización acumulativa 3 de SQL Server 2012 Service Pack 2

    Importante La revisión que se menciona en este artículo reemplaza estas actualizaciones acumulativas. No instale estas actualizaciones si aún no lo ha hecho. 

  • Para terminar de instalar la actualización acumulativa, reinicie esta réplica secundaria.

  • Conmuta por error el grupo de disponibilidad que está realizando la transición de la réplica secundaria actualizada al rol principal.

En este escenario, puede experimentar uno o varios de los síntomas siguientes en el servidor que ejecuta SQL Server y que ahora hospeda la réplica principal de su grupo de disponibilidad:

  • Las réplicas secundarias se notifican como "NO SINCRONIZANDO".

  • Al consultar sys.dm_exec_requests, observa un bloqueo intermitente de bloqueo entre las sesiones de los usuarios y una sesión cuyo comando se notifica como "DB_STARTUP". También puede observar el bloqueo entre los comandos CHECKPOINT y DB_STARTUP.

  • Los interbloqueos relacionados con la sesión que recuperó una de las bases de datos de disponibilidad se indican en el registro de errores de SQL Server. Estos registros son similares al siguiente:

    <Fecha y hora> SPID<xx> La recuperación consiste en escribir un punto de control en la base de datos <dbname/dbid>. Esto es
    un mensaje solo informativo. No se requiere ninguna acción del usuario.
    <Fecha y hora> SPID<xx> Recuperación completada para la base de datos <DBNAME/DBID> en <x> segundo(s) (análisis
    <x> ms, rehacer <x> ms, deshacer <x> ms.) Este es un mensaje solo informativo. No se requiere ninguna acción del usuario.
    …
    <Fecha y hora> SPID<xx> Error: 1205, Gravedad: 13, Estado: 28.
    <Fecha y hora> SPID<xx> La transacción (id. de <proceso xx>) se ha interbloqueado en los recursos de bloqueo con otro
    proceso y se ha elegido como la víctima del interbloqueo. Vuelva a ejecutar la transacción.

  • Si la base de datos de disponibilidad está habilitada para Microsoft SQL Server Service Broker, es posible que los mensajes de la base de datos de disponibilidad no se procesen correctamente. Si inicia la herramienta de seguimiento del generador de perfiles y, a continuación, captura el evento "Broker:Message Classify", se captura el evento siguiente:

    9791, El intermediario está deshabilitado en la base de datos del remitente

Nota: Este no es un problema sistemático. Es posible que pueda aplicar estas actualizaciones acumulativas en una configuración AlwaysOn sin experimentar este problema. Si ya ha aplicado estas actualizaciones acumulativas y no ha observado este problema, su sistema no se ve afectado y esta información no se aplica en su caso.

Causa

Este problema se produce porque a veces se produce una condición de carrera entre los subprocesos del sistema y las conexiones de usuario. Esto impide que la lógica de aplicación de revisiones de la actualización acumulativa obtenga los bloqueos necesarios para completar el proceso de actualización.

Resolución

Para resolver este problema, aplique la siguiente revisión crítica a petición (COD):

3034679 CORRECCIÓN: es posible que se notifique que los grupos de disponibilidad AlwaysOn NO SE SINCRONIZAN
Importante: Debe aplicar esta revisión COD en lugar de las siguientes actualizaciones acumulativas:

  • Actualización acumulativa 5 de SQL Server 2014
  • Actualización acumulativa 4 de SQL Server 2012 Service Pack 2
  • Actualización acumulativa 3 de SQL Server 2012 Service Pack 2

        
Nota: Si ya ha aplicado estas actualizaciones acumulativas, debe usar la siguiente solución alternativa para resolver este problema.

Solución alternativa

Dado que este problema se debe a la contención entre la sesión de usuario y la sesión de actualización en las bases de datos de disponibilidad mientras las bases de datos realizan la transición al rol principal, debe eliminar esta contención para permitir que las bases de datos se recuperen de este estado.

Siga estos pasos para solucionar el problema:

  1. Pruebe los métodos siguientes en el orden indicado.

    Método 1: eliminar el acceso a la base de datosCuando las bases de datos experimenten los síntomas que se mencionan en la sección "Síntomas", siga uno o los dos pasos siguientes, según sea necesario, para eliminar la condición de bloqueo de bloqueo:

    • Consulte sys.dm_exec_requests para localizar las sesiones en las que se produce el bloqueo de bloqueo en las bases de datos de disponibilidad. Use la instrucción KILL para finalizar estas sesiones.
    • Deshabilite o detenga la aplicación que tiene acceso a las bases de datos de disponibilidad.

    Si el método 1 no resuelve el problema, vaya al método 2.

    Método 2: reiniciar el servidor host de SQL ServerCuando el acceso a la aplicación y el acceso del usuario sigan deshabilitados, reinicie la instancia de SQL Server que hospeda las bases de datos de disponibilidad afectadas. Para hacerlo, siga estos pasos.

    1. Deshabilite la conmutación automática por error del grupo de disponibilidad.
    2. Reinicie la instancia afectada de SQL Server que hospeda la réplica principal.
    3. Habilite la conmutación automática por error del grupo de disponibilidad.
  2. Cuando las bases de datos afectadas se recuperen por completo, restablezca la conectividad de la aplicación y del usuario.

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

Para obtener más información sobre las actualizaciones acumulativas que se ven afectadas por este problema, consulte los siguientes artículos de Microsoft Knowledge Base: