Перемещенная база данных SQL Server внезапно в “Восстановлении” состояния

Базовая проблема, которую Вы имеете, состоит в том, что вместо того, чтобы иметь распределение отслеживают обновления системы защиты и применяют их для Вас, необходимо обработать это сами. Можно сделать жизнь немного легче, тем не менее, путем подписки на список объявлений безопасности для дистрибутива и фильтрации его для обновлений, о которых Вы заботитесь. У меня есть procmail сценарий, что это сохранило автоматически актуальным моим разработчиком пакета (любой пакет там идет на "объявления, которым позволяют, для этого пакета через"), и что-либо, что передает фильтр (значение, "Я должен рассмотреть ручное обновление для этого"), заскакивает в список ожидающих выполнения задач (система покупки билетов) для дальнейшей обработки.

4
задан 24 March 2010 в 21:01
3 ответа

Это может произойти из-за многих причин, но существуют некоторые вещи, которые можно попробовать. Попытайтесь выполнить следующую команду:

RESTORE DATABASE <database name> WITH RECOVERY 

Если это не делает этого, можно попытаться удалить базу данных и восстановить ее снова.

7
ответ дан 3 December 2019 в 02:39
  • 1
    Вы могли объяснить? I' m не DBA. Как / почему это могло произойти? –   24 March 2010 в 21:05
  • 2
    По умолчанию, оставленного в состоянии, готовом к восстановлениям файла журнала. Эта команда приносит его полностью на строке, но больше восстановлений журнала не может быть применено. Я принимаю you' ve, просто сделанный ПОЛНОЕ восстановление msdn.microsoft.com/en-us/library/ms191455.aspx " Отношения ВОССТАНОВЛЕНИЯ и Опций NORECOVERY Восстановить Phases" –  gbn 24 March 2010 в 21:07
  • 3
    Это рискует уничтожать какие-либо данные? –   24 March 2010 в 21:09
  • 4
    Я использовал GUI; я don' t знают вид восстановления, которое я выполнил. –   24 March 2010 в 21:10
  • 5
    Выполнение команды восстановления не заставит Вас терять данные, это будет только препятствовать тому, чтобы Вы больше применяли восстановления журнала. –  jball 24 March 2010 в 21:12

это - съемка общим планом, но это могла быть автоблизкая база данных с довольно большим журналом. Автоблизкие базы данных автоматически закрывают себя, когда больше не используемый. По умолчанию выпуски Экспресса создают базы данных как автоблизко. Когда база данных открыта, она выполняет восстановление, и если журнал является очень большим и нет никакой недавней контрольной точки, восстановление может продлиться некоторое время, достаточно долго чтобы быть видимым в Проводнике Сервера или в SSMS. Это верно, что автоблизкие базы данных имеют некоторую оптимизацию, чтобы сделать 'быстрый' запуск, но это могут дурачить некоторые угловые случаи в выполнение полного восстановления.

Для проверки проверьте, что автоблизкое состояние базы данных является sys.databases.

Иначе проверьте ERRORLOG и/или журнал системного события для сообщений, которые указали бы, почему база данных проходит восстановление.

2
ответ дан 3 December 2019 в 02:39

Проверьте опцию в задании на резервное копирование в соответствии с планом технического обслуживания. Возьмите резервную копию хвостового журнала и сохраните базу данных в состоянии восстановления. Чтобы Прийти, отключите вышеописанную опцию. и выполнить следующий запрос для каждой затрагиваемой базы данных. Восстановление базы данных DB_NAME с восстановлением;

В случае, если это могло произойти, случайно эта опция была отмечена, так как для этой опции не нужно ставить мышь под флажок, чтобы активировать ее, ошибочно щелкнув по ней рядом, можно активировать ее. Таким образом, когда эта работа была запущена, он взял резервную копию хвостового журнала и поместил БД в состояние восстановления.

.
1
ответ дан 3 December 2019 в 02:39

Теги

Похожие вопросы