Восстановление SQL

Раннее я уже писал о создании резервных копий в MS SQL Server 2012. В данной статье подробно рассмотрим процессе восстановления базы данных из имеющейся резервной копии (резервных копий) в MS SQL Server 2012 (в более ранних версиях, например в MS SQL Server 2008 набор действий аналогичен).

  1. Восстановление базы данных
  2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

1. Восстановление базы данных

Подключаемся к MS SQL Server c помощью программы «SQL Server Management Studio». В Microsoft Windows Server 2012 R2 ее можно найти в списке всех программ.

Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).

Слева, в обозревателе объектов (Object Explorer), раскрываем вкладку «Базы данных» (Server Oblects), находим в списке базу данных из которой (или в которую) необходимо восстановить данные, кликаем по ней правой кнопкой мыши, затем в появившемся контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…)

Запустится мастер восстановления базы данных (Restore Database). Выбираем базу источник (Source for restore), при этом мастер попробует автоматически подобрать последовательность файлов резервных копий для восстановления базы на текущий момент времени.

Если же требуется загрузить данные из конкретного файла или устройства резервного копирования, то необходимо установить соответствующий переключатель в положение «Устройство» (From device) и вручную указать источник для восстановления.

Затем необходимо выбрать базу данных назначения (Destination for restore), т. е. ту информационную базу в которую будут загружаться данные. Эта может быть как база с которой делалась резервная копия, так и любая другая база данных, зарегистрированная на текущем экземпляре SQL Server.

Нажав кнопку «Временная шкала…» (Timeline) можно указать время на которое необходимо восстановить данные. При имеющейся копии журнала транзакций время восстановления можно выбрать с точностью до секунды (или имеющегося checkpoint’а в журнале транзакций).

Очень важно (!) также помнить о том, что если восстановление данных осуществляется в информационную базу отличную от той с которой производилось резервное копирование (т. е. необходимо скопировать базу данных) то на вкладке «Файлы» (Files) необходимо указать путь к файлам этой информационной базы.

На вкладке «Параметры» (Options) можно указать дополнительные параметры резервного копирования. В частности:

  • Флаг «Перезаписать существующую базу данных (WITH REPLACE)» (Overwrite the existing database) указывает, что операция восстановления перезапишет файлы любой базы данных, в настоящее время использующей имя, указанное в качестве базы данных назначения.
  • Флаг «Сохранить параметры репликации (WITH KEEP_REPLICATION)» (Preserve the replication settings) сохраняет настройки репликации при восстановлении опубликованной базы данных на сервере, отличном от сервера, на котором была создана база данных. Этот параметр имеет значение, только если во время создания резервной копии проводилась репликация базы данных.
  • Флаг «Ограничение доступа к восстановленной базе данных (WITH RESTRICTED_USER)» (Restrict access to the restored database) ограничит доступ к базе данных, за исключением пользователей с правами db_owner, dbcreator или sysadmin. Данный параметр имеет смысл использовать, например, если необходимо последовательно восстановить базу из нескольких файлов резервных копий, и доступ пользователей необходимо ограничить до завершения всех операций по восстановлению данных.
  • Если оставить флаг «Создание резервной копии заключительного фрагмента журнала перед восстановлением» (Take tail-log backup before restore) то будет создана резервная копия заключительного фрагмента журнала транзакций. Если для точки во времени, выбранной в окне «Временная шкала резервного копирования» (Backup Timeline) требуется резервная копия заключительного фрагмента журнала, этот флажок будет установлен и снять его будет нельзя.
  • Флаг «Закрыть существующие соединения» (Close existing connections option) переводит базу данных в однопользовательский режим перед началом выполнения процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.
  • Ну и наконец, флаг «Выдавать приглашение перед восстановлением каждой резервной копии» (Prompt before restoring each backup) указывает, что после восстановления каждой резервной копии будет выводиться диалоговое окно с вопросом, нужно ли продолжать последовательность восстановления. Этот параметр позволяет приостанавливать последовательность восстановления после восстановления каждой резервной копии. Он будет полезен, например, когда нужно поменять ленты в устройстве, если на сервере имеется только одно ленточное устройство.

Когда все необходимые параметры установлены нажимаем «ОК» для запуска процесса восстановления базы данных. После того, как все операции по восстановлению будут завершены увидим соответствующее уведомление.

2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).

