Далі йде абзац з Документів Microsoft :
Нові сторінки, виділені в купі як частина операцій DML, не використовуватимуть стиснення PAGE, поки купа не буде відновлена. Відновіть купу, видаливши та повторно застосувавши стиснення, або створивши та видаливши кластерний індекс.
Я не можу зрозуміти, чому це так. Якщо у мене є купа з заданим параметром стиснення, чому б її не застосувати до сторінки, що належить до таблиці?
Спасибі
Відповіді:
Хоча я не знаю конкретних внутрішніх механізмів (механізмів), які відповідають за розбіжності, я можу сказати, що Heaps управляється (внутрішньо) дещо інакше, ніж кластерні індекси (і, можливо, також некластеризовані індекси):
Видалення рядків з Heap таким чином, що одна або кілька сторінок даних порожні (не виділені рядки) не обов'язково звільняє це місце. Вам, ймовірно, потрібно буде або створити, а потім відкинути на стіл індекс кластера або зателефонувати ALTER TABLE [TableName] REBUILD;(станом на SQL Server 2014?). Детальнішу інформацію та варіанти див. На сторінці Документи Microsoft для DELETE .
Вставлення окремих рядків (тобто не на основі набору INSERT) у купу не заповнює сторінки даних так повно, як це робиться з кластерними індексами. Кластеризовані індекси підходитимуть до рядків до тих пір, поки буде місце для рядка (дані та накладні рядки) плюс 2-байтові накладні масиви слотів. Сторінки даних у Heaps, однак, не використовують кількість байтів, залишених на сторінці, а натомість використовують дуже узагальнений показник того, наскільки повна сторінка, і не так багато рівнів, про які повідомляється. Рівні - це щось середнє: 0%, 20%, 50%, 80% і 100% повно. І він перемкнеться на 100%, поки ще є простір для іншого рядка (а насправді, якби таку ж кількість рядків було вставлено в операцію на основі набору, то вона заповнила б сторінку якомога більше). Звичайно, так само, як і зDELETE операції, відновлення Heap запакує стільки рядків, скільки вміститься на сторінці даних.
Тепер розглянемо наступну інформацію, взятою з розділу "Коли відбувається стиснення сторінки" на сторінці "Документи Microsoft" для реалізації стиснення сторінки :
... Коли дані додаються на першу сторінку даних, дані стискаються рядками. ... Коли сторінка заповнена, наступний рядок, який потрібно додати, ініціює операцію стиснення сторінки. Переглядається вся сторінка; ...
Отже, виглядає цілком впорядкованим з цією іншою поведінкою Heap, що їм потрібно буде ВІДНОВЛЕННЯ ТАБЛИЧНОГО ПОВТОРЕННЯ, СТВОРЕННЯ / ЗРОБКА кластерного індексу або зміни в налаштуваннях стиснення даних (усі вони відновлюють купу) до того, як сторінки даних будуть записані оптимально. Якщо Heaps не знають повністю про "цілі сторінки" (поки Купа не відбудується) і не знають, коли сторінка точно заповнена, вони не знають, коли ініціювати операцію стиснення сторінки (при роботі з оновленнями та одинарними -різні вставки).
Ще одна технічна характеристика, яка ще більше обмежила б деякі купівелі від автоматичного застосування стиснення сторінки (навіть якщо вони інакше могли), полягає в тому, що для застосування стиснення потрібно буде перебудувати всі некластеризовані індекси для цієї купи (якщо такі є). Оскільки на цій пов’язаній сторінці "Стиснення даних" також зазначено:
Зміна налаштування стиснення купи вимагає, щоб усі некластеризовані індекси на таблиці були перебудовані так, щоб вони мали вказівники на нові місця рядків у купі.
"Покажчики", на які посилаються, - це ідентифікатори рядків (RID), які є комбінацією: FileID, PageID та слота / позиції на сторінці. Ці RID копіюються в некластеризовані індекси. Будучи точним фізичним розташуванням, вони іноді швидше шукають, ніж обходять b-дерево за допомогою клавіш кластерного індексу. Але один недолік фізичного розташування полягає в тому, що воно може змінюватися, і в цьому і полягає проблема. Однак кластерні індекси не страждають від цієї проблеми, оскільки їх ключові значення копіюються в некластерні індекси як покажчик назад до кластерного індексу. І ключові значення залишаються такими ж, навіть коли їх фізичне розташування змінюється.
Також дивіться:
розділ "Керування групами" на сторінці "Документи Майкрософт" для Heaps (таблиці без кластерних індексів) :
Щоб відновити купу, щоб відновити витрачений простір, створіть кластерний індекс на купі, а потім скиньте цей кластерний індекс.
розділ "Розглядання при використанні стиснення рядків та сторінок" на сторінці "Документи Microsoft" для стиснення даних :
Коли купа налаштована для стиснення на рівні сторінки, сторінки отримують стиснення на рівні сторінки лише такими способами:
- Дані групово імпортуються з активованою масовою оптимізацією.
- Дані вставляються за допомогою синтаксису INSERT INTO ... WITH (TABLOCK), а в таблиці немає некластеризованого індексу.
- Таблиця перебудовується шляхом виконання оператора ALTER TABLE ... REBUILD за допомогою параметра стиснення PAGE.
І твердження, цитоване у питанні.
Не кожен механізм у SQL Server такий, як ми вважаємо, він повинен бути.
Пол Рандал надав настійну рекомендацію щодо управління проблемою.
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2930-fixing-heap-fragmentation/