Іноді доводиться зіткнутися із ситуацією, коли плоди багаторічної роботи, які перебувають у SQL-базі даних, опиняються під загрозою. Ця стаття про те, як не допустити втрату даних, а якщо це все-таки сталося, як відновити дані з того, що залишилося від колись нормальної бази.
Отже, почнемо. Ситуація наступна: є сервер із запущеною на ньому 1С+SQL. Під час роботи SQL бази рубанули живлення. Результат плачевний: база перебуває у стані suspect, і коли 1с намагається до неї зачепитися, видається помилка, що мовляв з'єднатися неможливо. база позначена suspect for recovery. Цей режим в принципі означає, що MS SQL 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 "
go
DBCC CHECKDB("
go
Якщо все гаразд, то:
sp_dboption "
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 або вище
Сталося страшне (посипався гвинт, був стрибок напруги, і т.п.) – база в стані suspect і виходити з нього не хоче, щоб ми не робили…
Резервні копіїбаз ми звичайно не робили - може пронесе. Чи не пронесло.
Отже, для відновлення даних нам потрібно:
1. MSSQL сервер, MS SQL Enterprise Manager (EM), MS SQL Query Analyzer (QA) від Microsoft (входить у постачання MS SQL).
2. 1С:Підприємство 7.7 SQL версія.
3. MSSQLRecovery від http://www.officerecovery.com
4. Копія 1cv7.md-файлу від зруйнованої бази даних 1С, копія зруйнованого файлу mdf, приблизно стільки ж вільного місцяна диску, що займає файл.
5. Вільного часу виходячи з розрахунку 3:00 на 1 Гб ваги файлу mdf.
6. Клавіатура, миша, монітор.
Коротко опишу, що робить MSSQLRecovery:
1. Розбирає mdf-файл лише на рівні структури (MFT), формують текстові sql-скрипти, містять схему БД і самі дані з нашої зруйнованої бази.
2. Створює командний файл commit.bat, який запускає консольну версію MS Query Analyzer, який послідовно виконує sql-файли і власне заповнює нашу новостворену базу SQL.
Коментарі на роботу MSSQLRecovery.
Усім хороша програма, може допомогти при безвихідній ситуації. Але є два прикрі моменти, які заважають відновленню роботи бази даних 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. І частіше.
Бази даних є основою основ багатьох корпоративних інформаційних систем. Вони може зберігатися практично будь-яка інформація, починаючи з оперативної і до бухгалтерської документацією. Навіть тимчасова недоступність цієї інформації може призвести до помітних збитків. Що вже говорити про повну їхню втрату! Тим часом така ситуація цілком реальна. Фізично бази даних є звичайнісінькими файлами, які легко можуть виявитися пошкодженими в результаті вірусної атаки, збоїв програмного забезпеченняабо файлової системи, виходу з ладу жорсткого диска, необережні дії користувачів і т.д. У кожному з цих випадків база перестає відкриватися і, відповідно, вся інформація, розміщена у ній, виявляється недоступною.
Допомогти впоратися з цією проблемою і повернути здавалося б остаточно втрачені даних може програма 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 – крайня простота використання. За допомогою цієї програми витягти інформацію з пошкодженої бази даних і зберегти її без попереднього навчання може будь-який користувач, навіть початківець вивчення комп'ютера.
Завантаження...