Відновлення інформації при частковому порушенні mdf (або backup)-файлів.
Сталося страшне (посипався гвинт, був стрибок напруги, і т.п.) - база в стані suspect і виходити з нього не хоче, що б ми не робили ...
Резервні копії баз ми природно не робили - авось пронесе. Чи не пронесло.
Отже, для відновлення даних нам потрібно:
1. MSSQL сервер, MS SQL Enterprise Manager (EM), MS SQL Query Analyzer (QA) від Microsoft (входить в поставку MS SQL).
2. 1С: Підприємство 7.7 SQL версія.
4. Копія 1cv7.md-файлу від зруйнованої бази даних 1С, копія зруйнованого файлу mdf, приблизно стільки ж вільного місця на диску, що і займає файл.
5. Вільного часу виходячи з розрахунку 3 годині на 1 Гб ваги файлу mdf.
6. Клавіатура, миша, монітор.
Коротенько опишу, що робить MSSQLRecovery:
1. Розбирає mdf-файл на рівні структури (MFT), формують текстові sql-скрипти, що містять схему БД і самі дані з нашої зруйнованої бази.
2. Створює командний файл commit.bat, який запускає консольную версію MS Query Analyzer, послідовно виконує sql-файли і власне заповнює нашу новостворену базу SQL.
Всім хороша програма, може виручити при безвихідній ситуації. Але є два прикрих моменту, які заважають відновленню роботи бази даних 1С.
По-перше, програма створює скрипт schema.sql, що містить опис структури таблиць, процедур, функцій, індексів тощо. Даний скрипт виконується першим, створює відповідно таблиці, процедури, функції, індекси та інше в нашій порожній поки ще базі даних. Дуже якісно це робить. За одним «але» - в файлі переплутано порядок проходження полів при створенні структури таблиць. Можливо для інших програм таке «перепутиваніе» не страшно, а ось 1С цього не переварює.
По-друге в створеному пакетному файлі commit.bat використовується консольна версія Query Analyzer (isql.exe), а він чомусь не бажає коректно працювати з кодовою сторінкою cp1251 - перетворює українські символи в OEM-кодування. Нам це теж не підходить.
Власне процедури, які необхідно виконати, щоб було щастя:
1. нацькувати MSSQLRecovery на частково зруйнований файл mdf, дати їй час на обробку і після вказати де ми хочемо зберегти отримані скрипти зі структурою БД і її відновленими даними.
2. Створити нову порожню базу на SQL-сервері.
3. Створити структури нашої бази, скориставшись копією 1cv7.md від зруйнованої бази за допомогою 1С: Конфігуратора.
4. Змінити файл commit.bat. прибравши рядок з викликом виконання скрипта schema.sql - ми вже створили структуру БД за допомогою 1С.
5. Змінити в тому ж commit.bat виклик isql на виклик isqlw - GUI версію Query Analyzer'а. Це потрібно для коректного сприйняття російської кодування. Тобто рядок:
isql -S% 1 -d% 2 -U% 3 -P% 4 -E -I data0001.sql
матиме вигляд:
isqlw -S% 1 -d% 2 -U% 3 -P% 4 -E -i data0001.sql -o out.txt
Параметр «-о» і файл «out.txt» необхідні для коректного запуску GUI-версії QA, в файл «out.txt» буде записаний лог вироблених транзакцій. Замінити потрібно у всьому файлі commit.bat, наприклад в файловому менеджері Far Manager.
6. Запустити файл commit.bat на виконання з чотирма параметрами: - Ім'я сервера SQL - Ім'я нової бази SQL, яку ми створили раніше - Ім'я користувача, що має роль dbowner для цієї бази (зазвичай це sa) - Пароль цього користувача Виглядати буде приблизно так : commit.bat my_sql_server recovery_1c_db sa gfhjkm
Власне все. Замість пакетного файлу можна написати простеньку обробку на 1С, яка з лістингу директорії буде послідовно виконувати скрипти.
Після відпрацювання commit.bat можна запустити 1С і подивитися, на скільки великі втрати. Зазвичай губляться ті дані, які найчастіше використовувалися або використовувалися в момент збою.
А щоб втрат не було - робіть backup. І частіше.