Grupos de disponibilidad AlwaysOn, pueden presentarse como no se SINCRONIZA después de aplicar SQL Server 2014 CU5, SQL Server 2012 SP2 CU4 o CU3 de SP2 de SQL Server 2012

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3033492
Síntomas

Considere el siguiente escenario:
  • Está ejecutando Microsoft SQL Server 2014 o Service Pack 2 (SP2) de Microsoft SQL Server 2012 en un servidor que aloja la réplica secundaria de un grupo de disponibilidad como parte de una actualización sucesiva.
  • Ha aplicado una de las siguientes actualizaciones para la instalación de SQL Server:
    • Actualización acumulativa 5 de SQL Server de 2014
    • Actualización acumulativa 4 de 2012 Service Pack 2 de SQL Server
    • 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.
  • La conmutación por error del grupo de disponibilidad que se está realizando la transición de la segunda réplica actualizada a la función principal.
En este escenario, puede experimentar uno o varios de los síntomas siguientes en el servidor que está ejecutando SQL Server y que aloja ahora la réplica principal de su grupo de disponibilidad:
  • Las réplicas secundarias se notifican como "No sincronizar".
  • Cuando se consulta sys.dm_exec_requests, observa intermitente traba de bloqueo entre sesiones de los usuarios y una sesión cuyo comando se notifica como "DB_STARTUP". También puede observar el bloqueo entre los comandos de punto de comprobación y DB_STARTUP .
  • Los interbloqueos que implican la sesión que recuperar una de las bases de datos de disponibilidad se notifican en el registro de errores de SQL Server. Estos registros 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 está habilitada la base de datos de disponibilidad de Microsoft SQL Server Service Broker, mensajes en la base de datos de disponibilidad pueden no procesarse correctamente. Si inicia la herramienta de traza de Profiler y capturar el evento "Mensaje de Broker: clasificar", se captura el evento siguiente:

    9791, el broker está deshabilitado en la base de datos del remitente
Nota: No es un problema sistemático. Puede aplicar estas actualizaciones acumulativas en una configuración AlwaysOn sin experimentar este problema. Si ya ha aplicado estas actualizaciones acumulativas, y no verá este problema, el sistema no se ve 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 impide que la lógica de revisión de la actualización acumulativa de la obtención de los bloqueos que son necesarios para completar el proceso de actualización.
Solución
Para resolver este problema, aplique la siguiente crítica a petición (COD) revisión:

3034679 REVISIÓN: Los grupos de disponibilidad AlwaysOn pueden aparecer como no SINCRONIZA

Importante: Debe aplicar esta revisión de Bacalao en lugar de las actualizaciones acumulativas siguientes:
  • Actualización acumulativa 5 de SQL Server de 2014
  • Actualización acumulativa 4 de 2012 Service Pack 2 de SQL Server
  • Actualización acumulativa 3 de SQL Server 2012 Service Pack 2


Nota: Si ya han aplicado estas actualizaciones acumulativas, debe utilizar la siguiente solución alternativa para resolver este problema.
Solución
Debido a este problema está causado por la contención entre la sesión de usuario y la sesión de actualización contra las bases de datos de disponibilidad durante la transición de las bases de datos a la función principal, debe eliminar esta contención para habilitar las bases de datos para recuperarse de este estado.

Para evitar este problema, siga estos pasos:
  1. Pruebe los métodos siguientes en el orden especificado.
    Método 1: Eliminar el acceso a la base de datos
    Cuando las bases de datos están experimentando los síntomas que se mencionan en la sección "Síntomas", utilice uno o ambos de los siguientes pasos según sea necesario para eliminar la condición de bloqueo de bloqueo:
    • Consulta Sys.dm_exec_requests para buscar sesiones en qué bloquear bloqueo se produce en las bases de datos de disponibilidad. Utilice el KILL instrucción para finalizar todas las sesiones.
    • Deshabilitar o detener 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 de host de SQL Server
    Cuando el acceso a las aplicaciones y el acceso de los usuarios aún están deshabilitados, reinicie la instancia de SQL Server que hospeda las bases de datos de disponibilidad afectado. Para ello, siga estos pasos:
    1. Desactivar la conmutación por error automática del grupo de disponibilidad.
    2. Reinicie la instancia de SQL Server que aloja la réplica principal afectada.
    3. Habilitar la conmutación por error automática del grupo de disponibilidad.
  2. Después de las bases de datos afectadas se recuperan por completo, restablecer 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 acerca de las actualizaciones acumulativas que se ven afectados por este problema, consulte los siguientes artículos de Microsoft Knowledge Base:

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3033492 - Última revisión: 11/14/2015 03:31:00 - Revisión: 5.0

Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2012 Service Pack 2, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise Core

  • kbsurveytest kbexpertiseadvanced kbmt KB3033492 KbMtes
Comentarios