Håller med Marc och Unkown ovan ... 6 index i det klustrade indexet är alldeles för många, speciellt på en tabell som bara har 14 kolumner. Du borde inte ha mer än 3 eller 4, om det är så skulle jag säga 1 eller kanske 2. Du kanske vet att det klustrade indexet är den faktiska tabellen på disken, så när en post infogas måste databasmotorn sortera den och placera den på sin ordnade plats på disken. Icke-klustrade index är det inte, de stöder uppslags-"tabeller". Mina VLDB:er läggs ut på disken (CLUSTERED INDEX) enligt den första punkten nedan.
- Reducera ditt klustrade index till 1 eller 2. De bästa fältalternativen är IDENTITET (INT), om du har en, eller ett datumfält där fälten läggs till i databasen, eller något annat fält som är en naturligt av hur din data läggs till i databasen. Poängen är att du försöker hålla den informationen längst ner i tabellen ... eller få den utlagd på disken på det bästa (90%+) sättet att du kan läsa upp posterna. Detta gör det så att det inte pågår någon omorganisering eller att det tar en enda träff för att få data på rätt plats för bästa läsning. Se till att placera de borttagna fälten i icke-klustrade index så att du inte förlorar uppslagseffektiviteten. Jag har ALDRIG lagt mer än 4 fält på mina VLDB:er. Om du har fält som uppdateras ofta och de är inkluderade i ditt klustrade index, OUCH, kommer det att omorganisera posten på disken och orsaka DYR fragmentering.
- Kontrollera fyllningsfaktorn på dina index. Ju större fyllfaktornummer (100) desto fylligare blir datasidorna och indexsidorna. I förhållande till hur många poster du har och hur många poster du infogar kommer du att ändra fillfactor # (+ eller -) för dina icke-klustrade index för att tillåta fyllutrymmet när en post infogas. Om du ändrar ditt klustrade index till ett sekventiellt datafält kommer detta inte att spela så stor roll på ett klustrade index. Tumregel (IMO), 60-70 fillfactor för hög skrivning, 70-90 för medium skrivning och 90-100 för hög läsning/låg skrivning. Genom att sänka din fillfactor till 70 kommer det att innebära att för varje 100 poster på en sida skrivs 70 poster, vilket kommer att lämna ledigt utrymme på 30 poster för nya eller omorganiserade poster. Äter mer utrymme, men det överträffar säkert att behöva DEFRAGERA varje natt (se 4 nedan)
- Se till att statistiken finns i tabellen. Om du vill sopa databasen för att skapa statistik med "sp_createstats 'indexonly'", så kommer SQL Server att skapa all statistik på alla index som motorn har samlat på sig som kräver statistik. Lämna dock inte attributet 'indexonly', annars lägger du till statistik för varje fält, det skulle då inte vara bra.
- Kontrollera tabellen/indexen med DBCC SHOWCONTIG för att se vilka index som blir mest fragmenterade. Jag går inte in på detaljerna här, bara vet att du måste göra det. Baserat på den informationen ändrar du sedan fyllningsfaktorn uppåt eller nedåt i förhållande till förändringarna som indexen upplever ändras och hur snabbt (över tiden).
- Ställ in ett jobbschema som fungerar online (DBCC INDEXDEFRAG) eller offline (DBCC DBREINDEX) på enskilda index för att defragmentera dem. Varning:gör inte DBCC DBREINDEX på denna stora tabell utan att det är under underhållstid eftersom det kommer att ta ner apparna ... speciellt på CLUSTERED INDEX. Du har blivit varnad. Testa och testa den här delen.
- Använd exekveringsplanerna för att se vilka SCANS och FAT PIPES som finns och justera indexen, defragmentera och skriv om lagrade processer för att bli av med dessa hotspots. Om du ser ett RÖTT objekt i din utförandeplan beror det på att det inte finns statistik på det fältet. Det är dåligt. Detta steg är mer av "konsten än vetenskapen".
- Under lågtrafik, kör UPPDATERA STATISTIK MED FULLSCAN för att ge sökmotorn så mycket information om datadistributionerna du kan. Annars gör du standard UPPDATERA STATISTIK (med standard 10 % skanning) på tabeller under veckonätterna eller oftare som du tycker är lämpligt med dina observationer för att se till att motorn har mer information om datadistributionerna för att kunna hämta data för effektivt.
Ledsen att det här är så långt, men det är oerhört viktigt. Jag har bara gett dig minimal information men kommer att hjälpa dig massor. Det finns några magkänslor och observationer som går in på strategier som används av dessa punkter som kommer att kräva din tid och testning.
Du behöver inte gå till Enterprise-utgåvan. Jag gjorde dock för att få de funktioner som talades om tidigare med partitionering. Men jag gjorde SÄRSKILT för att ha mycket bättre multi-threading-kapacitet med sökning och online-DEFRAGING och underhåll ... I Enterprise-utgåvan är det mycket mycket bättre och mer vänligt med VLDB:er. Standardutgåvan klarar inte av att göra DBCC INDEXDEFRAG med onlinedatabaser också.