Сформировавшийся отчет содержит в себе следующие данные:

  • Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
  • Успешные операции резервного копирования (Saccessful Backup Operations)
  • Ошибки операции резервного копирования (Backup Operation Errors)
  • Успешные операции восстановления (Saccessful Restore Operations)

Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.

Помогла ли Вам данная статья?

В разных ситуациях может потребоваться восстановление базы данных 1С из резервной копии. В этой статье опишим действия, которые необходимы для восстановления.

Перед тем, как начать это, требуется убедиться что выполнили следующие предварительные условия:

  • иметь достаточные права на СУБД
  • действительный файл резервной копии база дынных существует для базы данных
  • действительные файлы журнала транзакции существуют для базы данных

Разрешения

Если восстанавливаемая база данных не существует, пользователь должен иметь разрешения create database, чтобы иметь возможность выполнить восстановление. Если база данных существует, разрешение выполнения по умолчанию назначаются членам sysadmin и dbcreator фиксированным ролям сервера и владельцу базы данных (dbo).

Разрешения восстановления предоставляются ролям, в которых информация о членстве всегда доступна на сервере. Поскольку членство в фиксированной роли базы данных можно проверить только тогда, когда база данных доступна и не повреждена (что не всегда имеется при выполнении восстановления, пользователи db_owner фиксированной роли базы данных не имеют разрешения на восстановлении.

Восстановление базы данных

Чтобы восстановить базу данных, выполните следующие действия:

  1. После подключения к соответствующему экземпляру СУБД MS SQL требуется щелкнуть имя сервера, чтобы развернуть дерево серверов в обозревателе объектов.
  2. Разверните Базы данных. В зависимости от базы данных, выберите пользовательскую базу данных или разверните Системные базы данных и выберите системную базу данных.
  3. Щелкните ПКМ базу данных, выберите «Задачи» > «Восстановить» > «База данных», чтобы открыть диалоговое окно «Восстановить базу данных».
  4. В разделе «Источник» страницы «Общие» укажите источник и расположение наборов резервных копий для восстановления, выбрав «Устройство» > «Добавить», а затем найдите файл резервной копии:

Рисунок 1 — Путь к файлу резервной копии

  1. В разделе «Назначение» страницы «Общие» поле «База данных» автоматически заполняется именем базы данных, введите новое имя в этом поле.
  2. В разделе «План восстановления» на странице «Общие» оставьте значение по умолчанию «До последней сохраненной резервной копии» или нажмите «Временная шкала», чтобы открыть диалоговое окно «Временная шкала резервного копирования», где вы можете вручную выбрать момент времени, чтобы остановить действие восстановления.
  3. В разделе Резервные копии для восстановления сетки выберите резервные копии для восстановления. Эта сетка отображает резервные копии, доступные для указанного местоположения. По умолчанию предлагается план восстановления.
  4. Чтобы просмотреть или выбрать дополнительные параметры, на панели «Параметры восстановления» на странице «Параметры» можно выбрать любой из следующих параметров, если это соответствует вашей ситуации:

Рисунок 2 — Окно об успешном завершении

С опциями (не обязательно):

  • Перезаписать существующую базу данных (with replace)
  • Сохранить настройки репликации (with keep_replication)
  • Ограничить доступ к восстанавливаемой базе данных (with restricted_user)

Выберите опцию для поля Состояние восстановления, которое определяет состояние базы данных после операции восстановления:

  • restore with recovery — это поведение по умолчанию, которое оставляет базу данных готовой к использованию, откатывая незавершенные транзакции
    • Дополнительные журналы транзакций не могут быть восстановлены
    • Выберите эту опцию, если вы сейчас восстанавливаете все необходимые резервные копии
  • restore with norecovery оставляет базу данных неработоспособной и не откатывает незафиксированные транзакции
    • Дополнительные журналы транзакций могут быть восстановлены
    • База данных не может быть использована, пока она не будет восстановлена
  • restore with standby оставляет базу данных в режтме только для чтения
    • Он отменяет незавершенные транзакции, но сохраняет действия отмены в резервном файле, чтобы можно было восстановить эффекты восстановления

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

Операции восстановления могут завершится неудачно, если есть активные подключения данных, поэтому желательно установить флажок Закрыть существующие соединения с базой данных назначения, чтобы убедиться, что все активные подключения между Management Studio и базой данных закрыты (этот флажок устанавливает базу данных в однопользовательский режим перед выполнением операций восстановления и устанавливает базу данных в однопользовательский режим после завершения).

Выберите Отображать запрос перед восстановлением каждой резервной копии, если вы хотите получать запросы между каждой операцией восстановления.

Нажимаем ОК, после этого выполнится восстановление базы данных и увидим информационное окно об успешном завершении.

Какими методами восстанавливать разрушенные базы программы 1С:Предприятие 8,1

Зачем нужна эта статья

Есть такая очень правдивая шутка, мол, все администраторы делятся на 2 группы: одни делают бэкапы, а другие будут делать бэкапы. Обычно чем старше человек, тем больше вероятность того, что он принадлежит к первой категории. Впрочем, эта статья как раз и создана для того, чтобы читатель смог перейти в первую категорию

Стандартная документация программ 1С практически не затрагивает тему нештатной работы 1С:Предприятие; часто в этих статьях советуют использовать серверы с разными механизмами резервирования устройств, а также использовать источники бесперебойного питания; ну и, конечно же, иногда делать резервные копии, храня их на флешке, диске или дополнительных винчестерах

Но, как свидетельствует практика, большинство пользователей, и даже администраторов имеют привычку сначала испортить базу, а когда ее восстановить уже нельзя, как впрочем и данные в ней, тогда и кричат о помощи

Методы восстановления данных

Сейчас мы расскажем немного о том, как поступать в случаях, когда резервной копии нет, а база при этом повреждена

1) запишите на бумаге дату и время, когда появились ошибки; это поможет намного быстрее найти и исправить ошибку, когда, например, вы будете просматривать логии. Если не помните точное время, запишите хотя бы приблизительное, или временные рамки, когда, по вашему мнению, могли начаться глюки и ошибки

