KB2938828 — poprawka: dublowanie bazy danych wskazuje stan potwierdzenia, a sesja dublowania pokazuje stan wstrzymania w SQL Server 2012 lub SQL Server 2014

Dotyczy
SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Standard SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Objawy

Podczas używania klonowania bazy danych w programie Microsoft SQL Server 2012 lub Microsoft SQL Server 2014 możesz napotkać warunek assert i klonowanie bazy danych przejdzie do stanu wstrzymania.

Przyczyna

Ten problem występuje, ponieważ podczas przydzielania nowej strony program SQL Server uzyskuje blokadę X na nowej stronie. SQL Server umieści hobt_id (stertę lub identyfikator drzewa B), do której należy nowa strona, w żądaniu blokady. Jednak SQL Server nie może umieścić hobt_id w dzienniku dublowania i powoduje inne zachowanie blokady między serwerem podstawowym a lustrzanym.

Można to szczegółowo wyjaśnić w następujący sposób:

  1. T1 przytrzymaj blokadę IX na stronie P1.
  2. T2 wykonaj podział strony na P1, przydziel nową stronę P2, transakcja systemowa TX jest tutaj używana, posiada blokadę X na P2. W tym przypadku SQL Server nie umieścił hobt_id w dzienniku dublowania.
  3. TX wykonuje migrację blokady dla T1, aby przenieść blokadę IX z P1 do P2.
  4. TX, teraz T2 może korzystać ze strony P2, a T2 uzyskać kolejną blokadę IX na stronie P2.
  5. T1 zatwierdzony, teraz T2 jest jedynym, który posiada blokadę IX na P2.
  6. Po wielu włożeniach następuje eskalacja blokady, na głównej T2 zwalnia IX na P2, ale na lustrze, podczas eskalacji blokady, T2 nie zwalnia blokady IX.
  7. Po wielu usunięciach strona P2 stała się pusta i została cofnięta alokacja.
  8. T3 potrzebuje nowej strony i zdarza się, że przydzielisz P2, co wymaga blokady X, ale w kopii lustrzanej ten krok nie powiódł się z powodu kroku 6.

Na lustrze Krok 6 nie zwalnia blokady IX, ponieważ hobt_id w bloku blokady jest nieprawidłowy. Ta niepoprawna hobt_id pojawia się w kroku 2 i SQL Server nie umieszcza hobt_id w dzienniku dublowania.
Zazwyczaj nie widzisz żadnego problemu, ponieważ TX w kroku 2 jest bardzo krótki, a blok blokady z nieprawidłowym hobt_id zostanie zwolniony podczas zatwierdzania. Jednak ze względu na migrację blokady w kroku 3 i kolejnych krokach (4 i 5) ten blok blokady z nieprawidłowym hobt_id jest zachowywany i ostatecznie powoduje problem.
Podstawowego problemu nie ma, ponieważ w kroku 2 jest używany prawidłowy hobt_id. Jednak rekord dziennika nie ma poprawnych hobt_id.

Rozwiązanie

Ten problem został po raz pierwszy rozwiązany w następującej aktualizacji zbiorczej programu SQL Server.

Aktualizacja zbiorcza 1 dla systemu SQL Server 2014 /pl-pl/pomoc/2931693

Aktualizacja skumulowana 9 dla SQL Server 2012 z dodatkiem Service Pack 1 /en-us/help/2931078

Informacje o aktualizacjach zbiorczych dla programu SQL Server

Każda nowa aktualizacja zbiorcza programu SQL Server zawiera wszystkie poprawki zabezpieczeń uwzględnione w poprzedniej aktualizacji skumulowanej. Sprawdź najnowsze aktualizacje zbiorcze dla programu SQL Server:

      

Obejście

Aby obejść ten problem, zainicjuj ponownie kopię lustrzaną w celu zakończenia stanu wstrzymania.

Stan

Firma Microsoft potwierdziła, że jest to problem dotyczący produktów firmy Microsoft wymienionych w sekcji „Dotyczy”.