Сторінка 3 з 4
фрагментація індексів
Крім фрагментації на рівні файлової системи і всередині файлу журналу, також можлива фрагментація всередині файлів даних, в структурах, що зберігають дані таблиць і індексів. Всередині файлу даних може статися два базових типу фрагментації:
Мал. 1. Структура сторінки бази даних
Найчастіше внутрішня фрагментація викликається змінами даних, такими як вставки, оновлення та видалення, що може залишити на сторінці порожні місця. Неправильне розпорядження коефіцієнтом заповнення також може сприяти фрагментації, подробиці приведені в технічній документації. Залежно від схеми таблиці / індексу і характеристик програми це порожнє місце може виявитися непридатним для повторного використання після його появи, що може привести до постійного зростання невикористаного місця в базі даних.
Розглянемо, для прикладу, таблицю з 100 мільйонів рядків, де середня запис має розмір 400 байтів. Згодом шаблон зміни даних програми призведе до появи в середньому 2800 байтів вільного простору на сторінку. Спільний простір, необхідне таблицею, становить 59 ГБ, це виводиться шляхом наступного розрахунку: 8096-2800 / 400 = 13 записів на 8-кілобайтні сторінку, потім ділимо 100 мільйонів на 13, щоб отримати число сторінок. Якби простір не пропадало, то на одній сторінці можна було б умістити 20 записів, що зменшує загальний потрібний простір до 38 ГБ. Величезна економія!
Неиспользуемое місце на сторінках даних / індексу може, таким чином, привести до зберігання того ж обсягу даних на більшій кількості сторінок. Це не тільки призводить до більшого витраті місця на диску, але і означає, що запит треба провести більше операцій введення / виводу, щоб прочитати той же обсяг даних. І всі ці додаткові сторінки займають більше місця в кеші даних, займаючи тим самим пам'ять сервера.
На рис. 2 показані свіжостворені сторінки індексу зі 100-відсотковим коефіцієнтом заповнення - сторінки повні, і фізичний порядок сторінок збігається з логічним порядком. На Рис. 3 показана фрагментація, яка може відбуватися після випадкових вставок / оновлень / вилучень.
Мал. 2. новоствореного сторінки індексу без фрагментації, сторінки повні на 100%
Фрагментацію часом можна запобігти, змінивши схему таблиці / індексу, але, як я згадав вище, це може бути дуже складним або неможливим. Якщо запобігання нереально, існують способи усунення фрагментації після її виникнення - зокрема, шляхом відновлення або реорганізації індексу.
Деякі користувачі просто вирішують відновлювати або перебудовувати все індекси щоночі або щотижня (використовуючи, наприклад, варіант з планом обслуговування) замість того, щоб з'ясовувати, які індекси фрагментовані і яке переваги дасть усунення фрагментації. Хоча це може бути хорошим рішенням для мимовільного адміністратора бази даних, який просто хоче застосувати якесь рішення з мінімальними зусиллями, це може виявитися дуже поганим вибором для більших баз даних і систем, де ресурси в дефіциті.
Який би метод не використовувався, настійно рекомендується регулярно шукати і усувати фрагментацію.
Оброблювач запитів є частиною SQL Server, яка вирішує, як слід виконувати запит - а саме, які таблиці і індекси використовувати і які операції виконувати на них для отримання результатів; це називається планом запитів. У число найбільш важливих вхідних даних цього процесу прийняття рішень входить статистика, що описує розподіл значень даних для стовпців усередині таблиці або індексу. Очевидно, щоб бути корисною для обробника запитів, статистика повинна бути точною і свіжої, інакше можуть бути обрані непродуктивні плани запитів.
Статистика створюється шляхом зчитування даних таблиці / індексу і визначення розподілу даних для відповідних стовпців. Статистика може бути побудована шляхом перевірки всіх значень даних для певного стовпця (повної перевірки), але її також можна побудувати на основі зазначеного користувачем відсотка даних (перевірки прикладів). Якщо розподіл значень в стовпці є відносно рівномірним, то перевірки прикладів може бути досить, і це робить створення і оновлення статистики швидшим, ніж при повній перевірці.
Мал. 4. Зміна параметрів бази даних через SQL Server Management Studio
Якщо потрібно оновлювати статистику як частина плану регулярного обслуговування, то потрібно пам'ятати про одну хитрість. І UPDATE STATISTICS, і sp_updatestats за замовчуванням використовують раніше зазначений рівень збору даних (якщо зазначений якийсь) - і він може бути нижче, ніж повна перевірка. Відновлення індексу автоматично оновлюють статистику за допомогою повної перевірки. У разі поновлення статистики вручну після відновлення індексу можна отримати ще менш точну статистику! Це може статися, якщо перевірка прикладів з поновлення вручну перепише повну перевірку, створену відновленням індексу. З іншого боку, при реорганізації індексу статистика взагалі не оновлюється.
Знову-таки, багато хто має план обслуговування, відновлювальний всю статистику в будь-який момент до або після відновлення всіх індексів - і самі того не знаючи, вони можуть виявитися з менш точною статистикою. Якщо вибрано просте відновлення всіх індексів час від часу, то воно подбає і про статистику. У разі вибору більш складний шлях з усуненням фрагментації, це варто робити і для обслуговування статистики. Я пропоную наступне:
- Проаналізуйте індекси і визначте, на якому індексі слід працювати і як провести дефрагментацію.
- Оновлення статистику для всіх індексів, які були відновлені.
- Оновлення статистику для всіх неіндексованих стовпців.
Всі ці питання я постійно бачу на форумах SQL Server, тому в даній статті я збираюся надати огляд системи ведення журналу та відновлення і пояснити, для чого існує ця невід'ємна частина модуля сховищ SQL Server. Буде розглянута архітектура журналу транзакції і те, яким обр.
Але хіба це єдине, що можна зробити? Існує можливість проводити попереджуючий моніторинг продуктивності, просту процедуру управління, яка використовує визначення базових параметрів роботи системи, отримання еталонів і безперервне спостереження. У цій статті я розповім про те, як п.
Однак вам не обов'язково так поступати. Є дуже проста альтернатива, яка використовує те, що ще відомо під назвою хеш-блоків або хеш-ключів. Що таке хешування? Говорячи коротко, хешування - це цілочисельний результат алгоритму (відомого як хеш-функція), що застосовується до заданої рядку.