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


564

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

3
Miałem dokładnie ten sam problem i wszystkie rozwiązania zawiodły. Co ciekawe, zalogowałem się bezpośrednio na serwerze SQL i wydałem DROP DATABASE dbpolecenie za pośrednictwem SSMS i zadziałało (wcześniej używałem SSMS z innego komputera do wydawania poleceń). Domyślam się, że inne rozwiązania również by zadziałały.
Salman A

Odpowiedzi:


437

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.


3
Nigdy nie musiałem używać instrukcji odzyskiwania podczas robienia tego, co robi. Z WYMIANA powinna wystarczyć.
Sam

8
Tak, korzystałem z NORECOVERY, ale proces przywracania został zawieszony. Używając Z ODZYSKIWANIEM, WYMIANA nie zawiesza już procesu
Junior Mayhé

To rozwiązało mój problem. Podczas przywracania mieliśmy awarię SAN i było to szybkie i czyste rozwiązanie.
Zarejestrowany użytkownik

Miałem podobny problem dzisiaj z bazą danych SQL Server 2005. W moim przypadku musiałem dodać „RESTART” do klauzuli WITH, aby rozwiązać problem. To dawało mi komunikat o błędzie informujący, że poprzednia operacja nie powiodła się.
XpiritO

3
@FistOfFury Jeśli poprzednia operacja przywracania w tej samej bazie danych była w stanie zawieszenia / uśpienia, to tak. Po prostu zatrzymanie / anulowanie przywracania w trakcie procesu powinno mieć ten sam efekt.
John Sansom,

692

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

4
Mieliśmy blokadę DB w przywracaniu na 2 godziny. Uruchomiliśmy to polecenie z innej maszyny przeciwko masterowi i to nas naprawiło. Dzięki!
Pete

11
+1, z gotcha. Kiedy to uruchomiłem, dostałem komunikat o błędzie informujący, że baza danych została już w pełni odzyskana. Ale nadal okazało się, że jest w stanie „w fazie odzyskiwania”. Więc kliknąłem prawym przyciskiem myszy w Management Studio, nacisnąłem Odśwież i wróciłem do normy.
dario_ramos

2
Przywróciłem za pomocą kreatora Mng Studio, wprowadziłem nową nazwę bazy danych, ale przez pomyłkę pozostawiłem nazwy plików takie same jak istniejąca baza danych. Wystąpił błąd „przywracanie nie powiodło się, ale log zakończony powodzeniem” i baza danych dołączona do tych plików utknęła w stanie przywracania. Wydaje się, że to polecenie przywróciło bazę danych do poprzedniego stanu.
Chris

3
To zadziałało. Próbowałem przywrócić kopię zapasową do bocznej bazy danych, ale moja główna baza danych z jakiegoś powodu przeszła w stan przywracania. To faktycznie odzyskało moją DB. Wielkie dzięki!
Aravindh,

2
Niektóre domyślne ustawienia kreatora przywracania SSMS pozostawiają źródłową bazę danych w stanie przywracania, dzięki czemu można kontynuować przywracanie różnych kopii zapasowych lub dzienników bez obawy użytkowników, a to polecenie jest właściwym sposobem na przywrócenie bazy danych po zakończeniu.
Tim Lehner,

102

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.

Tipu, dzięki za to. Miałem podobny problem do oryginalnego plakatu, ale był on spowodowany brakiem miejsca na serwerze podczas przywracania, a więc spowodował stan trwałego przywracania.
Pauk

8
Dlaczego po prostu nie upuścić bazy danych? W ten sposób nie musisz przerywać usługi.
ErikE

8
@ErikE Dla mnie serwer SQL powiedział, że nie może upuścić bazy danych w trakcie przywracania, nawet jeśli tak naprawdę nie przywracał ....
Erik Philips

@ErikPhilips W takim przypadku przypuszczam, że ktoś powrócił do zatrzymania usługi. Zastanawiam się, czy zdarza się to za każdym razem, czy tylko w niektórych przypadkach problemu z zablokowaniem przywracania.
ErikE

5
W moim przypadku wystarczyło usunąć bazę danych zawieszoną 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).
Matt

84

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.


6
Szczególnie przydatne, gdy już przywróciłeś bazę danych, ale zapomniałeś opcji ODZYSKIWANIA ...
JBickford