2) запишите туда же текст ошибки, причем максимально точный – каждый символ и число из этого текста. Также нужно записать номер релиза СУБД, версию программы 1С:Предприятие, и ее текущую конфигурацию

— если возможно, сделайте скриншота экрана, когда на нем высветилась ошибка;

— сделайте пометку, может ли это быть результатом рассинхронизации узлов базы, или нет;

Например, текст ошибки может быть таким:

Ошибка SDBL:
Разрушена структура базы данных 1С:Предприятия. (pos=0)

Или на английском:

Иногда в MS SQL Server база данных может иметь статус Suspect

3) пока еще все помните и все находится в действии, попробуйте восстановить последовательность действий, которые вы делали до этого, и которые возможно были причиной возникновения ошибки;

— если в этом момент будете вносить изменения, сначала обязательно сделайте копию;

4) предложите вашему заказчику прислать базы данных с SQL Server’а или dt-файл, или же архивную копию каталога на адрес v8@1c.ru ;

— это обязательно нужно делать сразу, ведь если заказчик откажется, можно предложить ему платную версию ваших работ;

— для передачи данных в 1С нужно предоставить продукт, зарегистрированный в 1С, а также подписку на ИТС в текущем месяце; учтите, что сроки реакции 1С бывают медленные;

5) спросите у заказчика, какие резервные копии у его есть, или какие другие узлы базы; в дальнейшем их можно будет использовать для восстановления

— обязательно обратите внимание на актуальность этих копий – когда они были сделаны;

— для распределенных баз может быть полезен состав информации, которая регистрируется;

— спросите Заказчика о наличии dt-файла

6) определяем то, что вызвало ошибку – это описано во втором пункте;

— обычно источник ошибки – это MS SQL Server, но все равно нужно внимательно читать текст, исследовать ошибки PostgreSQL отдельно от ошибок MS SQL Server;

— бывает, что ответ уже заложен в источнике ошибки;

— стандартная документация программ 1С описывает такую возможную причины:

При запуске 1С:Предприятие начинает проверять, есть ли в информационной базе таблицы следующие элементы: Config, ConfigSave, Files, Params, _YearOffset, DBSchema, и если какого-то не находит, выдает сообщение о том, что ИБ разрушена

Еще один вариант описан сотрудников компании 1С:

Сообщение об ошибке может появляться в случае, когда отсутствует или заполнена поврежденными данными таблица под названием DBSchema, если в ней есть таблицы DBChanges и DBSchemaOG, но таблицы DBSchema DBSchemaOG не находятся

7) всегда можно поискать в Интернете решение для любого конкретного случая, в том числе того, который случился у вас;

