Sql зависает при выборе файла восстановления
И теперь база данных застряла в состоянии восстановления.
Некоторые считают, что это потому, что в резервной копии не было файла журнала, и его нужно было перенести, используя:
Кроме того, конечно, не получается:
И именно то, что вы хотите в катастрофической ситуации, это восстановление, которое не будет работать.
Резервная копия содержит данные и файл журнала:
У меня была та же самая проблема, и все решения потерпели неудачу. Интересно, что я подключился к серверу SQL напрямую и ввел DROP DATABASE db команду через SSMS, и она работала (ранее я использовал SSMS с другого компьютера для выдачи команд). Я предполагаю, что другие решения работали бы также.
Вам необходимо использовать эту WITH RECOVERY опцию с RESTORE командой вашей базы данных , чтобы перевести вашу базу данных в оперативный режим как часть процесса восстановления.
Это, конечно, только в том случае, если вы не собираетесь восстанавливать какие-либо резервные копии журнала транзакций, т. Е. Вы хотите только восстановить резервную копию базы данных и затем иметь доступ к базе данных.
Ваша команда должна выглядеть так,
Вы можете добиться большего успеха при использовании мастера восстановления базы данных в SQL Server Management Studio. Таким образом, вы можете выбрать конкретные местоположения файлов, параметр перезаписи и параметр WITH Recovery.
Мне никогда не приходилось использовать оператор восстановления при выполнении того, что он делает. С ЗАМЕНЫ должно хватить.
Да, я использовал NORECOVERY, но процесс восстановления зависает. Используя WITH RECOVERY, ЗАМЕНИТЕ, что процесс больше не зависает
Это решило мою проблему. У нас был сбой SAN во время восстановления, и это было быстрое и чистое решение.
@FistOfFury Если предыдущая операция восстановления в той же базе данных находится в состоянии ожидания / ожидания, тогда да. Простая остановка / отмена процесса восстановления должна иметь тот же эффект.
У меня была такая ситуация при восстановлении базы данных до экземпляра SQL Server 2005 Standard Edition с использованием Symantec Backup Exec 11d. После завершения задания восстановления база данных оставалась в состоянии «Восстановление». У меня не было проблем с дисковым пространством - база данных просто не вышла из состояния «Восстановление».
Я запустил следующий запрос к экземпляру SQL Server и обнаружил, что база данных сразу стала пригодной для использования:
У нас была БД, застрявшая в восстановлении на 2 часа. Мы запустили эту команду с другой машины против мастера, и это исправило нас. Спасибо!
Я восстановил с помощью мастера Mng Studio, ввел имя новой базы данных, но по ошибке оставил имена файлов такими же, как и у существующей базы данных. Я получил ошибку «восстановление не удалось, но журнал успешно завершен», и база данных, прикрепленная к этим файлам, застряла в состоянии восстановления. Эта команда, кажется, восстановила базу данных до ее предыдущего состояния.
Это сработало. Я пытался восстановить резервную копию в сторонней базе данных, но моя основная база данных почему-то перешла в состояние восстановления. Это фактически восстановило мою БД. Огромное спасибо!
По умолчанию некоторые мастера восстановления SSMS оставляют исходную БД в состоянии восстановления, так что вы можете продолжать восстанавливать различные резервные копии или журналы без страха перед пользователями, и эта команда является правильным способом вернуть БД в нормальное состояние, как только вы закончите.
Вот как вы это делаете:
- Остановить службу (MSSQLSERVER);
- Переименуйте или удалите файлы базы данных и журнала (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data . ) или там, где у вас есть файлы;
- Запустить сервис (MSSQLSERVER);
- Удалить базу данных с проблемой;
- Восстановите базу данных снова.
Типу, спасибо за это. У меня была похожая проблема с оригинальным постером, но она была вызвана тем, что серверу не хватило места на диске во время восстановления, и поэтому вызвала постоянное состояние восстановления.
@ErikE Для меня SQL-сервер сказал, что он не может отбросить базу данных в процессе восстановления, даже если это не было на самом деле восстановление .
@ErikPhilips В этом случае, я полагаю, кто-то вернулся к остановке службы. Интересно, происходит ли это каждый раз или только в определенных случаях проблемы с зависанием-восстановлением.
В моем случае достаточно было сбросить базу данных, которая висела в состоянии «Восстановление . » с помощью команды SQL drop database
У меня был похожий инцидент с остановкой вторичного сервера доставки журналов. После команды удалить сервер из доставки журналов и остановить доставку журналов с основного сервера база данных на дополнительном сервере застряла в состоянии восстановления после команды
RESTORE DATABASE успешно обработал 0 страниц за 18,530 секунд (0,000 МБ / с).
База данных была пригодна для использования снова после этих 18 секунд.
Это было все, что мне нужно, чтобы заставить его выйти из состояния «Восстановление» после восстановления резервной копии этой базы данных с другим именем БД. Огромное спасибо.
У меня была похожая проблема с восстановлением с помощью SQL Management Studio. Я попытался восстановить резервную копию базы данных на новую с другим именем. Сначала это не удалось, и после исправления имен файлов новой базы данных оно было успешно выполнено - в любом случае описываемая мной проблема повторялась, даже если я понял это правильно с первого раза. Таким образом, после восстановления исходная база данных осталась с (Восстановление . ) рядом с ее именем. Учитывая ответы на форуме выше (Bhusan's), я попытался запустить в редакторе запросов на стороне следующее:
что решило проблему. Сначала у меня были проблемы из-за имени базы данных, содержащей специальные символы. Я решил эту проблему, добавив двойные кавычки - одинарные кавычки не сработали бы с ошибкой «Неверный синтаксис рядом . ».
Это было минимальное решение, которое я пытался решить (застрявшая база данных в восстановленном состоянии), и я надеюсь, что она может быть применена к другим случаям.
Работал отлично - без необходимости сносить его снова и снова. 3 Dbs 80+ Гб каждый занимает некоторое время! Спасибо!
Я почти сделал это на производственной среде. Я попробовал это на местном сначала, закончил в той же самой ситуации и нашел Ваш комментарий. Извлеченный урок: используйте сценарии и не доверяйте SSMS в важных ситуациях.
Я получил эту проблему при восстановлении резервной копии файла только для копирования базы данных в новую базу данных. Исходная база данных показала ошибку. Это решение сработало, и я получил ответ «RESTORE DATABASE успешно обработал 0 страниц за 0,263 секунды (0,000 МБ / с)». Таким образом, кажется, что SQL Server был просто сбит с толку о состоянии базы данных.
Работал для меня, но только когда я удалил двойные кавычки - у меня просто был [MY_DB_NAME] в качестве параметра.
ОК, у меня похожая проблема, и точно так же, как это было в случае с Pauk, она была вызвана тем, что серверу не хватило места на диске при восстановлении, и, таким образом, вызвала постоянное состояние восстановления. Как завершить это состояние без остановки служб SQL Server?
Я нашел решение :)
Параметр WITH RECOVERY используется по умолчанию при выполнении команд RESTORE DATABASE / RESTORE LOG. Если вы застряли в процессе «восстановления», вы можете вернуть базу данных в оперативное состояние, выполнив:
Если требуется восстановление нескольких файлов, для команд CLI требуются WITH NORECOVERY и WITH RECOVERY соответственно - только последний файл в команде должен иметь WITH RECOVERY для возврата базы данных в оперативный режим:
Вы также можете использовать мастер SQL Server Management Studio:
Существует также процесс виртуального восстановления, но вам придется использовать сторонние решения. Обычно вы можете использовать резервную копию базы данных в качестве онлайн-базы данных. ApexSQL и Idera имеют свои собственные решения. Обзор SQL Hammer об ApexSQL Restore . Виртуальное восстановление является хорошим решением, если вы имеете дело с большим количеством резервных копий. Процесс восстановления намного быстрее, а также может сэкономить много места на диске. Вы можете посмотреть на инфографику здесь для сравнения.
Это может быть довольно очевидно, но это сбило меня с толку только сейчас:
Если вы делаете резервную копию хвостового журнала, эта проблема также может быть вызвана проверкой этой опции в мастере восстановления SSMS - «Оставить исходную базу данных в состоянии восстановления (WITH NORECOVERY)»
Если вы находитесь в этом состоянии, то вам лучше всего: 1. Щелкните правой кнопкой мыши базу данных, перейдите в Задачи-> Восстановить-> Журналы транзакций 2. Найдите файл резервной копии, который использовался для резервного копирования Tail Log 3. Восстановите резервное копирование Восстановление должно завершиться успешно и вернуть базу данных в оперативный режим.
Если клиент, выдавший RESTORE DATABASE команду, отключится во время восстановления, восстановление застрянет.
Странно, что сервер, когда ему приказывают восстановить базу данных посредством клиентского соединения, не завершит восстановление, пока клиент не будет оставаться на связи все время.
У меня та же проблема при запуске этой команды с драйвером PHP PDO от Microsoft. Однако, при работе с Microsoft SQL Server, студия управления сервером Это работает просто отлично. Интересно, как сделать так, чтобы мое приложение php постоянно подключалось?
Случилось и здесь, БД зависла в восстановлении / однопользовательском режиме после возможного разрыва соединения. Убил всех остальных SPID из нового сеанса, но все еще застрял. Был в состоянии отбросить базу данных в качестве решения.
этот действительно работал:
У меня была ситуация, когда моя база данных показала состояние восстановления, и я не мог выполнить какие-либо запросы и не мог соединиться с нашим программным обеспечением.
Что я сделал, чтобы выйти из этой ситуации:
Остановите все службы, связанные с SQL, из служб Windows.
Я открыл папку DATA, в которой файлы Ldf и Mdf находятся в каталоге SQL, обычно это выглядит так: «C: \ Program Files *********** \ MSSQL \ DATA
Затем я скопировал файлы базы данных Ldf и Mdf: [имя базы данных] .mdf и [имя базы данных] _log.ldf
Я скопировал оба этих файла в другую папку.
Затем я снова запустил все службы, связанные с SQL (на шаге 1), из служб Windows.
Запустил мою студию MS SQL Management с обычным логином.
Щелкните правой кнопкой мыши на базе данных виновника и нажмите DELETE (чтобы удалить базу данных вообще).
Все файлы LDF и MDF, относящиеся к этой базе данных, были взяты из папки DATA (упомянутой в шаге 2).
Создана новая база данных с тем же именем (то же имя, которое я удалил на шаге 6 - база данных преступников).
Затем [имя базы данных] -> щелкните правой кнопкой мыши -> задачи -> отключить.
Затем я скопировал оба файла (из шага 3) обратно в папку DATA (шаг 2).
[имя базы данных] -> щелчок правой кнопкой мыши -> задачи -> Подключить к сети.
У меня есть . в моем имени базы данных, и запрос не работал из-за этого (говоря неправильный синтаксис рядом с '.') Тогда я понял, что мне нужна скобка для имени:
В моем случае было достаточно отбросить базу данных, которая висела в состоянии «Восстановление . » с помощью команды SQL
Затем я щелкнул правой кнопкой мыши на Базы данных и выбрал Обновить, который удалил запись в Management Studio. После этого я сделал новое восстановление, которое работало нормально (обратите внимание, что его отключение не работало, перезапуск службы SQL не работал, перезагрузка сервера также не работала).
У меня была эта проблема, когда я также получил ошибку TCP в журнале событий .
Сбросьте БД с помощью sql или щелкните правой кнопкой мыши на ней в диспетчере «Удалить» и восстановите снова.
Я действительно начал делать это по умолчанию. Сценарий сброса БД, воссоздать и затем восстановить.
По умолчанию каждый RESTORE DATABASE поставляется с RECOVERY настройкой. Параметры 'NORECOVERY', в основном, говорят SQL Server, что база данных ожидает больше файлов восстановления (это может быть файл DIFF и LOG и, если возможно, файл резервной копии). Опции 'RECOVERY' завершают все транзакции и позволяют базе данных быть готовой к выполнению транзакций.
- если ваша база данных настроена на модель восстановления SIMPLE , вы можете выполнить полное восстановление с NORECOVERY опцией, только если у вас есть резервная копия DIFF . В базе данных модели восстановления SIMPLE не допускается резервное копирование LOG .
- В противном случае, если ваша база данных настроена с моделью восстановления FULL или BULK-LOGGED , вы можете выполнить полное восстановление, а затем NORECOVERY параметр, а затем выполнить DIFF. последующим NORECOVERY и, наконец, выполнить восстановление LOG с RECOVERY параметром.
Помните, что последний запрос на восстановление должен иметь RECOVERY вариант . Это может быть явный способ или нет. В терминах T-SQL ситуация:
Параметр WITH REPLACE следует использовать с осторожностью, так как это может привести к потере данных
Или, если вы выполняете полное и DIFF резервное копирование, вы можете использовать это
Конечно, вы можете выполнить восстановление с опцией STATS = 10 который указывает SQL Server сообщать о завершении каждых 10%.
Если вы предпочитаете, вы можете наблюдать за процессом или восстановить в режиме реального времени на основе запроса. Следующим образом:
SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Web SQL Server 2008 R2 Standard SQL Server 2008 R2 Express SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Express SQL Server 2012 Standard SQL Server 2012 Web Еще. Меньше
Microsoft SQL Server 2008 R2 с пакетом обновления 1 (SP1) или Microsoft SQL Server 2008 или Microsoft SQL Server 2012 исправления в одном загружаемом файле. Поскольку исправления являются кумулятивными, каждый новый выпуск содержит все исправления и все обновления для системы безопасности, которые были включены в предыдущий выпуск SQL Server 2008 R2 с пакетом обновления 1 (SP1) или SQL Server 2008 или Microsoft SQL Server 2012.
Эта восстановления БД
- Создание файла БД
- Копирование всех страниц данных из backup
- Создание файла логов
- Копирование блоков данных в файл лога из backup
- Запуск Recovery БД
Сделаю предположение, что большинство людей использует Instant File Initialization, поэтому не будем останавливаться на 1 шаге, так как с этой возможностью создание файла на файловой системе происходит быстро.
Пункт 3 выглядит наиболее подходящим для наших исследований, так как к нему не может быть применено Instant File Initialization и файл лога должен быть заполнен нулями полностью, так же нам может помешать большое количество виртуальных файлов логов.
Я решил проверить моё предположение с помощью доработки XEvent и увеличения размера БД до 10 Гб файла данных и 5 Гб файл лога (реальных данных всего 13 Мб). После запуска нового восстановления я получил следующий результат:
Обратите внимание, что процент восстановление указывает количество байт, которое было восстановлено и когда восстановление дошло до 100% мы получили наши 13 Мб (реальный размер данных). Но самое важно для нас — это шаги «Waiting for Log zeroing» и “Log Zeroing is complete”. Если посмотреть внимательно, то мы обнаружим, что эти шаги заняли значительно больше времени (около 2-х минут), чем процесс восстановления, выраженный в процентах (секунды).
Дополнительная информация
Ссылки
Дополнительные сведения о номерах LSN можно найти на веб-сайте MSDN по следующему адресу:
Дополнительные сведения о том, как структура файла журнала может повлиять на время восстановления базы данных, можно найти на веб-сайте MSDN по следующему адресу:
Влияние структуры файла журнала на время восстановления базы данныхДополнительные сведения о VLFs журнала транзакций можно найти на веб-сайте MSDN по адресу:
Обходное решение
Дождитесь завершения операции восстановления или восстановленияЕсли у вас нет восстановленной базы данных, в которой возникают проблемы с низкой производительностью при восстановлении или восстановлении базы данных, может потребоваться дождаться завершения операции восстановления или восстановления. Например, вы можете увидеть состояние OFFLINE или состояние восстановления в среде SQL Server Management Studio (SSMS) для невосстановленной базы данных. Как правило, остановка SQL Server не гарантирует медленного восстановления и может занять больше времени, чтобы повторить ту же стадию восстановления, стадию повтора или этап отката.
Избегайте восстановления последовательности журнала транзакций, содержащей тысячи VLFsЕсли при восстановлении и восстановлении базы данных с помощью резервной копии вы наблюдайте снижение производительности, вы можете избежать восстановления последовательностей журналов транзакций, которые содержат тысячи VLFs. Чтобы определить файл резервной копии, в котором содержатся самые последние файлы журнала, воспользуйтесь приведенными ниже инструкциями, чтобы просмотреть столбцы FirstLSN и LastLSN в файлах резервной копии журнала: восстановление HEADERONLY с диска = ' C:\folder\file.TRN '. Вы можете решить, что не нужно восстанавливать файлы резервной копии журнала. Кроме того, можно использовать инструкцию STOP в командах Restore, чтобы избежать сильно фрагментированных частей журналов транзакций. Если вы не полностью восстановите последовательности журналов до последней точки во время восстановления после сбоя, в SQL Server базы данных произойдет потеря данных. Эта потеря данных происходит из-за того, что не все транзакции хранятся. Таким образом, существует решение о компромиссе между деловыми организациями. Вы можете полностью восстановить сильно фрагментированный журнал транзакций. Однако эта операция может занять много времени. Кроме того, можно использовать оператор STOP на этапе восстановления, чтобы остановить восстановление до сильной части журнала. Однако все пропущенные транзакции будут утрачены.Примечание. Без установки этого исправления, как правило, не удается безопасно пройти для ускорения восстановления после перезапуска SQL Server. Чтобы безопасно перевести базу данных в оперативный режим, SQL Server должен найти список VLFs, чтобы проанализировать их, а затем отменить завершенные транзакции, чтобы завершить восстановление. Во время восстановления невозможно спокойно пропускать транзакции.
У меня есть ноутбук для разработки с SSMS Express 2012 с экземпляром 2012 дБ и экземпляром 2008 дБ. Использовали эту конфигурацию более года. Внезапно я не могу использовать мастер восстановления. Мастер выберет файл резервной копии, но когда я выберу опцию «Файлы» в левом верхнем углу, чтобы указать расположение MDF и LDF, диалоговое окно зависнет. Я попытался восстановить, не повезло.
Почему вы не используете сценарий T-SQL для восстановления? У волшебника больше нет правильной мудрости, и поэтому он зависает 😊
Я видел зависание мастера восстановления, когда в прошлом были выбраны неправильно сформированные файлы резервных копий. Сделайте RESTORE HEADERONLY и RESTORE VERIFYONLY посмотрите, работает ли это. Также используйте T-SQL, как предложено @marko.
@Pat Я уже давно сталкиваюсь с той же проблемой, но несколько минут назад нашел способ ее обойти.
Прежде всего НЕ пытайтесь восстановить, щелкнув правой кнопкой мыши на пустой базе данных. Что вам нужно сделать, это щелкнуть правой кнопкой мыши на Базы данных и в меню выбрать Восстановить базу данных . В этом пользовательском интерфейсе вы можете использовать опцию Файлы, и пользовательский интерфейс не будет зависать.
Примечание. После этого SQL создаст вашу БД и восстановит ее за один раз.
Надеюсь, это поможет.
Ух ты . Зачем голосовать за этот ответ. После беспроблемной попытки восстановления резервной копии на только что созданной пустой базе данных я попытался сделать это в крайнем случае. Это единственное решение, которое сработало для меня!
Также не знаю, почему это было понижено. Успешно работал для меня, чтобы после того же вопроса продолжала
+1 У меня работает и в SSMS 17.5, на которой я все еще вижу эту проблему при поиске файлов резервных копий.
Вы можете попытаться восстановить через T-SQL. Например:
Что касается ошибки мастера, вы можете попробовать использовать Windows Event Viewer, чтобы попытаться устранить неполадки
У меня тоже SSMS зависла сразу после выбора базы данных для восстановления.
Исправление для меня было простым, мне просто нужно было запускать SSMS в качестве администратора.
Я надеюсь, что это помогает кому-то еще.
У меня была такая же проблема сегодня, когда я пытался восстановить несколько файлов базы данных X в качестве новой базы данных, заданной в качестве места назначения.
Проблема в моем случае заключалась в том, что резервные копии были для базы данных X (Full + Diff + Logs), и на сервере уже была база данных X, но в данный момент база данных была отключена. Это заставляло SMSS зависать каждый раз. Чтобы решить эту проблему, я просто временно перевел базу данных X в оперативный режим, сделал восстановление новой базы данных, а затем перевел базу данных X в автономный режим.
Надеюсь, это может помочь кому-то, кто испытывает эту проблему. Если диалоговое окно «Восстановление базы данных» зависает и не отвечает, проверьте, не существует ли автономная база данных с тем же именем, что и в резервных копиях.
У меня есть сервер Sharepoint. У нас была проблема с нашим инструментом резервного копирования, и теперь некоторые из моих баз данных застряли в состоянии восстановления!
Можно ли остановить процесс восстановления? а также, Как я могу убедиться, что целостность базы данных не была нарушена?
Вероятно, это вызвано тем, что сценарий восстановления добавляет WITH NORECOVERY параметр, чтобы база данных была готова к журналу транзакций после восстановления.
База данных теперь ожидает последний файл журнала транзакций.
Вы также можете:
-
, используя RESTORE LOG database_name FROM backup_device WITH RECOVERY; . или
- Восстановите базу данных снова, но на этот раз, используя . WITH RECOVERY; . или
- Выведите базу данных из режима восстановления, выполнив: RESTORE DATABASE YourDb WITH RECOVERY;
Прежде чем сделать это, пожалуйста, убедитесь, что вы понимаете значение этих параметров. Вы можете потерять данные, если не будете осторожны.
Смотрите это для деталей:
Msgstr "Вывести базу данных из режима восстановления, выполнив: RESTORE DATABASE YourDb WITH RECOVERY". 20 минут работы с царапинами и перезапуском головы, затем фиксируется одним вкладышем. Спасибо!
Простой T-SQL скрипт для решения этой проблемы:
напишите этот скрипт в окне New Query и выполните:
Будьте очень осторожны, чтобы понять последствия этого. Если БД ожидает восстановления журнала, это может привести к значительной потере данных.
Не работает из-за ошибки: «Невозможно восстановить базу данных, поскольку журнал не был восстановлен».
У меня просто была такая ситуация, и лекарство было довольно удивительным:
По-видимому, восстановление NetBackup, которое сломалось, оставило его в странном состоянии. Ни одно другое решение не сработало (хотя я еще не пытался перезапустить службу SQL Server)
Я был бы осторожен с базой данных, хотя, теоретически, как только восстановление начинается, а затем завершается неудачей, вы могли испортить данные. Я все равно просто собираюсь восстановить базу данных, так что для меня это не имеет значения.
Возможно, вы не знакомы с тем, как в StackOverflow мы иногда отвечаем на вопросы, которые немного отличаются от опубликованных. Это обеспечивает ценность, потому что люди часто приходят к вопросам, похожим на их, после поиска в Интернете. Что касается вашего фактического утверждения о том, что его ALTER DATABASE не разрешили, заверяю вас, что в моем случае база данных фактически показала, что она находится в состоянии восстановления, а использование SET ONLINE фактически сработало . Так что понимайте, что вы называете меня ошибкой или ложью. Это то, что вам действительно нужно делать, когда есть альтернатива?
@JamesJenkins А что это за альтернатива? Альтернативой является гипотеза о том, что база данных может отображаться в состоянии восстановления, но фактически не восстанавливаться. Или это может быть на последнем этапе восстановления, когда восстановление фактически завершено, чтобы его можно было установить в ONLINE состояние. Короче говоря, я думаю, что ваш комментарий и отрицательное мнение не соответствуют этому сайту, и ваша информация фактически неверна, потому что она не соответствует действительности с данными, которые я представил.
Как мы знаем, опция восстановления базы данных по умолчанию - это «Восстановление», которое обеспечивает доступность базы данных и ее использование в сети после завершения восстановления базы данных.
Пример:
Давайте посмотрим на важные моменты о восстановлении без восстановления
- База данных не используется
- Остается в режиме восстановления
- Следующая последовательность восстановления может быть выполнена
- Не откатывает никаких незафиксированных транзакций
Восстановить с NoRecovery
Эта опция особенно используется, когда необходимо восстановить несколько резервных копий. Это означает, что при выполнении команды восстановления с параметром norecovery это означает, что база данных не будет выпущена пользователям до тех пор, пока не будет восстановлено последнее резервное копирование в последовательности. При последнем резервном копировании используется опция восстановления, и база данных переходит в оперативный режим.
У вас может быть опечатка в вашем ответе. В разделе с пометкой . о Восстановлении с помощью Восстановления перечислены все параметры, относящиеся к этому RESTORE . WITH NORECOVERY параметру. Не могли бы вы еще раз проверить это?
«Я использую восстановление базы данных с опцией WITH STATS, которая показывает процент восстановления базы данных, но когда процент восстановления доходит до 100%, то процесс может ещё долго висеть на 100%, что происходит в этот момент?»
Я не смог сразу ответить на этот вопрос, поэтому решил провести исследование. Первым делом я настроил extendev events (XEvent) и запустил восстановление БД WideWorldImporters sample database. После восстановления я получил следующий вывод в SSMS:
Когда я посмотрел на события в XEvent, то увидел следующее:
После восстановления БД до 100% есть ещё несколько событий. Давайте рассмотрим этапы восстановления БД и их влияние на время восстановления.
Причина
Эта проблема возникает из-за того, что создание списка виртуальных файлов журнала (VLF) занимает много времени, если в базе данных имеется множество VLFs.
Проблемы
Восстановление базы данных в Microsoft SQL Server 2008 R2 или Microsoft SQL Server 2008 или Microsoft SQL Server 2012 может занять много времени.
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".
Сведения о накопительном пакете обновления
SQL Server 2012
Исправление для этой проблемы впервые выпущено в накопительном обновлении 1 для SQL Server 2012. Чтобы получить дополнительные сведения об этом накопительном пакете обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2679368 Накопительный пакет обновления 1 (SP1) для SQL Server 2012Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012. Корпорация Microsoft рекомендует установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2692828 Сборки SQL Server 2012, выпущенные после выпуска SQL Server 2012 Вы должны применить исправление SQL Server 2012 к установке SQL Server 2012.
SQL Server 2008 с пакетом обновления 2
Исправление для этой проблемы впервые выпущено в накопительном обновлении 8 для SQL Server 2008 с пакетом обновления 2. Чтобы получить дополнительные сведения об этом накопительном пакете обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2648096 Накопительный пакет обновления 8 для SQL Server 2008 с пакетом обновления 2 (SP2)Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008. Корпорация Microsoft рекомендует установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2402659 Сборки SQL Server 2008, выпущенные после выпуска пакета обновления 2 (SP2) для SQL Server 2008 Исправления Microsoft SQL Server 2008 создаются для конкретных пакетов обновления для SQL Server. Необходимо применить исправление для SQL Server 2008 с пакетом обновления 2 (SP2) к установке SQL Server 2008 с пакетом обновления 2. По умолчанию любое исправление, предоставленное в пакете обновления SQL Server, входит в следующий пакет обновления для SQL Server.
SQL Server 2008 с пакетом обновления 3
Исправление для этой проблемы впервые выпущено в накопительном обновлении 3 для SQL Server 2008 с пакетом обновления 3. Чтобы получить дополнительные сведения об этом накопительном пакете обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2648098 Накопительный пакет обновления 3 для SQL Server 2008 с пакетом обновления 3 (SP3)Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008. Корпорация Microsoft рекомендует установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2629969 Сборки SQL Server 2008, выпущенные после выпуска пакета обновления 3 (SP3) для SQL Server 2008 Исправления Microsoft SQL Server 2008 создаются для конкретных пакетов обновления для SQL Server. Вы должны применить исправление SQL Server 2008 с пакетом обновления 3 (SP3) к установке SQL Server 2008 с пакетом обновления 3 (SP3). По умолчанию любое исправление, предоставленное в пакете обновления SQL Server, входит в следующий пакет обновления для SQL Server.
Накопительный пакет обновления 11 для SQL Server 2008 R2
Исправление для этой проблемы впервые выпущено в накопительном обновлении 11. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2008 R2, щелкните следующий номер статьи базы знаний Майкрософт:
2633145 Накопительный пакет обновления 11 для SQL Server 2008 R2Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
981356 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2
Накопительный пакет обновления 4 для SQL Server 2008 R2 с пакетом обновления 1 (SP1)
Исправление для этой проблемы впервые выпущено в накопительном обновлении 4. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2008 R2 с пакетом обновления 1 (SP1), щелкните следующий номер статьи базы знаний Майкрософт:
2633146 Накопительный пакет обновления 4 для SQL Server 2008 R2 с пакетом обновления 1 (SP1)Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2 с пакетом обновления 1 (SP1). Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2567616 Сборки SQL Server 2008 R2, выпущенные после выпуска сервера SQL Server 2008 R2 с пакетом обновления 1 (SP1)
Решение
Читайте также: