Проблем
Нека внесем малко яснота, защото това е често срещан проблем, сериозен проблем за всяка компания, използваща SQL Server.
Този проблем и нуждата от CREATE CLUSTERED INDEX са неразбрани.
Съгласих се, че наличието на постоянен клъстериран индекс е по-добро, отколкото липсата на такъв. Но това не е целта и така или иначе ще доведе до дълга дискусия, така че нека оставим това настрана и да се съсредоточим върху публикувания въпрос.
Въпросът е, че имате значителна фрагментация на Heap . Продължавате да го наричате „таблица“, но няма такова нещо на ниво физическо съхранение на данни или DataStructure. Масата е логическа концепция, а не физическа. Това е колекция от физически DataStructures. Колекцията е една от двете възможности:
-
Група
плюс всички неклъстерирани индекси
плюс вериги текст/изображение -
или Клъстърен индекс
(елиминира купчината и един Негрупиран индекс)
плюс всички негрупирани индекси
плюс текстови/изображени вериги.
Купчините са силно фрагментирани; колкото повече разпръснати (произволни) вмъквания/изтривания/актуализации има, толкова по-голяма е фрагментацията.
Няма начин да почистите Грамадата, както е. MS не предоставя възможност (други доставчици го правят).
Решение
Ние обаче знаем, че Create Clustered Index пренаписва и пренарежда купчината изцяло. Следователно методът (не трик) е да се създаде клъстерен индекс само за целите на дефрагментирането на купчината и го пуснете след това. Имате нужда от свободно място в db на table_size x 1,25.
Докато го правите, по всякакъв начин използвайте FILLFACTOR, за да намалите бъдещето фрагментация. След това Heap ще заеме повече разпределено пространство, позволявайки бъдещи вмъквания, изтривания и разширения на редове поради актуализации.
Забележка
-
Имайте предвид, че има три нива на фрагментация; това се занимава само с ниво III, фрагментация в рамките на Heap, което е причинено от Липса на клъстерен индекс
-
Като отделна задача, по някое друго време, може да пожелаете да обмислите внедряването на постоянен клъстерен индекс, който елиминира напълно фрагментацията ... но това е отделно от публикувания проблем.
Отговор на коментар
Не точно. Не бих го нарекъл "ограничение".
-
Методът, който дадох за елиминиране на фрагментацията в купчината, е да се създаде клъстерен индекс и след това да се изтрие. т.е. временно, чиято единствена цел е коригиране на фрагментацията.
-
Внедряването на клъстериран индекс в таблицата (постоянно) е много по-добро решение, защото намалява общо Фрагментация (DataStructure все още може да бъде фрагментирана, вижте подробна информация във връзките по-долу), което е много по-малко от фрагментацията, която се случва в Heap.
-
Всяка таблица в релационна база данни (с изключение на таблиците "pipe" или "queue") трябва да има клъстерен индекс, за да се възползвате от различните предимства.
-
Клъстерираният индекс трябва да бъде върху колони, които разпределят данните (избягвайки конфликти при INSERT), никога да не се индексира върху монотонно нарастваща колона, като например ID на запис, което гарантира гореща точка INSERT на последната страница.
-
В MS SQL и Sybase ASE има три нива на фрагментиране и в рамките на всяко ниво няколко различни типа . Имайте предвид, че когато се занимаваме с фрагментиране, трябва да се фокусираме върху DataStructures, а не върху таблици (таблицата е колекция от DataStructures, както е обяснено по-горе). Нивата са:
-
Ниво I • Extra-DataStructure
Извън съответната DataStructure, през или в рамките на базата данни. -
Ниво II • DataStructure
В рамките на съответната DataStructure, над страниците (във всички страници)
Това е нивото, което най-често се адресира от администраторите на бази данни. -
Ниво III • Страница
В рамките на съответната DataStructure, в рамките на страниците
Тези връзки предоставят пълни подробности относно фрагментирането. Те са специфични за Sybase ASE, но на структурно ниво информацията се отнася за MS SQL.
Обърнете внимание, че методът, който дадох, е от ниво II, той коригира фрагментацията от ниво II и III.
