Symptomen
Stel dat u een AlwaysOn-beschikbaarheidsgroep (AG) hebt in SQL Server 2016 en 2017. Wanneer u een leesquery op een secundaire replica verwerkt, zijn de prestaties mogelijk veel langzamer dan de primaire replica vanwege frequente DIRTY_PAGE_TABLE_LOCK wachttijden.
Oorzaak
Dit probleem treedt op vanwege conflicten tussen de leesquery en de thread opnieuw uitvoeren en omdat de tabel is vergrendeld.
Oplossing
Deze oplossing is opgenomen in de volgende updates voor SQL Server:
Cumulatieve update 8 voor SQL Server 2017
Cumulatieve update 1 voor SQL Server 2016 Service Pack 2
Cumulatieve update 9 voor SQL Server 2016 Service Pack 1
Over SQL Server builds
Elke nieuwe build voor SQL Server bevat alle hotfixes en beveiligingspatches uit de vorige build. U wordt aangeraden de meest recente build te installeren voor uw versie van SQL Server:
Tijdelijke oplossing
U kunt dit probleem omzeilen door traceringsvlag 3459 in te schakelen met één redo-thread in plaats van een parallelle redo-thread.
Meer informatie
Wanneer alleen-lezenquery's worden uitgevoerd op een leesbare secundaire replica, proberen querythreads bewerkingen voor het opnieuw uitvoeren van logboeken toe te passen en moeten ze samenwerken met opnieuw uitvoeren worker-threads met DIRTY_PAGE_TABLE_LOCK wachttijden, die vaak kunnen worden gegenereerd en de prestaties van zowel opnieuw uitvoeren als query's kunnen vertragen als er gelijktijdige werkbelastingen voor opnieuw uitvoeren zijn. Het prestatieprobleem met betrekking tot DIRTY_PAGE_TABLE_LOCK wachttijd wordt opgelost in de cumulatieve updaterelease voor SQL Server 2016 SP en SQL Server 2017 die in dit artikel worden vermeld.
Zie het volgende blog over het redo-model en prestaties van secundaire replica van beschikbaarheidsgroep voor meer informatie.
Status
Microsoft heeft bevestigd dat dit probleem zich kan voordoen in de Microsoft-producten die worden vermeld in de sectie Van toepassing op.
Verwijzingen
Meer informatie over de terminologie die Microsoft gebruikt om software-updates te beschrijven.
