Пол С. Рендал
Перехід на новий дисковий масив
По-перше, переведіть базу в автономний режим, використовуючи наступну команду. Якщо до бази даних підключені користувачі, потрібно попередньо скинути їх підключення:
Короткочасні блокування сторінок
Питання: Я не можу розібратися з деякими речами, які стосуються налаштування продуктивності. Я читав кілька разів що потрібно уникати «короткочасних блокувань сторінок». Я не розумію, що означає «сторінка» або «блокування» або чому короткочасна блокування сторінки може бути проблемою. Чи не могли б ви пояснити все це детальніше?
Відповідь: Всі дані в базі даних SQL Server зберігаються в файлах даних. Внутрішня структура цих файлів така, що вони організовані в вигляді послідовностей блоків довжиною 8 КБ, званих сторінками. Сторінка - основна одиниця зберігання і введення-виведення в системі управління сервера SQL Server. Сторінки зазвичай зберігаються в файлах даних на диску, а перед тим як обробити запит, SQL Server повинен вважати і розмістити відповідні сторінки в своєму кеші (ще його називають буферний пул).
SQL Server використовує різні види сторінок для зберігання різних видів реляційних даних (наприклад, рядки таблиці, рядки некластерізованний індексу, текстових або LOB-даних). Є також сторінки, які зберігають частини внутрішніх структур даних, необхідних SQL Server для організації та отримання доступу до сторінок зберігання реляційних даних.
Короткочасна блокування (latch) є полегшеним внутрішнім механізмом, використовуваним SQL Server для синхронізації доступу до сторінки в кеші. Існує два типи короткочасних блокувань, які потрібно відстежувати: звичайна блокування і блокування введення-виведення. Якщо потоку SQL Server доводиться очікувати отримання однієї з цих блокувань, це негативно позначається на продуктивності.
Коли SQL Server очікує читання з диска частини файлу даних, можуть створюватися блокування введення-виведення сторінки. Якщо такі блокування займають занадто багато часу, це зазвичай вказує на проблеми з продуктивністю дискової підсистеми (тобто, на її перевантаження).
Спроба кількох потоків SQL Server отримати доступ до однієї сторінки файлу даних в пам'яті в умовах конкуренції за цей доступ може привести до очікування завершення блокування сторінки. Найчастіше це відбувається при інтенсивному використанні малих тимчасових об'єктів в базі tempdb.
Докладне пояснення, як спостерігати і вирішувати проблему короткочасної блокування сторінок, виходить за рамки цієї рубрики, а за більш детальною інформацією звертайтесь до наступних джерел:
Гортаючи моментальні знімки баз даних
Питання: Тільки що я відкрив для себе моментальні знімки баз даних. Тепер я розглядаю їх як альтернативу повного відновлення і резервного копіювання журналів. Я планую створювати знімок кожну годину або близько того, і якщо щось піде не так, я зможу відновити пошкоджені дані. Такий шлях відновлення даних представляється набагато менш важким і набагато швидшим. Щось не так з таким планом?
Моментальний знімок бази даних дозволить відновити дані, випадково видалені з неї, якщо сама база все ще доступна. Наприклад, якщо видалена з бази даних таблиця все ще є в моментальному знімку, його можна використовувати, щоб відновити вилучену таблицю.
При цьому ідея створювати занадто багато знімків бази даних (в якості заміни для резервного копіювання журналу транзакцій кожні півтори години) явно невдала через можливі проблеми з ресурсами. Перш ніж замінити сторінку бази даних (докладніше див. Розділ «Короткочасні блокування сторінок»), потрібно її синхронно скопіювати в усі існуючі знімки бази даних, в яких версії цієї сторінки ще немає. Чим більше знімків бази даних, тим більше сторінок потрібно копіювати, а продуктивність при цьому падає.
Ще однією причиною не створювати занадто багато знімків бази даних є те, що кожен з них буде містити копії сторінок бази даних до внесення в них змін. Кожен з них буде зростати в міру збільшення числа змін в базі даних. Це може привести до проблем з дисковим простором, а також з продуктивністю.
Свет мой, зеркальце.
Питання: Мене попросили створити дзеркало нашої бази даних, але я боюся, що дзеркальне відображення бази даних не вирішить нашу проблему. Ми мали проблеми з перекручуванням даних в мережі пристроїв зберігання (SAN), тому для страховки плануємо створити дзеркальну базу даних. Чи не будуть все спотворення автоматично потрапляти на дзеркало? Як віддзеркалення бази даних допоможе вирішити цю проблему?
Відповідь: Дуже цікавий і складний питання, у багатьох викликає нерозуміння і збентеження. Здавалося б, що за будь-якої технології створення надлишкових копій бази даних спотворення даних будуть поширяться з основної бази даних на дзеркало, але в дійсності цього не відбувається.
Ключ - у розумінні, як працює дзеркало бази даних. Звичайно ж, спотворення будуть потрапляти на дзеркало, якщо механізм синхронізації цілком копіює сторінки бази даних з основної бази даних на дзеркало. Спотворені сторінки з основної бази даних в цьому випадку будуть потрапляти на дзеркало.
Навіть якщо сторінка бази даних пошкоджена базової підсистемою введення-виведення основної бази даних, пошкодження просто не зможуть напряму потрапити на дзеркало. Найгірше, що може статися - SQL Server не зможе виявити пошкоджені сторінки (через відключення контрольних сум сторінок) і пошкоджене значення стовпця буде використано для розрахунку значення, що зберігається в базі даних. В результаті неправильний результат потрапить в дзеркало бази даних - це так зване пошкодження другого порядку. Як я вже говорив, якщо включена перевірка контрольних сум сторінок, спотворення буде залишатися непоміченим при читанні сторінки з диска, а спотворень другого порядку не буде.
Така поведінка також пояснює, чому перевірка цілісності основної бази даних не дає ніякої інформації про цілісність стану дзеркальної бази даних і навпаки. Це дві незалежні бази даних, підтримувані в синхронізований стані за рахунок доставки описів фізичних змін в базу даних, а не конкретних сторінок бази даних.