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

Отже, почнемо. Ситуація наступна: є сервер із запущеною на ньому 1С+SQL. Під час роботи SQL бази рубанули живлення. Результат плачевний: база перебуває у стані suspect, і коли 1с намагається до неї зачепитися, видається помилка, що мовляв з'єднатися неможливо. база позначена suspect for recovery. Цей режим у принципі означає, що MSSQL Server спробує відновити базу власними засобами. Я не став ні чого чіпати і залишив все на ніч, сподіваючись, що до ранку база відновиться, але і вранці було те ж саме, і до бази ні як не підібратися. Backup за законом підлості є, але він триденної давності, плюс є купа документів які проводяться лише з базі, а, по паперовим документам їх немає, тобто. можливості вручну відновити документи немає. Витративши купу сил, і нервів, (які, як відомо, не відновлюються:)), я прийшов до наступної послідовності дій, необхідних для відновлення бази.

1) Основний принцип спочатку – не нашкодь. Глушимо SQL server і копіюємо *.mdf і *.ldf файли від бази убік.
2) У принципі, буває, що стан suspect виникає через те, що змінилися шляхи до файлів з базою (наприклад, додався новий диск у системі, який потім забрали, перейменували папку з базою і т.д.). Потім, звичайно, шляхи відновили, але база все одно залишається позначеною як suspect. Ось що ми робимо:
3) Запускаємо SQL Server.
4) Пробуємо підключити базу через Enterprise Manager:
Правою кнопкою по Databases, в меню вибираємо All tasks->Attach database, потім в діалогів вікні вибираємо файл з базою (*.mdf) і встановлюємо необхідні параметри.
5) або через Query Analyser приблизно такою командою:
a. sp_attach_db @dbname = "DemoXMB",
b. @filename1 = "E:\Data\DemoXMB_Data.MDF",
c. @filename2 = "E:\Data\DemoXMB_Log.LDF"
6) Шляхи до бази, звичайно необхідно замінити на свої. Якщо база підключилася, то можна сказати, відбулися легким переляком, якщо ж ні, то продовжимо.
7) Якщо log-файл не пошкоджений (*.ldf), а пошкоджений *.mdf (наприклад, при підключенні бази sql лається на помилки в mdf-файлі), і режим збереження backup'а стоїть full, то відновлюємо базу без відновлення лога транзакцій, майже 100%, що всі страждання на цьому можуть скінчитися.
8) Якщо ж навпаки, пошкоджено ldf-файл, але залишився *.mdf файл, при підключенні база лається на відсутність/ушкодження лога транзакцій. У цьому випадку можна скористатися ХП "sp_attach_single_file_db"

Наприклад:
use master
EXEC sp_attach_single_file_db @dbname = "DemoXMB",
@physname = "c:\mssql7\data\DemoXMB_Dat.mdf"

При виконанні цих команд, створиться файл DemoXMB_Log.ldf в тому ж каталозі, де і база, розміром 1MB і авторозширенням.
Якщо є *.MDF і *.LDF-файли, або дані зберігаються більш ніж в одному фізичному файлі (загальна кількість фізичних файлів, що підключаються, не повинна перевищувати 16-ти), то слід використовувати ХП "sp_attach_db"

Наприклад:
use master
EXEC sp_attach_db @dbname = "DemoXMB",
@filename1 = "c:\mssql7\data\DemoXMB_Dat.mdf",
@filename1 = "c:\mssql7\data\DemoXMB_Log.ldf"

Для підключення більше 16 фізичних файлів до БД слід використовувати команду:
CREATE DATABASE FOR ATTACH

Однак якщо нічого не допомогло, виявилися пошкодженими обидва файли і база все ще може suspect, то можна спробувати скинути стан бази наступною послідовністю: (перед використанням цієї ХП необхідно дозволити пряму зміну системних таблиць)
use master
go
Дозволяємо пряму зміну системних таблиць:
sp_configure "allow updates",1
go
reconfigure with override
go
Для скидання ознаки suspect виконуємо БД master ХП sp_resetstatus:
sp_resetstatus "DataBaseName"
go
А тепер заборонимо пряму зміну системних таблиць:
sp_configure "allow updates",0
go
reconfigure with override
go

В принципі, коли я виконав всі ці кроки, статус suspect скинувся, АЛЕ! при спробі виконати будь-які дії SQL починала лаятися, що база все ще може suspect. І тоді я зробив так:

