Probleem
Laten we wat duidelijkheid scheppen, want dit is een veelvoorkomend probleem, een serieus probleem voor elk bedrijf dat SQL Server gebruikt.
Dit probleem, en de noodzaak van CREATE CLUSTERED INDEX, wordt verkeerd begrepen.
Overeengekomen dat het hebben van een permanente Clustered Index beter is dan er geen te hebben. Maar daar gaat het niet om, en het zal sowieso leiden tot een lange discussie, dus laten we dat terzijde schuiven en ons concentreren op de geposte vraag.
Het punt is dat je substantiële fragmentatie hebt op de Heap . Je blijft het een "tabel" noemen, maar op het fysieke dataopslag- of DataStructure-niveau bestaat zoiets niet. Een tafel is een logisch concept, geen fysiek concept. Het is een verzameling fysieke DataStructures. De collectie is een van de twee mogelijkheden:
-
Hoop
plus alle niet-geclusterde indices
plus tekst-/afbeeldingsketens -
of een geclusterde index
(elimineert de Heap en één Niet-geclusterde index)
plus alle niet-geclusterde indexen
plus tekst-/afbeeldingsketens.
Hopen raken erg gefragmenteerd; hoe meer (willekeurige) invoegen/verwijderen/updates er zijn, hoe meer fragmentatie.
Er is geen manier om de Heap op te ruimen, zoals het is. MS biedt geen faciliteit (andere leveranciers wel).
Oplossing
We weten echter dat Create Clustered Index de Heap volledig herschrijft en opnieuw ordent. De methode (geen truc) is daarom om een geclusterde index te maken alleen voor het defragmenteren van de heap , en laat het daarna vallen. Je hebt vrije ruimte nodig in de db van table_size x 1.25.
Terwijl je toch bezig bent, gebruik FILLFACTOR om de toekomst te verkleinen fragmentatie. De heap neemt dan meer toegewezen ruimte in beslag, waardoor toekomstige invoegingen, verwijderingen en rij-uitbreidingen als gevolg van updates mogelijk zijn.
Opmerking
-
Merk op dat er drie Niveaus . zijn van fragmentatie; dit heeft alleen betrekking op niveau III, fragmentatie binnen de heap, die wordt veroorzaakt door Gebrek aan een geclusterde index
-
Als een afzonderlijke taak, op een ander moment, zou u de implementatie van een permanente geclusterde index kunnen overwegen, die fragmentatie helemaal elimineert ... maar dat staat los van het geposte probleem.
Reactie op reactie
Niet helemaal. Ik zou het geen "beperking" willen noemen.
-
De methode die ik heb gegeven om de fragmentatie in de hoop te elimineren, is door een geclusterde index te maken en deze vervolgens te laten vallen. D.w.z. tijdelijk, waarvan het enige doel het corrigeren van de fragmentatie is.
-
Het implementeren van een geclusterde index op tafel (permanent) is een veel betere oplossing, omdat het algemeen vermindert Fragmentatie (de datastructuur kan nog steeds gefragmenteerd raken, zie gedetailleerde informatie in onderstaande links), wat veel minder is dan de fragmentatie die in een heap voorkomt.
-
Elke tabel in een relationele database (behalve "pipe"- of "wachtrij"-tabellen) moet een geclusterde index hebben om te profiteren van de verschillende voordelen ervan.
-
De geclusterde index moet op kolommen staan die de gegevens verspreiden (vermijd INSERT-conflicten), nooit worden geïndexeerd op een monotoon toenemende kolom, zoals Record ID , die een INSERT-hotspot op de laatste pagina garandeert.
-
In MS SQL en Sybase ASE zijn er drie niveaus van fragmentatie, en binnen elk niveau, verschillende Typen . Houd er rekening mee dat wanneer we te maken hebben met fragmentatie, we ons moeten concentreren op DataStructures, niet op tabellen (een tabel is een verzameling DataStructures, zoals hierboven uitgelegd). De niveaus zijn:
-
Niveau I • Extra-gegevensstructuur
Buiten de betreffende DataStructuur, over of binnen de database. -
Niveau II • Gegevensstructuur
Binnen de betreffende gegevensstructuur, boven pagina's (over alle pagina's)
Dit is het niveau dat het vaakst wordt behandeld door DBA's. -
Niveau III • Pagina
Binnen de betreffende gegevensstructuur, binnen de pagina's
Deze links bieden volledige details over fragmentatie. Ze zijn specifiek voor Sybase ASE, maar op structureel niveau is de informatie van toepassing op MS SQL.
Merk op dat de methode die ik heb gegeven niveau II is, het corrigeert de fragmentatie van niveau II en III.