När du skapar en ny databas i SQL Server är alternativet Automatisk uppdatering av statistik aktiverat som standard. Det rekommenderas i allmänhet att låta detta alternativ vara aktiverat. Helst hanteras statistik av ett schemalagt jobb, och det automatiska alternativet används som ett skyddsnät – tillgängligt för att uppdatera statistik i händelse av att en schemalagd uppdatering inte inträffar, eller av misstag inte inkluderar all befintlig statistik.
Vissa DBA:er förlitar sig enbart på automatiska uppdateringar för att hantera statistik, och så länge det inte finns några prestandaproblem relaterade till inaktuell eller dåligt samplad statistik är detta acceptabelt. Om du förlitar dig på det här alternativet för att hantera din statistik, och du har några mycket stora tabeller, kan det vara värt att implementera spårningsflagga 2371. Som med alla spårningsflaggor, se till att du testar med en representativ arbetsbelastning innan du implementerar den i produktionen. Du kanske redan är medveten om att det finns tillfällen då en automatisk uppdatering kan påverka systemets prestanda. Till exempel kan uppdateringen av en statistik introducera en spik i CPU eller I/O när tabell- eller indexdata läses, samt fördröja exekveringen av frågor medan uppdateringen sker. Det finns ett annat databasalternativ du kan aktivera för att ta itu med den frågefördröjningen, och det kommer jag att ta upp senare i det här inlägget.
Frågan jag ofta får är:"Hur vet du om automatiska uppdateringar av statistik orsakar prestandaproblem?" Ett alternativ är att spåra dem och koppla uppdateringarna till en förändring i prestanda. Det finns många alternativ för att spåra uppdateringar, och i det här inlägget kommer vi att granska några av de tillgängliga metoderna så att du kan välja och sedan implementera alternativ som passar bäst med din befintliga metod för att övervaka prestandaproblem.
SQL-spårning
Om du kör SQL Server 2008 R2 eller lägre i din miljö är SQL Trace en metod som du kan använda för att fånga automatiska uppdateringar. Spårningsdefinitionsskriptet som används nedan fångar bara händelsen Auto Stats, som fångar när en statistik automatiskt uppdateras och när en statistik automatiskt skapas. Efter att denna spårning har körts ett tag i din miljö kan du ladda den i en tabell och sedan fråga utdata för att se vilka uppdateringar som inträffade. Det medföljande skriptet nedan går igenom ett exempel med hjälp av databasen för baseballstatistik.
Utökade evenemang
Om du kör SQL Server 2012 eller senare rekommenderar jag att du använder utökade händelser för att fånga automatiska uppdateringar. Liksom SQL Trace-skriptet, fångar det inkluderade sessionsdefinitionsskriptet bara Auto Stats-händelserna – återigen, både automatiska uppdateringar och auto-skapar. När XE-sessionen har körts ett tag kan du ladda utdata till en tabell via användargränssnittet och sedan fråga den för att se vilka uppdateringar som inträffade. Det inkluderade skriptet går igenom samma exempel som tidigare, men den här gången använder man Extended Events för att samla in data.
sys.dm_db_stats_properties
Ett tredje alternativ som du kan överväga för att övervaka statistikuppdateringar är sys.dm_db_stats_properties DMF, som endast är tillgänglig i SQL Server 2008 R2 SP2 och högre, och SQL Server 2012 SP1 och högre. Lika mycket som jag älskar denna DMF, är den här lösningen svårare när det gäller att se till att du fångar all data, och att granska utdatan kräver mer arbete. Med DMF spåras inte varje automatisk uppdatering, vi trendstatistik uppdaterar bara information för att se när uppdateringar sker.
Det är en enkel uppgift:du skapar en tabell för att hålla statistikinformationen och sedan ögonblicksbilder från DMF till tabellen regelbundet. Nyckeln här är att ta reda på hur ofta data ska samlas in. Varje timme är förmodligen överdrivet, en gång om dagen kanske inte är tillräckligt ofta. Jag rekommenderar att du börjar med ett SQL Agent-jobb som tar ögonblicksbilder av DMF-data var fjärde timme. Låt det köra i några dagar och kontrollera sedan dina data. Om statistiken uppdateras högst en gång om dagen, kan du öka intervallet till var åttonde eller tolfte timme. Om statistiken enkelt uppdateras var fjärde timme, sänk sedan ditt intervall till varannan timme – du vill vara säker på att du fångar varje uppdatering. Av denna anledning, för vissa system, sys.dm_db_stats_properties kanske inte är värt ansträngningen; en XE-session eller Trace kan vara enklare.
Ett sista exempelskript går igenom ett exempel på hur du skulle använda sys.dm_db_stats_properties för trenduppdateringar av statistik. Tänk på att det här skriptet bara fångar statistikinformation för en tabell. Om du ändrar skriptet för att fånga varje tabell i databasen kommer det att finnas mycket mer data att analysera.
Nästa steg
Ladda ner exempelskripten och bestäm vilken metod du ska använda för att spåra statistikuppdateringar.
När du har data som visar när automatiska uppdateringar sker måste du koppla tillbaka det till kända prestandaproblem. Som sådan, om du inte spårar några prestationsstatistik, kommer uppdateringsdata för automatisk statistik inte att hjälpa till med någon form av korrelation. Förutsatt att du har tidsstämplar för alla prestandaproblem kan du jämföra det med StartTime och EndTime från Trace, timestamp från XE, eller last_updated från sys.dm_db_stats_properties DMF, för att avgöra om den automatiska uppdateringen påverkade systemets prestanda.
Om du inte kan göra någon korrelation mellan uppdateringarna och prestandaproblemen kan du utesluta uppdateringar som orsaken till problemet och fokusera på ett annat område. Om uppdateringarna är grundorsaken har du två alternativ:inaktivera alternativet Automatisk uppdatering av statistik eller aktivera alternativet Automatisk uppdatering av statistik asynkront. Båda har för- och nackdelar som du som DBA måste överväga.
Inaktivera automatisk uppdateringsstatistik
Om du väljer att inaktivera alternativet för automatisk uppdatering av statistik är de två viktigaste sakerna att veta:
- Du måste absolut hantera din statistik via en underhållsuppgift eller anpassat jobb.
- Frågor kompileras inte om när du uppdaterar statistik i SQL Server 2008 R2 och senare.
Jag ser den andra punkten som en större utmaning – jag är en stor förespråkare för att hantera statistik och förväntar mig att det är något DBA:er gör ändå. Det större problemet är att, även om statistik uppdateras normalt gör att frågor kompileras om (för att dra nytta av den uppdaterade statistiken), gör det inte inträffa när du har inaktiverat alternativet för automatisk uppdatering av statistik. Jag har skrivit om detta tidigare och rekommenderar att du granskar denna information om du inte är bekant med detta beteende. Se också ett uppföljande inlägg för alternativ att ta itu med det.
I allmänhet är det inte den väg jag rekommenderar. Det finns mycket specifika kantfall där detta kan vara lämpligt, men jag skulle hellre se att en DBA utför manuella uppdateringar (genom schemalagda jobb) för att undvika de automatiska uppdateringarna och låta alternativet vara aktiverat som en säkerhetsåtgärd.
Aktivera automatisk uppdatering av statistik asynkront
När du aktiverar alternativet Automatisk uppdatering av statistik asynkront, om en statistik har blivit ogiltig och en fråga som använder den statistiken körs, kommer statistiken inte att uppdateras förrän efter att frågan har slutförts – uppdateringen är asynkron. Fördelen här är att uppdateringen inte kommer att påverka frågan som kördes; nackdelen är att frågan kommer att använda den befintliga planen, som kanske inte längre är den optimala planen. Huruvida planen fortfarande är optimal beror på din arbetsbelastning (t.ex. en rapporterande arbetsbelastning med långvariga frågor). Som DBA måste du väga för- och nackdelar med att aktivera det här alternativet och avgöra vad som är bäst för din databas. Observera att om du kör SQL Server 2008 till 2012 finns det en minnesläcka associerad med den här inställningen. Microsoft har kumulativa uppdateringar tillgängliga som ger en korrigering, men om du inte redan har tillämpat dem står du inför ett annat beslut:tillämpa CU så att du kan aktivera alternativet, eller tillämpa inte CU och aktivera inte alternativ.
Sammanfattning
Det enda sättet att veta om automatiska uppdateringar av statistik påverkar frågeprestanda är att antingen se en uppdatering ske samtidigt som ett problem, eller fånga när uppdateringar inträffar och relatera data till ytterligare information du samlar in om prestandaproblem. Det senare alternativet låter dig vara proaktiv – även om du inte har prestandaproblem kan det vara en bra idé att veta hur ofta automatiska uppdateringar sker. Frekventa uppdateringar kan innebära att du måste besöka agentjobbet som manuellt hanterar statistik. I allmänhet, lämna alternativet att automatiskt uppdatera statistik aktiverat, men ha en metod för att hantera statistik och använda alternativet som ett skyddsnät.