З QA виконуємо скрипт:
Use master
go
sp_configure "allow updates", 1
reconfigure with override
go

Там же виконуємо:
update sysdatabases set status= 32768 where name = " "

Перезапускаємо SQL Server. У принципі база має бути видна (в emergency mode).

З QA виконуємо:
USE " "
GO
sp_dboption " ", "single_user", "true"
go
DBCC CHECKDB(" ", REPAIR_ALLOW_DATA_LOSS)
go

Якщо все гаразд, то:
sp_dboption " ", "single_user", "false"
go
Use master
go
sp_configure "allow updates", 0
go

Після цього стало можливо переглянути таблиці бази з SQL, а працювати з нею було неможливо. Тепер необхідно за допомогою Data Transformation Services експортувати дані до нової бази. Після цього проводимо відновлення/тестування бази засобами 1С. Увага! Багато хто не звертає уваги на цей дуже важливий пункт. В результаті, ви можете одного разу виявити, що база відновлена, м'яко кажучи, не зовсім коректно. Тобто. у документі замість номенклатури стоятиме щось на кшталт 10122/<Объект не найден>, Це та проблема, яка виникла у мене, варіантів ж може бути безліч. Тому краще згаяти час, але перевірити базу засобами 1С.

Якщо вже зовсім нічого не допомагає, а ці пристрасті як треба відновити, є ще стороння утиліта під назвою MSSQLRecovery. Утиліта платна, але можна скористатися демонстраційною версією, яку можна взяти тут: http://www.officerecovery.com/mssql/download_demo.htm . Програма дуже проста, і відновлення бази зводиться до трьох кроків: 1) вибираємо файл із базою; 2) вибираємо шлях куди зберігати; 3) Тиснемо кнопку recovery; Чекаємо. Програма розбирає SQL-базу по кісточках та складає її в окремий каталог. Туди ж вона додає файл i.bat для відновлення бази з отриманих «шматочків». Я їй не скористався, т.к. зумів відновити основу попередніми кроками.

Але! Тут слід зробити паузу. Стаття не була б повною, якби я не описав методи для запобігання подібним проблемам. Отже, найпростіший і найнадійніший спосіб: архівація, архівація та ще раз архівація. В Enterprise Manager заходимо в меню Tools->Wizards->Management->Backup Wizard і налаштовуємо всі необхідні параметри. В результаті, у мене повне скидання SQL бази на диск відбувається вночі, а потім кожні 15 хвилин backup змін, внесених до бази. В принципі, якби у мене був такий backup, я за пару хвилин зробив би відкат назад, і продовжив би попивати Coca-Cola:).

У разі виникнення додаткових питань/коментарів писати сюди:

Відновити MDF

Якщо база даних Microsoft SQL Server непрацездатна і SQL Management Studio база має статус “suspend” (позначена сірим кольором), то цілісність даних у ній серйозно порушена. Як відновити пошкоджену базу даних зі стану suspend? Як відновити інформацію, що зберігається в .mdf файл бази даних?

Покроковий опис відновлення пошкодженого.mdf файлу:

• Від'єднати (de-attach) базу даних від MS SQL Server у SQL Management Studio
• Створити нову порожню базу даних для подальшого імпорту до неї відновлених даних.
• Запустити SQL Server Repair Toolboxта вибрати.mdf файл, вимкненої бази на першій сторінці програми

Виконати всі кроки всередині програми та:

• або зберегти дані як sql скриптів. Після збереження даних як скрипти SQL на диску потрібно запустити.bat файл з потрібними параметрами для імпорту даних в нову базу даних
• або експортувати дані безпосередньо до нової бази даних.

SQL Server Repair Toolboxне є безкоштовною програмою з відкритим кодом. Користувачі можуть спробувати цю програму перед придбанням за допомогою демонстраційної версії. Програма не має таких ліцензій, як GNU General Public License (GPL) або GNU Lesser General Public License (LGPL).

Системні вимоги: Windows 98 або вище

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

