Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
SQL Server
Po automatycznym przełączeniu awaryjnym lub planowanym ręcznym przełączeniu bez utraty danych w obrębie grupy dostępności może się okazać, że czas przełączenia awaryjnego przekracza docelowy czas odzyskiwania (RTO). Lub gdy oszacujesz czas przełączania awaryjnego repliki pomocniczej z zatwierdzaniem synchronicznym (takiej jak partner automatycznego przełączania awaryjnego) przy użyciu metody opisanej w Monitor performance for Always On Availability Groups, okaże się, że przekracza on wartość RTO.
Jeśli automatyczne przełączenie awaryjne nadal nie zostało ukończone, zobacz Rozwiązywanie problemów z automatycznym przełączaniem awaryjnym w środowiskach SQL Server 2012 Always On.
Poniższe sekcje opisują typowe przyczyny czasu awarii przekraczającego RTO.
Obciążenie związane z raportowaniem uniemożliwia uruchomienie wątku redo
Wątek ponawiania ma opóźnienia z powodu rywalizacji o zasoby
Obciążenie związane z raportowaniem uniemożliwia działanie wątku redo
Wątek redo na wtórnej repliki jest blokowany przed wprowadzaniem zmian w języku definicji danych (DDL) przez długo działające zapytanie tylko do odczytu.
Wyjaśnienie
W replikach wtórnych zapytania tylko do odczytu uzyskują blokady stabilności schematu (Sch-S). Te Sch-S blokady mogą uniemożliwiać wątkowi redo uzyskanie blokad modyfikacji schematu (Sch-M), aby można było wprowadzać wszelkie zmiany DDL. Zablokowany wątek powtórek nie może stosować rekordów logów, dopóki nie zostanie odblokowany. Po odblokowaniu może nadal nadrobić do końca dziennika i umożliwić przeprowadzenie następującego po nim procesu cofania oraz przełączenia awaryjnego.
Diagnoza i rozwiązanie procesu
Gdy wątek redo jest zablokowany, generowane jest zdarzenie rozszerzone o nazwie sqlserver.lock_redo_blocked. Dodatkowo możesz zapytać DMV sys.dm_exec_request na drugiej replice, aby dowiedzieć się, która sesja blokuje wątek REDO, a potem możesz podjąć działania naprawcze. Następujące zapytanie zwraca identyfikator sesji zapytania tylko do odczytu, które blokuje wątek powtórek.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Możesz poczekać, aż obciążenie związane z raportowaniem zakończy działanie; wtedy wątek ponawiania zostanie odblokowany. Możesz też natychmiast odblokować wątek ponawiania, wykonując polecenie KILL (Transact-SQL) dla identyfikatora sesji blokującej.
Wątek redo ma opóźnienia z powodu rywalizacji o zasoby
Duże obciążenie związane z raportowaniem na replice wtórnej spowolniło jej działanie, a wątek ponawiania pozostaje w tyle.
Wyjaśnienie
Podczas stosowania rekordów dziennika na replice wtórnej wątek redo odczytuje rekordy dziennika z dysku dziennika, a następnie dla każdego rekordu dziennika odwołuje się do stron danych, aby zastosować ten rekord dziennika. Dostęp do strony może być ograniczony I/O (dostęp do fizycznego dysku), jeśli strona nie znajduje się już w puli bufora. Jeśli jest obciążenie raportowania związane z I/O, to obciążenie raportowania konkuruje o zasoby I/O z wątkiem powtórek i może spowolnić wątek powtórek.
Diagnoza i rozwiązanie procesu
Możesz użyć poniższego zapytania DMV, aby sprawdzić, jak duże jest opóźnienie wątku redo, mierząc wartość luki między last_redone_lsn a last_received_lsn.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
Jeśli wątek poprawki faktycznie pozostaje w tyle, musisz zbadać źródło pogorszenia wydajności na wtórnej replice. Jeśli wystąpi konflikt I/O w obciążeniu raportującym, możesz użyć Resource Governor do kontrolowania cykli CPU wykorzystywanych przez obciążenie raportujące do pośredniej kontroli wykonywanych cykli I/O, w pewnym stopniu. Na przykład jeśli obciążenie generowane przez raportowanie zużywa 10 procent zasobów procesora, ale jest ograniczane przez operacje we/wy, można użyć narzędzia Resource Governor, aby ograniczyć użycie procesora do 5 procent i w ten sposób zdławić obciążenie odczytem, co minimalizuje wpływ na operacje we/wy.