Problembeschreibung
Wenn Sie die Datenbankspiegelung in Microsoft SQL Server 2012 oder Microsoft SQL Server 2014 verwenden, können Sie eine Assert-Bedingung treffen, und die Datenbankspiegelung wechselt in den Zustand "angehalten".
Ursache
Das Problem tritt auf, weil SQL Server beim Zuweisen einer neuen Seite eine X-Sperre auf der neuen Seite erhält. In SQL Server wird die hobt_id (Heap-oder B-Struktur-ID) platziert, zu der die neue Seite in die Sperranforderung gehört. SQL Server kann die hobt_id jedoch nicht in das Spiegelungsprotokoll aufnehmen und führt zu einem unterschiedlichen Sperrverhalten zwischen dem primären und dem Spiegel. Dies kann im Detail wie folgt erläutert werden:
-
T1 halten Sie eine IX-Sperre auf Seite P1.
-
T2 eine Seite auf P1 aufteilen, eine neue Seite P2 zuweisen, eine System Transaktion TX wird hier verwendet, Sie enthält eine X-Sperre auf P2. Hier hat SQL Server die hobt_id nicht in das Spiegelungsprotokoll eingefügt.
-
TX führt eine Sperr Migration für T1 aus, um die IX-Sperre von P1 in P2 zu verschieben.
-
TX zugesichert, jetzt kann T2 die Seite P2 verwenden, und T2 erhält eine weitere IX-Sperre auf Seite P2.
-
T1 zugesichert, jetzt ist T2 die einzige Person, die eine IX-Sperre für P2 besitzt.
-
Nach vielem einfügen erfolgt eine Sperrenausweitung, während T2 auf der primären Version IX auf P2 freigibt, auf dem Spiegel aber während der Sperrenausweitung die IX-Sperre nicht aufgehoben wurde.
-
Nach vielen Löschvorgang wurde Seite P2 leer, und die Zuweisung wurde aufgehoben.
-
T3 benötigt eine neue Seite, und es erfolgt die Zuweisung von P2, dies erfordert eine X-Sperre, aber auf der Spiegelung ist dieser Schritt aufgrund von Schritt 6 nicht möglich.
In Schritt 6 wird die IX-Sperre auf dem Spiegel nicht freigegeben, da die hobt_id im Sperrblock falsch ist. Dieser fehlerhafte hobt_id tritt in Schritt 2 auf, und aufgrund von SQL Server wird die hobt_id nicht in das Spiegelungsprotokoll eingefügt. in der Regel wird kein Problem angezeigt, da der TX-Eintrag in Schritt 2 sehr kurz ist und der Sperrblock mit falscher hobt_id beim Commit freigegeben wird. Aufgrund der Sperren-Migration in Schritt 3 und den folgenden Schritten (4 und 5) wird dieser Sperrblock mit falscher hobt_id beibehalten und schließlich das Problem verursacht. Das primäre Problem tritt nicht auf, da es in Schritt 2 eine korrekte hobt_id verwendet. Der Protokolleintrag hat jedoch nicht die richtigen hobt_id.
Fehlerbehebung
Das Problem wurde zuerst im folgenden kumulativen Update von SQL Server behoben.
Kumulatives Update 1 für SQL Server 2014 /en-us/help/2931693
Kumulatives Update 9 für SQL Server 2012 SP1 /en-us/help/2931078
Jedes neue kumulative Update für SQL Server enthält alle Hotfixes und alle Sicherheitsupdates, die im vorherigen kumulativen Update enthalten waren. Schauen Sie sich die neuesten kumulativen Updates für SQL Server an:
Problemumgehung
Um das Problem zu umgehen, initialisieren Sie die Spiegelung erneut, um den angehalten-Status zu beenden.
Status
Microsoft hat bestätigt, dass es sich hierbei um ein Problem bei den in diesem Artikel genannten Microsoft-Produkten handelt.
