Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:
SQL Server
Details
| Attribute | Value |
|---|---|
| Název produktu | SQL Server |
| ID události | 3414 |
| Zdroj události | MSSQLSERVER |
| Součást | SQLEngine |
| Symbolický název | REC_GIVEUP |
| Text zprávy | Během obnovy došlo k chybě, která zabránila restartu databáze '%.*ls' (ID databáze %d). Diagnostikujte chyby obnovení a opravte je, nebo použijte důvěryhodnou zálohu. Pokud chyby nejsou opravené nebo očekávané, obraťte se na technickou podporu. |
Vysvětlení
Specifikovaná databáze byla obnovena, ale nepodařilo se spustit, protože během obnovy došlo k chybám. Tato chyba dostala databázi do stavu SUSPECT. Primární souborová skupina, a možná i další, jsou podezřelé a mohou být poškozeny. Databáze nelze obnovit při spuštění SQL Server, a proto není dostupná. K vyřešení problému je nutná akce uživatele. Stav SUSPECT uvidíte jak v SQL Server Management Studio (vedle ikony databáze), tak když se podíváte na sloupec sys.databases.state_desc. Jakýkoli pokus o použití databáze v tomto stavu povede k následující chybě:
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
Všimněte si, že když k této chybě dojde v tempdb, instance SQL Server se vypne.
Příčina
Tato chyba může být způsobena přechodným stavem, který v systému existoval během pokusu o spuštění serverové instance nebo obnovení databáze. Tato chyba může být také způsobena trvalým selháním, které nastává pokaždé, když se pokusíte spustit databázi. Příčina selhání obnovy se obvykle nachází v chybách, které předcházejí chybě 3414 v ERRORLOGU nebo Event Logu. Předchozí chyba v logu obsahuje stejnou hodnotu spid<n> . Například následující selhání obnovy je způsobeno chybou kontrolního součtu při pokusu o čtení logu. Poznámka: spid15s je přítomen ve všech řádcích:
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
Existuje široká škála chyb, které mohou způsobit selhání obnovy databáze. I když musíte každou chybu vyhodnocovat případ od případu, řešení selhání obnovy databáze je obvykle stejné, jak je popsáno v sekci User Action níže.
Akce uživatele
Pro informace o příčině výskytu chyby 3414 si prohlédněte Windows Event Log nebo ERRORLOG, zda nejde o předchozí chybu, která indikuje konkrétní selhání. Vhodná uživatelská akce závisí na tom, zda informace v Windows Event Logu uvádějí, že chyba SQL Server byla způsobena přechodným stavem nebo trvalým selháním. Chybová zpráva uvádí "diagnostikovat chyby obnovy a opravit je, nebo obnovit z dobře známé zálohy". Proto se můžete pokusit opravit chybu, na kterou narazíte, aby obnova mohla být dokončena (viz Opravitelné chyby a odložené transakce).
Pokud chyby nelze opravit, první a nejlepší možností je obnovit z dobré zálohy. Pokud se však nemůžete obnovit ze zálohy, máte dvě další možnosti, které nezaručují úplné obnovení dat: použít nouzovou opravu pomocí DBCC CHECKDB nebo se pokusit zkopírovat co nejvíce dat do jiné databáze.
- Obnovení z poslední známé dobré databázové zálohy
- Použijte nouzovou opravu poskytovanou DBCC CHECKDB
- Snažte se zkopírovat co nejvíce dat do jiné databáze.
První metodou obnovení dobré databázové zálohy je nejlepší volba, jak přivést databázi do známého konzistentního stavu.
Druhou nejlepší možností, pokud není k dispozici záloha, je dát databázi online a přístupnou. Musíte si však uvědomit, že transakční konzistence nemůže být zaručena, protože obnova selhala. Není možné zjistit, které transakce měly být vráceny zpět nebo vpřed, ale nebyly povoleny kvůli selhání obnovy. Kroky k postupu při nouzové opravě jsou popsány v sekci nazvané Řešení chyb databáze v nouzovém režimu v dokumentaci DBCC CHECKDB.
Pokud nouzová oprava nefunguje a chcete se pokusit zachránit nějaká data do jiné databáze, přístup k databázi vede nastavením do nouzového režimu pomocí příkazu ALTER DATABASE<dbname>SET NUŽNÝ. Pak můžete zkusit zkopírovat data z tabulek.
Opravitelné chyby a odložené transakce
Ne všechny chyby při obnově databáze povedou k selhání obnovy a podezřelé databázi:
Chyby při prvním otevření databáze a/nebo transakčních logů se vyskytují před obnovou. Příklady takových chyb jsou 17204 a 17207. Jakmile jsou tyto chyby opraveny, může být obnova povolena (ale není zaručena její dokončení, pokud dojde k dalším chybám obnovy). Chyby jako 17204 a 17207 nevedou k databázi SUSPECT. Ve skutečnosti je stav databáze RECOVERY_PENDING v době, kdy tyto problémy nastávají.
SQL Server umožňuje dokončení obnovy i v případě chyby na úrovni stránky a stále zachová transakční konzistenci. Tento proces snížil počet scénářů vedoucích k databázi SUSPECT. Tento koncept se nazývá odložené transakce.
Pokud chyba při obnově naznačí problém s databázovou stránkou, například jako chyba kontrolního součtu nebo Msg 824, může být obnova dokončena s chybami v čekajícím stavu. V případě, že transakce není potvrzena, může chyba na stránce vést k odložené transakci , která umožní dokončení obnovy.
Následující záznamy v ERRORLOGu ukazují příklad chyby Msg 824 , která se objevila během obnovy, ale obnova byla dokončena odloženou transakcí. Všimněte si absence chyby 3414 v této situaci a zprávy, kterou obnova dokončila pro databázi:
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.
Pokud má být povázaná transakce převedena dopředu, stránka může být označena jako nepřístupná (jakékoli budoucí pokusy o přístup k stránce končí v Msg 829) a obnova může být dokončena. V této situaci je nutné chybu opravit obnovením stránky ze zálohy nebo jejím dealokováním pomocí DBCC CHECKDB s opravou.