Når du opretter en ny database i SQL Server, er indstillingen Auto Update Statistics aktiveret som standard. Det anbefales generelt at lade denne indstilling være aktiveret. Ideelt set administreres statistik af et planlagt job, og den automatiske mulighed bruges som et sikkerhedsnet – tilgængelig til at opdatere statistik i tilfælde af, at en planlagt opdatering ikke forekommer, eller ved et uheld ikke inkluderer alle eksisterende statistikker.
Nogle DBA'er er udelukkende afhængige af automatiske opdateringer til at administrere statistik, og så længe der ikke eksisterer ydeevneproblemer relateret til forældede eller dårligt stikprøvede statistikker, er dette acceptabelt. Hvis du er afhængig af denne mulighed for at administrere din statistik, og du har nogle meget store tabeller, kan det være værd at implementere sporingsflag 2371. Som med ethvert sporingsflag, skal du sørge for at teste med en repræsentativ arbejdsbelastning, før du implementerer det i produktionen. Du er måske allerede klar over, at der er tidspunkter, hvor en automatisk opdatering kan påvirke systemets ydeevne. For eksempel kan opdateringen til en statistik introducere en stigning i CPU eller I/O, når tabellen eller indeksdataene læses, samt forsinke udførelse af forespørgsler, mens opdateringen finder sted. Der er en anden databasemulighed, du kan aktivere for at løse denne forespørgselsforsinkelse, og det vil jeg dække senere i dette indlæg.
Det spørgsmål, jeg ofte bliver stillet, er:"Hvordan ved du, om automatiske opdateringer af statistikker forårsager ydeevneproblemer?" En mulighed er at spore dem og knytte opdateringerne til en ændring i ydeevne. Der findes mange muligheder for sporing af opdateringer, og i dette indlæg vil vi gennemgå et par af de tilgængelige metoder, så du kan vælge og derefter implementere mulighed, der passer bedst til din eksisterende metode til overvågning af ydeevneproblemer.
SQL-sporing
Hvis du kører SQL Server 2008 R2 eller derunder i dit miljø, er SQL Trace en metode, du kan bruge til at fange automatiske opdateringer. Sporingsdefinitionsscriptet, der bruges nedenfor, fanger kun hændelsen Auto Stats, som fanger, når en statistik automatisk opdateres, og når en statistik automatisk oprettes. Når denne sporing har kørt et stykke tid i dit miljø, kan du indlæse den i en tabel og derefter forespørge på outputtet for at se, hvilke opdateringer der er sket. Det inkluderede script nedenfor gennemgår et eksempel ved hjælp af baseballstatistik-eksempeldatabasen.
Udvidede begivenheder
Hvis du kører SQL Server 2012 eller nyere, anbefaler jeg at bruge udvidede hændelser til at fange automatiske opdateringer. Ligesom SQL Trace-scriptet, fanger det inkluderede sessionsdefinitionsscript kun de automatiske statistiske hændelser – igen, både automatiske opdateringer og automatiske oprettelser. Når XE-sessionen har kørt et stykke tid, kan du indlæse outputtet i en tabel gennem brugergrænsefladen og derefter forespørge på det for at se, hvilke opdateringer der er sket. Det inkluderede script gennemgår det samme eksempel som før, men denne gang bruger man udvidede begivenheder til at indsamle dataene.
sys.dm_db_stats_properties
En tredje mulighed, som du kunne overveje for at overvåge statistikopdateringer, er sys.dm_db_stats_properties DMF, som kun er tilgængelig i SQL Server 2008 R2 SP2 og højere, og SQL Server 2012 SP1 og højere. Så meget som jeg elsker denne DMF, er denne løsning vanskeligere med hensyn til at sikre, at du har fanget alle data, og at gennemgå outputtet kræver mere arbejde. Med DMF spores hver automatisk opdatering ikke, vi trendstatistikker opdaterer blot oplysninger for at se, hvornår opdateringer sker.
Det er en simpel opgave:du opretter en tabel til at indeholde statistikoplysningerne og derefter snapshot-oplysninger fra DMF til tabellen på regelmæssig basis. Nøglen her er at finde ud af, hvor ofte dataene skal fanges. Hver time er sandsynligvis overkill, en gang om dagen er måske ikke hyppigt nok. Jeg anbefaler at starte med et SQL Agent-job, der tager snapshots af DMF-dataene hver fjerde time. Lad det køre i et par dage, og tjek derefter dine data. Hvis statistikken højst opdateres én gang om dagen, kan du øge intervallet til hver ottende eller tolvte time. Hvis statistikker nemt kan opdateres hver fjerde time, så sænk dit interval til hver anden time – du vil være sikker på, at du fanger hver opdatering. Af denne grund, for nogle systemer, sys.dm_db_stats_properties måske ikke besværet værd; en XE-session eller Trace kan være enklere.
Et sidste eksempelscript gennemgår et eksempel på, hvordan du ville bruge sys.dm_db_stats_properties til trendopdateringer til statistik. Vær opmærksom på, at dette script kun fanger statistikoplysninger for én tabel. Hvis du ændrer scriptet til at fange hver tabel i databasen, vil der være meget flere data at analysere.
Næste trin
Download eksempelscripts, og beslut, hvilken metode du skal bruge til at spore statistikopdateringer.
Når du har de data, der viser, hvornår automatiske opdateringer opstår, skal du binde det tilbage til kendte ydeevneproblemer. Som sådan, hvis du ikke sporer nogen præstationsmålinger, vil de automatiske opdateringsdata ikke hjælpe med nogen form for korrelation. Forudsat at du har tidsstempler for ethvert ydelsesproblem, kan du sammenligne det med StartTime og EndTime fra Trace, timestamp fra XE eller last_updated fra sys.dm_db_stats_properties DMF, for at afgøre, om den automatiske opdatering påvirkede systemets ydeevne.
Hvis du ikke kan lave nogen sammenhæng mellem opdateringerne og ydeevneproblemer, så kan du udelukke opdateringer som årsag til problemet og fokusere på et andet område. Hvis opdateringerne er årsagen, har du to muligheder:deaktiver funktionen Automatisk opdatering af statistik eller aktiver funktionen Automatisk opdatering af statistikker asynkront. Begge har fordele og ulemper, som du som DBA skal overveje.
Deaktivering af automatisk opdatering af statistik
Hvis du vælger at deaktivere muligheden for automatisk opdatering af statistik, er de to vigtigste ting at vide:
- Du skal absolut administrere din statistik via en vedligeholdelsesopgave eller et tilpasset job.
- Forespørgsler genkompileres ikke, når du opdaterer statistik i SQL Server 2008 R2 og derunder.
Jeg ser det andet punkt som en større udfordring – jeg er en stor fortaler for at styre statistik og forventer, at det alligevel er noget DBA'er gør. Det større problem er, at selvom opdatering af statistik normalt får forespørgsler til at rekompilere (for at drage fordel af den opdaterede statistik), dette gør ikke opstår, når du har deaktiveret muligheden for automatisk opdatering af statistik. Jeg har skrevet om dette tidligere, og jeg anbefaler, at du gennemgår disse oplysninger, hvis du ikke er bekendt med denne adfærd. Se også et opfølgende indlæg for muligheder for at løse det.
Generelt er det ikke den vej, jeg anbefaler. Der er meget specifikke edge-cases, hvor dette kan være passende, men jeg vil hellere se en DBA udføre manuelle opdateringer (gennem planlagte job) for at undgå de automatiske opdateringer og lade indstillingen være aktiveret som en sikkerhedsforanstaltning.
Asynkron opdatering af statistikker
Når du aktiverer funktionen Automatisk opdatering af statistik asynkront, hvis en statistik er blevet ugyldig, og en forespørgsel, der bruger denne statistik, køres, vil statistikken ikke blive opdateret, før forespørgslen er fuldført – opdateringen er asynkron. Fordelen her er, at opdateringen ikke vil påvirke den forespørgsel, der blev kørt; Ulempen er, at forespørgslen vil bruge den eksisterende plan, som måske ikke længere er den optimale plan. Om planen stadig er optimal vil afhænge af din arbejdsbyrde (f.eks. en rapporterende arbejdsbyrde med langvarige forespørgsler). Som DBA skal du afveje fordele og ulemper ved at aktivere denne mulighed og afgøre, hvad der er bedst for din database. Bemærk, at hvis du kører SQL Server 2008 til 2012, er der en hukommelseslæk forbundet med denne indstilling. Microsoft har kumulative opdateringer tilgængelige, der giver en rettelse, men hvis du ikke allerede har dem anvendt, står du over for en anden beslutning:Anvend CU'en, så du kan aktivere muligheden, eller anvend ikke CU'en og aktiver ikke mulighed.
Oversigt
Den eneste måde at vide, om automatiske opdateringer af statistikker påvirker forespørgselsydeevnen, er enten at se en opdatering ske samtidig med et problem, eller at fange, når der opstår opdateringer, og korrelere dataene med yderligere oplysninger, du fanger om ydeevneproblemer. Sidstnævnte mulighed giver dig mulighed for at være proaktiv – selvom du ikke har problemer med ydeevnen, kan det være en god idé at vide, hvor ofte automatiske opdateringer forekommer. Hyppige opdateringer kan betyde, at du skal gense agent-jobbet, der manuelt administrerer statistik. Generelt skal du lade muligheden for automatisk opdatering af statistik være aktiveret, men have en metode til at administrere statistik og bruge muligheden som et sikkerhedsnet.