Виверт, що дозволяє обійти критичне (Emergency) стан бази даних, MS SQL Server, Бази даних, статті

Інформація в цій статті ставиться до версій Microsoft SQL Server 4.2x, 6.0, 6.5, 7.0

У критичних ситуаціях, база даних може бути представлена ​​Вам, як SUSPECT, через завершення невдачею її відновлення під час старту сервера, причому зазвичай, це перешкоджає будь доступу клієнтів до даних. Однак, існує можливість ручного виведення бази даних зі стану SUSPECT в “bypass mode” (також званого “emergency mode”) і подальшого виконання команди SELECT або запуску програми Bulk Copy (BCP), дозволяють здійснити копіювання даних в інше місце, з метою їх збереження. У той час, коли ніхто не зможе виконувати ніяких легітимних модифікацій даних, за допомогою цієї виверти, можна виконати DUMP TRANSACTION WITH NO_LOG. Зверніть увагу, що використання цієї виверти не підтримується Мікрософт, і є потенційно небезпечною операцією. З цих же причин, якщо відновлення бази при запуску буде здійснюватися занадто довгий час, Ви не повинні переривати цей процес, переводити базу даних в bypass mode, і потім виконувати DUMP TRANSACTION WITH NO_LOG.
Всі операції сервера, виконувані в рамках DUMP TRANSACTION, зазвичай реєструються в журналі, так, що ці операції можна відновити або скасувати. Однак, ці операції, породжені безпосередньо командою DUMP, також займають місце в transaction log. Якщо transaction log переповнений, і місця недостатньо для нормальної роботи сервера, а також для реєстрації операцій DUMP TRANSACTION, використання опції WITH NO_LOG може надати Вам можливість зробити усічення transaction log без реєстрації будь – яких операцій в журналі.
DUMP TRANSACTION WITH NO_LOG правильно зберігає транзакції тільки при відносно нормальних умовах роботи сервера. Сервер сам вживає певних заходів для гарантії успішності відновлення, навіть якщо на сервері відбудеться збій під час цієї операції. У рідкісних випадках автоматичне відновлення (також зване, відновлення при запуску – startup recovery) може закінчиться невдачею, після чого база даних буде відзначена, як SUSPECT. Відновлення закінчиться невдачею з певної причини. Дуже важливо звернути увагу на повідомлення в errorlog, яке відображає причину завершення невдачею відновлення, тому що це може допомогти локалізувати проблему. Відновлення, це процес пошуку і виправлення суперечностей в базі даних, який відновлює або скасовує всі транзакції, які були або активні або завершені після часу виконання останньої контрольної точки. Цей процес грунтується на write-ahead (випереджальної записи) природі transaction log (всі змінені сторінок записуються спочатку в журнал реєстрації транзакцій, і тільки потім в базу даних). Відновлення складається з читання кожного запису журналу, порівняння її timestamp з timestamp відповідної сторінки бази даних, і наступного прийняття або скасування цієї зміни. Скасування відбувається в разі не виконаної транзакції, а відновлення внесеного зміни в разі виконаної транзакції.
Після виявлення в errorlog потрібного повідомлення, яке відноситься до помилки, що спричинила невдачу процесу відновлення, спробуйте перевести стан бази даних в нормальне NORMAL, за допомогою простого перезапуску SQL сервера. Це дозволить Вам спробувати виконати процедуру відновлення вдруге. Ви можете змінити стан бази даних за допомогою збереженої процедури sp_resetstatus. Ця додаткова збережена процедура, яку Ви можете встановити, скориставшись сценарієм Instsupl.sql в каталозі Mssql \ Install. Для отримання додаткової інформації, див. “Resetting the Suspect Status” в документації.
Якщо відновлення все одно зазнає невдачі, зверніть увагу на повідомлення про помилки, і увійдіть у контакт з вашою службою підтримки. Ви повинні також переконатися в наявності і працездатності вашої останньої резервної копії бази даних, тому що вона може знадобиться для відновлення працездатності бази. Проте, багато дані у вашій базі можуть бути все ще доступні, хоча їх цілісність порушена. Ви можете звертатися до цих даними, встановивши попередньо стан бази даних в bypass або emergency mode. Для цього встановіть для бази даних sysdatabases.status в значення: -32768, яке буде застосовано після виконання команди “allow updates”. Наприклад, використовуйте наступну команду:

UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME=’DBNAME’

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

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


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

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

Ваш отзыв

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

*

*