Simptome
Să presupunem că aveți Microsoft SQL Server 2014, 2016 sau 2017 instalat. Vă puteți confrunta cu una sau mai multe dintre următoarele probleme:
- Instanța SQL Server pare să nu răspundă și apare o eroare "Programator care nu cedează". Poate fi necesar să reporniți serverul pentru a recupera.
- Revenirea la starea anterioară a unei tranzacții poate dura mult timp. În majoritatea cazurilor, repornirea instanței va permite recuperarea bazei de date mult mai rapid decât revenirea. Rețineți că există multe motive pentru care finalizarea unei reveniri poate dura mult timp; consultați secțiunea "Mai multe informații" de mai jos pentru detalii despre monitorizarea revenirilor înainte de a încerca repornirea.
- Este posibil să vedeți așteptări mari pe spinlock-uri, cum ar fi SOS_OBJECT_STORE.
Rezolvare
Această problemă este remediată în următoarele actualizări cumulative pentru SQL Server:
Actualizarea cumulativă 9 pentru SQL Server 2017
Actualizarea cumulativă 2 pentru SQL Server 2016 SP2
Despre actualizările cumulative pentru SQL Server:
Fiecare actualizare cumulativă nouă pentru SQL Server conține toate remedierile rapide și toate remedierile de securitate care au fost incluse cu 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 pachetele Service Pack pentru SQL Server
Această actualizare este remediată în următorul pachet Service Pack pentru SQL Server:
Service Pack 3 pentru SQL Server 2014
Despre pachetele Service Pack pentru SQL Server:
Pachetele Service Pack sunt cumulative. Fiecare pachet Service Pack nou conține toate remedierile din pachetele Service Pack 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 Service Pack 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ă versiunea, ediția și nivelul de actualizare al SQL Server și al componentelor sale
Există multe motive pentru care o revenire poate dura mult timp, cum ar fi o tranzacție de lungă durată, un număr mare de VLF-uri în fișierul jurnal de tranzacții, intrări/comenzi lente etc. Pentru a verifica dacă problema descrisă în acest articol este cauza principală a unei reveniri lente, vă sugerăm să utilizați următoarele tehnici pentru a monitoriza progresul operațiunii de revenire:
- De sys.dm_exec_requests, identificați session_id a cărui comandă este setată la "KILLED/ROLLBACK" și asigurați-vă că sesiunea acumulează atât timp IO, cât și timp CPU, indicând un progres. Dacă IO nu se modifică, acest lucru poate indica faptul 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 ca următoarea:
Notă
- 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)
- FROM sys.dm_tran_database_transactions t
- ALĂTURAȚI-sys.dm_exec_requests
ON t.transaction_id=s.transaction_id - WHERE 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 LSN-ul următoarei înregistrări de anulat. database_transaction_begin_lsn este LSN al înregistrării de început pentru tranzacție din jurnalul de tranzacții.
database_transaction_next_undo_lsn ar trebui să scadă cu fiecare instantaneu al acestei interogări. Revenirea se va finaliza cu succes atunci când database_transaction_next_undo_lsn ajunge la database_transaction_begin_lsn.
Scopul aici este de a face câteva instantanee ale interogării anterioare într-un interval predeterminat, apoi de a utiliza delta a LSN-urilor procesate în database_transaction_next_undo_lsn în cadrul acelui interval și de a extrapola timpul necesar pentru a estima timpul necesar pentru ca database_transaction_next_undo_lsn să ajungă la database_transaction_begin_lsn.
Dacă revenirea se desfășoară într-un ritm decent între fiecare instantaneu, vă sugerăm să se permită ca revenirea să se efectueze singură, fără a reporni instanța SQL Server.
Consultați articolele următoare pentru mai multe informații despre recuperarea cu termen lung:
- Înțelegerea performanței recuperării în SQL Server
- SQL Server (2000, 2005, 2008): recuperarea/revenirea durează mai mult decât se aștepta
- Cum poate afecta o structură de fișier jurnal timpul de recuperare a bazei de date
- Urmărirea progresului recuperării bazei de date utilizând informațiile de la DMV
Stare
Microsoft a confirmat că aceasta este o problemă în produsele Microsoft care sunt listate în secțiunea „Se aplică la”.
Referințe
Aflați despre terminologia pe care o utilizează Microsoft pentru a descrie actualizările de software.