SQL Server Performance Forum – Threads Archive
Anyone knows SQL Server 6.5 (CHECKDB)Hi I have a client who still runs on SQL Server 6.5 and has recently moved to a new server. Since moving he is getting the error prior to doing a dump. He has a scheduled task that does 2 things:
DBCC CHECKDB (master) WITH NO_INFOMSGS
DUMP DATABASE master TO Redaktion WITH NOUNLOAD , STATS = 10, INIT
———————– The backup statement is sucessfull but the CHECKDB gives this error: 2003/09/09 10:44:51.64 spid3 Error : 605, Severity: 21, State: 1
2003/09/09 10:44:51.64 spid3 Attempt to fetch logical page 7946 in database ‘master’ belongs to object ‘0’, not to object ‘syslogs’.
2003/09/09 10:44:51.64 spid3 Automatic checkpointing is disabled in database ‘master’ because the log is out of space. It will continue when the DBO successfully checkpoints the database. Please free up some space or extend the database and then run CHECKPOINT. Any idea where to look/fix this error???
What is the space utilization on the devices that the Database data and log are residing on? I strongly suspect this is a space issue. Gaurav
Man thrives, oddly enough, only in the presence of a challenging environment- L. Ron Hubbard
I reside in Denmark – and it’s currently after hours (GMT+1), so I won’t be able to tell till later. I’ll get back to you in about 13 hours
Thank you —————–
The error 605 occurs when it detects database corruption, execute DBCC CHECKTABLE on the second object specified in the error message. To determine the full extent of the corruption, execute DBCC CHECKDB as soon as possible. Also check the error log for other errors, which often accompany a 605 error. If the error involves an index page, use the REPAIR_REBUILD clause. If the error involves a data page, it may be necessary to use the REPAIR_ALLOW_DATA_LOSS clause. In the likely event that you cannot allow the loss of data, you will need to restore from a known clean backup. If the problem persists also check any H/w malfunctioning that might cause this issue. _________
I’m with Gaurav, sounds like a log space problem in the master database…?