Una replica secondaria AlwaysOn si blocca o viene generato l'errore 3961 quando il database di AlwaysOn include CLR UDT in SQL Server 2014

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 3042370
Sintomi

Si consideri lo scenario seguente:
  • Si attiva la funzionalità di disponibilità AlwaysOn in Microsoft SQL Server 2014.
  • Il database di AlwaysOn include il tipo di dati definito dall'utente di common language runtime (CLR) (dall'utente UDT). Inoltre, l'UDT CLR stesso esiste in più di un database.
  • Si esegue una query che coinvolge più database che hanno l'UDT CLR.
In questo scenario, si verifica un errore di violazione di accesso sulla replica secondaria e l'istanza di SQL Server si blocca con il seguente messaggio nel log degli errori di SQL Server:
2015-02-17 13:07:36.85 spid27s arresto del database a causa dell'eccezione 2905 durante il commit di elaborazione di VLR.

2015-02-17 13:07:36.85 spid27s errore: 3449, gravità: 21, stato: 17-02-1.2015 spid27s 13:07:36.85 necessario arrestare SQL Server per recuperare un database (database ID 2). Il database è un database di utente potrebbe non essere chiuso o un database di sistema. Riavviare SQL Server. Se il database non riesce a ripristinare dopo l'avvio di un altro, riparare o ripristinare il database.
Inoltre, è visualizzato il seguente messaggio di errore nel database secondario di replica e l'errore non scomparirà solo dopo il riavvio di SQL Server:
Msg 3961, livello 16, stato 1, riga 3
Transazione di isolamento non riuscita nel database di snapshot 'DatabaseName>' perché l'oggetto a cui accede l'istruzione è stato modificato mediante un'istruzione DDL in un'altra transazione concorrente dall'avvio dell'operazione. Esso non è consentita perché i metadati non sono una versione. Un aggiornamento simultaneo ai metadati può comportare un'incoerenza se miscelati con isolamento dello snapshot.


Risoluzione

Informazioni sull'aggiornamento cumulativi

Il problema è stato innanzitutto corretto nell'aggiornamento cumulativo seguente di SQL Server.

Raccomandazioni: Installare l'aggiornamento cumulativo più recente per SQL Server
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutte le correzioni di protezione che sono stati incluse nell'aggiornamento cumulativo precedente. Si consiglia di scaricare e installare aggiornamenti cumulativi per SQL Server:

Informazioni sull'aggiornamento

Per risolvere questo problema, applicare l'aggiornamento KB 3043788: Un pacchetto di aggiornamento su richiesta hotfix è disponibile per SQL Server 2014.
Status
Microsoft ha confermato che questo è un problema nei prodotti Microsoft elencati nella sezione "Si applica a".

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 3042370 - Ultima revisione: 06/25/2015 06:45:00 - Revisione: 3.0

Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Service Pack 1

  • kbqfe kbfix kbsurveynew kbexpertiseadvanced kbmt KB3042370 KbMtit
Feedback