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.
Author |
Topic |
gromit
Starting Member
2 Posts |
Posted - 2005-12-13 : 03:37:16
|
Hi,I can't manage to upgrade one of my DB to SQL Server 7.0 because of a table corruption error :"Table <tablename> is inconsistent. Objid (0) for page (0) does not match the objid of table (1952009985)".I run a DBCC CHECKDB on the DB and I had this error :"Checking 1952009985Msg 605, Level 21, State 1Attempt to fetch logical page 13441 in database <dbname> belongs to object '0', not to object 'CARDS'".I then run a DBCC PAGE (<dbname>, 13441) command and i had this result :"PAGE:Page found in cache.Page not found".So where can I go from here ?Is there a way to DTS data from the corrupted table in SQL Server 6.5 to SQL 2000 ?Thanks. |
|
gromit
Starting Member
2 Posts |
Posted - 2005-12-13 : 03:46:40
|
Add-on to this thread.I run the command DBCC PAGE (<dbname>, 13441, 0, 0, 0)and I had this result :"PAGE:Page read from disk. BUFFER:Buffer header for buffer 0x334f2d4 page=0x11d0000 bdnew=0x0 bdold=0x0 bhash=0x0 bnew=0x0 bold=0x0 bvirtpg=13441 bdbid=6 bpinproc=0 bkeep=0 bspid=0 bstat=0x0000 bpageno=0 PAGE HEADER:Page header for page 0x11d0000pageno=10365 nextpg=10364 prevpg=10366 objid=8 timestamp=000108b1b002nextrno=7 level=0 indid=0 freeoff=1772 minlen=12page status bits: 0x100,0x8,0x4,0x1".So it seems that the virtual page number does not match the real page number. |
|
|
paulrandal
Yak with Vast SQL Skills
899 Posts |
Posted - 2005-12-13 : 14:34:02
|
Here are some comment on your issue from Bob Ward (senior Escalation Engineer in PSS):I looked at the posting. The 605 doesn’t seem to match up with what the page header says but I would trust the page header more and it shows that the page belongs to syslogs (the tran log was a table back in the old days). This means one of two things:A page in the heap or clustered index chain points off into syslogs (broken chain)An index page points down into a syslogs page#2 is not bad of course because you can just rebuild the index, but #1 is not good. One problem is that you can’t tell how bad the chain is broken (it could be broken in several places).Steps:Try to simply bcp out the table. If it fails with 605, the data page chain is broken.If they have a non-clustered index, then they should try to copy out the data forcing the ncl index (hopefully it is not broken) but doing a select into (using the indid hint)Ex.select * into y from x (2)This is assuming no other errors exist from CHECKDB (because if allocation problems also exist you should not select into this same database)If these two ideas don’t work, it may be possible to pull out other parts of the broken chain by fiddling with sysindexes but this is very dangerous, error prone, and requires advanced skill.Paul RandalLead Program Manager, Microsoft SQL Server Storage Engine(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.) |
|
|
|
|
|
|
|