| Author |
Topic |
|
YaHozna
Starting Member
5 Posts |
 Posted - 2007-07-09 : 09:58:04
|
| Hi. An evaluation of Quest Log Reader threw up the following message on a particular database: 'Table Error: DBCC PAGE (1:111067) (object ID 0, index ID 0) is out of the range of this database'. Running DBCC CHECKDB shows no errors however I did have a hardware problems on the server last week, now resolved. The question is do I actually have any corruption since DBCC CHECKDB doesn't report anything? If so how do I determine where it is?Hope someone can point me in the right direction.Regards,YaHozna. |
|
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2007-07-09 : 10:49:46
|
| May run 'dbcc checkalloc' to see if get any error. |
 |
|
|
X002548
Not Just a Number
15586 Posts |
|
|
YaHozna
Starting Member
5 Posts |
Posted - 2007-07-09 : 11:28:29
|
| Hi Brett. Thanks for the response. How do I determine which table is involved from the information I've got?Regards,YaHozna. |
|
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2007-07-09 : 14:11:32
|
| ok - both of the previous replies are redundant as CHECKDB runs CHECKALLOC and then CHECKTABLE on each table in the database. Common misconception that you need to run multiple commands.I don't think this is a corrupt database. My guess would be that the data file was shrunk at some point and so a log record in the transaction log appears to be affecting a page that doesn't exist in the database. Do you know if that's the case?Paul RandalPrincipal Lead Program Manager, Microsoft SQL Server Core Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.)http://blogs.msdn.com/sqlserverstorageengine/default.aspx |
|
|
|
YaHozna
Starting Member
5 Posts |
Posted - 2007-07-11 : 04:53:37
|
| Hi Paul. Think I must have messed up my previous reply to your post as it's not showing. Yes, it's possible the database was shrunk albeit not very recently. But I'm puzzled by the page ID. The database in question isn't particularly large. It consists of a primary data file at just under 31Mb and a secondary at just over 1Gb so I can't see why there would ever have been a page with ID 111067 associated with that database. Unless I'm misunderstanding Page IDs here, which is possible as I'm not hugely experienced :)Regards,YaHozna. |
|
|
|
X002548
Not Just a Number
15586 Posts |
Posted - 2007-07-11 : 09:13:34
|
quote:
Originally posted by paulrandal
ok - both of the previous replies are redundant as CHECKDB runs CHECKALLOC and then CHECKTABLE on each table in the database. Common misconception that you need to run multiple commands.
Well that's comforting...nice architecture if that's the case...why then would you have all of them to use? Product bloat?And are you saying that CHECKDB will take care of everything?Brett8-)Hint: Want your questions answered fast? Follow the direction in this linkhttp://weblogs.sqlteam.com/brettk/archive/2005/05/25/5276.aspxAdd yourself!http://www.frappr.com/sqlteam |
|
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2007-07-11 : 14:19:16
|
quote:
Originally posted by YaHozna
Hi Paul. Think I must have messed up my previous reply to your post as it's not showing. Yes, it's possible the database was shrunk albeit not very recently. But I'm puzzled by the page ID. The database in question isn't particularly large. It consists of a primary data file at just under 31Mb and a secondary at just over 1Gb so I can't see why there would ever have been a page with ID 111067 associated with that database. Unless I'm misunderstanding Page IDs here, which is possible as I'm not hugely experienced :)Regards,YaHozna.
Page ID 111067 is about 870 Mb into the file - so if this file is only 31Mb then that's definitely off the end of the file. Without knowing more about what the Quest software is doing, I can't really say what's going on. If CHECKDB isn't complaining, then the database isn't corrupt.ThanksPaul RandalPrincipal Lead Program Manager, Microsoft SQL Server Core Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.)http://blogs.msdn.com/sqlserverstorageengine/default.aspx |
|
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2007-07-11 : 14:22:25
|
quote:
Originally posted by X002548
quote:
Originally posted by paulrandal
ok - both of the previous replies are redundant as CHECKDB runs CHECKALLOC and then CHECKTABLE on each table in the database. Common misconception that you need to run multiple commands.
Well that's comforting...nice architecture if that's the case...why then would you have all of them to use? Product bloat?And are you saying that CHECKDB will take care of everything?Brett
Yes - CHECKDB will take care of everything - so if CHECKDB doesn't return any errors then none of the finer granularity commands will either. However, you need to take the hit of the CPU and IO workload for the duration of checking everything. The finer granularity checks are there to minimize the run-time when you only need to check a small portion of the database.ThanksPaul RandalPrincipal Lead Program Manager, Microsoft SQL Server Core Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.)http://blogs.msdn.com/sqlserverstorageengine/default.aspx |
|
|
|
YaHozna
Starting Member
5 Posts |
Posted - 2007-07-12 : 03:47:43
|
| OK. Thanks Paul, I'll maybe speak to Quest to see if there are any issues with the Log Reader. I'll assume it ain't broke so I won't bother fixing it :) And thanks to everyone for their invaluable contributions. Much appreciated.Regards,Gordon (aka YaHozna). |
|
|
|
|
Table error