March 14, 2014 at 7:05 am
Hello all and thanks for your time.
I just added th Check Database Integrity Task to my daily maintenance plan yesterday, and this morning I got an alert from SQL:
Microsoft(R) Server Maintenance Utility (Unicode) Version 10.0.5512 Report was generated on "myServer\myInstance".
Maintenance Plan: 7 Day Retention Full Backups
Duration: 00:01:55
Status: Warning: One or more tasks failed.
Details:
Check Database Integrity Task (myServer\myInstance) Check Database integrity on Local server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped.
Databases: All databases
Include indexes
Task start: 2014-03-14T01:00:01.
Task end: 2014-03-14T01:00:11.
Failed: (-1073548784) Executing the query "DBCC CHECKDB(N'myDatabase') WITH NO_INFOMSGS " failed with the following error: "Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
If i run the tsql manually, with no_infomsgs, i get:
Msg 8921, Level 16, State 1, Line 1
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
I checked TempDB, 35.13MB size with 30.98MB available, seems ok.
When I viewed the msdb.suspect_pages table, I found an entry:
database_idfile_id page_idevent_typeerror_count last_update_date
8 1 458 2 7 2014-03-14 08:54:56.457
I would have just restored from backup, but since I just added this task to the maint plan, I fear it's been going on for awhile. I don't see any issues in production, just this message.
I'm wondering A. is something wrong? B. What is wrong? C. Can I fix it without a backup?
Thanks again for your input.
Jason
March 14, 2014 at 7:52 am
Corrupt page in a system table. This is not good news. There may well be more corruption, we just don't know.
Can you restore your latest backup somewhere else and run checkDB on that?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 14, 2014 at 8:06 am
As you probably feared, my oldest backup has been restored and still gives me the same errors.
I am guessing it is a matter of time before the application (Citrix provisioning server) accesses the bad page and freaks out, but will the problem get worse?
I also guess that I should start rebuilding the database in the mean time.
Any further advice?
Thanks Gail!
March 14, 2014 at 8:23 am
Check with "DBCC DBINFO WITH tableresults". The field dbi_dbcclastknowngood will show you the last time dbcc succeded without any errors in the DB. This will help you to identify the good backup as well if you want to restore.
March 14, 2014 at 8:45 am
Good tip. Too bad it came up with 1900-01-01, heh. If anyone else read this who doesn't run any sort of db corruption detection, learn from my mistake 😀
March 14, 2014 at 8:52 am
March 14, 2014 at 9:03 am
Is the result that mentioned came up for your user Db or for system DB's. You have to execute it in all the DB's.
March 14, 2014 at 11:13 am
I only ran it against the db that is in question. Now, the error says system tables, but you are saying the problem could be in system dbs? if so, why did the dbcc checkdb not find issue with them? Genuinely curious.
Anyways, I haven't even run dbcc checkdb against any dbs in this instance since it's inception.
March 14, 2014 at 11:38 am
I haven't told the error is with system DB. Even if you have dbcc scheduled on weekly basis, model DB at times shows the good time as the date that you mentioned. That was why I have asked you whether you have executed it on User or System DB. Since the result was for User DB itself, try executing dbcc with allow data loss(with SQL Server anything can happen:-P) or as Gail mentioned restore the DB.
March 14, 2014 at 12:53 pm
Bijoy.Kaiprath (3/14/2014)
try executing dbcc with allow data loss
NO! NO! NO! (not that it will do a damned thing in this case)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 14, 2014 at 12:58 pm
hada79 (3/14/2014)
I am guessing it is a matter of time before the application (Citrix provisioning server) accesses the bad page and freaks out, but will the problem get worse?
Corruption won't spread if that's what you're asking. It's not an infectious disease. That said, depends on the cause. Corruption is typically due to a bad IO subsystem. If it was a once off glitch (power spike or similar) then maybe that's it. If the IO subsystem is misbehaving, then other parts of the DB could be corrupt or become corrupt and without any way to check, you won't know until something important breaks.
Looks like you need to create a new database and start moving data.
^^
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 3, 2014 at 12:49 am
If you need to solve this without any loss problem and want to recover it firmly as well as to remove such corruption issue from the MS SQL Server database, then you can optimized external tool to retrieve all data from corrupt SQL MDF and NDF files as well as export it directly to SQL Server.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply