Висит восстановление из копии 1с
В статье показаны способы восстановления базы 1С с помощью встроенных в программу инструментов или сторонних приложений . Как создать и восстановить резервную копию базы данных. Для большинства пользователей продуктов компании 1С , повреждение или утеря базы «1С: Предприятие» есть тем, о чём даже боятся говорить. Для них, задача по восстановлению базы данных кажется просто нереальной, а её утеря страшной трагедией.
На самом деле, продукты компании 1С являются таким же программным обеспечением, как и любое другое. Информация, которую пользователи вносят в свои базы данных сохраняется в файлах, из которых можно создавать резервные копии или восстанавливать в случае повреждения или удаления. Часто для этого достаточно встроенных в «1С: Предприятие» инструментов, но и о стороннем программном обеспечении также забывать не стоит.
Файлы базы данных 1С
Для лучшего понимания того, каким образом происходит восстановление повреждённых или утерянных баз 1С, давайте ознакомимся с файлами, в которых они сохраняются.
По умолчанию, каталогом информационной базы, в котором кроме файла самой базы 1С сохраняются все файлы, которые имеют к ней отношение, является папка в Документах пользователя:
C:\Users\Имя Пользователя\Documents\InfoBase
В этой папке хранятся все файлы, которые имеют отношение к данной базе данных.
К таким файлам относятся:
- *.1CD – файл самой базы данных, который по умолчанию имеет название 1Cv8.1CD. Данный файл включает в себя все данные, которые внесены в базу данных, а также их конфигурацию;
- *.cf, *.cfu (*.cfl), *.dt, *.epf (*.erf) – конфигурационные файлы базы данных;
- *.log, *.lgf, *.lgp, *.elf – лог файлы;
- *.cdn – файл блокировки базы данных 1С;
- *.efd – архивный файл 1С;
- *.mft – вспомогательный файл конфигурации шаблона;
- *.st – файл шаблонов текстов
- *.mxl – файл печатных форм базы данных 1С;
- *.grs – файл графических схем базы данных 1С;
- *.geo – файл географических схем базы данных 1С.
Признаки и причины повреждения базы 1С
Причины повреждения базы 1С могут быть физического или логического происхождения.
Последствия физических причин повреждения баз банных самые тяжелые, так как связаны с повреждением носителя информации, на котором хранятся данные. Это может быть повреждение внешнего или встроенного жесткого диска, оптического носителя информации, флешки или карты памяти. В данном случае, чтобы иметь возможность восстановить базу 1С, необходимо вернуть работоспособность носителю информации.
Логические повреждения баз происходят в результате сбоев в работе программного обеспечения, неправильного или внезапного отключения компьютера или носителя информации, неправильная работа сетевого оборудования, а также вирусы и деятельность вредоносных программ.
Как говорится, админы делятся на тех, кто делает бекапы, и тех, кто уже делает. А из тех, кто уже делает, выделяются те, кто эти бекапы проверяют (народная мудрость).
К сожалению, если есть выгрузка базы в .dt, есть ненулевой шанс эту выгрузку не загрузить обратно, с чем мне в последнее время несколько раз и пришлось столкнуться. И это даже не касается крупных баз, которые не могут загрузиться в файловый вариант. Просто файловая база может быть незначительно повреждена, так что при работе это незаметно, и выгружаться нормально, но выгруженные повреждения не дадут базу загрузить обратно. Например, в результате повреждения в таблице образовалось несколько пустых строк, но по таблице построен уникальный индекс. Или образовалось null-значение в поле с ограничением not null. Или строковые данные повредились, и 1С из строкового поля "на 10 символов" выгрузит 200 символов мусора. Все эти проблемы всплывают только при попытке воспользоваться выгрузкой.
1С загружает базу в следующем порядке:
1. удаляются таблицы базы если они были
2. Создаётся и загружается таблица CONFIG и прочие служебные таблицы и создаётся новая структура таблиц.
3. Таблицы заполняются данными
4. После заполнения очередной таблицы создаются индексы, и начинается заполнение следующей таблицы.
Нужно создать триггерную функцию такого вида:
При загрузке 1С не удаляет триггерные функции, но назначить триггер придётся таблице после её создания. Это можно попробовать сделать через событийный триггер (см. ниже), но я делал есть вручную. Нужно назначить таблице триггер, указать созданную триггерную функцию и событие - BEFORE INSERT
Создать можно в диалоге, или таким запросом:
Где tbl1_flt - произвольно заданное имя
_acc50 - имя таблицы, вставку в которую данных фильтруем
qqqq() - имя созданной триггерной функции
Т.е. сначала нужно создать функцию, затем начать загрузку, и когда таблица появилась - назначить триггер.
Если загрузка прерывается по ошибке неуникальных данных:
Нужно сначала создать функцию, в которой будем чистить лишние данные. К сожалению, есть сложности с определением какая именно команда и над каким объектом вызывается, возможно возникающие исключения будем гасить. Пример такой функции, удаляющей данные:
Здесь я просто удаляю мешающие данные, их можно было удалить и на этапе загрузки в прошлом способе. Но если есть цель оставить из неуникальных записей только одну, придётся писать запрос в обработчике событийного триггера.
Функция создана, теперь надо создать триггер. В диалоге:
Таким образом функция будет вызываться перед каждым созданием индексов, и можно производить разные манипуляции над данными.
Есть база для 1С 8.2 на MS SQL 2005. Настроен полный бэкап каждую ночь, бэкап лога транзакций днём каждые 2 часа. На момент 15 часов потребовалось восстановить базу. Восстановил, Managemeng Studio ответил, что восстановлено. А база зависла в состоянии восстановления из копии.
а ты думал - в сказку попал? Скуль последовательно выполняет все запросы с момента полного бэкапа до 15-ти часов
это как? можно подробнее на 2000 сервере аналогичный приём запуска из консоли срабатывал. А на более продвинутом нужно всё руками делать? восстановить полную копию, а потом руками каждый файл лога транзакций - порядка 5 штук.
в - это мое предположение, что база в состоянии нормальном, а в списке отображается как restoring - встаньте на databases и тыркните f5. Опишите, подробнее, что вы делали. Мож просто забыли при накате последней копии установить галку "recovery", вот оно и ждет, что вы еще что=-нибудь накатывать будете
4 часа прошло, база со всеми логами восстановилась минут за 10. Эта же база, но полный бэкап без логов транзакций восстанавливается и переходит в нормальное состояние. Пробовал с разных серверов через разные консоли заходить - через английскую и через русскую, ответы однозначные как в subj use skip отвечает так: Database 'skip' cannot be opened. It is in the middle of a restore.
а как тогда обеспечить оптимальное время восстановления при аварии? нужно было делать разностный бэкап каждые 2 часа? А лог иначе растёт если не бэкапить. Activiti Monitor пишет что с этой базой сейчас никто не работает
Да кстати. я вот тоже думаю, у меня тут упала база. а бекап только ночной, кое что нужное потерялось. Бекап лога делать не хочтеся, наверное то что очень нужно буду писать в MySQL в процессе дня.
указал момент времени и выбрал всё из предложенного списка - полный бэкап и все логи. 0 строк, с десяток колонок.
restore database [your] with recovery оно (gui), похоже, само базу в это состояние не перевело. Юзайте православные скрипты.
ну так в том и цель топика. Меня бы устроил такой порядок - восстановил из gui потом дополнительно запустил бы скрипт, чтобы вывести базу из ступора.
ну так запустите. я че-т не понимаю что вас останавливает.. попробуйте посмотреть на скрипт, генерируемый gui - в окне восстановления сверху нажмите script-> to new window (или как-то так). И посмотрите что там в самой последней команде restore - with recovery или with norecovery..
почему gui не работает? Зачем он тогда нужен? Допустим потрачу время, найду способ восстановления с помощью скриптов. Через какой-то время забуду или в отпуск уеду, другой человек так же должен мучатся? в gui в раздере параметры в группе окна Состояние восстановления по умолчанию выбран флаг restore with recovery Попробую пока скриптом и отпишусь. Но мне не нравится такой способ. можно в 2-х словах сказать как правильно обеспечить возможность восстановления базы с максимальной потерей времени 2 часа?
спасибо виден конец. )) Как последнюю строку записать? Так? RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn' WITH FILE = 1, RECOVERY RESTORE DATABASE [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009300425.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009300700.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009300900.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009301100.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009301300.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [МояБаза] FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N'2010-09-30T15:24:36' GO
Только что проверил - база висит в Restoring после восстановления полного бэкапа с "RESTORE WITH NORECOVERY", она, собссно, ждет журналов транзакций. З.Ы. А сколько база весит-то, что бэкап журнала каждые 2 часа делается?
8Гб SQL база, 10Гб лог через день сжатие базы данных + первая и последние строки, соответственно так: WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10 WITH FILE = 1, RECOVERY, NOUNLOAD, STATS = 10 База восстановилась, подключу её обратно к 1С-ке, проверю. А как gui заставить не на момент времени восстанавливать, а. чтобы как в этом ручном скрипте? Неужели всегда руками подправлять?
все ясно, gui нормально отработал. Смотрите: В последней команде стоит STOPAT = N'2010-09-30T15:24:36' И там же: FROM DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn', т.е. время создания бэкапа: 201009301500. Т.е. вы пытаетесь восстановиться на несуществующую в ваших бэкапах точку времени. SQL Server понимает, что такого времени нет и оставляет базу данных в состоянии restoring, чтобы вы могли накатить следующие бэкапы, содержащие в себе это время.
а если это последний бэкап, как сказать об этом? смотреть время последнего лога и устанавливать это время? Или дату начала или дату окончания(Start date Finish Date)?
Перед тем как делать восстановление из бэкапа, сделал полный бэкап, поэтому пришлось в gui вводить время чуть больше чем последний лог транзакций и меньше чем последний полный бэкап.
почитайте в BOL про цепочку восстановления. Вы всегда начинаете восстановление с полного бэкапа, а затем, последовательно, "накатываете" резервные копии журналов транзакций. В 2005-м sql server'e полный бэкап не прерывает цепочку журналов (т.е. после снятия последнего полного бэкапа надо было сделать еще одну резервную копию журнала транзакций и использовать ее в своей, "использованной" цепочке) и не поддерживает восстановление на момент времени. Из полного бэкапа вы можете восстановиться только на момент создания бэкапа. Т.е., чтобы вам восстановиться на указанный вами момент времени надо снять еще одну копию журнала транзакций (после полной резервной копии) и проделать все тоже самое, что вы уже делали, но в качестве последней копии указать последнюю копию журнала транзакций. Фух.. надеюсь, понятно :)
сколько делается полный бэкап? может есть смысл делать полные копии вместо бэкапа лога? --- хотя к текущей ситуации это отношения не имеет
только резервное копирование журнала транзакций дает вам возможность восстановиться на ЛЮБОЙ момент времени, начиная от времени создания первой резервной копии журнала транзакций и заканчивая временем создания последней копии.. Вот, нашел-таки ссылку
понятно, нужно будет потренироваться пока база не перешла на полную нагрузку ;) Можно было поступить так. сделать бэкап лога транзакций, потом полный бэкап, а потом восстановить на нужное время до момента возникновения проблем. Но попробовал глянуть на скрипт для другой базы. Логов там до конца дня, я задал момент времени 13 часов, вот последняя строка: _backup_201009301400.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N'2010-09-30T13:16:19' RECOVERY там нет не проверял время, проверил объем. полный бэкап порядка 4Гб, все логи за весь день порядка 600Мб в сумме. А диск для бэкапов не резиновый ))
20 гб база бэкапится в онлайн режиме 51 сек потом 40 минут сжимается до 1,5 гб но я не навязываю свою точку зрения
не пробовал ещё )) спасибо за ссылку. давно подобное читал, но потерял ссылки. во времена 2000 серверов даже держал в голове ;) самым важным будет время восстановления после сбоя. В течение дня все сервера загружены делом, сжимать и разжимать нужно время и ресурсы.
+ На восстоновление после сбоя , больше всего времени ушло на загрузку бекаппа. на тупом серваке 3 часа 30минут. против 30 минут на нормальном серваке. база 80 гб
и теперь база данных застряла в состоянии восстановления.
некоторые люди предположили, что это потому, что в резервной копии не было файла журнала, и его нужно было свернуть с помощью:
кроме того, что, конечно, не удается:
и именно то, что вы хотите в катастрофической ситуации, - это восстановление, которое не будет работа.
резервная копия содержит как данные, так и файл журнала:
вам нужно использовать WITH RECOVERY опция, с вашей базой данных RESTORE команда, чтобы привести вашу базу данных в режиме онлайн в рамках процесса восстановления.
Это, конечно, только если вы не собираетесь восстанавливать резервные копии журналов транзакций, т. е. вы хотите восстановить резервную копию базы данных, а затем иметь доступ к базе данных.
ваша команда должна выглядеть так,
У меня была эта ситуация восстановление базы данных в экземпляр SQL Server 2005 Standard Edition с помощью Symantec Backup Exec 11d. После завершения задания восстановления база данных осталась в состоянии" восстановление". У меня не было проблем с дисковым пространством-база данных просто не вышла из состояния "восстановление".
Я запустил следующий запрос к экземпляру SQL Server и обнаружил, что база данных сразу стала полезной:
вот как вы это делаете:
- остановить службу (MSSQLSERVER);
- переименовать или удалить файлы базы данных и журналов (C:\Program файлы\Microsoft SQL Server\MSSQL.1\MSSQL\данные. ) или где у вас есть файлы;
- запустить службу (MSSQLSERVER);
- удалить базу данных с проблемы;
- восстановить базу данных.
У меня был аналогичный инцидент с остановкой сервера-получателя доставки журналов. После команды удалить сервер из доставки журналов и остановить доставку журналов с первичного сервера база данных на вторичном сервере застряла в восстановлении состояния после команды
восстановление базы данных успешно обработано 0 страниц за 18.530 секунд (0.000 MB / sec).
база данных была использована снова после тех 18 секунд.
который исправил проблему. Сначала у меня возникли проблемы из-за имени базы данных, содержащей специальные символы. Я решил это, добавив двойные кавычки вокруг-одиночные кавычки не будут работать, давая " неправильный синтаксис рядом . " ошибка.
Это было минимальное решение, которое я пытался решить эту проблему (застрявшая база данных в состоянии восстановления), и я надеюсь, что его можно применить к более случаи.
OK, у меня есть аналогичная проблема, и точно так же, как это было в случае Pauk, это было вызвано тем, что сервер исчерпал дисковое пространство при восстановлении и поэтому вызвал постоянное состояние восстановления. Как завершить это состояние без остановки служб SQL Server?
Я нашел решение :)
с опцией восстановления используется по умолчанию при выполнении команд RESTORE DATABASE/RESTORE LOG. Если вы застряли в процессе "восстановления", вы можете вернуть базу данных в онлайн-состояние, выполнив:
Если есть необходимость в восстановлении нескольких файлов, команды CLI требуют с NORECOVERY и с восстановлением соответственно-только последний файл в команде должен иметь с восстановлением, чтобы вернуть базу данных онлайн:
можно использовать SQL Server Мастер Management Studio также:
существует также виртуальный процесс восстановления, но вам придется использовать сторонние решения. Как правило, вы можете использовать резервную копию базы данных в онлайн базе. ApexSQL и Idera имеют свои собственные решения. Обзор по SQL Hammer о восстановлении ApexSQL. Виртуальный восстанавливая хорошее решение, если вы имеете дело с большим количеством резервных копий. Процесс восстановления намного быстрее, а также может сэкономить много места на диске. Вы можете взгляните на инфографики здесь для некоторого сравнения.
Это может быть довольно очевидно, но это меня только что споткнулось:
Если вы берете резервную копию хвостового журнала, эта проблема также может быть вызвана тем, что эта опция включена в Мастере восстановления SSMS - " оставить исходную базу данных в состоянии восстановления (с NORECOVERY)"
если клиент, который выдал RESTORE DATABASE команда отключается во время восстановления, Восстановление будет застрять.
странно, что сервер, когда ему говорят восстановить базу данных с помощью клиентского соединения, не завершит восстановление, если клиент не будет подключен все время.
У меня была ситуация, когда моя база данных показывала состояние восстановления, и я не мог запускать какие-либо запросы и не мог подключиться к нашему программному обеспечению.
Что я сделала, чтобы выйти из этой ситуации:
остановить все связанные службы SQL из windows сервисы.
Я открыл папку данных, где файлы Ldf и Mdf находятся в каталоге SQL, обычно это похоже : "C:\Program файлы***********\MSSQL\DATA
затем я скопировал файлы Ldf и Mdf базы данных: [имя БД].mdf и [имя БД]_log.ldf
Я скопировал оба файла в другую папку.
затем я запустил все службы, связанные с SQL (на шаге 1) снова из служб windows.
запустил мою MS SQL Management studio с обычным логином.
Правой Кнопкой Мыши на базе данных виновника и нажмите Удалить (чтобы удалить базу данных на всех).
все файлы LDF и MDF, связанные с этой базой данных, ушли из папки данных (упомянутой в шаге 2).
создал новую базу данных с тем же именем (то же имя, которое я удалил в шаге 6 - база данных виновника).
затем [имя базы данных] - > щелкните правой кнопкой мыши - > задачи - > отключить.
затем я скопировал оба файла (с шага 3) обратно в папку данных (Шаг 2).
[имя базы данных] - >щелкните правой кнопкой мыши - > задачи - > вывести в интернет.
У меня было . в моем имени базы данных, и запрос не работал из-за этого (говоря неправильный синтаксис рядом '.Затем я понял, что мне нужна скобка для имени:
У меня была эта проблема, когда я также получил ошибку TCP в журнале событий.
падение БД с sql или щелкните правой кнопкой мыши на нем в диспетчере " удалить" И восстановить снова.
Я фактически начал делать это по умолчанию. Сценарий падение БД, воссоздать, а затем восстановить.
по умолчанию every RESTORE DATABASE входит RECOVERY настройка. Параметры "NORECOVERY" в основном сообщают SQL Server, что база данных ожидает больше файлов восстановления (может быть DIFF файл и LOG файл и, может включать файл резервной копии хвостового журнала, если это возможно). Параметры "восстановление", завершить все транзакции и пусть база данных готова к выполнению транзакций.
- если ваша база данных настроена простой модель восстановления, вы можете выполнять только полное восстановить с помощью NORECOVERY вариант, когда у вас есть DIFF резервное копирование. Нет!--12-->LOG резервное копирование разрешается в простой модель восстановления базы данных.
- в противном случае, если база данных настроена с полное или МАССОВАЯ РЕГИСТРАЦИЯ модель восстановления, вы можете выполнять полное восстановление с последующим NORECOVERY опция, затем выполните DIFF следовал по NORECOVERY и, наконец, выполнить LOG восстановить с помощью .
помните, что ПОСЛЕДНИЙ ЗАПРОС ВОССТАНОВЛЕНИЯ ДОЛЖЕН ИМЕТЬ RECOVERY опции. Это может быть явный способ или нет. В термах T-SQL ситуация:
- USE [master] GO RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, RECOVERY -- This option could be omitted. GO
С заменой опция должна использоваться с осторожностью, так как это может привести к потере данных
или, если вы выполняете Полное и DIFF резервное копирование, вы можете использовать это
- USE [master] GO -- Perform a Tail-Log backup, if possible. BACKUP LOG Database_name GO -- Restoring a FULL backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY GO -- Restore the last DIFF backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_DIFF_backup_file.bak' WITH FILE = 1, NORECOVERY,NOUNLOAD GO -- Restore a Log backup RESTORE LOG Database_name FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2, RECOVERY, NOUNLOAD GO
конечно, вы можете выполнить восстановление с параметром статистика = 10 это говорит SQL Server сообщать о каждом 10% завершено.
если вы предпочитаете, вы можете наблюдать процесс или восстановление в режиме реального времени на основе запроса. Как следует:
надеюсь, что это поможет.
также может возникнуть проблема с удалением застрявшей базы данных, если включен снимок. Для меня это сработало:
в моем случае этого было достаточно, чтобы удалить базу данных, который висел в состоянии "восстановление. " С помощью команды SQL
затем я щелкнул правой кнопкой мыши на базы данных и выбранными обновить который удалил запись в Management Studio. После этого я сделал новое восстановление, которое работало нормально (обратите внимание, что вывод его в автономном режиме не работал, перезапуск службы SQL не работал, перезагрузка сервера также не работала).
вы пробовали запустить только проверку? Просто чтобы убедиться, что это резервная копия.
Данный материал является переводом оригинальной статьи "MSSQLTips : Daniel Calbimonte : SQL Server Database Stuck in Restoring State".
Вы обнаружили, что база данных Microsoft SQL Server находится в состоянии восстановления. Как это произошло и как получить обратно доступ к этой базе данных SQL Server?
В этой статье мы покажем причины, по которым база данных MS SQL Server находится в состоянии восстановления, и как получить доступ к базе данных в состоянии восстановления. Это не очень распространенная проблема, но когда так случается, для администратора баз данных это головная боль. В этой статье мы рассмотрим различные причины и возможные решения этой проблемы. Рассмотренные здесь рекомендации пригодны для любой версии SQL Server.
База данных SQL Server в состоянии RESTORING после восстановления
Обычно состояние восстановления возникает, когда вы восстанавливаете базу данных. Здесь мы рассмотрим пример этого.
Создадим файл полной резервной копии (файл *.bak) и файл резервной копии журнала транзакций (файл *.bak), запустив вот такой код T-SQL в SQL Server Management Studio (SSMS):
Как только у нас будут созданы резервные копии, начнем процесс восстановления.
Чтобы восстановить полную резервную копию с резервной копией журнала, нам нужно использовать параметр NORECOVERY в процессе восстановления. Итак, если мы сперва восстановим полную резервную копию следующим образом:
База данных теперь будет в состоянии восстановления. Если мы забудем восстановить дополнительные резервные копии, база данных застрянет в этом режиме.
Чтобы завершить восстановление и получить доступ к базе данных, далее необходимо выполнить команду восстановления резервной копии журнала следующим образом:
База данных SQL Server в состоянии RESTORING после выполнения резервного копирования журнала с помощью NORECOVERY
Другая причина, по которой ваша база данных может находиться в состоянии восстановления, - это резервное копирование хвоста журнала (Log Tail) с помощью параметра NORECOVERY , как показано ниже.
Это приведет к переходу базы данных в состояние восстановления.
Как сделать базу данных SQL Server доступной в состоянии RESTORING без восстановления резервных копий
Если база данных застряла в состоянии восстановления и у вас нет дополнительных резервных копий для восстановления, вы можете восстановить базу данных с помощью следующей команды:
После того, как вы введете эту команду, база данных станет доступной для использования, но вы не сможете восстановить какие-либо дополнительные резервные копии для этой базы данных, не запустив все заново с полной резервной копией.
Дополнительные сведения о восстановлении базы данных в состоянии восстановления можно найти в статье "Recovering a SQL Server database that is in the restoring state".
База данных SQL Server в состоянии RESTORING и Database Mirroring
Другая причина, по которой ваша база данных находится в состоянии восстановления, заключается в том, что она является частью зеркального отображения базы данных SQL Server (Database Mirroring). Database Mirroring - это решение, позволяющее обеспечить высокую доступность базы данных. Если в первичной базе данных произошел сбой, база данных вторичной реплики на другом сервере возьмет на себя операции с базой данных. Основная база данных - это основной сервер, вторичная - это зеркальный сервер и, при желании вы можете иметь еще один зеркальный сервер.
Вот пример. Слева мы видим, что на основном сервере доступна база данных. Справа мы видим зеркало базы, которое находится в состоянии восстановления.
Дополнительные сведения о зеркальном отображении базы данных можно найти в статье "Configure SQL Server Database Mirroring Using SSMS".
В зеркальном отображении базы данных зеркальный сервер находится в состоянии восстановления до тех пор, пока не будет выполнено переключение на другой ресурс (FailOver). Чтобы получить доступ к базе данных, которая находится в состоянии восстановления, когда она является частью ошибки базы данных, вы можете выполнить ручное или автоматическое переключение при отказе, от участника к зеркалу.
Чтобы выполнить автоматическое переключение при отказе, выполните действия описанные в статье: "SQL Docs : Role Switching During a Database Mirroring Session - Manual Failover".
Чтобы "сломать" зеркало, вам нужно будет выбрать базу данных, перейти на страницу зеркального отображения и нажать кнопку удаления зеркального отображения. В следующей статье показано, как это сделать: "SQL Docs : Remove Database Mirroring (SQL Server)". После удаления база данных зеркального отображения вернется в нормальное состояние, и вы сможете создать резервную копию и восстановить базу данных как обычную базу данных.
База данных SQL Server в состоянии RESTORING и Log Shipping
Режим Доставки журналов SQL Server (Log Shipping) позволяет постоянно создавать резервные копии журналов транзакций, а также отправлять и восстанавливать резервные копии на другом сервере, чтобы иметь реплики базы данных в случае отказа основного сервера.
Доставка журналов переводит базу данных в состояние ожидания с восстановлением, либо без восстановления. В режиме "без восстановления" база данных доставки журналов будет находиться в состоянии восстановления, как показано ниже.
Ссылка на статью об изменении состояния, чтобы избежать состояния восстановления: "Change the restore mode of a secondary SQL Server database in Log shipping with SSMS".
База данных SQL Server застряла в состоянии RESTORING после перезапуска компьютера
Иногда база данных находится в состоянии восстановления после перезапуска компьютера или по какой-либо другой причине. Обычно это происходит с большими базами данных, когда выполняется длинная транзакция и происходит неожиданное завершение работы или перезапуск сервера.
Если у вас возникла эта проблема, попробуйте сначала команду:
Затем попробуйте снова выполнить восстановление с помощью предыдущей команды восстановления.
После восстановления вы можете перейти в многопользовательский режим с помощью следующей команды T-SQL:
Кроме того, убедитесь, что вы используете последний пакет обновления или накопительное обновление SQL Server.
Так же, вам следует просмотреть журнал ошибок и средство просмотра событий Windows, чтобы проверить наличие ошибок.
Заключение
В этой статье мы рассмотрели разные причины, по которым база данных может находиться в состоянии восстановления. Надеемся, это будет полезно, если вам придется устранять эту проблему.
Читайте также: