Příznaky
Předpokládejme, že máte skupinu dostupnosti AlwaysOn v SQL Server 2016 a 2017. Při zpracování dotazu na čtení na sekundární replice může být výkon mnohem pomalejší než primární replika kvůli častému čekání DIRTY_PAGE_TABLE_LOCK.
Příčina
K tomuto problému dochází kvůli kolizím mezi dotazem pro čtení a podprocesem opakování a protože tabulka je uzamčena.
Řešení
Tato oprava je součástí následujících aktualizací pro SQL Server:
8. kumulativní aktualizace pro SQL Server 2017
Kumulativní aktualizace 1 pro SQL Server 2016 Service Pack 2
Kumulativní aktualizace 9 pro SQL Server 2016 Service Pack 1
Informace o SQL Server buildech
Každý nový build pro SQL Server obsahuje všechny opravy hotfix a opravy zabezpečení, které byly v předchozím buildu. Doporučujeme nainstalovat nejnovější build pro vaši verzi SQL Server:
Řešení
Chcete-li tento problém vyřešit, můžete místo paralelního vlákna opakování použít jedno vlákno opakování povolením příznaku trasování 3459.
Další informace
Pokud jsou dotazy jen pro čtení spuštěné na čitelné sekundární replice, vlákna dotazů se pokoušejí použít čekající operace opakování protokolu a potřebují spolupracovat s pracovními vlákny znovu s DIRTY_PAGE_TABLE_LOCK čekáním, která se dají často generovat a v případě souběžných úloh opakování i dotazů snížit výkon. Problém s výkonem související s čekáním DIRTY_PAGE_TABLE_LOCK řeší vydání kumulativní aktualizace pro SQL Server 2016 SP a SQL Server 2017 uvedené v tomto článku.
Další informace najdete na následujícím blogu o opětovném modelu a výkonu sekundární repliky skupiny dostupnosti.
Stav
Společnost Microsoft potvrzuje, že se jedná o problém v produktech této společnosti, které jsou uvedeny v části Informace v tomto článku jsou určeny pro produkt.
Odkazy
Seznamte se s terminologií , pomocí které Microsoft popisuje aktualizace softwaru.
