Last week i encountered some problems installing SQL Server 2008. Immediately after launching the installation…
Vi fick ett larm att en backup för en SQL 2012 databas misslyckats och noterade följande tre rader i SQL ErrorLog:
Error: 3043, Severity: 16, State: 1.
BACKUP failed to complete the command BACKUP DATABASE EnDatabas.
Check the backup application log for detailed messages.
Error: 3041, Severity: 16, State: 1.
Ola Hallengren jobbens CommandLog visar error 3013 för aktuellt backupjobb, vilket kan betyda en hel del olika saker.
Vid försök till manuell av backup fås följande felmeddelande:BACKUP ‘EnDatabas’ detected an error on page (1:5833797) in file ‘E:\Data\EnDatabas.mdf’.
Vid försök till manuell av backup fås följande felmeddelande:BACKUP ‘EnDatabas’ detected an error on page (1:5833797) in file ‘E:\Data\EnDatabas.mdf’.
Vid körning av
DBCC CHECKDB('EnDatabas')
och även
DBCC CHECKDB('EnDatabas') WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY
visas inga fel för databasen!
Vid kontroll av suspect pages:
USE [MSDB] GO SELECT * FROM [suspect_pages]
visas två rader rörande samma page:5833797
Efter försök igen med manuell backup med option ,CONTINUE_AFTER_ERRORS “lyckas” backup:en.
Nu fanns det istället 22 st rader istället för 2 i [suspect_pages] och de rapporterar totalt 11 st pages som “suspect”.
Vid kontroll av dessa olika 11 pages
DBCC TRACEON (3604) DBCC PAGE (39,1,5833797,3) WITH TABLERESULTS DBCC PAGE (39,1,nnnnnnn,3) WITH TABLERESULTS
….(för alla 11 pages nr som listas)
DBCC TRACEOFF (3604)
ser man att object_id för pages alla ingår i samma tabell “EnTabell” i “EnDatabas”.
(en tabell utan index eller beroenden)
(en tabell utan index eller beroenden)
“EnTabell” kunde läsas men det visade sig att det även fanns en SUSPENDED BULK INSERT gentemot den tabellen
och det gick dessutom inte att läsa en “AnnanTabell” i samma databas.
och det gick dessutom inte att läsa en “AnnanTabell” i samma databas.
Underligt nog så markerades pages som “suspect” för en sådan sak och backup kunde inte tas.
Efter att ha stoppat ett hängt SSIS-jobb (initierat från en dedikerad SSIS-server) så släpptes SUSPENDED BULK INSERT processen och det gick att ta backup igen.
Det fanns då inga “suspect” pages längre i [suspect_pages].
Det fanns då inga “suspect” pages längre i [suspect_pages].
Grundorsaken:
Efter att kunden noterade ett liknande beteende i sin utvecklingsmiljö upptäcktes att en saknad post i ytterligare en annan tabell ställde till problem i SSIS jobbet.
Efter korrigering så kunde SSIS jobbet köra normalt igen.
Efter att kunden noterade ett liknande beteende i sin utvecklingsmiljö upptäcktes att en saknad post i ytterligare en annan tabell ställde till problem i SSIS jobbet.
Efter korrigering så kunde SSIS jobbet köra normalt igen.
För att summera:
En saknad post i en tabell ställde till det för ett SSIS-jobb vilket ledde till en hängd BULK INSERT i en annan tabell vilken i sin tur flaggade pages som suspect:a och detta ledde i sin tur till att databasen inte kunde säkerhetskopieras.
Alltså inga diskproblem lyckligtvis.
En saknad post i en tabell ställde till det för ett SSIS-jobb vilket ledde till en hängd BULK INSERT i en annan tabell vilken i sin tur flaggade pages som suspect:a och detta ledde i sin tur till att databasen inte kunde säkerhetskopieras.
Alltså inga diskproblem lyckligtvis.