Почему в sql server management studio у базы статус restoring

Обзор восстановления и восстановления (SQL Server)

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

• База данных ( полное восстановление базы данных) Вся база данных восстанавливается и восстанавливается, а база данных находится в автономном режиме во время операций восстановления и восстановления.
• Файл данных ( восстановление файла) Файл данных или набор файлов данных возвращается в исходное состояние и восстанавливается. Во время восстановления файла файловые группы, содержащие файлы, автоматически находятся в автономном режиме во время восстановления. Любые попытки подключения и работы с файловой группой вне сети приведут к ошибке.
• Страница данных ( восстановление страницы) При использовании модели полного восстановления или модели восстановления с неполным протоколированием можно восстановить отдельные станицы. Восстановление страниц может применяться для любой базы данных вне зависимости от числа файловых групп.

Резервное копирование и восстановление SQL Server работают во всех поддерживаемых операционных системах. Дополнительные сведения о поддерживаемых операционных системах см. в разделе Требования к оборудованию и программному обеспечению для установки SQL Server 2016. Сведения о поддержке резервных копий более ранних версий SQL Server см. в подразделе «Поддержка совместимости» раздела RESTORE (Transact-SQL).

Обзор сценариев восстановления

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

Следующая таблица предоставляет возможные сценарии восстановления, которые поддерживаются различными моделями восстановления.

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

1 Восстановление в Сети поддерживается только в выпуске Enterprise.

Шаги по восстановлению базы данных

Для восстановления файла ядро СУБД выполняет два шага:

• создает любой недостающий файл базы данных;
• копирует данные с устройств резервного копирования в файл(ы) базы данных.

Для восстановления базы данных ядро СУБД выполняет три шага.

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

Независимо от того, как восстанавливаются данные, перед восстановлением базы данных ядро СУБД SQL Server гарантирует согласованность всей базы данных. Например, если вы восстановите файл, его нельзя восстановить и перенести в режим «в сети», пока он не будет развернут достаточно далеко вперед, чтобы быть согласован с базой данных.

Преимущества восстановления файла или страницы

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

• Восстановление данных меньшего объема данных уменьшает время, затрачиваемое на копирование и восстановление.
• В SQL Server восстановление файлов или страниц может позволить другим данным в базе данных оставаться в сети во время операции восстановления.

Восстановление и журнал транзакций

Для большинства сценариев восстановления необходимо применить резервную копию журнала транзакций и разрешить ядро СУБД SQL Server запускать процесс восстановления, чтобы база данных была подключена к сети. Восстановление — это процесс, используемый SQL Server для каждой базы данных для запуска в транзакционно согласованном состоянии ( или очистке).

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

• Этап 1 — это этап анализа, который анализирует журнал транзакций, чтобы определить, что является последней контрольной точкой, и создает таблицу грязной страницы (DPT) и активную таблицу транзакций (ATT). ТГС содержит записи о страницах, которые были «грязными» на момент завершения работы базы данных. ATT содержит записи транзакций, которые были активными во время завершения работы базы данных.
• Этап 2 — это этап повтора, который выполняет перекат всех изменений, записанных в журнале, которые, возможно, не были записаны в файлы данных во время завершения работы базы данных. Минимальный регистрационный номер транзакции в журнале (minLSN), необходимый для успешного восстановления всей базы данных, находится в ТГС и отмечает начало операций восстановления, необходимых для всех «грязных» страниц. На этом этапе ядро СУБД SQL Server записывает на диск все грязные страницы, принадлежащие зафиксированным транзакциям.
• Этап 3 — это этап отмены, который откатывает неполные транзакции, найденные в ATT, чтобы убедиться, что целостность базы данных сохраняется. После отката база данных включается в режим «в сети», и больше никакие резервные копии журнала транзакций не могут быть применены.

