SQL Server: Baza danych utknęła w stanie „Przywracanie”

Utworzyłem kopię zapasową bazy danych:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

A potem próbował go przywrócić:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

A teraz baza danych utknęła w stanie przywracania.

Niektóre osoby teoretyzowały, że dzieje się tak, ponieważ w kopii zapasowej nie było pliku dziennika i konieczne było jego rozwinięcie przy użyciu:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

Tyle że oczywiście się nie udaje:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

I dokładnie to, czego chcesz w katastrofalnej sytuacji, to przywracanie, które nie zadziała.

Kopia zapasowa zawiera zarówno plik danych, jak i plik dziennika:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

Musisz użyć tej WITH RECOVERYopcji z RESTOREpoleceniem bazy danych , aby przełączyć bazę danych do trybu online w ramach procesu przywracania.

Dzieje się tak oczywiście tylko wtedy, gdy nie zamierzasz przywracać żadnych kopii zapasowych dziennika transakcji, tzn. Chcesz przywrócić kopię zapasową bazy danych, a następnie mieć dostęp do bazy danych.

Twoje polecenie powinno wyglądać tak,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

Możesz odnieść większy sukces, korzystając z kreatora przywracania bazy danych w SQL Server Management Studio. W ten sposób możesz wybrać określone lokalizacje plików, opcję zastąpienia i opcję Z odzyskiwaniem.

Miałem taką sytuację podczas przywracania bazy danych do instancji SQL Server 2005 Standard Edition przy użyciu programu Symantec Backup Exec 11d. Po zakończeniu zadania przywracania baza danych pozostała w stanie „Przywracanie”. Nie miałem problemów z miejscem na dysku - baza danych po prostu nie wyszła ze stanu „Przywracanie”.

Uruchomiłem następujące zapytanie przeciwko instancji SQL Server i stwierdziłem, że baza danych natychmiast stała się użyteczna:

RESTORE DATABASE <database name> WITH RECOVERY

Oto jak to zrobić:

1. Zatrzymaj usługę (MSSQLSERVER);
2. Zmień nazwę lub usuń pliki bazy danych i dzienników (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) lub gdziekolwiek masz pliki;
3. Uruchom usługę (MSSQLSERVER);
4. Usuń bazę danych z problemem;
5. Przywróć bazę danych ponownie.

Miałem podobny incydent z zatrzymaniem pomocniczego serwera wysyłającego dzienniki. Po wydaniu polecenia usunięcia serwera z wysyłania dziennika i zatrzymaniu wysyłania dziennika z serwera głównego baza danych na serwerze pomocniczym utknęła w przywracaniu statusu po poleceniu

RESTORE DATABASE <database name> WITH RECOVERY

Wiadomości z bazy danych:

PRZYWRÓĆ BAZY DANYCH pomyślnie przetworzono 0 stron w 18.530 sekund (0.000 MB / s).

Baza danych była ponownie użyteczna po tych 18 sekundach.

Miałem podobny problem z przywracaniem za pomocą SQL Management Studio. Próbowałem przywrócić kopię zapasową bazy danych do nowej o innej nazwie. Na początku się to nie powiodło i po poprawieniu nazw plików nowej bazy danych zostało pomyślnie wykonane - w każdym razie problem, który opisuję, pojawił się ponownie, nawet jeśli dostałem to od razu. Tak więc po przywróceniu oryginalna baza danych pozostała z (Przywracanie ...) obok swojej nazwy. Biorąc pod uwagę odpowiedzi powyższego forum (Bhusana), próbowałem uruchomić w edytorze zapytań z boku:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

który naprawił problem. Na początku miałem problemy z powodu nazwy bazy danych zawierającej znaki specjalne. Rozwiązałem ten problem, dodając wokół siebie podwójne cudzysłowy - pojedyncze cudzysłowy nie działałyby, dając błąd „Niepoprawna składnia w pobliżu ...”.

To było minimalne rozwiązanie, które próbowałem rozwiązać ten problem (zablokowana baza danych w trybie przywracania) i mam nadzieję, że można ją zastosować w większej liczbie przypadków.

OK, mam podobny problem i dokładnie tak, jak w przypadku Pauka, był on spowodowany brakiem miejsca na dysku podczas przywracania i spowodował trwały stan przywracania. Jak zakończyć ten stan bez zatrzymywania usług SQL Server?

Znalazłem rozwiązanie :)

Drop database *dbname*

Opcja Z ODZYSKANIEM jest domyślnie używana, gdy wykonywane są polecenia PRZYWRÓĆ BAZĘ DANYCH / PRZYWRÓĆ LOG. Jeśli utkniesz w procesie „przywracania”, możesz przywrócić bazę danych do stanu online, wykonując:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Jeśli istnieje potrzeba przywrócenia wielu plików, polecenia CLI wymagają odpowiednio Z NORECOVERY i Z ODZYSKIWANIEM - tylko ostatni plik w poleceniu powinien mieć Z ODZYSKIWANIEM, aby przywrócić bazę danych do trybu online:

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

