Чи є якась користь для дефрагментації індексів SQL у середовищі SAN?

Наш сервер SQL живе на SAN. Він містить десятки баз даних OLTP, деякі з кількома таблицями, що містять понад 1м записів.

Ми виконуємо сценарії технічного обслуговування індексу Ola Hallengren щотижня, і він працює щоразу кілька годин. Спираючись на поріг фрагментації, сценарій буде або реорганізувати, або повторно встановити індекс. Ми помітили, що під час повторного деіндексів файли журналів отримують величезну кількість, що призводить до надмірного споживання пропускної здатності під час доставки журналу.

Потім виходить стаття Brent Ozar, в якій він говорить, щоб перестати турбуватися про індекси SQL :

Ваші жорсткі диски поділяються з іншими серверами, які одночасно роблять запити на диски, тому диски завжди будуть стрибати всюди, щоб отримати дані. Дефрагмація ваших індексів - просто безглузда зайнята робота.

Гуглінг цього питання призводить до різних думок, більшість з яких підтримується аргументами, які здаються занадто короткими або слабкими. Наш попередній план полягає в тому, щоб відкоригувати поріг фрагментації в нашому сценарії технічного обслуговування, щоб він реорганізувався набагато частіше, ніж повторно встановлюється.

Який остаточний вердикт? Чи варто дефрагментувати індекси SQL на SAN з урахуванням тягарів, пов’язаних із запуском щотижневих завдань з обслуговування?

Стратегії дефрагментації допомагають покращити швидкість сканування до / з диска .

Широка різноманітність думок полягає в тому, що ідеальна стратегія дефрагментації середовища повинна залежати від багатьох різних факторів. У грі також є декілька потенційних шарів фрагментації .

Скажімо, що ваші бази даних зберігаються в SAN, недостатньо інформації. Наприклад:

• Чи зберігаються файли бази даних в окремих фізичних групах RAID або в одній групі RAID? Які ще процеси активні на цьому ж пристрої? Чи закінчуються і ваші резервні файли? Можливо, вам доведеться попросити у вашого адміністратора SAN цю інформацію, оскільки вона не завжди прозора.

• Які схеми доступу до баз даних? OLTP - це, як правило, випадковий доступ, але іноді програма підходить до сканування таблиці, і ви не можете змінити її поведінку (додаток ISV). Програми читання в основному, в основному, чи десь посередині?

• Чи грають угоди про ефективність угоди під час відновлення / відмовлення ?

Пост Брента передбачає, що є один гігантський пул зберігання, і все ним ділиться. Це означає, що фізичні диски рідко не працюють, а значить, більшість доступу є випадковими. Якщо це ваша ситуація, то порада застосовується, і я погоджуюсь з нею здебільшого. Хоча цим типом стратегії набагато простіше керувати, це не обов'язково (а) те, що у вас є у вашому оточенні, або (б) яке найкраще рішення для вашого оточення.

Якщо обслуговування індексів є обтяжливим, подумайте, чи робити це менш агресивно, та / або амортизуйте витрати протягом тижня (тобто, запускайте легке обслуговування один раз на день, замість великого обслуговування один раз на тиждень).

Ви також можете ввімкнути SortInTempdbопцію, щоб потенційно зменшити кількість журналів, що відбуваються в базі даних користувачів.

В ідеалі вам слід реорганізувати / переіндексувати ТІЛЬКИ ті ​​індекси, які потребують уваги, інакше ви витрачаєте ресурси та потенційно спричиняєте інші проблеми.

Вам потрібно встановити базову лінію ефективності та кожного разу, коли ви вносите зміни, порівнюйте зміни ефективності з базовою лінією, щоб визначити, чи варто зміни внести.

Гаразд, питання стосується індексів баз даних, які є конструкцією файлу або набору файлів. Читання відповідей вище змусить людину повірити, що ми говоримо про фрагментацію на рівні диска, а не про індекси всередині файлу. Ці абсолютно окремі предмети.

Міопічний підхід тут полягає в тому, що ефективність при отриманні даних всередині і бази даних OLTP покращиться, якщо індекси будуть дефрагментовані або відновлені. Відповідь ТАК! Однак важливо зазначити, що фрагментація диска також є фактором.

Найнижча "вартість" в цілому? Зробіть ваше обслуговування баз даних. Другий з найнижчою вартістю, від'єднайте базу даних, перенесіть її кудись інше, переформатуйте свої диски та дотримуйтесь кращих практик для вирівнювання дискового розділу http://msdn.microsoft.com/en-us/library/dd758814.aspx . І останнє, але не менш важливе, використовуйте сторонній розширений дефрагментатор, як Diskkeeper.

Пам'ятайте, що це ТОЛЬКО рекомендується для зберігання типу NTFS (наприклад, ОС Windows), і це не є схваленням для будь-якого продукту, і я не пов'язаний з Condusiv Technologies або його філіями.