Съгласен съм с Marc и Unkown по-горе... 6 индекса в групирания индекс са твърде много, особено в таблица, която има само 14 колони. Не трябва да имате повече от 3 или 4, ако е така, бих казал 1 или може би 2. Може би знаете, че клъстерираният индекс е действителната таблица на диска, така че когато се вмъкне запис, машината на базата данни трябва да го сортира и поставете го на сортирано организирано място на диска. Неклъстерираните индекси не са, те поддържат справочни „таблици“. Моите VLDB са разположени на диска (КЛУСТЕРИРАН ИНДЕКС) съгласно 1-ва точка по-долу.
- Намалете вашия групиран индекс до 1 или 2. Най-добрият избор на поле е ИДЕНТИЧНОСТ (INT), ако имате такъв, или поле за дата, в което полетата се добавят към базата данни, или някое друго поле, което е естествен вид как вашите данни се добавят към базата данни. Въпросът е, че се опитвате да запазите тези данни в долната част на таблицата ... или да ги поставите на диска по най-добрия (90%+) начин, по който ще прочетете записите. Това го прави така, че да не се извършва реорганизация или че е необходимо едно и само едно попадение, за да се поставят данните на правилното място за най-добро четене. Не забравяйте да поставите премахнатите полета в неклъстерни индекси, за да не загубите ефикасността на търсенето. НИКОГА не съм поставял повече от 4 полета на моите VLDB. Ако имате полета, които се актуализират често и те са включени във вашия клъстериран индекс, ОУЧ, това ще реорганизира записа на диска и ще причини СКЪПО ДЕЛЕ фрагментиране.
- Проверете коефициента на запълване на вашите индекси. Колкото по-голямо е числото на фактора на запълване (100), толкова по-пълни ще бъдат страниците с данни и индексните страници. Във връзка с това колко записа имате и колко записа вмъквате, ще промените коефициента на запълване # (+ или -) на вашите неклъстерирани индекси, за да позволите пространството за запълване, когато се вмъкне запис. Ако промените вашия клъстерен индекс на поле за последователни данни, тогава това няма да има толкова голямо значение за клъстерен индекс. Основно правило (IMO), 60-70 фактор на запълване за високи записи, 70-90 за средни записи и 90-100 за високи четения/слаби записи. Намаляването на вашия коефициент на запълване до 70 ще означава, че за всеки 100 записа на страница се записват 70 записа, което ще остави свободно пространство от 30 записа за нови или реорганизирани записи. Заема повече място, но със сигурност побеждава необходимостта от ДЕФРАГРАЖИРАНЕ всяка вечер (вижте 4 по-долу)
- Уверете се, че статистиката съществува в таблицата. Ако искате да почистите базата данни, за да създадете статистика, като използвате "sp_createstats 'indexonly'", тогава SQL Server ще създаде всички статистики за всички индекси, които двигателят е натрупал като изискващи статистика. Все пак не оставяйте атрибута 'indexonly' или ще добавите статистика за всяко поле, това не би било добре.
- Проверете таблицата/индексите с помощта на DBCC SHOWCONTIG, за да видите кои индекси се фрагментират най-много. Няма да навлизам в подробности тук, просто знайте, че трябва да го направите. След това въз основа на тази информация променете коефициента на запълване нагоре или надолу във връзка с промените, които индексите претърпяват, и колко бързо (с течение на времето).
- Настройте график на работа, който ще се изпълнява онлайн (DBCC INDEXDEFRAG) или офлайн (DBCC DBREINDEX) на отделни индекси, за да ги дефрагментирате. Предупреждение:не правете DBCC DBREINDEX на тази голяма таблица, без да е по време на поддръжката, защото това ще доведе до повреда на приложенията ... особено на CLUSTERED INDEX. Бяхте предупредени. Тествайте и тествайте тази част.
- Използвайте плановете за изпълнение, за да видите какво СКАНИРАНЕ и FAT PIPES съществуват и коригирайте индексите, след което дефрагментирайте и пренапишете съхранените процедури, за да се отървете от тези горещи точки. Ако видите ЧЕРВЕН обект във вашия план за изпълнение, това е защото няма статистика за това поле. Това е лошо. Тази стъпка е повече "изкуство, отколкото наука".
- В извън пиковите часове стартирайте АКТУАЛИЗИРАНЕ НА СТАТИСТИКА С ПЪЛНО СКАНИРАНЕ, за да предоставите на машината за заявки възможно най-много информация за разпределението на данни. В противен случай направете стандартната АКТУАЛИЗИРАНА СТАТИСТИКА (със стандартно 10% сканиране) на маси през делничните вечери или по-често, както сметнете за добре с вашите наблюдения, за да сте сигурни, че машината разполага с повече информация за разпределението на данни, за да извлича данните за ефективно.
Съжалявам, това е толкова дълго, но е изключително важно. Тук ви давам само минимална информация, но ще ви помогна много. Има някои интуиции и наблюдения, които са включени в стратегиите, използвани от тези точки, които ще изискват вашето време и тестване.
Няма нужда да отивате в изданието Enterprise. Направих го обаче, за да получа функциите, за които се говори по-рано с разделянето. Но го направих СПЕЦИАЛНО, за да имам много по-добри възможности за многопоточност с търсене и онлайн ДЕФРАГМЕНТИРАНЕ и поддръжка... В изданието Enterprise е много по-добро и по-приятелско с VLDB. Стандартното издание не се справя с извършването на DBCC INDEXDEFRAG и с онлайн бази данни.
