Коли використовувати sort_in_tempdb під час відновлення індексів?

Ми обговорюємо, чи використовувати опцію SORT_IN_TEMPDB для наших таблиць DW. Я розумію, що при використанні цієї опції є більше записів, хоча вони більш послідовні. У нас є SAN (який часом відомий повільно), тому в нашому випадку ми хочемо максимально обмежити кількість записів. Я вважаю, що tempdb знаходиться на окремому LUN (наборі дисків).

У нашому файлі даних та у файлі tempdb у нас достатньо місця на диску. У цьому випадку ми отримаємо користь від використання SORT_IN_TEMPDB?

Що мене вразило - це коментар до цієї відповіді

Під час перебудови індексу вам потрібно буде вдвічі більше місця індексу + 20% для сортування. Тож загалом для відновлення кожного індексу у вашому ДБ вам потрібно лише 120% вашого найбільшого індексу у вашій БД. Якщо ви використовуєте SORT_IN_TEMPDB, ви набираєте лише 20%, у вашому файлі даних все одно потрібен додатковий 100%. Крім того, використання сортування в tempdb різко збільшує завантаження вводу-виводу, оскільки замість того, щоб індекс записати один раз у файл даних, ви одноразово записуєте його до tempdb, а потім записуєте його у файл даних. Тож це не завжди ідеально.

Ми, безумовно, не хочемо збільшувати навантаження на введення-виведення за допомогою повільного / можливо неправильно налаштованого SAN.

Який був би найкращий спосіб перевірити це? Просто відновивши таблицю з опцією та без неї та ввівши час?

Редагувати : У нас є 8 темпдб-файлів, по 15 Гб. У нас встановлені прапори TF 1117/1118 і IFI увімкнено. В даний час ми робимо суміш відновлення з параметром sort_in_tempdb і без нього.

Спасибі!

SQL Server 2012 Enterprise

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

Це дає кращу перевагу, коли tempdb знаходиться на іншому наборі дисків (LUN) з бази даних користувачів.

Від SORT_IN_TEMPDB Варіант - BOL :

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

Переконайтесь, що ви прочитали вимоги до місця на диску, коли SORT_IN_TEMPDB увімкнено .

повільний / можливо неправильно налаштований SAN

Ви знаєте точку болю. Чому ви не працюєте зі своїм адміністратором SAN, щоб виправити це? Неправильно налаштований або повільний SAN викличе всілякі проблеми, такі як повільність .

Деякі важливі моменти, які слід зазначити:

• Використовуйте MAXDOP = 1 під час відновлення індексу в Інтернеті - інакше це призведе до збільшення фрагментації.
• Інтелектуально перебудуйте / відновіть ваші індекси на основі рівня фрагментації, а також фрагментів сторінки.
• Прочитайте досвід SQLFool зі створення індексу 60 Гб
• Переконайтеся, що ви правильно налаштували tempdb - TF 1117 (РІСНО ВСІХ ФАЙЛІВ В ФІЛОГРУПІ) та 1118 (ТІЛЬКИ ПОВНІШНІ), а також більше даних tempdb .

Який був би найкращий спосіб перевірити це?

Так, вам доведеться перевірити його, проаналізувавши стани очікування, коли відбудовуєте індекс із і без SORT_IN_TEMPDB. Виміряйте також час запуску та виконуючи це в PROD, переконайтеся, що ви це робите під час вікна обслуговування або менше роботи сервера. Також перевірте свої дані для читання / запису та затримку журналу .

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