Wanneer u een nieuwe database in SQL Server maakt, is de optie Statistieken automatisch bijwerken standaard ingeschakeld. Het wordt over het algemeen aanbevolen om deze optie ingeschakeld te laten. In het ideale geval worden statistieken beheerd door een geplande taak en wordt de automatische optie gebruikt als een vangnet - beschikbaar om statistieken bij te werken in het geval dat een geplande update niet plaatsvindt of per ongeluk niet alle bestaande statistieken bevat.
Sommige DBA's vertrouwen uitsluitend op automatische updates om statistieken te beheren, en zolang er geen prestatieproblemen zijn met betrekking tot verouderde of slecht gesamplede statistieken, is dit acceptabel. Als u op deze optie vertrouwt om uw statistieken te beheren, en u hebt een aantal zeer grote tabellen, kan het de moeite waard zijn om traceringsvlag 2371 te implementeren. Zoals bij elke traceringsvlag, moet u testen met een representatieve werkbelasting voordat u deze in productie implementeert. U weet misschien al dat er momenten zijn waarop een automatische update de systeemprestaties kan beïnvloeden. De update van een statistiek kan bijvoorbeeld een piek in CPU of I/O introduceren wanneer de tabel- of indexgegevens worden gelezen, evenals de uitvoering van query's vertragen terwijl de update plaatsvindt. Er is nog een andere database-optie die u kunt inschakelen om die vraagvertraging aan te pakken, en daar zal ik later in dit bericht op terugkomen.
De vraag die mij vaak wordt gesteld is:"Hoe weet je of automatische updates van statistieken veroorzaken prestatieproblemen?" Een optie is om ze te volgen en de updates te koppelen aan een verandering in de prestaties. Er zijn veel opties voor het bijhouden van updates, en in dit bericht zullen we een paar van de beschikbare methoden bespreken, zodat u de optie die het beste past bij uw bestaande methode van monitoring voor prestatieproblemen.
SQL-tracering
Als u SQL Server 2008 R2 of lager in uw omgeving gebruikt, is SQL Trace een methode die u kunt gebruiken om automatische updates vast te leggen. Het hieronder gebruikte traceerdefinitiescript legt alleen de gebeurtenis Auto Stats vast, die wordt gedetecteerd wanneer een statistiek automatisch wordt bijgewerkt en wanneer een statistiek automatisch wordt gemaakt. Nadat deze tracering een tijdje in uw omgeving heeft gelopen, kunt u deze in een tabel laden en vervolgens de uitvoer opvragen om te zien welke updates er zijn opgetreden. Het meegeleverde script hieronder laat een voorbeeld zien met behulp van de voorbeelddatabase met honkbalstatistieken.
Uitgebreide evenementen
Als u SQL Server 2012 of hoger gebruikt, raad ik u aan Extended Events te gebruiken om automatische updates vast te leggen. Net als het SQL Trace-script, legt het meegeleverde sessiedefinitiescript alleen de Auto Stats-gebeurtenissen vast - nogmaals, zowel automatisch bijwerken als automatisch maken. Nadat de XE-sessie een tijdje heeft gelopen, kunt u de uitvoer via de gebruikersinterface in een tabel laden en deze vervolgens opvragen om te zien welke updates er zijn opgetreden. Het meegeleverde script doorloopt hetzelfde voorbeeld als voorheen, maar deze keer met behulp van Extended Events om de gegevens te verzamelen.
sys.dm_db_stats_properties
Een derde optie die u zou kunnen overwegen om updates van statistieken te controleren, is de sys.dm_db_stats_properties DMF, dat alleen beschikbaar is in SQL Server 2008 R2 SP2 en hoger, en SQL Server 2012 SP1 en hoger. Hoe dol ik ook ben op deze DMF, deze oplossing is lastiger om ervoor te zorgen dat je alle gegevens hebt vastgelegd, en het beoordelen van de uitvoer kost meer werk. Met de DMF wordt elke automatische update niet bijgehouden, we updaten alleen informatie over trendstatistieken om te zien wanneer er updates plaatsvinden.
Het is een eenvoudige taak:u maakt een tabel om de statistische informatie vast te houden, en vervolgens maakt u op regelmatige basis snapshots van informatie van de DMF naar de tabel. De sleutel hier is om erachter te komen hoe vaak de gegevens moeten worden vastgelegd. Elk uur is waarschijnlijk overdreven, één keer per dag is misschien niet frequent genoeg. Ik raad aan te beginnen met een SQL Agent-taak die elke vier uur een momentopname maakt van de DMF-gegevens. Laat dat een paar dagen lopen en controleer dan je gegevens. Als de statistieken maximaal één keer per dag worden bijgewerkt, kunt u het interval verlengen tot elke acht of twaalf uur. Als statistieken gemakkelijk elke vier uur kunnen worden bijgewerkt, verlaag dan uw interval naar elke twee uur - u wilt er zeker van zijn dat u elke update vastlegt. Om deze reden geldt voor sommige systemen sys.dm_db_stats_properties is misschien niet de moeite waard; een XE-sessie of Trace is misschien eenvoudiger.
Een laatste voorbeeldscript geeft een voorbeeld van hoe u sys.dm_db_stats_properties zou gebruiken naar trendupdates voor statistieken. Houd er rekening mee dat dit script alleen statistische informatie voor één tabel vastlegt. Als je het script wijzigt om elke tabel in de database vast te leggen, zullen er veel meer gegevens zijn om te analyseren.
Volgende stappen
Download de voorbeeldscripts en beslis welke methode u moet gebruiken om statistische updates bij te houden.
Zodra u over de gegevens beschikt die aangeven wanneer automatische updates plaatsvinden, moet u die koppelen aan bekende prestatieproblemen. Als u dus geen prestatiestatistieken bijhoudt, zullen de auto-stats-updategegevens niet helpen met enige vorm van correlatie. Ervan uitgaande dat u tijdstempels heeft voor een prestatieprobleem, kunt u dit vergelijken met de StartTime en EndTime van Trace, de timestamp van XE, of last_updated van de sys.dm_db_stats_properties DMF, om te bepalen of de automatische update de systeemprestaties beïnvloedde.
Als u geen correlatie kunt maken tussen de updates en prestatieproblemen, kunt u updates uitsluiten als de oorzaak van het probleem en u op een ander gebied concentreren. Als de updates de hoofdoorzaak zijn, hebt u twee opties:schakel de optie Statistieken automatisch bijwerken uit of schakel de optie Statistieken automatisch bijwerken in. Beide hebben voor- en nadelen waar u als DBA rekening mee moet houden.
Statistieken automatisch bijwerken uitschakelen
Als u ervoor kiest om de optie voor het automatisch bijwerken van statistieken uit te schakelen, zijn de twee belangrijkste dingen om te weten:
- U moet uw statistieken absoluut beheren via een onderhoudstaak of aangepaste taak.
- Query's worden niet opnieuw gecompileerd wanneer u statistieken bijwerkt in SQL Server 2008 R2 en lager.
Ik zie het tweede item als een grotere uitdaging – ik ben een groot voorstander van het beheren van statistieken en verwacht dat DBA's dit sowieso doen. Het grotere probleem is dat, hoewel het bijwerken van statistieken normaal zorgt ervoor dat zoekopdrachten opnieuw worden gecompileerd (om te profiteren van de bijgewerkte statistieken), dit doet niet optreden wanneer u de optie statistieken automatisch bijwerken hebt uitgeschakeld. Ik heb hier eerder over geschreven en raad u aan deze informatie te lezen als u niet bekend bent met dit gedrag. Zie ook een vervolgbericht voor opties om het aan te pakken.
Over het algemeen is dit niet het pad dat ik aanbeveel. Er zijn zeer specifieke randgevallen waar dit van toepassing kan zijn, maar ik zou liever zien dat een DBA handmatige updates uitvoert (via geplande taken) om de automatische updates te vermijden, en de optie ingeschakeld laat als veiligheidsmaatregel.
Statistieken automatisch bijwerken asynchroon inschakelen
Wanneer u de optie Statistieken automatisch bijwerken asynchroon inschakelt en een statistiek ongeldig is gemaakt en een query wordt uitgevoerd die deze statistiek gebruikt, wordt de statistiek pas bijgewerkt nadat de query is voltooid - de update is asynchroon. Het voordeel hiervan is dat de update geen invloed heeft op de uitgevoerde query; het nadeel is dat de query het bestaande plan gebruikt, wat mogelijk niet langer het optimale plan is. Of het plan nog steeds optimaal is, hangt af van uw werklast (bijvoorbeeld een rapportagewerklast met langlopende query's). Als DBA moet u de voor- en nadelen van het inschakelen van deze optie afwegen en bepalen wat het beste is voor uw database. Houd er rekening mee dat als u SQL Server 2008 tot en met 2012 gebruikt, er een geheugenlek aan deze instelling is gekoppeld. Microsoft heeft wel cumulatieve updates beschikbaar die een oplossing bieden, maar als u deze nog niet hebt toegepast, staat u voor een andere beslissing:pas de CU toe zodat u de optie kunt inschakelen, of pas de CU niet toe en schakel de optie.
Samenvatting
De enige manier om te weten of automatische updates van statistieken de prestaties van query's beïnvloeden, is door een update tegelijkertijd met een probleem te zien plaatsvinden, of door vast te leggen wanneer updates plaatsvinden en de gegevens te correleren met aanvullende informatie die u vastlegt over prestatieproblemen. Met de laatste optie kunt u proactief zijn - zelfs als u geen prestatieproblemen ondervindt, is het misschien een goed idee om te weten hoe vaak automatische updates plaatsvinden. Regelmatige updates kunnen betekenen dat u de Agent-taak die handmatig statistieken beheert, opnieuw moet bezoeken. Laat in het algemeen de optie om statistieken automatisch bij te werken ingeschakeld, maar zorg voor een methode om statistieken te beheren en gebruik de optie als een vangnet.