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
 General SQL Server Forums
 Data Corruption Issues
 Help with error 605 in SQL Server 6.5

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 1952009985
Msg 605, Level 21, State 1
Attempt 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 0x11d0000
pageno=10365 nextpg=10364 prevpg=10366 objid=8 timestamp=0001
08b1b002
nextrno=7 level=0 indid=0 freeoff=1772 minlen=12
page status bits: 0x100,0x8,0x4,0x1".

So it seems that the virtual page number does not match the real page number.
Go to Top of Page

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 Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
(Legalese: This posting is provided "AS IS" with no warranties, and confers no rights.)
Go to Top of Page
   

- Advertisement -