О. Відповіддю тут буде мій незмінно улюблений: все залежить від обставин! Дозвольте мені для пояснення привести деяку базову інформацію.
Ключовим моментом, який слід врахувати, є ступінь стиснення, яку буде мати кожна резервна копія бази даних, коли включено стиснення резервних копій. Ступінь стиснення при використанні будь-якого алгоритму визначається тим, які саме дані стискаються.
Випадкові дані (дрібні цілочисельні значення, наприклад) буду стискатися не дуже добре, так що можливий ступінь стиснення буде визначати в основному вміст таблиць і індексів в базі даних.
Ось кілька прикладів випадків, коли стиснення резервних копій може не дати високого ступеня стиснення:
- Якщо в базі даних включено прозоре шифрування даних, то ступінь стиснення буде дуже низькою, оскільки дані стискаються в випадкових дрібних значеннях.
- Якщо основна частина даних в базі даних стискається на рівні стовпців, то ступінь стиснення знову ж буде низькою, оскільки стиснення стовпців, по суті, перемішує дані.
- Якщо стиснення даних включено для більшості таблиць в базі даних, то ступінь стиснення буде низькою; стиснення даних, які вже в основному стиснуті, зазвичай дає малий ефект.
У разі, коли ступінь стиснення низька, проблема полягає не в самій низького ступеня, а в тому, що ресурси ЦП, які використовуються для виконання алгоритму стиснення, не приносять користі. Незалежно від того, наскільки добре можна стиснути ділянку даних, ресурси ЦП завжди використовуються для виконання алгоритмів стиснення і розпаковування.
Це означає, що перед ухваленням рішення про постійне використання стиснення для цієї бази даних необхідно перевірити, наскільки добре кожна база даних стискається в резервну копію. Інакше можлива безглузда трата ресурсів ЦП. Це і лежить в основі того, що ви чули.
Якщо коротко, якщо основна частина баз даних отримає вигоди від стиснення резервних копій, має сенс включити стиск резервних копій на рівні сервера і вручну змінити кілька завдань резервного копіювання, щоб спеціально використовувати параметр WITH NO_COMPRESSION. Як варіант, якщо основна частина баз даних не отримає вигоди від стиснення резервних копій, має сенс відключити стиск резервних копій на рівні сервера і вручну змінити кілька завдань резервного копіювання, щоб спеціально використовувати параметр WITH COMPRESSION.
В. В минулому році ми відновили наші бази даних, щоб внести в них віддзеркалення, що дозволяє в разі збою перейти на дзеркальну копію і продовжити роботу. При розробці системи ми виконували такі переходи для бази даних, і все працювало нормально. Минулого тижня ми зіткнулися з реальним збоєм, і перехід бази даних стався, але все транзакції додатки зупинилися, і програма не підключилося до відмовостійкості сервера. Як я можу встановити SQL Server в майбутньому, щоб він не скидав підключення до додатків в ході переходу, щоб транзакції могли тривати?
О. Давайте розіб'ємо відповідь на дві частини: як додатки можуть справлятися з отказоустойчивостью і як управляти перенаправленням клієнтів за допомогою віддзеркалення баз даних.
Коли відбувається перехід при збої з використанням будь-якої з технологій високої доступності, наявних в SQL Server, підключення клієнта до потерпілого збій сервера скидається, і всі, хто був у роботі транзакції губляться. Перенесення знаходиться в дорозі транзакції між серверами неможливий (як у випадку переходу при відмові, так і будь-якому іншому). Залежно від застосовуваної технології високої доступності знаходиться в роботі транзакція або не буде існувати взагалі на відмовостійкість сервері, або буде існувати як що знаходиться в роботі транзакція, але буде відкатав назад в якості процесу відновлення працездатності бази даних на відмовостійкість сервері.
Що стосується зеркалирования баз даних, постійно ретранслює записи журналу транзакцій від основного сервера до дзеркального сервера, то зазвичай відбудеться друге - що знаходяться в роботі транзакції відкочуються в процесі відновлення працездатності дзеркальної бази даних на нового учасника безпеки.
В силу цього є дві речі, які програма має вміти робити коректно при роботі на сервері з можливістю переходу на інший сервер при відмові:
- Воно повинно мати можливість коректно обробити скидати з'єднуватись з сервером і намагатися відновити підключення після невеликого проміжку часу.
- Воно повинно мати можливість коректно обробити скасування транзакції з подальшою спробою відновити транзакцію після установки підключення до відмовостійкості сервера (можливо з використанням диспетчера транзакцій проміжного рівня).
Єдина технологія високої доступності тут, яка не вимагає конкретно змін на клієнті, щоб дозволити перенаправлення клієнтських підключень після переходу, - це відмовостійка кластеризація. Клієнти підключаються до імені віртуального сервера і прозоро перенаправляються до активного вузла фізичного кластера.
У разі технологій високої доступності, таких, як доставка журналів і реплікація, ім'я сервера відмовостійкості відрізняється, а це значить, що після переходу на даний сервер необхідно перенаправлення клієнтських підключень вручну. Це перенаправлення можна виконати декількома способами:
- Можна жорстко закодувати ім'я отказоустойчивого сервера в клієнт, щоб спроби повторного підключення були спрямовані на цей сервер.
- Можна використовувати балансування мережевого навантаження з налаштуванням 100 / 0-0 / 100, що дозволить потім переключити підключення на відмовостійкий сервер.
- Можна використовувати що-небудь на зразок псевдоніма сервера або перемикання записів в таблиці DNS.
За допомогою віддзеркалення баз даних спрацює будь-який з цих варіантів. Але віддзеркалення баз даних також має вбудовані можливості направлення клієнта. Рядок підключення клієнта може прямо вказати ім'я дзеркального сервера, до якого автоматично станеться спроба підключення якщо воно неможливе до основного. Цей процес відомий як пряме перенаправлення.
Якщо рядок підключення клієнта неможливо змінити, то може бути можливо непряме перенаправлення, якщо потерпілий збій сервер тепер працює як дзеркальний сервер. Будь-яке підключення до нього буде автоматично перенаправлено до нового учасника безпеки - але це спрацює, тільки якщо дзеркальний сервер функціонує.
Мал. 1. Вивчення блокувань на таблиці, поділеної на розділи
О. Видимий проблема викликана механізмом, що має назву укрупненням блокувань. SQL Server отримує блокування на дані, щоб захистити їх, поки запит читає або записує дані. Він може отримувати блокування на цілі таблиці, сторінки файлів даних або окремі рядки таблиць / індексів, і кожна блокування займає невеликий простір в пам'яті.
Якщо запит викликає отримання занадто великого числа блокувань, SQL Server може вирішити замінити всі блокування на рядки або сторінки в таблиці єдиної блокуванням на всю таблицю (поріг, де це відбувається, становить приблизно 5000 блокувань, але точний алгоритм хитромудрий і налаштовуємо). Цей процес називається укрупненням блокувань.
Тоді запит Б зможе працювати на іншому розділі, не наражаючись блокування. Запит Б навіть зможе сам викликати укрупнення блокувань, яке заблокує тільки розділ, на якому працює запит Б, а не всю таблицю.
Цю модель укрупнення блокувань можна встановити, використовуючи наступний синтаксис:
Цей синтаксис вказує диспетчеру блокувань SQL Server використовувати укрупнення блокувань на рівні розділів, якщо таблиця розбита на них, і звичайне укрупнення на рівні таблиці, якщо немає. Поведінкою за замовчуванням є використання укрупнення блокувань на рівні таблиці. Встановлювати цей режим слід з обережністю, оскільки в залежності від поведінки запитів він може привести до взаімоблокіровка.
Наприклад, якщо кожен із запитів А і Б викликає укрупнення блокувань різних розділів в таблиці, але потім намагається отримати доступ до розділу, заблокованого іншим, один із запитів буде перерваний монітором взаімоблокіровок.
На малюнку показаний приклад запиту уявлення системного каталогу sys.partitions (перший набір результатів) і динамічного адміністративного подання sys.dm_os_locks (другий набір результатів), щоб вивчити блокування, утримувані для запитів на таблиці, поділеної на розділи, де відбулося укрупнення блокувань на рівні розділів . В даному випадку існують дві виняткові блокування рівні розділу (блокування HOBT у висновку), але блокування таблиць (блокування OBJECT у висновку) не виняткові, так що кілька запитів зможуть отримувати доступ до розділів, незважаючи на укрупнення блокувань. Зауважте, що ідентифікатори ресурсів для цих двох блокувань розділів збігаються з ідентифікаторами розділів для перших двох розділів таблиці у висновку для sys.partitions.
О. Коротко відповідь полягає в тому, що про відновлення журналу транзакцій я міг би задуматися, тільки якщо відновлення з резервних копій неможливо. Хоча вам і відомі небезпеки відновлення журналу транзакцій (читачі можуть подивитися запис в моєму блозі «Крайні заходи, що застосовуються в першу чергу.», Щоб дізнатися про них), факт того, що база даних стала ненадійною, означає те, що відновлення закінчилося невдачею, - або при відновленні після збою, або при відкат транзакції. Це означає реальну можливість пошкодження даних в базі даних.
Хоча проблема і виникла в тихий час, подумали ви про заплановані та фонових завданнях? У момент ушкодження журналу цілком могла працювати завдання обслуговування, відновлює або реорганізуються кластерізованний індекс. Фонова завдання цілком могла вести фантомний очистку на сторінках в купі або кластерізованний індексі. Будь-яка з цих завдань, для прикладу, могла вносити зміни в структури кластерізованного індексу, які в разі непроведення правильного відкату призвели б до пошкоджень в базі даних і можливих втрат даних.
Загалом, відновлення журналу транзакцій завжди має бути самою останньою і крайнім заходом в будь-якому варіанті аварійного відновлення через величезних можливостей для подальших ушкоджень і втрати даних. Як мінімум, на базі даних необхідно виконати повний DBCC CHECKDB, щоб перевірити, чи немає пошкоджень.
Далі необхідно змінити стратегію резервного копіювання, щоб мати можливість виконувати своєчасні відновлення, а не звертатися до радикальних заходів на кшталт відновлення журналу транзакцій. Дії по розробці цієї стратегії виходять за рамки даної статті, але я планую висвітлити цю тему в повноцінної спеціальної статті в цьому році. Так що залишайтеся з нами!