7,1) если разрушена база в файловом варианте, в папке C:\Program Files\1cv81\bin можно найти утилиту под названием chdbfl.exe; используйте ее или попробуйте конвертирование в клиент-серверную версию; если это возможно, конечно;

7,2) В случае с СУБД PostgreSQL можно попробовать ввести команду pg_resetxlog, перед тем обязательно сделав резервные копии каталога DATA. Может быть, PostgreSQL таки запустится, но при этом потеряется часть данных;

7,3) При обменах данными. Войдя в режим предприятия, нужно сделать базу не подчиненной; далее выгрузите из центральной конфигурации и загрузите в периферийную базу, после этого снова сделайте периферийную базу подчиненной. Загружаем изменения в конфигурации, которые во время обмена были выгружены из центральной базы;

7,4) Когда найдены базы со статусом Suspect. Именно такой статус имеют базы, которые находятся в аварийном состоянии. Довольно часто причиной этого являются неполадки с журналом транзакций. Если попробовать подключить базу без журналов, может появиться такое сообщение про ошибку:

Для того чтобы решить такую проблему, можно создать новую базу с таким же именем, и аналогичными по имени и расположению файлами mdf и ldf; пропишите параметр базы autoclose в активное состояние, то есть введите autoclose = true

Тепер нужно подменить файл с расширением mdf. Можно также делать проверку физической целостности базы при помощи команды DBCC CHECKDB

Если сервер был остановлен, то сразу запускаем, не обращая внимания на статус базы, а в Query Analyzer выполняем такое:

Use master
go — позволяем изменять данные систeмных баз
sp_configure ‘allow updates’, 1 –- для 2000
reconfigure with override –- для 2000
go –- сохраняем значение
select status from sysdatabases where name = ‘имя базы’ –- для 2000
go –-изменяем статус данной базы
update sysdatabases set status= 32768 where name = » –- для 2000

alter database set emergency –- для 2005
go
После перезапуска SQL Server прописываем в командной строке следующее:

Net stop mssqlserver
Net start mssqlserver

База должна быть видимой, если работаем в режиме emergency mode

Дальше создаем новый Журнал транзакций и проводим полное тестирование вот так:

ALTER DATABASE <Имя БД> SET SINGLE_USER –- для 2005
GO
USE имя_базы
GO
DBCC CHECKDB(‘имя_базы’, REPAIR_ALLOW_DATA_LOSS)

/*Этот код ищет Журнал транзакций по старому пути. Если база уже находится на другом компьютере, то нужно создать временный пустой Журнал транзакций в той же папке и на том же диске, что и раньше. После восстановление можно его перенести

Если у вас не получилось перевести базу в singleusermode, то проверку целостности может получить сделать через dbo only mode, для этого просто уберите знак – в строке:*/

— sp_dboption », ‘dbo use only’, ‘true’
GO
sp_dboption », ‘single_user’, ‘false’ –- для 2000

alter database set multi_user –- для 2005
GO
USE master
GO — запрещаем изменения в системных базах
sp_configure ‘allow updates’, 0 –- для 2000
GO

7,5) Откат к конфигурации базы данных. Эта ошибка исправляется, если открыть конфигуратор данных с помощью ключей запуска /RollbackCfg;

7,6) При тяжелых случаях, когда не запускается конфигуратор, а то и конфигурация не открывается, можно использовать такое, но только для СУБД MS SQL Server 2005:

7,7) наиболее тяжелый случай, когда конфигурация испорчен дальше некуда, но она является стандартной или похожа на стандартную, а также в случае если известен ее номер:

— создает чистую конфигурацию из стандартной;

— используем скрипт из пункта 7,6, но в нем вместо

SELECT * FROM Config

Прописываем SELECT * FROM dbo.Config

— снова выполняем скрипт, но не для ., а теперь уже для .;

— делаем реструктуризацию и реиндексацию

— делаем обновление;

— выполняем ТиС, но с очисткой испорченных ссылок

Работает ли все это?

Конечно, гарантий успешности этих мероприятий никто не дает, но уже многим людям данные советы помогли; но самый главный совет – регулярно делайте бэкапы!

Теги материала: база, 1с, бухгалтерия, предприятие, сломалась база, зависла база, повредилась база, не открывается база

Случилось страшное (посыпался винт, был скачок напряжения, и т.п.) – база в состоянии 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 часа на 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. И почаще.

Add a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *