Секціонування великих таблиць або індексів може дати наступні переваги в керованості і продуктивності.
Це дозволяє швидко і ефективно переносити підмножини даних і звертатися до них, зберігаючи при цьому цілісність набору даних. Наприклад, така операція, як завантаження даних з OLTP в систему OLAP, виконується за секунди, а не за хвилини і години, як у випадку несекціонірованних даних.
Операції обслуговування можна виконувати швидше з однією або декількома секціями. Операції більш ефективні, так як виконуються тільки з піднаборі даних, а не з усією таблицею. Наприклад, можна стиснути дані в одну або кілька секцій або перебудувати одну або кілька секцій індексу.
Можна підвищити швидкість виконання запитів в залежності від запитів, які часто виконуються у вашій конфігурації обладнання. Наприклад, оптимізатор запитів може швидше виконувати запити на еквісоедіненія двох і більше секціонованих таблиць, якщо в цих таблицях одні і ті ж стовпчики секціонування, тому що можна з'єднати самі секції.
У процесі сортування даних для операцій введення-виведення в SQL Server спочатку проводиться сортування даних по секціях. SQL Server може одночасно звертатися тільки до одного диску, що може знизити продуктивність. Для прискорення сортування даних рекомендується розподілити файли даних в секціях по декількох жорстких дисків, створивши RAID. Таким чином, незважаючи на сортування даних по секціях, SQL Server зможе одночасно здійснювати доступ до всіх жорстких дисків кожної секції.
Крім того, можна підвищити продуктивність, застосовуючи блокування на рівні секцій, а не всієї таблиці. Це може зменшити кількість конфліктів блокувань для таблиці.
Терміни відносяться до секционированию таблиць і індексів.
Об'єкт бази даних, який визначає розподіл рядків таблиці або індексу по секціях на основі значень певних стовпців, які називаються стовпцями секціонування. Тобто функція секціонування визначає кількість розділів в таблиці і як будуть визначені межі розділів. Наприклад, таблицю, яка містить дані замовлень на продаж, може знадобитися розділити таблицю на 12 місячних секцій за значеннями стовпчика datetime. такими як дата продажів.
Об'єкт бази даних, який зіставляє секції функції секціонування набору файлових груп. Головна причина, по якій секції розділяються за різними файловим групам, полягає в необхідності незалежного резервного копіювання цих секцій, оскільки воно завжди виконується окремо для кожної з файлових груп.
Стовпець таблиці або індексу, який використовується функцією секціонування для секціонування таблиці або індексу. Обчислювані стовпці, які беруть участь у функції секціонування, повинні бути явно позначені як PERSISTED. Всі типи даних, допустимі для використання в якості індексних стовпців, можуть використовуватися як стовпці секціонування, за винятком timestamp. Не можуть бути вказані типи даних ntext. text. image. xml. varchar (max). nvarchar (max) і varbinary (max). Також не можна вказати визначений користувачем тип даних середовища Microsoft .NET Framework CLR і стовпці типу даних псевдоніма.
Індекс, створений на основі тієї ж схеми секціонування, що і відповідна таблиця. Якщо таблиця і її індекси вирівняні, SQL Server може швидко перемикатися з секції на секцію, зберігаючи при цьому структуру секцій як таблиці, так і її індексів. Для вирівнювання з базовою таблицею індексу необов'язково використовувати функцію секціонування з тим же ім'ям. Однак функції секціонування індексу і базової таблиці не повинні мати відчутні відмінності, тобто: 1) аргументи функції секціонування повинні мати один і той же тип даних, 2) функції повинні визначати однакову кількість секцій і 3) функції повинні визначати для секцій однакові граничні значення.
Індекс, Секціонірованние незалежно від відповідної таблиці. Т. е. Індекс має іншу схему секціонування або знаходиться не в тій файлової групі, де знаходиться базова таблиця. Створення невирівняного Секціонірованние індексу може бути корисно в наступних випадках:
Базова таблиці не секціонірована.
Ключ індексу є унікальним і не містить стовпці секціонування таблиці.
Потрібна участь базової таблиці в вирівняних з'єднаннях з таблицями, що використовують інші стовпці з'єднання.
Процес, в ході якого оптимізатор запитів звертається тільки до певних секцій відповідно до фільтром запиту.
Більш висока нове максимальну кількість секцій (15 000) впливає на пам'ять, операції з секціонованими індексами, команди DBCC і запити. У цьому розділі показано, як впливає на продуктивність створення більше 1 000 секцій і як обійти проблеми. Збільшення максимальної кількості секцій до 15 000 дозволяє довше зберігати дані. Однак рекомендується зберігати дані рівно стільки часу, скільки потрібно, і підтримувати баланс між продуктивністю і кількістю секцій.
Використання пам'яті і рекомендації
При великій кількості використовуваних секцій рекомендується використовувати ОЗУ не менше 16 ГБ. Якщо у системи недостатньо пам'яті, можливий збій інструкцій мови обробки даних (DML), інструкцій мови опису даних (DDL) і інших операцій через брак пам'яті. У системах з ОЗУ 16 ГБ і великою кількістю процесів, що інтенсивно використовують пам'ять, можливі збої операцій, що працюють на великій кількості секцій, через брак пам'яті. Тому чим більше у вас пам'яті понад 16 ГБ, тим менше ймовірність проблем з продуктивністю і пам'яттю.
Обмеження оперативної пам'яті можуть вплинути на продуктивність або можливість створення Секціонірованние індексу. Таке трапляється, наприклад, коли індекс не вирівняні зі своєю базовою таблицею або зі своїм кластерізованний індексом, якщо такий існує в таблиці.
Операції з секціонованими індексами
Обмеження оперативної пам'яті можуть вплинути на продуктивність або можливість створення Секціонірованние індексу. Це особливо відноситься до невирівняних індексам. Створення і перебудова невирівняні індексів для таблиці, кількість секцій в якій перевищує 1000, можливі, але не підтримуються. Це може привести до зниження продуктивності або надмірного споживання пам'яті під час таких операцій.
Створення і перебудова вирівняних індексів може займати більше часу в міру збільшення кількості секцій. Не рекомендується виконувати одночасно кілька команд створення та розбудови індексу, так як можливі проблеми з продуктивністю і пам'яттю.
Коли компонент SQL Server виконує сортування для створення секціонованих індексів, спочатку він створює по одній таблиці сортування для кожної секції. Потім він створює таблиці сортування у відповідній файлової групі кожної секції або в tempdb. якщо заданий параметр SORT_IN_TEMPDB. Для всіх таблиць сортування потрібен мінімальний обсяг оперативної пам'яті. При побудові Секціонірованние індексу, вирівняного зі своєю базовою таблицею, таблиці сортування створюються по одній за раз, економно витрачаючи оперативну пам'ять. Однак при побудові невирівняного Секціонірованние індексу таблиці сортування створюються одночасно. В результаті необхідний достатній обсяг оперативної пам'яті, щоб паралельно їх обробляти. Чим більше число секцій, тим більше потрібно оперативної пам'яті. Для кожної з секцій розмір таблиці сортування становить не менше 40 сторінок, по 8 кілобайт кожна. Наприклад, для невирівняного Секціонірованние індексу, розбитого на 100 секцій, буде потрібно обсяг оперативної пам'яті для одночасної сортування 4 000 сторінок (40 * 100). Якщо такий обсяг пам'яті, доступний, операція створення буде виконана успішно, але може постраждати продуктивність. Якщо ж такий обсяг пам'яті недоступний, операція побудови завершиться помилкою. Для вирівняного Секціонірованние індексу, розбитого на 100 секцій, для сортування буде потрібно всього 40 сторінок, оскільки сортування здійснюються не одночасно.
Як для вирівняних, так і для невирівняні індексів може знадобитися більше оперативної пам'яті, якщо SQL Server застосовує ступеня паралелізму для операції створення на многопроцессорном комп'ютері. Чим більше ступінь паралелізму, тим більше потрібно оперативної пам'яті. Наприклад, якщо SQL Server задає ступінь паралелізму 4, то невирівняні Секціонірованние індексу зі 100 секціями буде потрібно такий обсяг пам'яті, щоб чотири процесори могли одночасно впорядкувати за 4 000 сторінок, тобто 16 000 сторінок. Якщо Секціонірованние індекс вирівняний, вимоги оперативної пам'яті знижуються до 40 сторінок для кожного з чотирьох процесорів, тобто 160 сторінок (4 * 40). За допомогою параметра індексу MAXDOP можна вручну знизити ступінь паралелізму.
команди DBCC
При більшій кількості секцій виконання команд DBCC може займати більше часу в міру збільшення кількості секцій.
Запити, що використовують функцію усунення секцій, можуть мати яку можна порівняти або більш високу продуктивність з великим числом секцій. Запити, які не використовують функцію усунення секцій, можуть займати більше часу в міру збільшення кількості секцій.
Припустимо, таблиця має 100 мільйонів рядків і стовпці A. B і C. У прикладі 1 таблиця ділиться на 1000 секцій по стовпцю A. В прикладі 2 таблиця ділиться на 10,000 секцій по стовпцю A. Запит до таблиці, що включає пропозицію WHERE з фільтром по стовпцю A. виконає функцію усунення секцій і просканує одну секцію. Той же самий запит може бути виконаний швидше в прикладі 2, так як в секції менше рядків для сканування. Запит, що включає пропозицію WHERE з фільтром по стовпчику B, буде сканувати всі секції. У прикладі 1 цей запит може бути виконаний швидше, ніж в прикладі 2, так як в цьому випадку менше секцій для сканування.
Запити, в яких такі оператори, як TOP або MAX / MIN, використовуються для будь-яких стовпців, крім стовпців секціонування, можуть зіткнутися зі зниженою продуктивністю при секціонуванні, оскільки всі секції повинні бути обчислені.