November 3, 2004 at 7:40 am
I have taken over a database recently and ran a script to pick up failed jobs. It returned one of the databases which failed the integrity check. I checked the log file and it showed me the following lines:-
-----
Table error: Object ID 1549248574, index ID 0, page ID (1:2077484). The PageId in the page header = (1:2077460).
Object ID 1549248574, index ID 0: Page (1:2077484) could not be processed. See other errors for details.
CHECKDB found 0 allocation errors and 2 consistency errors in table 'fees_old' (object ID 1549248574).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'OSPROD'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (OSPROD).
-----
I looked up the 'fees_old' table and checked with the developer and it seems that this table was used a long time back and it got corrupted so they just renamed the table as 'fees_old' and created a new 'fees' table. They told me to just delete the table.
So now, do I just delete the table and run the integrity check again or should I run the DBCC CHECKDB (OSPROD, repair_allow_data_loss) and the CHECKDB (OSPROD, repair_fast) on the database. What are the procedures to follow to ensure that the Integrity check runs smoothly and the database does not get corrupted?
November 3, 2004 at 9:33 am
Just an update. Our server is just a SQL Server 2000 and not the Yukon 2005 Server.
November 4, 2004 at 10:28 am
I can't see any reason why you shouldn't delete the table, then run the integrity check on the DB. I wouldn't bother trying to repair a table you are deleting.
So long, and thanks for all the fish,
Russell Shilling, MCDBA, MCSA 2K3, MCSE 2K3
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply