SQL Server: Поради з відновлення після ушкоджень, стиснення баз даних та інше, HTML, XML, DHTML, Інтернет-технології, статті

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


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


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


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



Нарешті, ви повинні ще раз запустити програму DBCC CHECKDB для перевірки наявності пошкодження, провести аналіз першопричин для того, щоб з'ясувати причину пошкодження, і зробити перші кроки по усуненню проблеми.


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


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


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


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


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


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



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


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


Існує два види ізоляції знімків – один забезпечує цілісність на рівні транзакцій (параметр бази даних: allow_snapshot_isolation), а інший – на рівні інструкцій T-SQL (параметр бази даних: read_committed_snapshot). Параметр на рівні транзакцій потрібно для коректного використання відстеження змін, і він просто називається ізоляція знімків.


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


Дуже детально ізоляція знімків описана в технічному документі моєї дружини Кімберлі Ізоляція знімків.


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


Сховище версій знаходиться в базі даних tempdb, і це є другою можливою проблемою, пов'язаною з продуктивністю. Tempdb може стати самої завантаженої базою даної на деяких примірниках SQL Server, так як вона є спільною для всіх підключень і баз даних. Загалом, база даних tempdb може зробити сильний негативний вплив на продуктивність, навіть без використання керування версіями рядків. Додавання управління версіями рядків означає збільшення навантаження на базу даних tempdb з точки зору використовуваного простору та операцій введення / виводу, що може значно знизити продуктивність.


Більш докладно на цю тему можна прочитати у технічному документі Робота з базою даних Tempdb в SQL Server 2005. Хоча обидва технічних документа, згаданих мною в цій статті, були написані для SQL Server 2005, вони підходять і для SQL Server 2008.


Питання. Перевіряє чи програма DBCC CHECKDB абсолютно все в базі даних? Хтось сказав мені, що ні. А також, чи може налагодження все виправити? Знову ж таки, мені сказали, що ні. Чи можу я зробити щось ще, якщо програма DBCC CHECKDB не є всебічної?


Відповідь. І так, і ні! Програма DBCC CHECKDB є всебічним набором перевірки цілісності, і набір виконуваних перевірок зростає від версії до версії. Ви праві, існує речі, які вона не перевіряє. Всі дуже просто.


Нижче представлено все, що вона виконує:



Більш докладний опис перевірок виходять за рамки обговорення даного питання (але ви можете знайти додаткову інформацію в моєму блозі або в книзі "Внутрішня структура SQL Server 2008"), але кожна сторінка бази даних передається в пам'ять і перевіряється. Ця програма виявить пошкодження, викликані збоями в підсистемі введення / виводу (приблизно 99.99% всіх пошкоджень відбуваються з цієї причини).


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


Система налагодження не може виправити все. Існує ряд ушкоджень, які неможливо виправити за гарантією протягом розумного періоду часу. Список таких ушкоджень невеликий і описаний в моєму блозі CHECKDB під будь-яким кутом: Чи може програма CHECKDB все виправити? Наприклад, перегляньте сторінку пошкодження в системному каталозі – єдиним засобом налагодження є видалення сторінки. Але що якщо на даній сторінці зберігаються метадані для деяких користувачів таблиць в базі даних? Видалення цієї сторінки, безумовно, видалить і ці користувальницькі таблиці, тому налагодження тут неможлива.


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


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


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


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


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


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


Замішання пов'язано з побічними ефектами від обох операцій, а також при виникненні питання, коли потрібно їх застосовувати.


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


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


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


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


Дізнатися більше про журнал транзакцій можна в статті "Розуміння ведення журналу і відновлення", яку я опублікував в лютневому номері журналу. Також у блозі є запис з обговоренням управління розміром журналу транзакцій – дивіться статтю Важливість правильного керування розміром журналу транзакцій.


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


Пол С. Рендал (Paul S. Randal) є керівним директором SQLskills.com і володарем звання MVP по SQL Server. Він працював у групі розробників обробника сховищ SQL Server в Microsoft з 1999 по 2007 рік. Пол написав DBCC CHECKDB / repair для SQL Server 2005 і був відповідальним за розробку базового механізму сховищ при розробці SQL Server 2008. Пол, будучи фахівцем з аварійного відновлення, високої доступності та обслуговування баз даних, регулярно робить презентації на конференціях. Він веде блог за адресою SQLskills.com / blogs / paul, або ви можете зайти в його чат Twitter на Twitter.com / PaulRandal.


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


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

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

Ваш отзыв

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

*

*