Сведения о ходе каждого этапа восстановления базы данных регистрируются в журнале ошибок SQL Server. Ход восстановления базы данных также можно отслеживать с помощью расширенных событий. Дополнительные сведения см. в записи блога New extended events for database recovery progress (Новые расширенные события для процесса восстановления базы данных).

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

Чтобы максимально повысить доступность баз данных в корпоративной среде после запуска службы SQL Server, например после отработки отказа экземпляра отказоустойчивого кластера AlwaysOn или перезапуска на месте, SQL Server Enterprise Edition может перевести базу данных в сеть после этапа повторного выполнения, а этап отмены по-прежнему выполняется. Это также называется быстрым восстановлением.
Однако быстрое восстановление недоступно при переходе базы данных в интерактивное состояние, но служба SQL Server не была перезапущена. Например, выполнение ALTER DATABASE AdventureWorks SET ONLINE; не позволит базе данных находиться в состоянии чтения и записи до завершения всех трех этапов восстановления.

Модели восстановления и поддерживаемые операции восстановления

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

Операция восстановления	Модель полного восстановления	Модель восстановления с неполным протоколированием	Простая модель восстановления
Восстановление данных	Полное восстановление (при наличии журнала).	С некоторыми потерями данных.	Будут потеряны все данные с момента создания последней полной или разностной резервной копии.
Восстановление на момент времени	На любое время, сохранившееся в резервных копиях журналов.	Запрещено, если резервная копия журналов содержит какие-либо изменения с неполным протоколированием.	Не поддерживается.
Восстановление файла 1	Поддерживается полностью.	Иногда. 2	Только для вторичных файлов, доступных только для чтения.
Восстановление страницы 1	Поддерживается полностью.	Иногда. 2	Нет.
Восстановление на уровне файловой группы 1	Поддерживается полностью.	Иногда. 2	Только для вторичных файлов, доступных только для чтения.

1 Доступно только в выпуске Enterprise SQL Server

2 Сведения о необходимых условиях см. в разделе «Ограничения восстановления» в рамках простой модели восстановления далее в этой статье.

Независимо от модели восстановления базы данных резервное копирование SQL Server не может быть восстановлено до версии ядра СУБД SQL Server, которая старше версии, созданной резервной копией.

Сценарии восстановления в простой модели восстановления

В простой модели восстановления предусмотрены следующие ограничения для операции восстановления.

• Восстановление файлов и поэтапное восстановление доступны только для вторичных файловых групп, предназначенных только для чтения. Дополнительные сведения об этих сценариях восстановления см. в статьях Восстановление файлов (простая модель восстановления) и Поэтапное восстановление (SQL Server).
• Восстановление страницы запрещено.
• Восстановление на определенный момент времени не допускается.

Если приведенные выше ограничения противоречат задачам восстановления, рекомендуется использовать модель полного восстановления. Дополнительные сведения см. в разделе Общие сведения о резервном копировании (SQL Server).

Независимо от модели восстановления базы данных резервная копия SQL Server не может быть восстановлена версией SQL Server, которая старше версии, созданной резервной копией.

Восстановление в модели восстановления с массовым журналом

В этом разделе рассматриваются вопросы, относящиеся исключительно к модели восстановления с неполным протоколированием, которая разработана исключительно в дополнение к модели полного восстановления.

Основные сведения о модели восстановления с неполным протоколированием см. в разделе Журнал транзакций (SQL Server).

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

Ограничения для восстановления на определенный момент времени

Если резервная копия журнала, выполненная в модели восстановления с массовым ведением журнала, содержит изменения с массовым журналом, восстановление на определенный момент времени не допускается. Попытка восстановления до момента времени из резервной копии журнала, содержащей массовые изменения, приводит к сбою операции восстановления.

Ограничения для восстановления в сети

Последовательность восстановления в сети работает только при выполнении следующих условий:

