Розмір бази даних, фрагментація індексів і доступність після переходу при збої - ось які питання цікавлять адміністраторів в цьому місяці.
Пол С. Рендал
бійтеся фрагментації
Питання Я прочитав кілька записів в блогах, в яких начебто мається на увазі, що не потрібно піклуватися про фрагментацію індексів в базах даних, розміщених на твердотільних (SSD) дисках, так як вони працюють набагато швидше звичайних жорстких дисків. Я правильно розумію, що падіння продуктивності буде зупинено, але чи можу просто ігнорувати фрагментацію індексів?
Відповідь Незалежно від використовуваних дисків - звичайних або твердотільних, потрібно дуже уважно стежити за фрагментацією. Фрагментація індексів пов'язана з двома явищами - неупорядкованими сторінками індексів і проблемами щільності сторінок. Перше явище знижує ефективність читання, під час сканування діапазонів сторінок, а друге знижує щільність даних.
Це правда, що затримки при читанні і запису на SSD-дисках дуже малі. Відповідно, потреба в більш частих і дрібних операціях введення / виводу, обумовлених фрагментацією індексу, не робить такого сильного ефекту на продуктивність, як при використанні звичайних жорстких дисків.
Однак зниження щільності даних через фрагментації індексів все одно може представляти проблему. Фрагментація індексів відбувається в основному через операцій, які називаються «розбиттям сторінок». Справа в тому, що нове вільний простір на сторінці утворюється за рахунок перенесення половини рядків індексу в нову сторінку. При цьому стара і нова сторінки виявляються заповненими приблизно наполовину. У разі високої фрагментації індексу дуже часто трапляється, що середня щільність сторінок становить 70% або менше (тобто в сторінці 30% вільного простору).
А це означає, що при наявності великої кількості індексів ваших базах даних, дорогі твердотільні диски зберігають великий обсяг порожнього простору, Зрозуміло, що така ситуація далека від оптимальної. Також хоча додаткові операції введення / виводу, необхідні в сторінках низької щільності, які не становлять значної проблеми на SSD-дисках, вони займають більше місця в буферному пулі SQL Server (кеші файлів даних в пам'яті). Це також означає, що цінний пам'ять сервера використовується неоптимально.
Крім самої індексації індексів треба врахувати її причину: розбиття сторінок. Це дорогі операції, які генерують багато записів транзакцій в журналі (у моїй записи в блозі я розповідаю, як сильно це може погіршувати ситуацію: blog post Ці додаткові записи журналу означають потребу в додатковій обробці в будь-якому компоненті, що читає журнал транзакцій (наприклад, при реплікації транзакцій, створення резервної копії, дзеркальному відображенні бази даних, доставки журналу). Це може викликати зниження продуктивності цих процесів. Тому не варто ігнорувати фрагментацію, навіть якщо ви использ ете швидкі SSD-диски.
Не дивіться в дзеркало
У механізмі дзеркального відображення баз даних відсутня підтримка підписки на дзеркальну БД (так як для дзеркального відображення публікуються БД існує агент читання журналу). Разом з тим, ви можете використовувати метод «ініціалізація з lsn» для забезпечення швидкої реініціалізації після переходу в системі дзеркального відображення.
Ця методика базується на визначенні реєстраційного номера транзакції самої останньої операції реплікації, яка застосовується до бази даних передплатника перед переходом дзеркального відображення. Ми будемо називати це LSN2.
Деякі операції також дзеркально відображаються на дзеркало БД перед переходом. Це може, наприклад, створювати номер LSN3, який знаходиться трохи далі по часу, ніж LSN2. Будуть також операції, які взагалі не застосовані до БД передплатника. Вони більш ранні, ніж LSN2 або LSN3. Ми назвемо їх LSN1.
Всі операції аж до LSN2 застосовані до основної бази даних підписки. Всі операції плоть до LSN3 застосовані до основної бази даних підписки і скопійовані на дзеркальну базу даних. Для виконання операції ініціалізації з LSN для нової передплати після переходу на дзеркало в якості аргументу в sp_addsubscription треба передати LSN3.
занадто велика
Питання Розмір нашої головної бази даних досяг 9 ТБ. Виявилося, що у нас просто не вистачає потужностей для виконання регулярного обслуговування так, щоб це не позначалося на поточній роботі підприємства. Найбільше нас турбує архівування бази даних для забезпечення можливості відновлення в разі аварії. Що б ви порадили в такій ситуації?
У будь-якому випадку ключова проблема полягає в створенні декількох файлових груп в базі даних. При секціонуванні окремі секції великих таблиць або індексів розташовуються в окремих файлових групах. При ручному розбитті кожна велика таблиця розташовується в окремій файлової групі (можливо, з усіма індексами).
В таких обставинах відновлення в разі збою також виконується швидше (якщо використовується редакція Enterprise Edition). Вам достатньо буде швидко відновити файлові групи, які необхідні для роботи OLTP-систем. Для цього можна скористатися частковим відновленням, після якого використовувати часткову доступність базу даних для повернення бази даних в інтерактивний режим. Відновити файлові групи, що містять більш старі дані, можна пізніше, скориставшись частковим відновленням, коли OLTP-операції відбуваються в уже доступних файлових групах.
В умовах перевантаження
Само по собі одне значення PLE малоинформативно. Потрібно дивитися на тенденції значень. Цілком можливо, що цілком легітимні операції SQL Server приведуть до значного зниження показань PLE. Часто свідчення повертаються до норми. Якщо показання PLE знижуються і залишаються низькими, тоді варто хвилюватися.
Поріг, при якому потрібно реагувати, не є фіксованим значенням, як про це часто пишуть. Значення 300 означає, що весь буферний пул замінюється кожні 300 секунд. Якщо у вас пул розміром 100 ГБ, то це означає, що 100 ГБ нових даних зчитуються в пам'ять кожні п'ять хвилин. У наявності проблема з продуктивністю. Однак це стає величезною проблемою з продуктивністю задовго до того, як PLE досягає значення 300. Можна підрахувати більш розумне значення: (<размер буферного пула в ГБ> / 4) × 300, як описано в наступному записі в блозі:
PLE саме той лічильник, за яким треба стежити, але його свідчення мають сенс, якщо вони падають значно нижче норми і залишаються довго в такому положенні. Це загальна рекомендація, і вона, на жаль, підходить не у всіх ситуаціях.