Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:
SQL Server
Details
| Attribute | Value |
|---|---|
| Produktnamn | SQL Server |
| Händelse-ID | 3414 |
| Händelsekälla | MSSQLSERVER |
| Component | SQLEngine |
| Symboliskt namn | REC_GIVEUP |
| Meddelandetext | Ett fel uppstod under återställningen, vilket hindrade databasen från att starta om databasens '%.*ls' (databas-ID %d). Diagnostisera återställningsfelen och åtgärda dem, eller återställ från en känd bra säkerhetskopia. Kontakta teknisk support om felen inte korrigeras eller förväntas. |
Explanation
Den angivna databasen återställdes, men startade inte eftersom fel uppstod under återställningen. Detta fel har satt databasen i MISSTÄNKT-tillståndet. Den primära filgruppen, och eventuellt andra filgrupper, är misstänkta och kan skadas. Databasen kan inte återställas vid uppstart av SQL Server och är därför otillgänglig. Användarhandling krävs för att lösa problemet. Du kommer att se MISSTÄNKT-statusen både i SQL Server Management Studio (bredvid databasikonen) och när du tittar på kolumnen sys.databases.state_desc. Varje försök att använda en databas i detta tillstånd kommer att resultera i följande fel:
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
Observera att när detta fel uppstår i tempdb stängs SQL Server-instansen ner.
Orsak
Detta fel kan orsakas av ett övergående tillstånd som fanns på systemet under ett givet försök att starta serverinstansen eller återställa en databas. Detta fel kan också orsakas av ett permanent fel som uppstår varje gång du försöker starta databasen. Orsaken till återställningsfelet finns vanligtvis i fel(ar) som föregår fel 3414 i ERRORLOG eller Event Log. Det föregående felet i loggfilen innehåller samma spid<n-värde> . Till exempel beror det följande återställningsfelet på ett kontrollsummefel när man försöker läsa ett loggblock. Observera att spid15s finns i alla rader:
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
Det finns en mängd fel som kan orsaka att databasåterställning misslyckas. Även om du måste utvärdera varje fel från fall till fall, är lösningen på ett databasåterställningsfel vanligtvis densamma som beskrivs i avsnittet Användaråtgärd nedan.
Användaråtgärd
För information om orsaken till detta feluppträdande av fel 3414, titta i Windows Event Log eller ERRORLOG för ett tidigare fel som indikerar det specifika felet. Den lämpliga användaråtgärden beror på om informationen i Windows Event Log indikerar att SQL Server-felet orsakades av ett övergående tillstånd eller ett permanent fel. Felmeddelandet säger att man ska "diagnostisera återställningsfel och åtgärda dem, eller återställa från en känd fungerande backup". Därför kan du försöka rätta till det fel du stöter på för att återställningen ska kunna slutföras (se Korrigerbara fel och uppskjutna transaktioner).
Om felen inte kan rättas till är det första och bästa alternativet att lösa detta problem att återställa från en bra backup. Men om du inte kan återställa från en backup har du två ytterligare alternativ, som inte garanterar full dataåterställning: använd akut reparation med DBCC CHECKDB eller försök kopiera ut så mycket data som möjligt till en annan databas.
- Återställ från den senaste kända bra databasbackupen
- Använd den akuta reparationsmetoden som tillhandahålls av DBCC CHECKDB
- Försök kopiera ut så mycket data som möjligt till en annan databas.
Den första metoden för att återställa en bra databasbackup är det bästa valet att föra databasen till ett känt konsekvent tillstånd.
Det näst bästa alternativet, om ingen backup finns tillgänglig, är att få databasen online och tillgänglig. Du måste dock inse att transaktionell konsekvens inte kan garanteras eftersom återställningen misslyckades. Det finns inget sätt att veta vilka transaktioner som borde ha rullats tillbaka eller vidareförts men som inte tilläts på grund av återställningsmisslyckandet. Stegen för att gå vidare med akut reparation beskrivs i avsnittet med titeln Att lösa databasfel i nödläge i DBCC CHECKDB-dokumentationen.
Om nödreparation inte fungerar och du vill försöka rädda viss data till en annan databas, är sättet att få tillgång till databasen att sätta databasen i nödläge via kommandot ALTER DATABASE<dbname>SET EMERGENCY. Sedan kan du försöka kopiera ut data från tabeller.
Korrigerbara fel och uppskjutna transaktioner
Inte alla fel som uppstår under databasåterställning leder till ett återställningsfel och en misstänkt databas:
Fel uppstår vid första öppningen av databasen och/eller transaktionsloggfiler innan återställning. Exempel på sådana fel är 17204 och 17207. När dessa fel har rättats kan återställningen tillåtas fortsätta (men det är inte garanterat att slutföras om andra återställningsfel uppstår). Fel som 17204 och 17207 resulterar inte i en SUSPECT-databas. Faktum är att databasens status är RECOVERY_PENDING när dessa problem uppstår.
SQL Server tillåter återställning att slutföras även när ett sidnivåfel uppstår och behåller fortfarande transaktionell konsistens. Denna process har minskat antalet scenarier som resulterar i en SUSPECT-databas. Detta koncept kallas för uppskjutna transaktioner.
Om felet som uppstod under återställningen indikerar ett problem med en databassida, till exempel som ett kontrollsummefel eller Msg 824, kan återställningen tillåtas slutföras med pågående fel. Om en transaktion är ocommittad kan ett fel på en sida resultera i en uppskjuten transaktion som tillåter återställning att slutföras.
Följande ERRORLOG-poster visar ett exempel på ett Msg 824-fel som uppstod under återställning men återställningen tilläts slutföras med en uppskjuten transaktion. Observera frånvaron av fel 3414 i denna situation och meddelandet att återställningen har slutförts för databasen:
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.
Om en committerad transaktion ska rullas framåt kan sidan markeras som otillgänglig (eventuella framtida försök att komma åt sidan resulterar i MSG 829) och återställningen kan slutföras. I denna situation måste felet rättas till genom att återställa sidan från en backup eller genom att frilokalisera sidan med DBCC CHECKDB med reparation.
Se även
ALTER DATABASE (Transact-SQL)
DBCC CHECKDB (Transact-SQL)
Fullständiga databasåterställningar (enkel återställningsmodell)
Uppskjutna transaktioner
MSSQLSERVER_824
sys.databases (Transact-SQL)