La disponibilità dei gruppi AlwaysOn potrebbe essere segnalata come NON SINCRONIZZATA dopo l'applicazione di SQL Server 2014 CU5, SQL Server 2012 SP2 CU4 o SQL Server 2012 SP2 CU3.

Sintomi

Considerare lo scenario descritto di seguito:

• Si esegue Microsoft SQL Server 2014 o Microsoft SQL Server 2012 Service Pack 2 (SP2) in un server che ospita la replica secondaria di un gruppo di disponibilità come parte di un aggiornamento a rotazione.

• È stato applicato uno degli aggiornamenti seguenti all'installazione di SQL Server:

  • Aggiornamento cumulativo 5 di SQL Server 2014

  • Aggiornamento cumulativo 4 di SQL Server 2012 Service Pack 2

  • Aggiornamento cumulativo 3 di SQL Server 2012 Service Pack 2

  Importante L'hotfix menzionato in questo articolo sostituisce questi aggiornamenti cumulativi. Non installare questi aggiornamenti se non è già stato fatto.

• Per completare l'installazione dell'aggiornamento cumulativo, riavviare questa replica secondaria.

• Viene eseguito il failover del gruppo di disponibilità che sta passando la replica secondaria aggiornata al ruolo principale.

In questo scenario, è possibile che si verifichino uno o più dei sintomi seguenti nel server in cui è in corso SQL Server e che ora ospita la replica primaria del gruppo di disponibilità:

• Le repliche secondarie vengono segnalate come "non SINCRONIZZAte".

• Quando si esegue una query sys.dm_exec_requests, si nota il blocco di blocco intermittente tra le sessioni degli utenti e una sessione il cui comando viene segnalato come "DB_STARTUP". Si può anche notare il blocco tra i comandi Checkpoint e DB_STARTUP .

• I deadlock che coinvolgono la sessione che ha recuperato uno dei database di disponibilità sono riportati nel log degli errori di SQL Server. Questi registri sono simili ai seguenti: <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.

• Se il database di disponibilità è abilitato per Microsoft SQL Server Service Broker, i messaggi nel database di disponibilità potrebbero non essere elaborati correttamente. Se si avvia lo strumento di analisi del profiler e quindi si acquisisce l'evento "Broker: Message classifica", viene acquisito l'evento seguente:

  9791, il broker è disabilitato nel database del mittente

Nota Non si tratta di un problema sistematico. Potresti essere in grado di applicare questi aggiornamenti cumulativi in una configurazione AlwaysOn senza provare questo problema. Se sono già stati applicati questi aggiornamenti cumulativi e non si è notato questo problema, il sistema non è interessato e queste informazioni non sono valide per l'utente.

Causa

Questo problema si verifica perché a volte si verifica una condizione di competizione tra i thread di sistema e le connessioni utente. In questo modo, la logica di correzione dell'aggiornamento cumulativo non consente di ottenere i blocchi necessari per completare il processo di aggiornamento.

Risoluzione

Per risolvere il problema, applicare il seguente hotfix critical su richiesta (COD) :

3034679 FIX: i gruppi di disponibilità AlwaysOn possono essere segnalati come non SINCRONIZZAtiImportante È necessario applicare questo aggiornamento rapido COD invece degli aggiornamenti cumulativi seguenti:

• Aggiornamento cumulativo 5 di SQL Server 2014

• Aggiornamento cumulativo 4 di SQL Server 2012 Service Pack 2

• Aggiornamento cumulativo 3 di SQL Server 2012 Service Pack 2

Nota Se sono già stati applicati questi aggiornamenti cumulativi, è necessario usare le operazioni seguenti per risolvere il problema.

Soluzione alternativa

Poiché questo problema è causato dal conflitto tra la sessione utente e la sessione di aggiornamento rispetto ai database di disponibilità mentre la transizione dei database al ruolo principale, è necessario eliminare questa contesa per consentire il ripristino dei database da questo stato. Per risolvere il problema, eseguire le operazioni seguenti:

1. Provare i metodi seguenti nell'ordine indicato.

   Metodo 1: eliminare l'accesso al databaseQuando i database avvertono i sintomi menzionati nella sezione "Sintomi", usare una o entrambe le operazioni seguenti, se necessario, per eliminare la condizione di blocco del blocco:

   • Query sys.dm_exec_requests per individuare le sessioni in cui il blocco blocco si verifica nei database di disponibilità. Usare l'istruzione Kill per terminare queste sessioni.

   • Disabilitare o arrestare l'applicazione che accede ai database di disponibilità.

   Se il metodo 1 non risolve il problema, vai al metodo 2.

   Metodo 2: riavviare il server host di SQL ServerQuando l'accesso dell'applicazione e l'accesso degli utenti sono ancora disabilitati, riavviare l'istanza di SQL Server che ospita i database di disponibilità interessati. A tal fine, attenersi alla seguente procedura:

   1. Disabilitare il failover automatico del gruppo di disponibilità.

   2. Riavviare l'istanza interessata di SQL Server che ospita la replica primaria.

   3. Abilitare il failover automatico del gruppo di disponibilità.

2. Dopo il ripristino completo dei database interessati, ristabilire la connettività dell'applicazione e dell'utente.

Stato

Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".

Riferimenti

Per altre informazioni sugli aggiornamenti cumulativi interessati da questo problema, vedere gli articoli della Microsoft Knowledge base seguenti:

• Pacchetto di aggiornamento cumulativo 5 per SQL Server 2014

• Aggiornamento cumulativo 4 per SQL Server 2012 SP2

• Pacchetto di aggiornamento cumulativo 3 per SQL Server 2012 SP2