• все необходимые резервные копии журналов должны быть сделаны до начала последовательности восстановления;
• резервные копии массовых изменений были созданы до начала последовательности восстановления в сети;
• Если в базе данных существуют массовые изменения, все файлы должны быть либо подключены к сети, либо уничтожены. (Это означает, что они больше не являются частью базы данных.)

Если эти условия не выполнены, последовательность восстановления в сети завершается ошибкой.

Перед тем, как начать восстановление в сети, рекомендуется переключиться к модели полного восстановления. Дополнительные сведения см. в разделе Модели восстановления (SQL Server).

Дополнительные сведения о выполнении восстановления в сети см. в разделе Восстановление в сети (SQL Server).

Помощник по восстановлению базы данных (среда SQL Server Management Studio)

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

• Алгоритм плана восстановления: значительно улучшен алгоритм, используемый при создании планов восстановления, особенно для сложных сценариев восстановления. Многие пограничные случаи, включая сценарии вилки в восстановления на определенный момент времени, обрабатываются более эффективно, чем в предыдущих версиях SQL Server.
• Восстановление на определенный момент времени: помощник по восстановлению баз данных значительно упрощает восстановление базы данных до определенного момента времени. Визуальная временная шкала резервного копирования значительно улучшает поддержку для выполнения восстановления на момент времени. Эта визуальная временная шкала позволяет определять подходящий момент времени в качестве целевой точки восстановления для базы данных. Временная шкала облегчает обзор разветвленного пути восстановления (пути, который покрывает вилки восстановления). Заданный план восстановления на момент времени автоматически включает резервные копии, относящиеся к восстановлению на целевой момент времени (дата и время). Дополнительные сведения см. в разделе Восстановление базы данных SQL Server на определенный момент времени (модель полного восстановления).

Дополнительные сведения см. в следующих блогах по управлению SQL Server:

• Помощник по восстановлению: введение
• Помощник по восстановлению: использование среды SSMS для создания и восстановления раздельных резервных копий

Ускоренное восстановление баз данных

Ускоренное восстановление базы данных доступно, начиная с SQL Server 2019 (15.x), и в Базе данных SQL Azure. Ускорение восстановления базы данных значительно повышает доступность базы данных, особенно в присутствии длительных транзакций, перепроектируя процесс восстановления ядра СУБД SQL Server. База данных, для которой было включено ускоренное восстановление, значительно быстрее восстанавливается после отработки отказа или другого неясного завершения работы. Если включено, ускоренное восстановление базы данных также значительно быстрее завершает откат отмененных продолжительных транзакций.

Вы можете включить ускоренное восстановление базы данных для каждой базы данных в SQL Server 2019 (15.x) с помощью следующего синтаксиса:

ALTER DATABASE [] SET ACCELERATED_DATABASE_RECOVERY = ON; 

Ускорение восстановления базы данных по умолчанию в базе данных SQL Azure.

Далее

• Общие сведения о резервном копировании (SQL Server)
• Журнал транзакций (SQL Server)
• Руководство по архитектуре журнала транзакций SQL Server и управлению им
• Резервное копирование и восстановление баз данных SQL Server
• Применение резервных копий журналов транзакций (SQL Server)

Состояния базы данных

База данных всегда находится в определенном состоянии. Например, к этим состояниям относятся состояния ONLINE, OFFLINE или SUSPECT. Чтобы проверить текущее состояние базы данных, выберите столбец state_desc в представлении каталога sys.databases или свойство Status в функции DATABASEPROPERTYEX .

Определения состояний базы данных

Состояния базы данных определяются в следующей таблице.

