MSSQLSERVER_3414

Dotyczy:SQL Server

Details

Attribute	Value
Nazwa produktu	SQL Server
Identyfikator zdarzenia	3414
Źródło zdarzenia	MSSQLSERVER
Component	SQLEngine
Nazwa symboliczna	REC_GIVEUP
Tekst wiadomości	Podczas odzyskiwania doszło do błędu, który uniemożliwił ponowne uruchomienie bazy danych '%.*ls' (ID bazy %d). Zdiagnozuj błędy odzyskiwania i napraw je lub przywróć ze znanej dobrej kopii zapasowej. Jeśli błędy nie zostały poprawione lub nadal występują, skontaktuj się z pomocą techniczną.

Explanation

Wskazana baza danych została odzyskana, ale nie udało się uruchomić z powodu błędów podczas odzyskiwania. Ten błąd sprawił, że baza danych przeszła w stan SUSPECT. Grupa plików podstawowa, a być może także inne, są podejrzane i mogą zostać uszkodzone. Baza danych nie może zostać odzyskana podczas uruchamiania SQL Server i dlatego jest niedostępna. Do rozwiązania problemu wymagana jest reakcja użytkownika. Status SUSPECT zobaczysz zarówno w SQL Server Management Studio (obok ikony bazy danych), jak i w kolumnie sys.databases.state_desc. Każda próba użycia bazy danych w tym stanie skutkuje następującym błędem:

Msg 926, Level 14, State 1, Line 1 
Database 'mydb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information

Należy zauważyć, że gdy ten błąd wystąpi w tempdb, instancja SQL Server zostaje wyłączona.

Przyczyna

Błąd ten może być spowodowany przez przejściowy warunek istniejący w systemie podczas próby uruchomienia instancji serwera lub odzyskania bazy danych. Ten błąd może być również spowodowany trwałą awarią, która pojawia się za każdym razem, gdy próbujesz uruchomić bazę danych. Przyczyną niepowodzenia odzyskiwania jest zazwyczaj błąd(y) poprzedzające błąd 3414 w ERRORLOG-e lub Event Log. Powyższy błąd w pliku logu zawiera tę samą wartość spid<n> . Na przykład, następująca awaria odzyskiwania wynika z błędu sumy kontrolnej podczas próby odczytu bloku logu. Uwaga: spid15s jest obecny we wszystkich linijkach:

