Ben het eens met Marc en Unkown hierboven ... 6 indexen in de geclusterde index is veel te veel, vooral in een tabel met slechts 14 kolommen. Je zou niet meer dan 3 of 4 moeten hebben, als dat zo is, zou ik zeggen 1 of misschien 2. Je weet misschien dat de geclusterde index de eigenlijke tabel op de schijf is, dus wanneer een record wordt ingevoegd, moet de database-engine het sorteren en plaats het op de gesorteerde, georganiseerde plaats op de schijf. Niet-geclusterde indexen zijn dat niet, ze ondersteunen opzoektabellen. Mijn VLDB's zijn ingedeeld op de schijf (CLUSTERED INDEX) volgens het eerste punt hieronder.
- Verlaag je geclusterde index naar 1 of 2. De beste veldkeuzes zijn de IDENTITEIT (INT), als je die hebt, of een datumveld waarin de velden worden toegevoegd aan de database, of een ander veld dat een natuurlijke manier van hoe uw gegevens aan de database worden toegevoegd. Het punt is dat u die gegevens onderaan de tabel probeert te houden ... of ze op de schijf wilt plaatsen op de beste (90%+) manier waarop u de records kunt uitlezen. Dit zorgt ervoor dat er geen reorganisatie plaatsvindt of dat er maar één hit nodig is om de gegevens op de juiste plaats te krijgen voor de beste lezing. Zorg ervoor dat u de verwijderde velden in niet-geclusterde indexen plaatst, zodat u de efficiëntie van het opzoeken niet verliest. Ik heb NOOIT meer dan 4 velden op mijn VLDB's gezet. Als je velden hebt die regelmatig worden bijgewerkt en ze zijn opgenomen in je geclusterde index, OUCH, dan zal dat de record op de schijf reorganiseren en KOSTBARE fragmentatie veroorzaken.
- Controleer de vulfactor op uw indexen. Hoe groter het vulfactornummer (100), hoe voller de gegevenspagina's en indexpagina's zullen zijn. Met betrekking tot het aantal records dat u heeft en het aantal records dat u invoegt, wijzigt u de vulfactor # (+ of -) van uw niet-geclusterde indexen om rekening te houden met de opvulruimte wanneer een record wordt ingevoegd. Als u uw geclusterde index wijzigt in een sequentieel gegevensveld, maakt dit niet zoveel uit op een geclusterde index. Vuistregel (IMO), 60-70 vulfactor voor hoge schrijfbewerkingen, 70-90 voor gemiddelde schrijfbewerkingen en 90-100 voor hoge lees-/lage schrijfbewerkingen. Door uw vulfactor te verlagen naar 70, betekent dit dat er voor elke 100 records op een pagina 70 records worden geschreven, waardoor er 30 records vrij blijven voor nieuwe of gereorganiseerde records. Neemt meer ruimte in beslag, maar het is zeker beter dan elke avond te moeten DEFRAGEREN (zie 4 hieronder)
- Zorg ervoor dat de statistieken op tafel staan. Als u de database wilt doorzoeken om statistieken te maken met behulp van de "sp_createstats 'indexonly'", dan zal SQL Server alle statistieken maken over alle indexen die de engine heeft verzameld en die statistieken vereisen. Laat het attribuut 'indexonly' echter niet weg, anders voeg je statistieken toe voor elk veld, dat zou dan niet goed zijn.
- Controleer de tabel/indexen met DBCC SHOWCONTIG om te zien welke indexen het meest gefragmenteerd raken. Ik zal hier niet in details treden, weet alleen dat je het moet doen. Wijzig vervolgens op basis van die informatie de vulfactor naar boven of naar beneden in relatie tot de veranderingen die de indexen ondergaan en hoe snel (in de loop van de tijd).
- Stel een taakschema in dat online (DBCC INDEXDEFRAG) of offline (DBCC DBREINDEX) op individuele indexen doet om ze te defragmenteren. Waarschuwing:doe geen DBCC DBREINDEX op deze grote tafel zonder dat het tijdens onderhoudstijd is, want het zal de apps naar beneden halen ... vooral op de CLUSTERED INDEX. Je bent gewaarschuwd. Test en test dit onderdeel.
- Gebruik de uitvoeringsplannen om te zien welke SCANS en FAT PIPES er zijn en pas de indexen aan, defragmenteer en herschrijf vervolgens de opgeslagen processen om van die hotspots af te komen. Als u een ROOD object in uw uitvoeringsplan ziet, komt dat omdat er geen statistieken over dat veld zijn. Dat is slecht. Deze stap is meer "kunst dan wetenschap".
- Voer op daluren de UPDATE STATISTICS WITH FULLSCAN uit om de query-engine zoveel mogelijk informatie over de gegevensdistributies te geven. Doe anders de standaard UPDATE STATISTIEKEN (met standaard 10% scan) op tafels tijdens de doordeweekse avonden of vaker naar eigen goeddunken met uw waarnemingen om ervoor te zorgen dat de engine meer informatie heeft over de gegevensdistributies om de gegevens efficiënt op te halen.
Sorry dat dit zo lang duurt, maar het is enorm belangrijk. Ik heb je hier slechts minimale informatie gegeven, maar zal een hoop helpen. Er zijn enkele onderbuikgevoelens en observaties die passen bij de strategieën die door deze punten worden gebruikt en die uw tijd en testen vergen.
U hoeft niet naar de Enterprise-editie te gaan. Ik deed het echter om de functies te krijgen waarover eerder werd gesproken met partitionering. Maar ik deed het VOORAL om veel betere multi-threading-mogelijkheden te hebben met zoeken en online DEFRAGING en onderhoud ... In Enterprise-editie is het veel beter en vriendelijker met VLDB's. De standaardeditie kan DBCC INDEXDEFRAG ook niet aan met online databases.