Síntomas
Imagine la siguiente situación:
-
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 sucesiva.
-
Ha aplicado una de las siguientes actualizaciones a la instalación de SQL Server:
-
Actualización acumulativa 5 de SQL Server 2014
-
Actualización acumulativa 4 de Service Pack 2 de SQL Server 2012
-
Actualización acumulativa 3 del Service Pack 2 de SQL Server 2012
Importante El hotfix que se menciona en este artículo reemplaza estas actualizaciones acumulativas. No instale estas actualizaciones si todavía no lo ha hecho.
-
-
Para finalizar la instalación de la actualización acumulativa, debe reiniciar esta réplica secundaria.
-
Se conmuta por error el grupo de disponibilidad que está transformando 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".
-
Cuando consulta sys.dm_exec_requests, observa un bloqueo intermitente entre sesiones de usuario y una sesión cuyo comando se ha notificado como "DB_STARTUP". También puede advertir que hay bloqueo entre el punto de control y los comandos de DB_STARTUP .
-
Los interbloqueos relacionados con la sesión que ha recuperado una de sus bases de datos de disponibilidad se muestran en el registro de errores de SQL Server. Estos registros tienen un aspecto similar al siguiente: <date/time> spid<xx> Recovery is writing a checkpoint in database <dbname/dbid>. This isan informational message only. No user action is required.<date/time> spid<xx> Recovery completed for database <dbname/dbid> in <x> second(s) (analysis<x> ms, redo <x> ms, undo <x> ms.) This is an informational message only. No user action is required.…<date/time> spid<xx> Error: 1205, Severity: 13, State: 28.<date/time> spid<xx> Transaction (Process ID <xx>) was deadlocked on lock resources with anotherprocess and has been chosen as the deadlock victim. Rerun the transaction.
-
Si la base de datos de disponibilidad está habilitada para Microsoft SQL Server Service Broker, es posible que los mensajes de su base de datos de disponibilidad no se hayan procesado correctamente. Si inicia la herramienta de seguimiento del analizador y, a continuación, captura el evento "Broker: clasificación de mensajes", se captura el siguiente evento:
9791, el broker 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 de AlwaysOn sin experimentar este problema. Si ya ha aplicado estas actualizaciones acumulativas y no ha observado este problema, el sistema no se verá afectado y esta información no se aplica a usted.
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 evita que la lógica de revisión 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 corrección crítica a petición (c.o.d.) :
3034679 CORRECCIÓN: los grupos de disponibilidad AlwaysOn se pueden notificar como que no se SINCRONIZAnImportante Debe aplicar este Hotfix de pago contra reembolso en lugar de las siguientes actualizaciones acumulativas:
-
Actualización acumulativa 5 de SQL Server 2014
-
Actualización acumulativa 4 de Service Pack 2 de SQL Server 2012
-
Actualización acumulativa 3 del Service Pack 2 de SQL Server 2012
Nota Si ya ha aplicado estas actualizaciones acumulativas, debe seguir este procedimiento para resolver este problema.
Solución alternativa
Debido a que este problema se debe a la contención entre la sesión de usuario y la sesión de actualización con las bases de datos de disponibilidad, mientras que las bases de datos pasan al rol principal, debe eliminar esta contención para permitir que las bases de datos se recuperen de este estado. Para solucionar este problema, siga estos pasos:
-
Pruebe los métodos siguientes en el orden indicado.
Método 1: eliminar el acceso a la base de datosCuando las bases de datos experimentan los síntomas que se mencionan en la sección "síntomas", siga uno o ambos de los pasos siguientes según sea necesario para eliminar la condición de bloqueo de bloqueo:
-
Sys.dm_exec_requests de consultas para localizar las sesiones en las que se produce 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 está teniendo 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 de la aplicación y el acceso de los usuarios siguen deshabilitados, reinicie la instancia de SQL Server que hospeda las bases de datos de disponibilidad afectadas. Para ello, siga estos pasos:
-
Deshabilitar la conmutación por error automática del grupo de disponibilidad.
-
Reinicie la instancia afectada de SQL Server que hospeda la réplica principal.
-
Habilitar la conmutación por error automática del grupo de disponibilidad.
-
-
Una vez que las bases de datos afectadas se recuperen por completo, vuelva a establecer la conectividad de usuarios y aplicaciones.
Estado
Microsoft ha confirmado que se trata de un problema de los productos de Microsoft enumerados en la sección "Se aplica a".
Referencias
Para obtener más información sobre las actualizaciones acumulativas que se ven afectadas por este problema, consulte los artículos siguientes de Microsoft Knowledge Base:
