Błąd asercji na serwerze dublowania podczas korzystania z architektury dublowania SQL Server

W tym artykule omówiono błąd asercji SQL Server firmy Microsoft, który może wystąpić na serwerze partnerskim podczas korzystania z architektury dublowania SQL Server.

Oryginalna wersja produktu: SQL Server 2014, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008
Oryginalny numer KB: 2729953

Symptomy

W SQL Server architektury dublowania może wystąpić błąd sprawdzania asercji SQL Server na serwerze partnera (dublowania). W takim przypadku sprawdź dziennik błędów SQL Server, aby uzyskać szczegółowe informacje. W dzienniku znajdziesz komunikat o błędzie podobny do poniższego komunikatu. Ten błąd zwykle oznacza, że należy ponownie skompilować parę dublowania.

SQL Server Assertion: File: loglock.cpp, line=834 Failed Assertion = 'result == LCK_OK' . Ten błąd może być związany z chronometrażem. Jeśli błąd będzie się powtarzać po ponownym uruchomieniu instrukcji, użyj DBCC CHECKDB, aby sprawdzić integralność strukturalną bazy danych, lub uruchom ponownie serwer, aby upewnić się, że struktury danych w pamięci nie są uszkodzone.

Błąd: 3624, ważność: 20, stan: 1.

Zazwyczaj niepowodzenie asercji jest spowodowane usterką oprogramowania lub uszkodzeniem danych. Aby sprawdzić, czy nie ma uszkodzenia bazy danych, rozważ uruchomienie polecenia DBCC CHECKDB. Jeśli wyrażasz zgodę na wysyłanie zrzutów do firmy Microsoft podczas instalacji, minidump zostanie wysłany do firmy Microsoft. Aktualizacja może być dostępna od firmy Microsoft w najnowszym dodatku Service Pack lub w interfejsie QFE z pomocy technicznej.

Uwaga

W przypadku wystąpienia tego problemu w folderze dziennika błędów SQL Server jest generowany plik minidump. Ten plik ma nazwę podobną do nazwy pliku SQLDumpnnnn.mdmp .

Przyczyna

Ten problem może wystąpić w różnych scenariuszach. Każdy scenariusz ma inną przyczynę i rozwiązanie, a każdy scenariusz może powodować ten sam komunikat o błędzie i niepowodzenie asercji.

Uwaga

• Chociaż sygnatura błędu wydaje się być bardzo specyficzna, rzeczywisty błąd jest spowodowany przez potwierdzenie, które nie powiodło się. Na przykład błąd może być spowodowany przez potwierdzenie, które wykonuje proaktywne sprawdzanie kodu SQL Server, który sprawdza, czy warunki dobrej kondycji nie powiodą się tak czysto, jak to możliwe, zamiast powodować awarię w całym procesie.
• Nie można łatwo określić rzeczywistej przyczyny. Przyczynę zwykle określa dział pomocy technicznej firmy Microsoft. Zwykle odbywa się to przez zebranie pliku pełnej kopii zapasowej głównej bazy danych i kopii zapasowych dziennika transakcji, które obejmują czas wystąpienia problemu. Ponadto do odtworzenia problemu w określonych ustawieniach może być wymagany pełny plik zrzutu procesu dublowania.

Rozwiązanie

Aby rozwiązać ten problem, uzyskaj najnowszą poprawkę dla swojej wersji SQL Server. Aby uzyskać więcej informacji, zapoznaj się z poniższą tabelą.

Przyczyna	Artykuł z bazy wiedzy	Po raz pierwszy naprawiono w
Różne zachowanie blokady między podstawowym i dublowaniem	2938828 POPRAWKA: dublowanie bazy danych powoduje potwierdzenie, a sesja dublowania pokazuje stan wstrzymania w SQL Server 2012 r. lub SQL Server 2014 r.	2931693 aktualizacja zbiorcza 1 dla SQL Server 2014 r. 2931078 aktualizacji zbiorczej 9 dla SQL Server 2012 r. z dodatkiem SP1
Wstawianie zbiorcze /BCP z Check_Constraints WYŁĄCZONE		SQL Server 2012
Zmiana kluczy szyfrowania: klucz główny bazy danych, klucz główny wystąpienia serwera		SQL Server 2012

Uwaga

• W poprzedniej tabeli ostatnia kolumna zawiera tylko pierwszą kompilację zawierającą poprawkę. Ponieważ kompilacje SQL Server są zbiorcze, późniejsze kompilacje, takie jak SQL Server 2014 z dodatkiem SP1, zawierają te poprawki. Jednak te kompilacje nie są wymienione w tabeli.
• Aby uzyskać więcej informacji na temat uzyskiwania najnowszego dodatku Service Pack dla swojej wersji SQL Server, zobacz Określanie wersji, wersji i poziomu aktualizacji. Scenariusz wstawiania zbiorczego/BCP jest typowym scenariuszem, który pozostaje bez poprawek dla SQL Server 2008 i SQL Server 2008 R2 i jest to najbardziej prawdopodobna znana przyczyna lck_ok asercji w tych wersjach. Problem został po raz pierwszy rozwiązany w SQL Server 2012 roku. Przyczyną braku rozwiązania tego problemu we wcześniejszych wersjach jest to, że wymaga ono ponownej architektury SQL Server wewnętrznych dzienników transakcji. Taka zmiana może być uwzględniona tylko w wersji głównej SQL Server.

Zobacz też

Asercja podczas wykonywania operacji wstawiania zbiorczego lub BCP