Розподілені транзакції, лічильники продуктивності і резервні копії SQL, Інтеграція додатків і даних, Бази даних, статті

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


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


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


Якщо розподілена транзакція активна, координатор транзакцій на учасника дзеркального відображення намагається з'ясувати стан транзакції і йому це не вдається через іншого ідентифікатора ресурсу. Координатор не розпізнає його, так як спочатку не брав участі в розподіленої транзакції.


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


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


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


Відповідь: SQL Server виконує багато обов'язкових допоміжних операцій, їх називають фоновими завданнями. Одна або кілька таких завдань і викликають активний введення-виведення. Ось лише кілька "підозрюваних":


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


Автоматичний стиск: Це завдання автоматично видаляє порожній простір в базі даних. Вона переміщує сторінки з кінця файлів даних на початок, таким чином консолідуючи вільний простір в кінці файлу, і потім буде скорочуватися файли. Ви можете включити цю задачу, але це зовсім не обов'язково – вона викликає проблеми фрагментації індексів (що знижує продуктивність) і використовує багато ресурсів. Зазвичай в базі даних активовано автоматичне збільшення розміру файлу, тому так дуже легко організувати нескінченний цикл "стиснення-збільшення" і маса роботи буде виконуватися даремно. Перевірити стан всіх баз даних дозволяє такий запит:


SELECT name, is_auto_shrink_on FROM sys.databases


SEОтложенное звільнення: Це завдання відповідає за видалення або усікання таблиць і індексів (усікання індексів може вимагатися через операцію перестроювання індексів, коли після створення нового індексу старий вилучається). У маленьких таблицях і індексах звільнення виконується негайно, а у великих – фонової завданням. При цьому потрібно гарантувати, що всі необхідні блокування будуть отримані без перевищення розміру доступної пам'яті. Для контролю цього завдання можете використовувати лічильники продуктивності, контролюючі відкладене звільнення.


Відкладена запис: Це завдання видаляє старі сторінки з кеша в пам'яті (його ще називають буферним пулом). Коли сервер близький до нестачі пам'яті, сторінки можуть видалятися навіть при наявності змін в них. У тому випадку змінена сторінка повинна бути записана на диск до її видалення з пам'яті. Для спостереження за цим завданням можна використовувати лічильник "Lazy writes / sec", як це описано тут в розділі Books Online.


Всі ці завдання можуть вносити зміни в базу даних. У них зміни виконуються в рамках транзакцій, але при кожній фіксації транзакції згенеровані записи журналу транзакцій повинні записуватися в журнальну частину бази даних на диску. При кожній зміні бази даних повинна створюватися контрольна точка для скидання змінених сторінок файлу даних на диск. Докладніше про це розповідається в моїй статті у випуску журналу TechNet Magazine за лютий 2009 в статті Understanding Logging and Recovery in SQL Server ..


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


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


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



На жаль, ця інформація марна в вашій ситуації – у вас вже є файл з багатьма резервними копіями. Є два способи відновлення з резервних копій: вручну або засобами середовища SQL Server Management Studio (SSMS).


Щоб дізнатися, які резервні копії знаходяться у файлі, можна в SSMS створити "Новий пристрій резервного копіювання" (New Backup Device), посилається на цей файл. Створивши таку посилання. можна дізнатися, що є в цьому пристрої резервного копіювання. З іншого боку, можна скористатися командою RESTORE HEADERONLY. У будь-якому випадку аналізується резервне пристрій і повертається один рядок вихідних даних, що описують кожну копію у файлі. SSMS постачає типи резервних копій інформативним ім'ям. Використовуючи правильний синтаксис, можна дізнатися тип кожної резервної копії та задіяти відповідну команду RESTORE для відновлення з резервної копії. Докладніше див електронну документацію по SQL Server (у даній статті ми використовуємо довідку для версії SQL Server 2008).


Вам доведеться з'ясувати, які резервні копії вибрати для відновлення. У цьому є декілька хитрих моментів, тому що потрібний стовпець результату виконання запиту RESTORE HEADERONLY не відповідає параметру, який треба використовувати для відновлення. Резервні копії у файлі пронумеровані, починаючи з одиниці, причому одиниця відповідає найстарішої резервної копії. Номер вказується в стовпці Position. Щоб відновити резервну копію з певним номером, треба використати пропозицію WITH FILE = <номер> в складі команди RESTORE. Ось приклад:


RESTORE DATABASE test FROM DISK = C: SQLskills est.bak WITH FILE = 1, NORECOVERY; RESTORE LOG test FROM DISK = C: SQLskills est.bak
WITH FILE = 2, NORECOVERY


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


Використовуючи SSMS, файл з резервної копією задають в Майстрі відновлення баз даних, а той автоматично покаже всі наявні у файлі резервні копії і дозволить вибирати потрібні (рис. Приклад показаний на рис. 1.



Використання Майстра відновлення баз даних у SSMS для відображення наявних у файлі резервних копій


Який варіант ви б не вибрали, винятково важливо перед спробою відновити виробничу систему повправлятися на тестовій системі. Один з моїх улюблених принципів: "Не можна говорити, що у вас є резервна копія, поки ви успішно не відновили систему з неї ".


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


Відповідь: Це досить популярне питання, на який, на жаль, немає задовільної відповіді.


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


Так, як же все-таки домогтися бажаного? Залежно від конкретної ситуації можна вибрати один з трьох можливих варіантів.


По-перше, можна виконати операцію стиснення на виробничій базі даних, щоб повернути в систему порожній простір. У цьому випадку відновлена ​​копія бази даних буде містити все те ж, що і виробнича база, але без зайвого пустого простору. Проте ціна цього рішення висока. Виробничу базу даних доведеться потім знову розширити, а операція стиснення надзвичайно ресурсомістка (висока навантаження на процесор, багато операцій введення-виведення і збільшується розмір журналу транзакцій) і викликає фрагментацію індексів. Фрагментацію індексів доведеться усунути, на що будуть потрібні ще ресурси. Це далеко не самий вдалий варіант. (Докладніше про небезпеки стиснення файлу даних див. мій блог.) Можна спробувати видалити вільний простір в кінці файлу (DBCC SHRINKFILE WITH TRUNCATEONLY), але це навряд чи дасть бажаний скорочення розміру.


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


Якщо ви збираєтеся тестувати продуктивність виконання запитів або створення звітів, фрагментація може сильно знизити продуктивність. В іншому випадку можна не звертати увагу на фрагментацію. Для вирішення проблеми фрагментації не можна перебудувати індекси (командою ALTER INDEX … REBUILD), оскільки це потребує додаткового простору і викличе зростання бази даних – треба реорганізувати індекси (Командою ALTER INDEX … REORGANIZE).


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


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


Ця друга резервна копія може далі використовуватися для багаторазового відновлення промислової бази даних мінімального розміру.


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


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


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

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

Ваш отзыв

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

*

*