Możesz użyć kreatora SQL Server Management Studio również:

Istnieje również proces wirtualnego przywracania, ale będziesz musiał użyć rozwiązań innych firm. Zwykle można użyć kopii zapasowej bazy danych jako bazy danych online na żywo. ApexSQL i Idera mają własne rozwiązania. Recenzja SQL Hammer na temat ApexSQL Restore . Przywracanie wirtualne jest dobrym rozwiązaniem, jeśli masz do czynienia z dużą liczbą kopii zapasowych. Proces przywracania jest znacznie szybszy, a także może zaoszczędzić dużo miejsca na dysku. Możesz zobaczyć infografikę tutaj dla porównania.

To może być dość oczywiste, ale właśnie mnie to potknęło:

Jeśli wykonujesz kopię zapasową dziennika ogona, ten problem może być również spowodowany przez zaznaczenie tej opcji w kreatorze przywracania SSMS - „Pozostaw źródłową bazę danych w stanie przywracania (Z NORECOVERY)”

Zrozumiałem dlaczego.

Jeśli klient, który wydał RESTORE DATABASE polecenie, rozłączy się podczas przywracania, przywracanie zostanie zablokowane.

Dziwne jest to, że serwer, gdy otrzyma polecenie przywrócenia bazy danych przez połączenie klienta, nie dokończy przywracania, chyba że klient pozostanie podłączony przez cały czas.

ten działał:

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

Miałem sytuację, w której moja baza danych wykazała stan przywracania i nie mogłam uruchamiać żadnych zapytań i nie mogłam połączyć się z naszym oprogramowaniem.

To, co zrobiłem, aby wyjść z tej sytuacji to:

1. Zatrzymaj wszystkie usługi związane z SQL z usług Windows.

2. Otworzyłem folder DATA, w którym pliki Ldf i Mdf znajdują się w katalogu SQL, zwykle jest to: „C: \ Program Files *********** \ MSSQL \ DATA

3. Następnie skopiowałem zarówno pliki Ldf, jak i Mdf bazy danych: [nazwa bazy danych] .mdf i [nazwa bazy danych] _log.ldf

Skopiowałem oba te pliki do innego folderu.

4. Następnie ponownie uruchomiłem wszystkie usługi związane z SQL (w kroku 1) z usług Windows.

5. Rozpocząłem moje studio MS SQL Management z normalnym logowaniem.

6. Kliknij prawym przyciskiem myszy bazę danych winowajców i naciśnij klawisz DELETE (aby w ogóle usunąć bazę danych).

7. Wszystkie pliki LDF i MDF związane z tą bazą danych zostały usunięte z folderu DATA (wspomnianego w kroku 2).

8. Utworzono nową bazę danych o tej samej nazwie (ta sama nazwa, którą usunąłem w kroku 6 - baza danych winowajców).

9. Następnie [nazwa bazy danych] -> kliknij prawym przyciskiem myszy -> zadania -> Przełącz w tryb offline.

10. Następnie skopiowałem oba pliki (z kroku 3) z powrotem do folderu DANE (krok 2).

11. [nazwa bazy danych] -> kliknij prawym przyciskiem myszy -> zadania -> Przejdź do trybu online.

Mam . w nazwie mojej bazy danych, a zapytanie nie działało z tego powodu (mówiąc: Niepoprawna składnia w pobliżu „.”). Wtedy zdałem sobie sprawę, że potrzebuję nawiasu na nazwę:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

W moim przypadku wystarczyło usunąć bazę danych, która wisiała w stanie „Przywracanie ...” za pomocą polecenia SQL

 drop database <dbname> 

w oknie zapytania.

Następnie kliknąłem prawym przyciskiem myszy Bazy danych i wybrałem opcję Odśwież, która usunęła wpis w Management Studio. Następnie dokonałem nowego przywracania, które działało dobrze (pamiętaj, że przełączenie go w tryb offline nie działało, ponowne uruchomienie usługi SQL nie działało, ponowne uruchomienie serwera również nie działało).

Miałem ten problem, gdy otrzymałem błąd TCP w dzienniku zdarzeń ...

Upuść DB za pomocą sql lub kliknij prawym przyciskiem myszy w menedżerze „usuń” i przywróć ponownie.

Właściwie zacząłem to robić domyślnie. Skrypt upuść DB, ponownie utwórz, a następnie przywróć.

Domyślnie każdy RESTORE DATABASEjest dostarczany z RECOVERYkonfiguracją. Opcje „NORECOVERY” w zasadzie informują SQL Server, że baza danych czeka na więcej plików przywracania (może to być plik DIFF i LOG plik oraz, jeśli to możliwe, zawierać plik kopii zapasowej dziennika ogona). Opcje „ODZYSKIWANIE” kończą wszystkie transakcje i pozwalają bazie danych na wykonanie transakcji.

Więc:

