KB4338890 – LØSNING: «Ikke-ettergivende planlegger»-feil og SQL Server ser ut til å ikke svare i SQL Server 2014, 2016 og 2017

Gjelder for
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Symptomer

Anta at du har Microsoft SQL Server 2014, 2016 eller 2017 installert.  Du kan oppleve ett eller flere av følgende problemer:

  • SQL Server-forekomsten svarer ikke, og feilmeldingen "Ikke-avkastningsplanlegger" oppstår. Du må kanskje starte serveren på nytt for å gjenopprette.
  • Det kan ta lang tid å fullføre tilbakerullingen av en transaksjon. I de fleste tilfeller vil omstart av forekomsten tillate at databasen gjenopprettes mye raskere enn tilbakerullingen. Vær oppmerksom på at det er mange årsaker til at en tilbakerulling kan ta lang tid å fullføre. Se delen «Mer informasjon» nedenfor for mer informasjon om overvåking av tilbakerullinger før du prøver å starte på nytt.
  • Du kan se høye ventetider på spinlocks som SOS_OBJECT_STORE.

Oppløsning

Dette problemet er løst i følgende kumulative oppdateringer for SQL Server:

Kumulativ oppdatering 9 for SQL Server 2017

Kumulativ oppdatering 2 for SQL Server 2016 SP2

Om kumulative oppdateringer for SQL Server:

Hver nye kumulative oppdatering for SQL Server inneholder alle hurtigreparasjoner og alle sikkerhetsrettinger som fulgte med den forrige kumulative oppdateringen. Ta en titt på de nyeste kumulative oppdateringene for SQL Server:

Den nyeste kumulative oppdateringen for SQL Server 2017

Den nyeste kumulative oppdateringen for SQL Server 2016

Den nyeste kumulative oppdateringen for SQL Server 2014

Informasjon om oppdateringspakke for SQL Server

Denne oppdateringen er løst i følgende oppdateringspakke for SQL Server:

Service Pack 3 for SQL Server 2014

Om oppdateringspakker for SQL Server:

Oppdateringspakker er kumulative. Hver nye oppdateringspakke inneholder alle reparasjonene som finnes i tidligere oppdateringspakker, sammen med eventuelle nye reparasjoner. Vi anbefaler at du bruker den nyeste oppdateringspakken og den nyeste kumulative oppdateringen for denne oppdateringspakken. Du trenger ikke å installere en tidligere oppdateringspakke før du installerer den nyeste oppdateringspakken. Bruk tabell 1 i følgende artikkel for å finne mer informasjon om den nyeste oppdateringspakken og den nyeste kumulative oppdateringen.

Slik finner du versjonen, utgaven og oppdateringsnivået for SQL Server og komponentene

Mer informasjon

Det er mange grunner til at en tilbakerulling kan ta lang tid, for eksempel en langvarig transaksjon, et stort antall VLF-er i transaksjonsloggfilen, treg I/O osv. For å kontrollere at problemet som beskrives i denne artikkelen, er hovedårsaken til en langsom tilbakerulling, foreslår vi at følgende teknikker brukes til å overvåke fremdriften for tilbakerullingsoperasjonen:

  • Fra sys.dm_exec_requests identifiserer du session_id hvis kommando er satt til «KILLED/ROLLBACK», og sikre at økten akkumulerer både I/O- og CPU-tid, noe som indikerer fremdrift. Hvis IO ikke endres, kan det være en indikasjon på at du støter på problemet som beskrives i denne artikkelen.
  • Spørring sys.dm_tran_database_transactions identifisere den gjeldende tilstanden til tilbakerullingen ved hjelp av en spørring som følgende:

Obs!

  • VELG getdate() som 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)
  • FRA sys.dm_tran_database_transactions t
  • BLI MED sys.dm_exec_requests R
       PÅ t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Databasenavn') og s.session_id=Session_id<utføre tilbakerullingsoperasjonen>

Obs!:

I spørringen ovenfor

database_transaction_next_undo_lsn er LSN-nummeret for den neste posten som skal angres. database_transaction_begin_lsn er LSN for startposten for transaksjonen i transaksjonsloggen.

database_transaction_next_undo_lsn skal reduseres for hvert øyeblikksbilde av denne spørringen. Tilbakerullingen fullføres når database_transaction_next_undo_lsn når database_transaction_begin_lsn.

Målet her er å ta noen øyeblikksbilder av den forrige spørringen innenfor et forhåndsbestemt intervall og deretter bruke deltaet for LSN-ene som behandles i database_transaction_next_undo_lsn innenfor dette intervallet og ekstrapolere tiden det tar for å beregne tiden det vil ta for database_transaction_next_undo_lsn å nå database_transaction_begin_lsn.

Hvis tilbakerullingen går i en anstendig hastighet mellom hvert øyeblikksbilde, foreslår vi at tilbakerullingen får fullføres av seg selv uten å starte SQL Server-forekomsten på nytt.

Se følgende artikler for mer informasjon om langvarig gjenoppretting:

Status

Microsoft har bekreftet at dette er et problem i Microsoft-produktene som er oppført i delen «Gjelder for».

Kilder

Finn ut mer om terminologien som Microsoft bruker til å beskrive programvareoppdateringer.