KB4338890 – RETTELSE: Fejlen "Ikke-eftergivende planlægger" og SQL Server ser ikke ud til at svare i SQL Server 2014, 2016 og 2017

Gælder 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

Lad os antage, at du har Microsoft SQL Server 2014, 2016 eller 2017 installeret.  Du kan opleve et eller flere af følgende problemer:

  • SQL Server-forekomsten svarer ikke, og fejlen "Non-yielding Scheduler" opstår. Du skal muligvis genstarte serveren for at genoprette.
  • Det kan tage lang tid at gennemføre annullering af en transaktion. I de fleste tilfælde vil genstart af forekomsten give databasen mulighed for at genoprette meget hurtigere end annullering af opdatering. Bemærk, at der er mange grunde til, at en annullering af opdatering kan tage lang tid at fuldføre. Se afsnittet "Flere oplysninger" nedenfor for at få oplysninger om overvågning af annullering af opdateringer, før du forsøger at genstarte.
  • Du kan opleve høje ventetider på spinlåse som f.eks. SOS_OBJECT_STORE.

Løsning

Dette problem er rettet i følgende kumulative opdateringer til SQL Server:

Kumulativ opdatering 9 til SQL Server 2017

Kumulativ opdatering 2 til SQL Server 2016 SP2

Om kumulative opdateringer til SQL Server:

Hver ny kumulativ opdatering til SQL Server indeholder alle de hotfixes og alle de sikkerhedsrettelser, der fulgte med den forrige kumulative opdatering. Se de seneste kumulative opdateringer til SQL Server:

Seneste kumulative opdatering til SQL Server 2017

Seneste kumulative opdatering til SQL Server 2016

Seneste kumulative opdatering til SQL Server 2014

Servicepakkeoplysninger for SQL Server

Denne opdatering er rettet i følgende servicepakke til SQL Server:

Service Pack 3 til SQL Server 2014

Om servicepakker til SQL Server:

Servicepakker er akkumulerede. Hver ny service pack indeholder alle de rettelser, der var inkluderet i tidligere service packs, samt eventuelle nye rettelser. Vores anbefaling er at anvende den seneste servicepakke og den seneste kumulative opdatering for den pågældende servicepakke. Det er ikke nødvendigt at installere en tidligere servicepakke, før du installerer den seneste udgave. Brug tabel 1 i følgende artikel for at finde flere oplysninger om den seneste servicepakke og seneste samlede opdatering.

Sådan bestemmer du versionen, udgaven og opdateringsniveauet for SQL Server og dens komponenter

Flere oplysninger

Der er mange grunde til, at en rollback kan tage lang tid, såsom en langvarig transaktion, et stort antal VLF'er i transaktionslogfilen, langsom I/O osv. For at bekræfte, at det problem, der er beskrevet i denne artikel, er den primære årsag til en langsom annullering af opdatering, foreslår vi, at følgende metoder bruges til at overvåge status for annullering af opdatering:

  • I sys.dm_exec_requests skal du identificere den session_id, hvis kommando er indstillet til "KILLED/ROLLBACK", og sikre, at sessionen akkumulerer både IO- og CPU-tid, hvilket angiver status. Hvis IO ikke ændres, kan det være et tegn på, at du støder på det problem, der er beskrevet i denne artikel.
  • Forespørgslen sys.dm_tran_database_transactions til at identificere den aktuelle tilstand for annullering af opdatering ved hjælp af en forespørgsel som den følgende:

Bemærk

  • 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)
  • FRA sys.dm_tran_database_transactions t
  • DELTAG sys.dm_exec_requests er
       TIL t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<databasenavn') og s.session_id=<Session_id udførelse af annulleringshandlingen>

Bemærk!

I den ovenstående forespørgsel

database_transaction_next_undo_lsn er LSN for den næste plade, der skal fortrydes. database_transaction_begin_lsn er LSN for begin-posten for transaktionen i transaktionslogfilen.

database_transaction_next_undo_lsn bør være faldende for hvert øjebliksbillede af denne forespørgsel. Annullering af opdatering fuldføres, når database_transaction_next_undo_lsn når database_transaction_begin_lsn.

Målet her er at tage et par øjebliksbilleder af den forrige forespørgsel inden for et forudbestemt interval og derefter bruge deltaet for de LSN'er, der behandles i database_transaction_next_undo_lsn inden for dette interval, og ekstrapolere den tid, det tager at estimere den tid, det vil tage for database_transaction_next_undo_lsn at nå database_transaction_begin_lsn.

Hvis annulleringen af opdateringen skrider frem med en anstændig hastighed mellem hvert øjebliksbillede, foreslår vi, at annulleringen af opdateringen fuldføres af sig selv uden at genstarte SQL Server-forekomsten.

Se følgende artikler for at få mere at vide om langvarig genoprettelse:

Status

Microsoft har bekræftet, at dette er et problem i de Microsoft-produkter, der er angivet i afsnittet "Gælder for".

Referencer

Få mere at vide om den terminologi, som Microsoft bruger til at beskrive softwareopdateringer.