2020-03-31 17:33:13.00 spid15s     Error: 824, Severity: 24, State: 4.  
2020-03-31 17:33:13.00 spid15s     SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb_log.LDF'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2020-03-31 17:33:13.16 spid15s     Error: 3414, Severity: 21, State: 1.  
2020-03-31 17:33:13.16 spid15s     An error occurred during recovery, preventing the database 'mydb' (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support

Istnieje szeroki zakres błędów, które mogą powodować niepowodzenie procesu odzyskiwania bazy danych. Chociaż każdy błąd należy oceniać indywidualnie, rozwiązanie błędu w procesie odzyskiwania bazy danych jest zazwyczaj takie samo, jak opisano w sekcji Działania użytkownika poniżej.

Akcja użytkownika

Aby uzyskać informacje o przyczynie wystąpienia tego błędu 3414, sprawdź dziennik zdarzeń Windows lub ERRORLOG pod kątem wcześniejszego błędu wskazującego na konkretną awarię. Odpowiednia akcja użytkownika zależy od tego, czy informacje w dzienniku zdarzeń Windows wskazują, że błąd SQL Server był spowodowany stanem przejściowym lub trwałą awarią. Komunikat o błędzie mówi: "zdiagnozuj błędy w odzyskiwaniu i napraw je, lub przywróć z dobrze znanej kopii zapasowej". Dlatego możesz spróbować poprawić napotkany błąd, aby umożliwić zakończenie odzyskiwania (patrz Błędy do poprawy i odroczone transakcje).

Jeśli błędów nie da się naprawić, pierwszą i najlepszą opcją jest przywrócenie z dobrej kopii zapasowej. Jednak jeśli nie możesz odzyskać danych z kopii zapasowej, masz dwie dodatkowe opcje, które nie gwarantują pełnego odzyskania danych: skorzystać z awaryjnej naprawy za pomocą DBCC CHECKDB lub spróbować skopiować jak najwięcej danych do innej bazy danych.

1. Przywrócenie z ostatniej znanej dobrej kopii zapasowej bazy danych
2. Skorzystaj z awaryjnej metody naprawy oferowanej przez DBCC CHECKDB
3. Spróbuj skopiować jak najwięcej danych do innej bazy danych.

Pierwszą metodą przywrócenia dobrej kopii zapasowej bazy danych jest najlepszy wybór, aby przywrócić bazę danych do znanego, spójnego stanu.

Drugą najlepszą opcją, jeśli nie ma kopii zapasowej, jest udostępnienie bazy danych online. Musisz jednak zdać sobie sprawę, że nie można zagwarantować spójności transakcji, ponieważ proces odzyskania się nie powiódł. Nie ma sposobu, by wiedzieć, które transakcje powinny zostać cofnięte, a które nie zostały dozwolone z powodu niepowodzenia w odzyskaniu. Kroki przeprowadzenia naprawy awaryjnej opisano w sekcji zatytułowanej Rozwiązywanie błędów bazy danych w trybie awaryjnym w dokumentacji DBCC CHECKDB.

Jeśli naprawa awaryjna nie zadziała i chcesz spróbować odzyskać część danych do innej bazy danych, dostęp do bazy danych to ustawienie bazy w trybie awaryjnym za pomocą polecenia ALTER DATABASE<dbname>SET AWARGENT. Potem możesz spróbować kopiować dane z tabel.

Błędy do naprawy i transakcje odroczone

Nie wszystkie błędy napotkane podczas odzyskiwania bazy danych skutkują niepowodzeniem odzyskiwania i podejrzaną bazą danych:

Błędy przy pierwszym otwieraniu bazy danych i/lub plików dziennika transakcyjnych pojawiają się przed odzyskaniem. Przykładami takich błędów są 17204 i 17207. Po naprawieniu tych błędów może być dopuszczone do kontynuowania procesu odzyskiwania (choć nie jest gwarantowane, że zostanie ukończona, jeśli pojawią się inne błędy). Błędy takie jak 17204 i 17207 nie prowadzą do powstania bazy danych SUSPECT. W rzeczywistości status bazy danych jest RECOVERY_PENDING w momencie wystąpienia tych usterek.

SQL Server pozwala na zakończenie procesu odzyskiwania nawet w przypadku błędu na poziomie strony i nadal zachowuje spójność transakcyjną. Proces ten zmniejszył liczbę scenariuszy prowadzących do powstania bazy danych SUSPECT. To pojęcie nazywa się transakcjami odroczonymi.

Jeśli błąd napotkany podczas odzyskiwania wskazuje na problem ze stroną bazy danych, na przykład jako błąd sumy kontrolnej lub Msg 824, może zostać dopuszczone do zakończenia odzyskiwania przy oczekujących błędach. W przypadku, gdy transakcja nie zostanie zatwierdzona, błąd na stronie może skutkować transakcją odroczoną umożliwiającą zakończenie odzyskiwania.

Poniższe wpisy ERRORLOG pokazują przykład błędu Msg 824 napotkanego podczas odzyskiwania, ale proces odzyskania został dopuszczony do zakończenia poprzez transakcję odroczoną. Zwróć uwagę na brak błędu 3414 w tej sytuacji oraz komunikat, który odzyskiwanie zostało ukończone dla bazy danych:

2010-03-31 19:17:18.45 spid7s      SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xb2c87a0a; actual: 0xb6c0a5e2). It occurred during a read of page (1:153) in database ID 13 at offset 0x00000000132000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.   
2010-03-31 19:17:18.45 spid7s      Error: 3314, Severity: 21, State: 1.   
2010-03-31 19:17:18.45 spid7s      During undoing of a logged operation in database 'mydb', an error occurred at log record ID (25:100:19). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2010-03-31 19:17:18.45 spid7s      Errors occurred during recovery while rolling back a transaction. The transaction was deferred. Restore the bad page or file, and re-run recovery.   
2010-03-31 19:17:18.45 spid7s      Recovery completed for database mydb (database ID 13) in 2 second(s) (analysis 204 ms, redo 25 ms, undo 1832 ms.) This is an informational message only. No user action is required.   

Jeśli zobowiązana transakcja ma zostać przesunięta dalej, strona może zostać oznaczona jako niedostępna (wszelkie przyszłe próby dostępu do strony kończą się w Msg 829) i proces odzyskania może zostać ukończony. W takiej sytuacji błąd należy skorygować poprzez przywrócenie strony z kopii zapasowej lub poprzez jej przydzielenie za pomocą DBCC CHECKDB z naprawą.

Zobacz także

ALTER DATABASE (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
Pełne przywracanie bazy danych (prosty model odzyskiwania)
Transakcje odroczone
MSSQLSERVER_824
sys.databases (Transact-SQL)