State	Определение
ONLINE	База данных доступна. Первичная файловая группа находится в режиме в сети, хотя возможно не завершена стадия отката восстановления.
OFFLINE	База данных недоступна. База данных переходит в режим вне сети с помощью явного указания пользователя и остается в режиме вне сети до тех пор, пока пользователем не будет предпринято дополнительное действие. Например, база данных может быть переведена в режим вне сети, чтобы переместить файл на другой диск. После завершения перемещения файла база данных снова переводится в режим в сети.
RESTORING	Восстанавливаются один или несколько файлов, принадлежащих к первичной файловой группе, или один или более файлов, принадлежащих ко вторичным группам, причем база данных остается в режиме в сети. База данных недоступна.
RECOVERING	База данных в процессе восстановления. Процесс восстановления является переходным состоянием; после успешного завершения восстановления база данных автоматически переходит в режим вне сети. При неудачном завершении восстановления база данных будет помечена как подозрительная. База данных недоступна.
RECOVERY PENDING	SQL Server столкнулась с ошибкой, связанной с ресурсами во время восстановления. База данных не повреждена, но, возможно, потеряны файлы или ограничения системных ресурсов препятствуют началу процесса восстановления. База данных недоступна. Со стороны пользователя требуется дополнительное действие, чтобы исправить ошибку и разрешить завершение процесса восстановления.
SUSPECT	По меньшей мере, первичная файловая группа помечена как подозрительная и, возможно, повреждена. Невозможно восстановить базу данных во время запуска SQL Server. База данных недоступна. Со стороны пользователя требуется дополнительное действие, чтобы устранить проблему.
АВАРИЙНЫЙ РЕЖИМ	Пользователь изменил базу данных и установил состояние базы данных в значение EMERGENCY. База данных находится в однопользовательском режиме и, возможно, в процессе исправления или восстановления. База данных помечена как READ_ONLY, ведение журнала отключено и доступ возможен только элементам предопределенной роли сервера sysadmin . EMERGENCY используется в основном для диагностики. Например, база данных, помеченная как подозрительная, может быть переведена в состояние EMERGENCY. Это предоставляет системному администратору доступ к базе данных только для чтения. Только члены предопределенной роли сервера sysadmin могут перевести базу данных в состояние EMERGENCY.

База в MS SQL застряла в режиме восстановления In recovery

Наверное, одна из самых частых ошибок в Management Studio (SSMS) с которой сталкиваются новички, так это когда база застревает в режиме «Восстановления» или в eng версиях MS SQL «In recovery».

В таком случаи она становится недоступной для работы, собственно что и является проблемой.

Конечно причин, по которых база переходит в состояние «Восстановление из копии…» или «In recovery» много.

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Но конечно несколько базовых причин, что ведут к этому выделить стоит:

1. При восстановлении базы ошиблись файлом бэкапа
2. Восстанавливали базу используя бэкапы журналов транзакций.
3. В базе на момент восстановления работали пользователи (Активные соединения).
4. Восстановление происходило из поврежденного бэкапа.
5. Сработала «Защита» при восстановлении базы (не использовали параметр WITH REPLACE, когда это действительно нужно).

Фактически во всех выше упомянутых случаях базу можно быстро вернуть в рабочие состояние

Но придется использовать простенький скрипт:

Ручной Способ исправить Состояние ожидания восстановления SQL Server

Люди, которые использовали SQL-сервер, возможно, однажды столкнулись с ошибкой SQL база данных в состояние ожидания восстановления из-за ее повторного появления. Если вы не знаете, почему происходит эта ошибка, значит, ваш раздел базы данных, вероятно, заполнен. SQL не может открыть базу данных и не может заблокировать файл базы данных, который очень похож на базу данных в автономном режиме. Это больше похоже на то, что что-то мешает запуску сервера. В этом блоге мы собираемся обсудить, как исправить состояние ожидания восстановления SQL Server с помощью наилучших возможных методов. Прежде чем продолжить, давайте узнаем, каковы причины этой ошибки.

Причины – Состояние Ожидания восстановления базы данных SQL Server

• Раздел базы данных переполнен или недостаточно памяти
• Аппаратный сбой
• Повреждение в лог-файлах
• Из-за какой-либо незавершенной задачи или при закрытии были некоторые действия, ожидающие со стороны пользователя
• Повреждение или повреждение в файлах MDF
• Запуск сервера без промежутков времени