2
To wszystko, czego potrzebowałem, aby opuścić stan „Przywracanie” po przywróceniu kopii zapasowej tej bazy danych pod inną nazwą DB. Wielkie dzięki.
Sean

81

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.


2
Działa idealnie - bez konieczności rozrywania go w górę iw górę. 3 Dbs o wartości ponad 80 Gb każda zajmuje trochę czasu! Dzięki!
Christer

1
Prawie zrobiłem to w środowisku produkcyjnym. Najpierw spróbowałem na lokalnym, w tej samej sytuacji znalazłem swój komentarz. Wyciągnięta lekcja: używaj skryptów i nie ufaj SSMS w ważnych sytuacjach.
Mariusz

1
Ten problem występuje podczas przywracania kopii zapasowej pliku tylko do kopii bazy danych do nowej bazy danych. Oryginalna baza danych pokazała błąd. To rozwiązanie zadziałało, a odpowiedź brzmiała: „PRZYWRÓĆ BAZY DANYCH pomyślnie przetworzono 0 stron w 0,263 sekundy (0,000 MB / s)”. , więc wygląda na to, że SQL Server był po prostu zdezorientowany co do stanu bazy danych.
R. Schreurs,

1
Pracowałem dla mnie, ale tylko wtedy, gdy usunąłem podwójne cudzysłowy - właśnie parametr [MY_DB_NAME].
StackOverflowUser

34

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*

29

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ż:

wprowadź opis zdjęcia tutaj

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.


23

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)”

wprowadź opis zdjęcia tutaj


7
Jeśli jesteś w tym stanie, najlepszym rozwiązaniem jest: 1. Kliknij bazę danych prawym przyciskiem myszy, przejdź do Zadania-> Przywróć-> Dzienniki transakcji 2. Znajdź plik kopii zapasowej, który został użyty do utworzenia kopii zapasowej Dziennika ogona 3. Przywróć kopia zapasowa Przywracanie powinno się powieść i przywrócić bazę danych do trybu online.
Ryan Gross

16

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.


10
Wszystkie polecenia SQL wymagają, aby klient pozostawał podłączony przez cały czas.
mrdenny

2
@mrdenny: Zakładam, że zmiany zostaną cofnięte, gdy klient się rozłączy.
Ian Boyd

Mam ten sam problem z uruchomieniem tego polecenia ze sterownikiem PHP PDO firmy Microsoft. jednak podczas pracy z Microsoft Management Server SQL Studio Studio działa dobrze. Zastanawiam się, jak sprawić, by moja aplikacja php była podłączona przez cały czas?
channa ly

Zdarzyło się również tutaj, DB utknął w przywracaniu / pojedynczy użytkownik po możliwej przerwie połączenia. Zabił wszystkie inne identyfikatory SPID z nowej sesji, ale nadal utknął. Był w stanie usunąć bazę danych jako rozwiązanie.
crokusek

10

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.

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

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

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

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

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

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

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

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


To też działało dla mnie. W kroku 10 postanowiłem zastąpić istniejące pliki.
Divi perdomo

8

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

5

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


3

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óć.


3

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.


2

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.


1

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 .


To była baza danych TFS, a klient TFS już mi powiedział: Baza danych pełna.
cskwg

1

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

0
  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!


0

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

0

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


0

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

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

Proszę wskazać dodatkowy wgląd, jaki zapewnia ta odpowiedź w porównaniu ze starszą, zaakceptowaną i wysoko ocenioną odpowiedzią. Pomogłoby to uniknąć wrażenia, że ​​właśnie go skopiowałem w nadziei na uzyskanie reputacji. Nie docenia się również odpowiedzi zawierających tylko kod (co jest główną widoczną różnicą), ponieważ dają one błędne wrażenie, że StackOverflow jest darmową usługą pisania kodu,
Yunnosch

Poprawiłem formatowanie, aby podobieństwo do starszej odpowiedzi było bardziej oczywiste. Ale możesz się tego nauczyć tutaj stackoverflow.com/editing-help na wypadek, gdybyś próbował w przyszłości uzyskać bardziej czytelne odpowiedzi.
Yunnosch,

0

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

RESTORE DATABASE [DatabaseName] WITH RECOVERY
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.