1. jeśli twoja baza danych jest skonfigurowana z modelem odzyskiwania SIMPLE , możesz wykonać PEŁNE przywracanie tylko z NORECOVERYopcją, jeśli masz kopię zapasową DIFF . Nie LOG zapasowej są dozwolone w SIMPLE bazie modelu odzyskiwania.
2. W przeciwnym razie, jeśli baza danych jest skonfigurowana z PEŁNYM lub rejestrowane zbiorczej model odzyskiwanie, można przeprowadzić PEŁEN przywracania następnie NORECOVERYopcji, a następnie wykonać DIFF następnie NORECOVERY, i, w końcu, należy wykonać ZALOGUJ przywrócić z RECOVERYopcją.

Pamiętaj, OSTATNIE ZAPYTANIE PRZYWRACANE MUSI MIEĆ RECOVERYOPCJĘ . Może to być sposób jawny lub nie. W przypadku T-SQL sytuacja:

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

Z opcją Z WYMIANA należy używać ostrożnie, ponieważ może to prowadzić do utraty danych

Lub, jeśli wykonujesz kopię zapasową FULL i DIFF, możesz jej użyć

   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

Oczywiście możesz wykonać przywracanie z opcją STATS = 10 która informuje SQL Server o raportowaniu co 10% ukończenia.

Jeśli wolisz, możesz obserwować proces lub przywracać w zapytaniu w czasie rzeczywistym. Następująco:

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

Mam nadzieję, że to pomoże.

Problem może również powodować usunięcie zablokowanej bazy danych, jeśli włączona jest migawka. Dla mnie to zadziałało:

1. Najpierw wykonałem kroki Tipu Delacablu (przeczytaj kilka postów w górę)
2. Uruchom polecenie: upuść bazę danych [twoja baza danych], która wyświetli błąd informujący o nazwie bazy danych migawek
3. Uruchom polecenie: upuść bazę danych [baza danych migawek], a następnie ponownie uruchom polecenie w kroku 2.

Czy próbowałeś uruchomić TYLKO WERYFIKACJĘ? Aby upewnić się, że jest to dźwiękowa kopia zapasowa.

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

Mam sprawę MyDbName (przywracanie ...) z powodu limitu licencji SQL Express.

W pliku dziennika znalazłem to:

Utworzenie bazy danych lub ZMIANA BAZY DANYCH nie powiodło się, ponieważ wynikowy skumulowany rozmiar bazy danych przekroczyłby licencjonowany limit 10240 MB na bazę danych.

Jeśli więc próbujesz przywrócić większą bazę danych, musisz na przykład przełączyć serwer SQL Express na wersję Developer .

Wystąpił podobny problem podczas przywracania bazy danych za pomocą studia zarządzania serwerem SQL i utknął w trybie przywracania. Po kilku godzinach śledzenia problemów zadziałało dla mnie następujące zapytanie. Poniższe zapytanie przywraca bazę danych z istniejącej kopii zapasowej do poprzedniego stanu. Uważam, że haczyk polega na tym, że plik .mdf i .log znajduje się w tym samym katalogu.

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

1. Najpierw sprawdź i uruchom usługę SQL Agent.

2. Za pomocą następującego języka T-SQL:

   WYBIERZ nazwę pliku z master.sys.sysaltfiles GDZIE dbid = DB_ID („nazwa_db”);

3. Ciągłe używanie T-SQL:

   PRZYWRÓĆ BAZY DANYCH Z DYSKU = „ścieżka_DB” Z PONOWNYM URUCHOMIENIEM, WYMIANA;

Mam nadzieję, że to pomoże!

Wszystkie opcje oparte na ODZYSKIWANIU nie działały dla mnie.

W tym celu wykonano pełne przywracanie z 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

Miałem ten sam problem ... chociaż nie wiem, dlaczego moja baza danych doświadczyła tego problemu, ponieważ mój dysk nie był pełny ... To tak, jakby został uszkodzony lub coś takiego. Próbowałem wszystkich powyższych, ale żaden z nich w pełni nie działał, szczególnie pomyślałem, że sugestia zatrzymania usługi i usunięcia plików mdf i ldf będzie działać ... ale nadal zamroziło się po przywróceniu?

Rozwiązałem ten problem, usuwając pliki, jak wspomniano, ale zamiast próbować przywrócić DB ponownie skopiowałem nowe pliki .mdf i .ldf i załączyłem je za pomocą kreatora Front End Attachment. Ulga, zadziałało !!

Kopiowanie nowych plików trwało NA ZAWSZE, ponieważ korzystam z maszyny wirtualnej ... więc kopiowanie i wklejanie za pomocą schowka zajęło samo godzinę, więc poleciłbym to tylko jako ostatnią próbę.

Naprawiłem to

1. zatrzymanie instancji
2. tworzenie kopii zapasowej plików .mdf i .ldf w folderze danych
3. Uruchom ponownie instancję
4. usuń przywracanie zablokowanej bazy danych
5. umieść pliki .mdf i.ldf z powrotem w folderze danych
6. Dołącz instancję do plików .mdf i .ldf

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Użyj następującego polecenia, aby rozwiązać ten problem

RESTORE DATABASE [DatabaseName] WITH RECOVERY