Enig med Marc og Unkown ovenfor ... 6 indekser i det grupperede indeks er alt for mange, især på en tabel, der kun har 14 kolonner. Du bør ikke have mere end 3 eller 4, hvis det, vil jeg sige 1 eller måske 2. Du ved måske, at det klyngede indeks er den faktiske tabel på disken, så når en post indsættes, skal databasemotoren sortere den og placer den på sin organiserede plads på disken. Ikke-klyngede indekser er det ikke, de understøtter opslags-"tabeller". Mine VLDB'er er lagt ud på disken (CLUSTERED INDEX) i henhold til 1. punkt nedenfor.
- Reducer dit klyngeindeks til 1 eller 2. De bedste feltvalg er IDENTITET (INT), hvis du har et, eller et datofelt, hvor felterne føjes til databasen, eller et andet felt, der er en naturlig måde, hvordan dine data tilføjes til databasen. Pointen er, at du forsøger at holde disse data i bunden af tabellen ... eller få dem lagt ud på disken på den bedste (90%+) måde, så du kan læse posterne op. Dette gør det sådan, at der ikke er nogen omorganisering i gang, eller at det tager et og kun et hit for at få dataene på det rigtige sted for den bedste læsning. Sørg for at placere de fjernede felter i ikke-klyngede indekser, så du ikke mister opslagseffektiviteten. Jeg har ALDRIG lagt mere end 4 felter på mine VLDB'er. Hvis du har felter, der opdateres hyppigt, og de er inkluderet i dit klyngeindeks, OUCH, vil det omorganisere posten på disken og forårsage DYR fragmentering.
- Tjek udfyldningsfaktoren på dine indekser. Jo større fyldfaktornummeret (100) desto mere fyldige vil datasiderne og indekssiderne være. I forhold til hvor mange poster du har, og hvor mange poster du indsætter, vil du ændre udfyldningsfaktoren # (+ eller -) for dine ikke-klyngede indekser for at tillade fylderummet, når en post indsættes. Hvis du ændrer dit klyngede indeks til et sekventielt datafelt, betyder dette ikke så meget på et klynget indeks. Tommelfingerregel (IMO), 60-70 fillfactor for høj skrivning, 70-90 for medium skrivning og 90-100 for høj læsning/lav skrivning. Hvis du dropper din fillfactor til 70, vil det betyde, at for hver 100 poster på en side, bliver der skrevet 70 poster, hvilket vil efterlade ledig plads på 30 poster til nye eller reorganiserede poster. Spiser mere plads, men det slår helt sikkert at skulle DEFRAGERE hver nat (se 4 nedenfor)
- Sørg for, at statistikken findes i tabellen. Hvis du vil gennemse databasen for at oprette statistik ved hjælp af "sp_createstats 'indeksonly'", så vil SQL Server oprette al statistik på alle de indekser, som motoren har akkumuleret som krævende statistik. Undlad dog at udelade attributten 'kun indeks', ellers tilføjer du statistik for hvert felt, det ville da ikke være godt.
- Tjek tabellen/indekserne ved hjælp af DBCC SHOWCONTIG for at se, hvilke indekser der bliver mest fragmenteret. Jeg vil ikke gå i detaljer her, bare ved, at du skal gøre det. Ud fra disse oplysninger skal du derefter ændre udfyldningsfaktoren op eller ned i forhold til de ændringer, som indekserne oplever, ændres og hvor hurtigt (over tid).
- Opsæt en jobplan, der fungerer online (DBCC INDEXDEFRAG) eller offline (DBCC DBREINDEX) på individuelle indekser for at defragmentere dem. Advarsel:lav ikke DBCC DBREINDEX på denne store tabel, uden at det er under vedligeholdelsestiden, da det vil bringe apps ned ... især på CLUSTERED INDEX. Du er blevet advaret. Test og test denne del.
- Brug udførelsesplanerne til at se, hvilke SCANS og FAT PIPES der findes, og juster indekserne, og defragmenter og omskriv derefter lagrede processer for at slippe af med disse hot spots. Hvis du ser et RØDT objekt i din udførelsesplan, er det fordi der ikke er statistik på det felt. Det er slemt. Dette trin er mere "kunst end videnskab".
- I perioder uden for spidsbelastning, kør OPDATERING STATISTIKKER MED FULLSCAN for at give forespørgselsmotoren så mange oplysninger om datadistributionerne, som du kan. Ellers lav standard OPDATERING STATISTIK (med standard 10 % scanning) på tabeller i løbet af ugenætterne eller oftere, som du finder det passende med dine observationer for at sikre, at motoren har flere oplysninger om datadistributionerne for at hente dataene til effektivt.
Undskyld det er så langt, men det er ekstremt vigtigt. Jeg har kun givet dig minimal information, men vil hjælpe en masse. Der er nogle mavefornemmelser og observationer, der indgår i strategier, der bruges af disse punkter, og som vil kræve din tid og afprøvning.
Ingen grund til at gå til Enterprise-udgaven. Det gjorde jeg dog for at få de funktioner, der blev talt om tidligere med partitionering. Men jeg gjorde ISÆR for at have meget bedre multi-threading-kapaciteter med søgning og online DEFRAGING og vedligeholdelse ... I Enterprise-udgaven er det meget meget bedre og mere venligt med VLDB'er. Standardudgaven håndterer heller ikke DBCC INDEXDEFRAG med onlinedatabaser.