KB4338890 - FIX: fout 'Niet-renderende planner' en SQL Server lijkt niet te reageren in SQL Server 2014, 2016 en 2017

Van toepassing op
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)

Symptomen

Stel dat u Microsoft SQL Server 2014, 2016 of 2017 hebt geïnstalleerd.  Je kunt een of meer van de volgende problemen ondervinden:

  • Het exemplaar van SQL Server lijkt niet meer te reageren en de fout 'Niet-renderende planner' treedt op. Mogelijk moet u de server opnieuw opstarten om te herstellen.
  • Het terugdraaien van een transactie kan lang duren. In de meeste gevallen zal het opnieuw starten van het exemplaar ervoor zorgen dat de database veel sneller herstelt dan bij het terugdraaien. Houd er rekening mee dat er veel redenen zijn waarom het lang kan duren voordat een terugdraaibewerking is voltooid. Zie de sectie 'Meer informatie' hieronder voor meer informatie over het controleren van terugdraaibewerkingen voordat u probeert opnieuw op te starten.
  • Mogelijk zie je hoge wachttijden op spinlocks zoals SOS_OBJECT_STORE.

Oplossing

Dit probleem is opgelost in de volgende cumulatieve updates voor SQL Server:

Cumulatieve update 9 voor SQL Server 2017

Cumulatieve update 2 voor SQL Server 2016 SP2

Over cumulatieve updates voor SQL Server:

Elke nieuwe cumulatieve update voor SQL Server bevat alle hotfixes en alle beveiligingspatches die deel uitmaakten van de vorige cumulatieve update. Bekijk de meest recente cumulatieve updates voor SQL Server:

Meest recente cumulatieve update voor SQL Server 2017

Meest recente cumulatieve update voor SQL Server 2016

Meest recente cumulatieve update voor SQL Server 2014

Servicepackgegevens voor SQL Server

Deze update wordt opgelost in het volgende servicepack voor SQL Server:

Servicepack 3 voor SQL Server 2014

Over servicepacks voor SQL Server:

Servicepacks zijn cumulatief. Elk nieuw servicepack bevat alle correcties uit vorige servicepacks, samen met nieuwe oplossingen. Wij raden aan om het nieuwste servicepack en de meest recente cumulatieve update voor dit servicepack toe te passen. U hoeft geen eerdere servicepack te installeren voordat u het nieuwste servicepack installeert. Gebruik tabel 1 in het volgende artikel voor meer informatie over het nieuwste servicepack en de meest recente cumulatieve update.

Het versie-, editie- en updateniveau van SQL Server en de onderdelen ervan bepalen

Meer informatie

Er zijn veel redenen waarom een rollback lang kan duren, zoals een langlopende transactie, een groot aantal VLF's in het transactielogboekbestand, trage I/O, enz. Om te controleren of het probleem dat in dit artikel wordt beschreven, de oorzaak is van een trage rollback, raden we aan de volgende technieken te gebruiken om de voortgang van de rollback-bewerking te controleren:

  • Identificeer vanuit sys.dm_exec_requests de session_id waarvan de opdracht is ingesteld op "KILLED/ROLLBACK" en zorg ervoor dat de sessie zowel IO- als CPU-tijd verzamelt die de voortgang aangeeft. Als IO niet verandert, kan dit een indicatie zijn dat u het probleem ondervindt dat in dit artikel wordt beschreven.
  • Query sys.dm_tran_database_transactions om de huidige status van de rollback te bepalen met behulp van een query zoals de volgende:

Opmerking

  • SELECT getdate() als 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)
  • VAN sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<databasenaam') en s.session_id=<Session_id die de terugdraaibewerking> uitvoeren

Opmerking:

In de bovenstaande query,

database_transaction_next_undo_lsn is de LSN van de volgende record die ongedaan moet worden gemaakt. database_transaction_begin_lsn is de LSN van de beginrecord voor de transactie in het transactielogboek.

database_transaction_next_undo_lsn zou met elke momentopname van deze query kleiner moeten worden. Het terugdraaien wordt voltooid wanneer de database_transaction_next_undo_lsn database_transaction_begin_lsn bereikt.

Het doel hier is om enkele momentopnamen te maken van de vorige query binnen een vooraf bepaald interval en vervolgens de delta te gebruiken van de LSN's die binnen dat interval in database_transaction_next_undo_lsn zijn verwerkt, en de benodigde tijd te extrapoleren om een schatting te maken van de tijd die de database_transaction_next_undo_lsn nodig heeft om de database_transaction_begin_lsn te bereiken.

Als het terugdraaien tussen elke momentopname redelijk snel verloopt, raden we aan om het terugdraaien zelfstandig te voltooien zonder het SQL Server-exemplaar opnieuw te starten.

Zie de volgende artikelen voor meer informatie over langdurig herstel:

Status

Microsoft heeft bevestigd dat dit een probleem is bij de Microsoft-producten die worden vermeld in de sectie Van toepassing op.

Meer informatie

Meer informatie over de terminologie die Microsoft gebruikt om software-updates te beschrijven.