Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:
SQL Server
Po automatickém přerušení nebo plánovaném manuálním přerušení bez ztráty dat ve skupině dostupnosti můžete zjistit, že doba překročení překročí váš cíl obnovy (RTO). Nebo když pomocí metody uvedené v Monitor performance for Always On Availability Groups odhadnete dobu převzetí služeb při selhání sekundární repliky se synchronním potvrzováním (například partnera pro automatické převzetí služeb při selhání), zjistíte, že překračuje váš cíl doby obnovení (RTO).
Pokud vaše automatické přepnutí stále nebylo dokončeno, podívejte se na Řešení problémů s automatickým přepnutím v prostředí SQL Server 2012 Always On.
Následující sekce popisují běžné příčiny doby přepnutí přesahující RTO.
Reporting workload blokuje opakovací vlákno
Vlákno redo na sekundární replice je blokováno dlouho běžícím dotazem pouze pro čtení, aby nemohl měnit jazyk pro definici dat (DDL).
Explanation
Na sekundární replikě získají dotazy pouze pro čtení zámky stability schématu (Sch-S). Tyto Sch-S zámky mohou zabránit vláknu redo v získání zámků pro změnu schématu (Sch-M), aby mohlo provádět jakékoli změny DDL. Blokované vlákno pro opětovné zpracování nemůže aplikovat záznamy v logu, dokud není odblokováno. Po odblokování může pokračovat až do konce protokolu a umožnit pokračování následného procesu vrácení změn a převzetí služeb při selhání.
Diagnóza a vyřešení
Když je redo vlákno zablokované, vygeneruje se rozšířená událost s názvem sqlserver.lock_redo_blocked. Kromě toho se můžete na sekundární replice dotázat na DMV sys.dm_exec_requests, abyste zjistili, která relace blokuje vlákno REDO, a poté můžete podniknout nápravná opatření. Následující dotaz vrátí ID relace dotazu v režimu pouze pro čtení, který blokuje vlákno redo.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Můžete nechat dokončit reportovací zátěž, kdy je vlákno redo odblokováno, nebo můžete vlákno okamžitě odblokovat spuštěním příkazu KILL (Transact-SQL) na ID blokující relace.
Vlákno Redo zaostává kvůli sporu o zdroje
Velká zátěž reportování sekundární repliky zpomalila výkon sekundární repliky a vlákno pro opakování zaostává.
Explanation
Při aplikaci záznamů protokolu na sekundární replice vlákno redo čte záznamy protokolu z disku protokolu a poté pro každý záznam přistupuje k datovým stránkám, aby daný záznam protokolu aplikovalo. Přístup ke stránce může být vázaný na I/O (přístup k fyzickému disku), pokud stránka již není v buffer poolu. Pokud je zátěž na reportování vázaná na I/O, reportovací zátěž soutěží o I/O zdroje s redo vláknem a může zpomalit redo vlákno.
Diagnóza a vyřešení
Pomocí následujícího dotazu DMV můžete zjistit, o kolik vlákno redo zaostává, a to změřením rozdílu mezi 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
Pokud je vlákno pro opakování skutečně pozadu, musíte prozkoumat hlavní příčinu zhoršení výkonu sekundární repliky. Pokud je v reportovací zátěži spor o I/O, můžete použít Resource Governor k řízení CPU cyklů, které reportovací zátěž využívá k nepřímé kontrole I/O cyklů, alespoň do určité míry. Například pokud vaše reportovací zátěž spotřebovává 10 % procesorového času, ale je omezena vstupně-výstupními operacemi, můžete pomocí Resource Governor omezit využití procesoru na 5 % a tím omezit zátěž způsobenou čtením, což minimalizuje dopad na vstupně-výstupní operace.