Допомогти впоратися з цією проблемою і повернути здавалося б остаточно втрачені даних може програма SQL Server Recovery Toolbox(). Вона призначена для отримання та збереження інформації з пошкоджених баз MS SQL Server (підтримуються файли Microsoft SQL Server 7.0, 2000, 2005, 2005 64-bit, 2008 і 2008 R2). Звичайно, SQL Server Recovery Toolbox не може гарантувати повного відновлення всіх даних. Необхідно розуміти, що в деяких випадках пошкодження можуть виявитися настільки сильними, що частину інформації витягти просто неможливо. Процес відновлення та збереження інформації з пошкодженої бази даних MS SQL Server за допомогою програми SQL Server Recovery Toolboxздійснюється за допомогою покрокового майстра. На кожному етапі користувач повинен виконати лише одну дію, що дуже зручно та практично.

На першому кроці потрібно вибрати пошкоджену базу даних MS SQL Server. Найзручніше це зробити за допомогою Windows Explorer, який запускається при натисканні на кнопку . Як фільтр відбору автоматично вказані розширення *.mdf та *.ndf (стандартні розширення баз даних MS SQL Server). Усі проаналізовані файли заносяться до спеціального списку швидкого доступу. У майбутньому для їх вибору користувачеві достатньо натиснути на значок , перемістити в списку курсор на потрібний документ і натиснути на ліву кнопку миші.

Перехід на наступний етап здійснюється за допомогою кнопки Next. При цьому програма видасть на екран діалогове вікно з питанням, чи потрібно проводити аналіз вихідного файлу. У разі ствердної відповіді вона витягує з пошкодженої бази службові дані та відображає інформацію, яку вона може відновити. Для зручності користувача вікно поділяється на дві частини. У лівій виводяться всі можливі категорії інформації: користувача та системні таблиці (User Tables і System Tables), уявлення (Views), процедури (Stored Procedures), функції (Functions) і певні користувачем типи (User Defined Data Types). Під час встановлення курсору на будь-якій з них у правій частині буде показано список доступних об'єктів та їх вміст. Користувач повинен уважно переглянути її та переконатися в тому, що програма SQL Server Recovery Toolboxвпорається із завданням і справді зможе відновити втрачені дані.

На наступному етапі відбувається вибір способу збереження інформації. Справа в тому, що в даній утиліті витягнуті з пошкодженого файлу дані можуть бути збережені на жорсткий диск у вигляді набору скриптів на мові SQL або експортовані безпосередньо в базу MS SQL Server. Перший варіант хороший тим, що дозволяє перенести витягнуту інформацію будь-який сервер. Для цього достатньо скопіювати отриманий в результаті роботи пакет скриптів на комп'ютер і запустити його там. А другий варіант зручніший у тих випадках, коли ПК, на якому здійснюється відновлення, має підключення до потрібної бази даних. У цьому випадку експорт інформації до неї відбувається без будь-яких додаткових дій.

Далі користувачеві необхідно вибрати інформацію, яку потрібно відновити із пошкодженого файлу та зберегти. Для цього програма SQL Recovery Roolboxзнову відображає на екрані те, що може витягти. А користувач повинен за допомогою установки/зняття прапорців у чекбоксах відзначити потрібні дані. Вибирати або знімати вибір можна відразу ж з усієї бази даних, цілих категорій інформації або окремих об'єктів (таблиць, уявлень, процедур, що зберігаються і т.д.).

Після завершення вибору можна запускати процес сканування вихідного файлу і збереження видобуваної їх інформації. Для цього необхідно натиснути кнопку Start Recovery. Тривалість цієї роботи залежить від двох факторів. По-перше, від вихідного файлу, його структури та розміру. А по-друге, від продуктивності комп'ютера, де вона виконується. Варто зазначити, що в деяких випадках бази даних мають величезні розміри, а тому відновлення інформації з них може тривати кілька днів. Відразу після закінчення процесу програма SQL Server Recovery Toolbox видасть на екран балка. У ньому наводяться дані щодо всіх процесів відновлення інформації, реалізованих протягом поточної сесії роботи.

Таким чином, програма SQL Server Recovery Toolbox є вдалим засобом відновлення даних з пошкоджених баз MS SQL Server. Вона вирізняється двома особливостями. Перша їх - ефективність. Утиліта, що розглядається, здатна відновити з пошкодженого файлу можливий максимум інформації. Друга особливість SQL Server Recovery Toolbox – крайня простота використання. За допомогою цієї програми витягти інформацію з пошкодженої бази даних і зберегти її без попереднього навчання може будь-який користувач, навіть початківець вивчення комп'ютера.