Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 DBCC CHECKDB return Errors

Author  Topic 

franco
Constraint Violating Yak Guru

255 Posts

Posted - 2005-04-14 : 08:21:17
Environment:
SQL Server 2K sp3a Producr version 8.00.818 on Windows Server 2K3 - 2 nodes MSCS Cluster (Single instance).
We have Maintenance Plan scheduled and every week a Database Integrity Check is running thru a job on all of our databases.
This was done before, for at least 4 years on SQL Server 7 on a NT4 MSCS CLuster and now for at least 1 year on the new HW and SW platform.
Never had any problem since now when I received the following errors:

DBCC CHECKDB (SOI_Abitanti_PROD01) executed by LUGANO\SQL-Service found 1 errors and repaired 0 errors.

[Microsoft][ODBC SQL Server Driver][SQL Server]Object ID 2048062382, index ID 0: Page (1:15733) could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 1 consistency errors in table 'presenza' (object ID 2048062382).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 1 consistency errors in database 'SOI_Abitanti_PROD01'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss i

When I saw this error I just re-check the database with DBCC CHECKDB but this time there was no errors anymore.
What could be the cause of that?
Do I have to worry about this?

You also may have to consider the following:

1)this database is no more updated, it's just a read only database for history purpose.
2)We recently have installed Lotus Domino 6.5.3 (1 month ago)
3)We recently upgraded from IBM DIrector version 4.12 to version 4.21. (1 month ago)


Please advise.
Kind regards.


Franco

jason
Posting Yak Master

164 Posts

Posted - 2005-04-14 : 15:49:01
If you specify to reorganize index pages in you maintenance plan, this may be the reason if the corruption was in an index. Also, is this from the SQL error log? It should indicate whether or not anything like this was done after the error was found.

To be safe (in case of MFT corruption), I would do the following:

1) backup the database manually
2) detach it
3) move it to a seperate volume
4) reformat the volume
5) move the database back
6) reattach it
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2005-04-14 : 16:00:20
You should not have selected the option of repair_allow_data_loss in your maintenance plan. This means that if it encounters a problem, to go ahead and delete the data. You don't want this done as a scheduled job. This should only be run by a DBA when he/she has no other choice but to lose data to fix the corrupted database.

Tara
Go to Top of Page
   

- Advertisement -