KB4338890 - OPRAVA: Chyba "Non-yielding Scheduler" a SQL Server se zdá, že nereaguje v SQL Server 2014, 2016 a 2017

Platí pro
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)

Příznaky

Předpokládejme, že máte nainstalovaný Microsoft SQL Server 2014, 2016 nebo 2017.  Může se vyskytnout jeden nebo více z následujících problémů:

  • Zdá se, že instance SQL Serveru nereaguje a dojde k chybě Nepoddajný plánovač. K obnovení může být nutné restartovat server.
  • Vrácení transakce zpět může trvat dlouhou dobu. Ve většině případů restartování instance umožní obnovení databáze mnohem rychleji než vrácení. Všimněte si, že existuje mnoho důvodů, proč může dokončení vrácení zpět trvat dlouhou dobu. Podrobnosti o monitorování vrácení zpět před pokusem o restartování najdete v části "Další informace" níže.
  • U spinlocků, jako je SOS_OBJECT_STORE, můžete zaznamenat dlouhé čekání.

Řešení

Tento problém je opravený v následujících kumulativních aktualizacích pro SQL Server:

Kumulativní aktualizace 9 pro SQL Server 2017

Kumulativní aktualizace 2 pro SQL Server 2016 SP2

Informace o kumulativních aktualizacích pro SQL Server:

Každá nová kumulativní aktualizace pro SQL Server obsahuje všechny opravy hotfix a všechny opravy zabezpečení, které byly součástí předchozí kumulativní aktualizace. Podívejte se na nejnovější kumulativní aktualizace pro SQL Server:

Nejnovější kumulativní aktualizace pro SQL Server 2017

Nejnovější kumulativní aktualizace pro SQL Server 2016

Nejnovější kumulativní aktualizace pro SQL Server 2014

Informace o aktualizacích Service Pack pro SQL Server

Tato aktualizace je opravená v následující aktualizaci Service Pack pro SQL Server:

Service Pack 3 pro SQL Server 2014

Informace o aktualizacích Service Pack pro SQL Server:

Aktualizace Service Pack jsou kumulativní. Každá nová aktualizace Service Pack obsahuje všechny opravy z předchozích aktualizací Service Pack společně s novými opravami. Doporučujeme použít nejnovější aktualizaci Service Pack a nejnovější kumulativní aktualizaci pro tuto aktualizaci Service Pack. Před instalací nejnovější aktualizace Service Pack není nutné instalovat předchozí aktualizaci Service Pack. Další informace o nejnovější aktualizaci Service Pack a nejnovější kumulativní aktualizaci najdete v tabulce 1 v následujícím článku.

Jak zjistit verzi, edici a úroveň aktualizace SQL Server a jeho součástí

Další informace

Existuje mnoho důvodů, proč může rollback trvat dlouhou dobu, jako je dlouhotrvající transakce, velký počet VLF v souboru transakčního protokolu, pomalé I/O atd. Pokud chcete ověřit, že problém popsaný v tomto článku je hlavní příčinou pomalého vrácení zpět, doporučujeme použít následující techniky ke sledování průběhu operace vrácení zpět:

  • Z sys.dm_exec_requests identifikujte session_id, jehož příkaz je nastavený na "KILLED/ROLLBACK", a ujistěte se, že relace shromažďuje čas vstupně-výstupních operací i času procesoru, který indikuje průběh. Pokud se IO nemění, může to znamenat, že jste narazili na problém popsaný v tomto článku.
  • Dotazem sys.dm_tran_database_transactions zjistit aktuální stav vrácení zpět pomocí dotazu, jako je tento:

Poznámka

  • 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)
  • OD sys.dm_tran_database_transactions
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Název databáze') a s.session_id=<Session_id provedení operace> vrácení zpět

Poznámka:

Ve výše uvedeném dotazu:

database_transaction_next_undo_lsn je LSN dalšího záznamu, který se má vrátit zpět. database_transaction_begin_lsn je LSN počátečního záznamu transakce v transakčním protokolu.

database_transaction_next_undo_lsn by se měly s každým snímkem tohoto dotazu snižovat. Vrácení změn se úspěšně dokončí, jakmile database_transaction_next_undo_lsn dosáhne database_transaction_begin_lsn.

Cílem je pořídit několik snímků předchozího dotazu v předem určeném intervalu a pak použít rozdíl LSN zpracovaných v database_transaction_next_undo_lsn v tomto intervalu a extrapolovat čas, který zabral, aby bylo možné odhadnout, jak dlouho bude trvat, než se database_transaction_next_undo_lsn dostane na database_transaction_begin_lsn.

Pokud vrácení zpět postupuje slušnou rychlostí mezi jednotlivými snímky, doporučujeme, aby se vrácení zpět dokončilo samo bez restartování instance SQL Server.

Další informace o dlouhotrvajícím obnovení najdete v následujících článcích:

Stav

Společnost Microsoft potvrdila, že se jedná o problém produktů Microsoft, které jsou uvedeny v sekci Platí pro.

Reference

Podívejte se na informace o terminologii, kterou společnost Microsoft používá k popisování aktualizací softwaru.