SQL Server: Базата данни е блокирана в състояние на възстановяване

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

RESTORE DATABASE <database name> WITH RECOVERY

Съобщенията на базата данни:

ВЪЗСТАНОВЯВАНЕТО НА БАЗАТА ДАННИ успешно обработи 0 страници за 18,530 секунди (0,000 MB/сек).

Базата данни беше използваема отново след тези 18 секунди.

Имах подобен проблем с възстановяването с помощта на SQL Management Studio. Опитах се да възстановя резервно копие на базата данни в нова с различно име. Първоначално това се провали и след коригирането на имената на файловете на новата база данни беше успешно извършено - във всеки случай проблемът, който описвам, се появи отново, дори ако разбрах това правилно от първия път. Така че след възстановяването оригиналната база данни остава с (Възстановява се...) до името си. Имайки предвид отговорите във форума по-горе (на Bhusan), опитах да стартирам в редактора на заявки отстрани следното:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

което коригира проблема. Отначало имах проблеми поради името на базата данни, което съдържаше специални знаци. Разреших това, като добавих двойни кавички наоколо - единичните кавички няма да работят, давайки грешка „Неправилен синтаксис близо до ...“.

Това беше минималното решение, което се опитах да разреша този проблем (заседнала база данни в състояние на възстановяване) и се надявам, че може да се приложи към повече случаи.

Добре, имам подобен проблем и точно както беше в случая с Pauk, той беше причинен от изчерпване на дисковото пространство на сървъра по време на възстановяване и така предизвика постоянно състояние на възстановяване. Как да прекратя това състояние, без да спирам услугите на SQL Server?

Намерих решение :)

Drop database *dbname*

Опцията WITH RECOVERY се използва по подразбиране, когато се изпълняват команди RESTORE DATABASE/RESTORE LOG. Ако сте заседнали в процеса на „възстановяване“, можете да върнете база данни в онлайн състояние, като изпълните:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Ако има нужда от възстановяване на множество файлове, CLI командите изискват съответно WITH NORECOVERY и WITH RECOVERY - само последният файл в командата трябва да има WITH RECOVERY, за да върне базата данни онлайн:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

Можете също да използвате съветника на SQL Server Management Studio:

Има и процес на виртуално възстановяване, но ще трябва да използвате решения на трети страни. Обикновено можете да използвате резервно копие на база данни като жива онлайн база данни. ApexSQL и Idera имат свои собствени решения. Преглед от SQL Hammer относно ApexSQL Restore. Виртуалното възстановяване е добро решение, ако имате работа с голям брой резервни копия. Процесът на възстановяване е много по-бърз и също може да спести много място на дисковото устройство. Можете да разгледате инфографика тук за малко сравнение.

Това може да е доста очевидно, но току-що ме препъна:

Ако правите резервно копие на последния журнал, този проблем може да бъде причинен и от отметката на тази опция в съветника за възстановяване на SSMS - „Оставете изходната база данни в състояние на възстановяване (С НЕВЪЗСТАНОВЯВАНЕ)“

Разбрах защо.

Ако клиентът, който е издал командата RESTORE DATABASE, прекъсне връзката по време на възстановяването, възстановяването ще бъде блокирано.

Странно е, че сървърът, когато му бъде казано да възстанови база данни от клиентска връзка, няма да завърши възстановяването, освен ако клиентът не остане свързан през цялото време.

този свърши работа:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

Имах ситуация, при която моята база данни показа състояние на възстановяване и не можах да изпълня никакви заявки и не можах да се свържа с нашия софтуер.

Това, което направих, за да изляза от тази ситуация е:

1. Спрете всички услуги, свързани със SQL, от услугите на Windows.

2. Отворих папката DATA, където се намират Ldf и Mdf файловете в SQL директорията, обикновено е като: "C:\Program Files***********\MSSQL\DATA

3. След това копирах Ldf и Mdf файловете на базата данни: [db name].mdf и [db name]_log.ldf

Копирах и двата файла в друга папка.

4. След това стартирах всички свързани със SQL услуги (в стъпка 1) отново от услуги на Windows.

5. Стартирах моето студио за управление на MS SQL с нормално влизане.

6. Щракнете с десния бутон върху базата данни на виновника и натиснете DELETE (за да изтриете базата данни изобщо).

7. Всички LDF и MDF файлове, свързани с тази база данни, са излезли от папка DATA (спомената в стъпка 2).

8. Създадох нова база данни със същото име (същото име на тази, която изтрих в стъпка 6 - базата данни на виновника).

