Znaki
Recimo, da imate nameščen Microsoft SQL Server 2014, 2016 ali 2017. Naletite lahko na eno ali več od teh težav:
- Primerek strežnika SQL Server se ne odziva in prikaže se napaka »Non-yielding Scheduler«. Za obnovitev boste morda morali znova zagnati strežnik.
- Povrnitev prejšnjega stanja transakcije lahko traja dalj časa. V večini primerkov s ponovnim zagonom primerka omogočite obnovitev zbirke podatkov veliko hitreje kot povrnitev prejšnjega stanja. Upoštevajte, da obstaja veliko razlogov, zakaj lahko traja povrnitev prejšnjega stanja dolgo. V razdelku »Več informacij« spodaj najdete podrobnosti o spremljanju povrnitev prejšnjega stanja pred poskusom ponovnega zagona.
- Morda boste videli veliko čakanj na spinlockih, kot je SOS_OBJECT_STORE.
Rešitev
Ta težava je odpravljena v naslednjih zbirnih posodobitvah za SQL Server:
Zbirna posodobitev 9 za SQL Server 2017
Zbirna posodobitev 2 za SQL Server 2016 SP2
O zbirnih posodobitvah za SQL Server:
Vsaka nova zbirna posodobitev za SQL Server vsebuje vse sprotne in varnostne popravke, ki so bili vključeni v prejšnjo zbirno posodobitev. Oglejte si najnovejše zbirne posodobitve za SQL Server:
Najnovejša zbirna posodobitev za SQL Server 2017
Najnovejša zbirna posodobitev za SQL Server 2016
Najnovejša zbirna posodobitev za SQL Server 2014
Informacije o servisnem paketu za SQL Server
Ta posodobitev je popravljena v tem servisnem paketu za SQL Server:
Servisni paket SP3 za SQL Server 2014
O servisnih paketih za SQL Server:
Servisni paketi so zbirni. V vsakem novem servisnem paketu so vsi popravki, ki so na voljo v prejšnjih servisnih paketih, skupaj z morebitnimi novimi popravki. Priporočamo, da za ta servisni paket uporabite najnovejši servisni paket in najnovejšo zbirno posodobitev. Pred namestitvijo najnovejšega servisnega paketa vam ni treba namestiti prejšnjega servisnega paketa. Če želite poiskati več informacij o najnovejšem servisnem paketu in najnovejši zbirni posodobitvi, si oglejte tabelo 1 v naslednjem članku.
Kako določiti različico, izdajo in raven posodobitve za SQL Server in njegove komponente
Obstaja veliko razlogov, zakaj lahko povrnitev prejšnjega stanja traja dlje časa, kot so dolgotrajna transakcija, veliko število VLF v transakcijski dnevniški datoteki, počasni V/I itd. Če želite preveriti, ali je težava, opisana v tem članku, temeljni vzrok počasne povrnitve prejšnjega stanja, vam priporočamo, da za spremljanje napredka postopka povrnitve prejšnjega stanja uporabite naslednje tehnike:
- Na sys.dm_exec_requests določite session_id, katerih ukaz je nastavljen na »KILLED/ROLLBACK«, in se prepričajte, da seja zbira tako IO kot CPE, ki označuje napredek. Če se IO ne spreminja, je to lahko znak, da ste naleteli na težavo, opisano v tem članku.
- sys.dm_tran_database_transactions poizvedbe, če želite določiti trenutno stanje povrnitve prejšnjega stanja s poizvedbo, podobno tej:
Opomba
- SELECT getdate() as CurrentTime, database_transaction_next_undo_lsn,database_transaction_begin_lsn,t.transaction_id,database_transaction_begin_time,database_transaction_log_record_count,db_name(t.database_id)
- OD sys.dm_tran_database_transactions T
- PRIDRUŽITE sys.dm_exec_requests S
ON t.transaction_id=s.transaction_id - WHERE t.database_id=db_id('<Ime zbirke podatkov') in s.session_id=<Session_id izvajanje postopka> povrnitve prejšnjega stanja
Opomba:
V zgornji poizvedbi
database_transaction_next_undo_lsn je LSN naslednjega zapisa, ki ga morate razveljaviti. database_transaction_begin_lsn je LSN začetnega zapisa za transakcijo v transakcijskem dnevniku.
database_transaction_next_undo_lsn bi se moral z vsakim posnetkom te poizvedbe zmanjševati. Povrnitev prejšnjega stanja bo uspešno dokončana, ko database_transaction_next_undo_lsn doseže database_transaction_begin_lsn.
Cilj je ustvariti nekaj posnetkov prejšnje poizvedbe v vnaprej določenem intervalu in nato uporabiti delto številk LSN, obdelanih v database_transaction_next_undo_lsn znotraj tega intervala, ter ekstrapolirati čas, ki je potreben, da ocenimo čas, potreben, da database_transaction_next_undo_lsn doseže database_transaction_begin_lsn.
Če povrnitev prejšnjega stanja med posameznimi posnetki napreduje dostojno hitro, priporočamo, da se povrnitev prejšnjega stanja dokonča samostojno brez vnovičnega zagona primerka SQL Server.
Če želite več informacij o dolgotrajni obnovitvi, si oglejte spodnje članke:
- Razumevanje učinkovitosti obnovitve v SQL Server
- SQL Server (2000, 2005, 2008): Obnovitev/povrnitev prejšnjega stanja traja dlje kot pričakovano
- Kako lahko struktura dnevniške datoteke vpliva na čas obnovitve zbirke podatkov
- Sledenje napredka obnovitve zbirke podatkov z uporabo informacij iz DMV
Stanje
Microsoft je potrdil, da gre za težavo v Microsoftovih izdelkih, ki so navedeni v razdelku »Velja za«.
Sklici
Preberite več o terminologiji, ki jo Microsoft uporablja za opisovanje posodobitev programske opreme.