KB2938828 CORRECCIÓN: La creación de reflejo de la base de datos alcanza la aserción y la sesión de creación de reflejos muestra un estado suspendido en SQL Server 2012 o SQL Server 2014

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

Síntomas

Cuando se utiliza la creación de reflejo de bases de datos en Microsoft SQL Server 2012 o Microsoft SQL Server 2014, puede alcanzar una condición de aserción y la creación de reflejo de la base de datos entra en estado suspendido.

Causa

El problema se produce porque, al asignar una nueva página, SQL Server obtiene un bloqueo X en la nueva página. SQL Server colocará el hobt_id (identificador de montón o árbol B) al que pertenece la nueva página en la solicitud de bloqueo. Sin embargo, SQL Server no puede colocar el hobt_id en el registro de creación de reflejos y da como resultado un comportamiento de bloqueo diferente entre el principal y el reflejo.

Esto se puede explicar en detalle de la siguiente manera:

  1. Mantenga presionado un bloqueo IX en la página P1.
  2. T2 hacer una división de página en P1, asignar una nueva página P2, aquí se usa una TX de transacción del sistema, que mantiene un bloqueo X en P2. Aquí SQL Server no puso el hobt_id en el registro de duplicación.
  3. TX realiza una migración de bloqueo para T1 para mover el bloqueo IX de P1 a P2.
  4. TX confirmado, ahora T2 puede usar la página P2 y T2 obtener otro bloqueo IX en la página P2.
  5. T1 confirmado, ahora T2 es el único que tiene un bloqueo IX en P2.
  6. Después de muchas inserciones, se produce una escalación de bloqueo, en el primario, T2 libera el IX en P2, pero en el espejo, durante la escalación de bloqueo, T2 no liberó el bloqueo IX.
  7. Después de muchas eliminaciones, la página P2 quedó vacía y se desasignó.
  8. T3 necesita una nueva página, y resulta asignar P2, esto requiere un bloqueo X, pero en el reflejo, este paso falló debido al paso 6.

En el espejo, el paso 6 no libera el bloqueo IX porque el hobt_id en el bloque de bloqueo es incorrecto. Este hobt_id incorrecto se produce durante el paso 2 y, debido a SQL Server, no coloca el hobt_id en el registro de creación de reflejos.
Normalmente no ve ningún problema porque la transmisión en el paso 2 es muy corta y el bloque de bloqueo con hobt_id incorrecto se liberará cuando se confirme. Sin embargo, debido a la migración de bloqueos en el paso 3 y los pasos siguientes (4 y 5), este bloque de bloqueo con hobt_id incorrecto se conserva y finalmente causa el problema.
La principal no tiene este problema porque usa un hobt_id correcto en el paso 2. Pero la entrada de registro no tiene hobt_id correcta.

Resolución

Este problema se corrigió por primera vez en la siguiente actualización acumulativa de SQL Server.

Actualización acumulativa 1 para SQL Server 2014 /en-us/help/2931693

Actualización acumulativa 9 para SQL Server 2012 SP1 /en-us/help/2931078

Acerca de las actualizaciones acumulativas para SQL Server

Cada nueva actualización acumulativa para SQL Server contiene todas las revisiones y correcciones de seguridad que se incluyeron con la actualización acumulativa anterior. Consulte las actualizaciones acumulativas más recientes para SQL Server:

      

Solución alternativa

Para solucionar el problema, reinicialice el reflejo para finalizar el estado suspendido.

Estado

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