9. След това [име на база данни]->щракнете с десния бутон -> задачи -> Вземете офлайн.

10. След това копирах и двата файла (от стъпка 3) обратно в папката DATA (стъпка 2).

11. [име на база данни]->щракнете с десния бутон -> задачи -> Вземете онлайн.

Имах . в името на моята база данни и заявката не работи поради това (казвайки Неправилен синтаксис близо до '.') Тогава разбрах, че имам нужда от скоба за името:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Щракнете с десния бутон върху базата данни, отидете на Задачи --› Възстановяване --› Дневници на транзакции Във файловете за транзакции, ако видите файл с отметка, тогава SQL сървърът се опитва да възстанови от този файл. Премахнете отметката от файла и щракнете върху OK. Базата данни се завръща .....

това реши проблема за мен, надявам се това да помогне на някого.

В моя случай беше достатъчно да премахна базата данни, която висеше в състояние „Възстановява се...“ с SQL командата

 drop database <dbname> 

в прозорец за заявка.

След това щракнах с десния бутон върху Бази данни и избрах Опресняване, което премахна записа в Management Studio. След това направих ново възстановяване, което работи добре (имайте предвид, че прехвърлянето му офлайн не проработи, рестартирането на SQL услугата не проработи, рестартирането на сървъра също не проработи).

Имах този проблем, когато получих TCP грешка в регистъра на събитията...

Пуснете DB с sql или щракнете с десния бутон върху него в мениджъра „изтриване“ и възстановете отново.

Всъщност започнах да правя това по подразбиране. Направете скрипт за премахване на DB, пресъздайте и след това възстановете.

По подразбиране всеки RESTORE DATABASE идва с настройка RECOVERY. Опциите „NORECOVERY“ основно казват на SQL Server, че базата данни чака още файлове за възстановяване (може да е DIFF файл и LOG файл и може да включва tail-log архивен файл, ако е възможно). Опциите „ВЪЗСТАНОВЯВАНЕ“ завършват всички транзакции и оставят базата данни готова за извършване на транзакции.

So:

1. ако вашата база данни е настроена с SIMPLE модел за възстановяване, можете да извършите ПЪЛНО възстановяване само с опция NORECOVERY, когато имате DIFF резервно копие. Не се допуска резервно копие на LOG в базата данни на модела за възстановяване на SIMPLE.
2. В противен случай, ако вашата база данни е настроена с ПЪЛЕН или ГРУПОВ РЕГИСТРИРАН модел на възстановяване, можете да извършите ПЪЛНО възстановяване, последвано от NORECOVERYoption, след което изпълнете DIFF, последвано от NORECOVERY, и накрая изпълнете възстановяване на LOG с опция RECOVERY.

Не забравяйте, че ПОСЛЕДНАТА ЗАЯВКА ЗА ВЪЗСТАНОВЯВАНЕ ТРЯБВА ДА ИМА RECOVERY ОПЦИЯ. Може да е изричен начин или не. От гледна точка на T-SQL, ситуацията:

1.

 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

Опцията WITH REPLACE трябва да се използва с повишено внимание, тъй като може да доведе до загуба на данни

Или, ако извършите ПЪЛНО и РАЗЛИЧНО архивиране, можете да използвате това

   USE [master]
    GO
    RESTORE DATABASE Database_name
      FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
       NOUNLOAD,NORECOVERY
    GO
    RESTORE DATABASE Database_name
      FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
     NOUNLOAD, RECOVERY
    GO

 2. 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

Разбира се, можете да извършите възстановяване с опцията STATS = 10, която казва на SQL Server да отчита всеки 10% завършени.

Ако предпочитате, можете да наблюдавате процеса или да възстановите в базирана заявка в реално време. Както следва:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

Надявам се това да помогне.

Използвайте следната команда, за да разрешите този проблем

RESTORE DATABASE [DatabaseName] WITH RECOVERY

Може също да има проблем с изтриването на блокирана база данни, ако моментната снимка е активирана. За мен това проработи:

1. Първо следвах стъпките на Tipu Delacablu (прочетете няколко публикации)
2. run command: drop database [вашата база данни], което ще ви даде грешка, казвайки ви името на базата данни за моментни снимки
3. изпълнете команда: пуснете база данни [моментна снимка база данни] и след това изпълнете отново командата в стъпка 2.

Опитахте ли да стартирате VERIFY ONLY? Само за да се уверя, че е резервно копие на звука.

http://msdn.microsoft.com/en-us/library/ms188902.aspx

Имам случай MyDbName (Възстановяване...) поради ограничението за лиценз на SQL Express.

