Simptome
Să presupunem că aveți instalat Microsoft SQL Server 2014, 2016 sau 2017. Este posibil să vă confruntați cu una sau mai multe dintre următoarele probleme:
-
Instanța SQL Server apare nereceptivă și apare o eroare "programator neelastic". Poate fi necesar să reporniți serverul pentru a-l recupera.
-
Revenirea la o tranzacție poate dura mult timp. În majoritatea cazurilor, repornirea instanței va permite bazei de date să se recupereze mult mai rapid decât revenirea. Rețineți că există mai multe motive pentru ca revenirea să dureze mult timp, consultați secțiunea "mai multe informații" de mai jos pentru detalii despre monitorizarea revenirii înainte de a încerca să reporniți.
-
Este posibil să vedeți așteaptă la spinlocks, cum ar fi SOS_OBJECT_STORE.
Rezolvare
Această problemă este remediată în următoarele actualizări cumulative pentru SQL Server:
Fiecare nouă actualizare cumulativă pentru SQL Server conține toate remedierile rapide și toate remedierile de securitate care au fost incluse în actualizarea cumulativă anterioară. Consultați cele mai recente actualizări cumulative pentru SQL Server:
Cea mai recentă actualizare cumulativă pentru SQL Server 2017
Cea mai recentă actualizare cumulativă pentru SQL Server 2016
Cea mai recentă actualizare cumulativă pentru SQL Server 2014
Informații despre pachetul de servicii pentru SQL Server
Această actualizare este remediată în următorul pachet Service Pack pentru SQL Server:
Pachetele Service Pack sunt cumulative. Fiecare pachet Service Pack nou conține toate remedierile care se află în pachetele de servicii anterioare, împreună cu orice remedieri noi. Recomandarea noastră este să aplicați cel mai recent pachet Service Pack și cea mai recentă actualizare cumulativă pentru acel pachet Service Pack. Nu trebuie să instalați un pachet de servicii anterior înainte de a instala cel mai recent pachet Service Pack. Utilizați tabelul 1 din următorul articol pentru a găsi mai multe informații despre cel mai recent pachet Service Pack și cea mai recentă actualizare cumulativă.
Cum se determină nivelul de versiune, ediție și actualizare al SQL Server și componentele sale
Mai multe informații
Există mai multe motive pentru care o revenire poate dura mult timp, cum ar fi o tranzacție lungă, un număr mare de VLFs în fișierul jurnal de tranzacții, I/O lent etc. Pentru a verifica dacă problema descrisă în acest articol este cauza principală a unui Rollback lent, vă sugerăm să utilizați următoarele tehnici pentru a monitoriza progresul operațiunii de revenire:
-
Din sys.dm_exec_requests, identificați session_id a cărui comandă este setată la "ucis/revenire" și asigurați-vă că sesiunea acumulează atât io, cât și CPU indicând progresul. Dacă IO nu se modifică, atunci poate fi un indiciu că întâmpinați problema descrisă în acest articol.
-
Interogare sys.dm_tran_database_transactions pentru a identifica starea curentă a revenirii utilizând o interogare, cum ar fi următoarele:
Selectați getdate () ca 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)
DE la sys.dm_tran_database_transactions t
ASOCIEREa sys.dm_exec_requests s PE t.transaction_id = s.transaction_id
Unde t.database_id = db_id (' <Nume bază de date') și s.session_id =<Session_id efectuarea operațiunii de revenire>
Notă:
În interogarea de mai sus,
database_transaction_next_undo_lsn este lsnul înregistrării următoare de anulat. database_transaction_begin_lsn este LSN-ul înregistrării începe pentru tranzacția din jurnalul de tranzacții.
database_transaction_next_undo_lsn ar trebui să scadă cu fiecare instantaneu al acestei interogări. Revenirea se va termina cu succes când database_transaction_next_undo_lsn ajunge la database_transaction_begin_lsn.
Scopul este să efectuați câteva instantanee ale interogării anterioare într-un interval prestabilit, apoi să utilizați Delta LSNs prelucrate în database_transaction_next_undo_lsn în intervalul respectiv și să extrapolați timpul necesar pentru a estima timpul pe care îl va lua database_transaction_next_undo_lsn pentru a ajunge la database_transaction_begin_lsn.
Dacă revenirea progresează la un tarif decent între fiecare instantaneu, vă sugerăm să permiteți revenirea să se finalizeze singur, fără a reîncepe instanța SQL Server.
Consultați următoarele articole pentru mai multe informații despre recuperarea pe termen lung:
-
SQL Server (2000, 2005, 2008): recuperare/revenire durează mai mult decât se așteaptă
-
Cum o structură de fișier jurnal poate afecta timpul de recuperare a bazei de date
-
Urmărirea progresului recuperării bazei de date utilizând informații din DMV
Stare
Microsoft a confirmat că aceasta este o problemă în produsele Microsoft enumerate în secțiunea „Se aplică la”.
Referințe
Aflați despre terminologiape care o utilizează Microsoft pentru a descrie actualizările de software.