Мгновенное Решение: Используйте средство восстановления SQL SysTools, чтобы исправить состояние ожидания восстановления в базе данных SQL Server. Это программное обеспечение может быстро устранить все ошибки, связанные с базой данных SQL. После восстановления он предоставляет возможность экспортировать данные в базу данных SQL или сценарии SQL.

Ручные способы исправить Состояние ожидания восстановления SQL Server

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

Способ 1

В этом ручном методе для разрешения Состояние ожидания восстановления базы данных SQL Server необходимо запустить принудительное восстановление.

1. Запустите нижеуказанные SQL-запросы.

ALTER DATABASE (Database Name) SET EMERGENCY;

ALTER DATABASE (Database Name) set single_user

DBCC CHECKDB ([Database Name], REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;

ALTER DATABASE (Database Name) set multi_user

2. База данных помечена как READ_ONLY в аварийном режиме, отключает ведение журнала и предоставляет доступ только системным администраторам.

3. После того, как эти шаги будут выполнены, повреждение файла будет исправлено, и база данных снова будет подключена автоматически.

Способ 2

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

1. Выполните следующие команды:

ALTER DATABASE (Database Name) SET EMERGENCY;

ALTER DATABASE (Database Name) set multi_user

EXEC sp_detach_ db ‘(Database Name)’

EXEC sp_attach_single_file_db @Database Name = ‘(Database Name)’, @physname = N’(mdf path)’

2. Система автоматически удалять поврежденные журналы и создаст новый.

Если вы успешно выполнили оба метода, то до сих пор проблема Состояние ожидания восстановления базы данных SQL Server может быть решена. Если нет, то рекомендуется перейти на более безопасный и лучший подход, который является автоматизированным методом.

Автоматизированное решение для исправления Состояние Ожидания восстановления SQL Server

Автоматизация гораздо лучше, чем тратить много времени и усилий на ручные методы. Для автоматического метода вы можете перейти к Восстановление базы данных SQL. Это программное обеспечение помогает восстановить поврежденный файл MDF со всеми объектами базы данных. Для выполнения процесса восстановления базы данных SQL не требуется резервное копирование. Можно легко восстановить базу данных SQL без резервного копирования. Давайте узнаем, как это работает для восстановления поврежденных файлов базы данных SQL и устранения состояние ожидания восстановления в базе данных SQL Server.

1. Установите и запустите программу восстановления SQL, затем нажмите кнопку «Открыть», чтобы загрузить файл базы данных.

2. Выберите режим быстрого или расширенного сканирования, а затем установите флажок Автоопределение версии файла SQL Server.

3. Теперь начнется процесс сканирования. После сканирования вы можете увидеть предварительный просмотр восстановленных предметов.

4. Выберите опцию «Экспорт» сверху и выберите «Экспорт данных в базу данных SQL или сценарии SQL».

5. Заполните все необходимые данные ниже и выберите экспорт только со схемой или только со схемой и данными.

6. В конце нажмите кнопку «Экспорт», чтобы восстановить файлы базы данных SQL.

Вывод

Как мы уже обсуждали в блоге, насколько важна для нас база данных SQL и насколько она склонна к состояние ожидания восстановления SQL Server , вы должны знать эти методы для спасения. Но как мы видим, насколько сложен ручной метод, поэтому всегда рекомендуется переходить на автоматизированный метод. Это лучший инструмент SQL для восстановления поврежденной базы данных SQL и устранения проблемы SQL база данных в состояние ожидания восстановления.

Exclusive Offers & Deals, Grab it Now!

By Chirag Arora

Chirag Arora is a seasoned professional who wears multiple hats in the digital realm. As a Digital Marketing Manager, he orchestrates successful online campaigns, optimizing brand visibility and engagement. Additionally, Chirag brings meticulous attention to detail to his role as a Content Proofreader, ensuring that every piece of content shines with accuracy and clarity.