В регистрационния файл намерих това:

CREATE DATABASE или ALTER DATABASE неуспешно, тъй като полученият кумулативен размер на база данни би надхвърлил лицензирания лимит от 10240 MB на база данни.

Така че, ако се опитвате да възстановите по-голяма база данни, трябва да превключите вашия SQL Express сървър на версия за разработчици например.

Попаднах на подобен проблем, докато възстановявах базата данни с помощта на студио за управление на SQL сървър и тя остана в режим на възстановяване. След няколко часа проследяване на проблема, следната заявка работи за мен. Следната заявка възстановява базата данни от съществуващо архивиране до предишно състояние. Вярвам, че уловката е да имате .mdf и .log файла в една и съща директория.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

1. Нека първо проверим и стартираме SQL Agent Service.

2. Използване на следния T-SQL:

   ИЗБЕРЕТЕ име на файл ОТ master.sys.sysaltfiles WHERE dbid = DB_ID('db_name');

3. Използване на T-SQL непрекъснато:

   ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ ОТ ДИСК = 'DB_path' С РЕСТАРТ, ЗАМЕНА;

Надявам се това да помогне!

Всички опции, базирани на WITH RECOVERY, не работеха за мен.

Това, което направих, беше да направя пълното възстановяване от Management Studio.

USE [master]
RESTORE DATABASE Sales_SSD
FROM  DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak' 
WITH  FILE = 1,  
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',  
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',  
NOUNLOAD,  REPLACE,  STATS = 5

Имах същия проблем... въпреки че не знам защо моята база данни изпита този проблем, тъй като устройството ми не беше пълно... Сякаш се е повредило или нещо подобно. Опитах всичко по-горе, нито едно от тях не работи напълно, особено мислех, че предложението за спиране на услугата и изтриването на mdf и ldf файловете ще проработи... но въпреки това замръзна при възстановяване?

В крайна сметка разреших това, като изтрих файловете, както беше споменато, но вместо да се опитам да възстановя DB отново, копирах нови .mdf и .ldf файлове и ги прикачих с помощта на съветника за прикачен файл от предния край. Облекчение, проработи!!

Отне ЗАВИНАГИ да копирам новите файлове, тъй като използвам виртуална машина... така че копирането и поставянето с помощта на клипборда отне около час, така че бих препоръчал това само като последен опит.

Това, което го оправи за мен, беше

1. спиране на инстанцията
2. създаване на резервно копие на .mdf и .ldf файловете в папката с данни
3. Рестартирайте инстанцията
4. изтрийте базата данни, блокирана при възстановяване
5. върнете .mdf и .ldf файловете обратно в папката с данни
6. Прикачете екземпляра към .mdf и .ldf файловете

Ако искате да възстановите база данни на SQL Server от архивен файл, можете да използвате следния скрипт:

RESTORE DATABASE [MyDatabase] -- which database to restore
FROM DISK = N'X:\MyDatabase.bak' -- location of the database backup
WITH 
    FILE = 1, -- restore from a backup file
    -- declare where the file groups should be located (can be more than two)
    MOVE N'MyDatabase_Data' TO N'D:\SSDPATH\MyDatabase.mdf',
    MOVE N'MyDatabase_Log' TO N'E:\HDDPATH\MyDatabase.ldf',
    -- Tape option; only relevant if you backup from magnetic tape
    NOUNLOAD,
    -- brings the database online after the database got restored
    -- use this option when you don't want to restore incremental backups
    -- use NORECOVERY when you want to restore differential and incremental backup files
    RECOVERY,
    -- replace existing database with the backup 
    -- deletes the existing database
    REPLACE, 
    -- print log message for every 1 percent of restore
    STATS = 1;

Това е стар проблем, който продължава да се появява през цялото време с SQL Server, дори и най-новата версия от 2019 г.! Не знам защо Microsoft са оставили тази болка толкова дълго и са позволили на техния MSSQL двигател да продължи да се държи по този начин. Независимо от това, предлагам друго възможно решение за тези, които са опитали опцията ВЪЗСТАНОВЯВАНЕ НА БАЗА ДАННИ С ВЪЗСТАНОВЯВАНЕ и тя все още не работи.

Влезте в самия сървър и стартирайте програмата SSMS по подразбиране на действителния сървър на база данни. След това отидете на базата данни за възстановяване и я ИЗТРИЕТЕ. Свършен. Проблемът изчезна. Ако трябва да го запазите, копирайте MDF файла и го преименувайте и го прикачете като нова база данни. Работи за мен на SQL Server 2008 R2.