Питання та відповіді по SQL. Стискання резервних копій, перенаправлення клієнтів за допомогою зеркалирования баз даних, Різне, Програмування, статті

Q Ми збираємося оновити більшість наших серверів до SQL Server 2008, І одна з функцій, появи яких у виробничому середовищі я чекаю з нетерпінням, – стиснення резервних копій. Я знаю, що можу включити її за умовчанням для всіх баз даних на кожному сервері, але я також чув, що, можливо, цього не варто робити. Я не впевнений, чому її може бути небажано включати за замовчуванням, оскільки здається, що втрачати тут нічого. Не могли б ви допомогти пояснити причини цього?

О. Відповіддю тут буде мій незмінно улюблений: все залежить від обставин! Дозвольте мені для пояснення привести деяку базову інформацію.


Ключовим моментом, який слід врахувати, є ступінь стиснення, яку буде мати кожна резервна копія бази даних, коли включено стиск резервних копій. Ступінь стиснення при використанні будь-якого алгоритму визначається тим, які саме дані стискаються.


Випадкові дані (дрібні цілочисельні значення, наприклад) буду стискатися не дуже добре, так що можливий ступінь стиснення буде визначати в основному вміст таблиць і індексів в базі даних.


Ось кілька прикладів випадків, коли стиснення резервних копій може не дати високого ступеня стиснення:




У випадку, коли ступінь стиснення низька, проблема полягає не в самій низького ступеня, а в тому, що ресурси ЦП, використовувані для виконання алгоритму стиснення, не приносять користі. Незалежно від того, наскільки добре можна стиснути ділянку даних, ресурси ЦП завжди використовуються для виконання алгоритмів стиснення і розпаковування.


Це означає, що перед ухваленням рішення про постійне використання стиснення для цієї бази даних необхідно перевірити, наскільки добре кожна база даних стискається в резервну копію. Інакше можлива безглузда трата ресурсів ЦП. Це і лежить в основі того, що ви чули.


Коротко, якщо основна частина баз даних отримає вигоди від стиснення резервних копій, має сенс включити стиск резервних копій на рівні сервера і вручну змінити кілька завдань резервного копіювання, щоб спеціально використовувати параметр WITH NO_COMPRESSION. Як варіант, якщо основна частина баз даних не отримає вигоди від стиснення резервних копій, має сенс відключити стиск резервних копій на рівні сервера і вручну змінити кілька завдань резервного копіювання, щоб спеціально використовувати параметр WITH COMPRESSION.


В. В минулому році ми відновили наші бази даних, щоб внести в них віддзеркалення, що дозволяє в разі збою перейти на дзеркальну копію і продовжити роботу. При розробці системи ми виконували такі переходи для бази даних, і все працювало нормально. Минулого тижня ми зіткнулися з реальним збоєм, і перехід бази даних стався, але всі транзакції програми зупинилися, і додаток не підключилося до відмовостійкої серверу. Як я можу встановити SQL Server в майбутньому, щоб він не скидав підключення до додатків в ході переходу, щоб транзакції могли тривати?


О. Давайте розіб’ємо відповідь на дві частини: як додатки можуть справлятися з отказоустойчивостью і як управляти перенаправленням клієнтів за допомогою зеркалирования баз даних.


Коли відбувається перехід при збої з використанням будь-якої з технологій високої доступності, наявних в SQL Server, Підключення клієнта до потерпілого збій сервера скидається, і всі, хто знаходився в роботі транзакції губляться. Перенесення знаходиться у дорозі транзакції між серверами неможливий (як у випадку переходу при відмову, так і будь-якому іншому). В залежності від застосовуваної технології високої доступності знаходиться в роботі транзакція або не буде існувати взагалі на відмовостійкої сервері, або буде існувати як що знаходиться в роботі транзакція, але буде відкатала назад в якості процесу відновлення працездатності бази даних на відмовостійкої сервері.


Що стосується віддзеркалення баз даних, постійно пересилає записи журналу транзакцій від основного сервера до дзеркального серверу, то зазвичай відбудеться друге – знаходяться в роботі транзакції відкочуються в процесі відновлення працездатності дзеркальної бази даних на новому учаснику безпеки.


В силу цього є дві речі, які додаток повинен вміти робити коректно при роботі на сервері з можливістю переходу на інший сервер при відмові:




  1. Воно повинно мати можливість коректно обробити скидаються підключення до сервера і намагатися відновити підключення після невеликого проміжку часу.
  2. Воно повинно мати можливість коректно обробити скасування транзакції з подальшою спробою відновити транзакцію після установки підключення до відмовостійкості сервера (можливо з використанням диспетчера транзакцій проміжного рівня).

Єдина технологія високої доступності тут, яка не вимагає конкретно змін на клієнті, щоб дозволити перенаправлення клієнтських підключень після переходу, – це відмовостійка кластеризація. Клієнти підключаються до імені віртуального сервера і прозоро перенаправляються до активного вузла фізичного кластера.


У разі технологій високої доступності, таких, як доставка журналів і реплікація, ім’я сервера відмовостійкості відрізняється, а це означає, що після переходу на даний сервер необхідно перенаправлення клієнтських підключень вручну. Це перенаправлення можна виконати кількома способами:




За допомогою зеркалирования баз даних спрацює будь-який з цих варіантів. Але дзеркалювання баз даних також має вбудовані можливості напряму клієнта. Рядок підключення клієнта може прямо вказати ім’я дзеркального сервера, до якого автоматично відбудеться спроба підключення якщо воно неможливе до основного. Цей процес відомий як пряме перенаправлення.


Якщо рядок підключення клієнта неможливо змінити, то може бути можливо непряме перенаправлення, якщо потерпілий збій сервер тепер працює як дзеркальний сервер. Будь-яке підключення до нього буде автоматично перенаправлено до нового учаснику безпеки – але це спрацює, тільки якщо дзеркальний сервер функціонує.


У технічному документі по SQL Server 2005 “Реалізація відмовостійкості додатків за допомогою зеркалирования баз даних” ці варіанти пояснені докладніше.


В. Коли ми перейшли на SQL Server 2005, ми переробили наші великі таблиці, щоб вони поділялися на розділи чином, що дозволяє скористатися пороздільний обслуговуванням і механізмом ковзаючого вікна. Це було описано у випуску за серпень 2008 року (“Поділ, перевірки узгодженості та інше”). Але ми зіткнулися з проблемою. Часом паралельні запити програми відчувають блокування по всій таблиці, навіть коли запити намагаються отримати доступ до різних розділів. Я чув, що в SQL Server 2008 дана проблема виправлена ​​- не могли б ви пояснити, як я можу зупинити це блокування?


Збільшити

Рис. 1. Вивчення блокувань на таблиці, поділеної на розділи


О. Видимий проблема викликана механізмом, що має назву укрупненням блокувань. SQL Server отримує блокування на дані, щоб захистити їх, поки запит читає або записує дані. Він може отримувати блокування на цілі таблиці, сторінки файлів даних або окремі рядки таблиць / індексів, і кожна блокування займає невеликий простір в пам’яті.


Якщо запит викликає отримання занадто великого числа блокувань, SQL Server може вирішити замінити всі блокування на рядки або сторінки в таблиці єдиної блокуванням на всю таблицю (поріг, де це відбувається, становить приблизно 5000 блокувань, але точний алгоритм хитромудрий і налаштовуємо). Цей процес називається укрупненням блокувань.


У SQL Server 2005, якщо запит А працює на одному розділі таблиці і викликає отримання достатнього числа блокувань, щоб викликати їх укрупнення, вся таблиця стає заблокованою. Це може запобігти роботу запиту Б на іншому розділі тієї ж таблиці. В силу цього, запит Б блокується, поки запит А не завершить роботу і не скидає свої блокування.


У SQL Server 2008 механізм поліпшення блокувань був поліпшений, щоб дозволити таблиці виробляти укрупнення блокувань на рівні розділів. У наведеному вище прикладі це означає, що укрупнення блокувань, викликане запитом А, призведе лише до блокування розділу, використовуваного запитом А, а не всієї таблиці.


Тоді запит Б зможе працювати на іншому розділі, не піддаючись блокування. Запит Б навіть зможе сам викликати укрупнення блокувань, яке заблокує тільки розділ, на якому працює запит Б, а не всю таблицю.


Цю модель укрупнення блокувань можна встановити, використовуючи наступний синтаксис:

ALTER TABLE MyTable SET (LOCK_ESCALATION = AUTO);
GO

Цей синтаксис вказує диспетчеру блокувань SQL Server використовувати укрупнення блокувань на рівні розділів, якщо таблиця розбита на них, і звичайне укрупнення на рівні таблиці, якщо немає. Поведінкою за замовчуванням є використання укрупнення блокувань на рівні таблиці. Встановлювати цей режим слід зі обережністю, оскільки в залежності від поведінки запитів він може привести до взаімоблокіровка.


Наприклад, якщо кожен із запитів А і Б викликає укрупнення блокувань різних розділів в таблиці, але потім намагається отримати доступ до розділу, заблокованого іншим, один із запитів буде перерваний монітором взаімоблокіровок.


На малюнку показаний приклад запиту подання системного каталогу sys.partitions (перший набір результатів) і динамічного адміністративного подання sys.dm_os_locks (другий набір результатів), щоб вивчити блокування, утримувані для запитів на таблиці, поділеної на розділи, де відбулося укрупнення блокувань на рівні розділів. В даному випадку існують дві виняткові блокування рівні розділу (блокування HOBT у висновку), але блокування таблиць (блокування OBJECT у висновку) не виняткові, так що декілька запитів зможуть отримувати доступ до розділів, незважаючи на укрупнення блокувань. Зауважте, що ідентифікатори ресурсів для цих двох блокувань розділів збігаються з ідентифікаторами розділів для перших двох розділів таблиці у висновку для sys.partitions.


Раніше в цьому році помістив у блог приклад сценарію, що показує, як працює ескалація блокувань на рівні розділу і потенціал для взаімоблокіровок. У темі електронної документації по SQL Server 2008 під назвою “Блокування в механізмі бази даних” міститься докладне роз’яснення всіх аспектів блокувань в SQL Server 2008.


В. На одному з наших серверів виникли певні проблеми з диском, що містить журнал транзакцій для бази даних, і база даних стала ненадійна. Останнє повне резервне копіювання відбулося п’ять тижнів тому, і відновлення всіх резервних копій журналу також повинно було зайняти занадто багато часу. Проблема виникла у позаробочий час, так що ми відновили зіпсований журнал транзакцій, щоб уникнути простою. У певних обставин це може викликати проблеми. Але якщо ніщо не отримувало доступ до даних, то я вважаю, що все в порядку. Чи вірно ми вчинили?


О. Коротко відповідь полягає в тому, що про відновлення журналу транзакцій я міг би задуматися, тільки якщо відновлення з резервних копій неможливо. Хоча вам і відомі небезпеки відновлення журналу транзакцій (читачі можуть подивитися запис у моєму блозі “Крайні заходи, що застосовуються в першу чергу …”, щоб дізнатися про них), факт того, що база даних стала ненадійною, означає те, що відновлення закінчилося невдачею, – або при відновленні після збою, або при відкат транзакції. Це означає реальну можливість пошкодження даних в базі даних.


Хоча проблема і виникла в тихий час, подумали ви про заплановані і фонових завданнях? У момент ушкодження журналу цілком могла працювати завдання обслуговування, відновлює або реорганізуються кластеризованих індекс. Фонова завдання цілком могла вести фантомний очистку на сторінках в купі або кластеризованих індексі. Будь-яка з цих задач, для прикладу, могла вносити зміни до структури кластеризованого індексу, які у разі непроведення правильного відкату привели б до пошкоджень в базі даних і можливих втрат даних.


Загалом, відновлення журналу транзакцій завжди повинно бути самою останньою і крайнім заходом в будь-якому варіанті аварійного відновлення через величезні можливостей для подальших пошкоджень і втрати даних. Як мінімум, на базі даних необхідно виконати повний DBCC CHECKDB, щоб перевірити, чи немає пошкоджень.


Далі необхідно змінити стратегію резервного копіювання, щоб мати можливість виконувати своєчасні відновлення, а не звертатися до радикальних заходів на кшталт відновлення журналу транзакцій. Дії по розробці цієї стратегії виходять за рамки цієї статті, але я планую висвітлити цю тему у повноцінній спеціальній статті в цьому році. Так що залишайтеся з нами!

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*