Sql-server – What does “slot 80 for LOB data type node does not exist” error in sql server mean

dbccsql-server-2008

When I modify a table in SQL Server 2008 I get the following error:

The Database ID 29, Page (1:235225),
slot 80 for LOB data type node does
not exist. This is usually caused by
transactions that can read uncommitted
data on a data page. Run DBCC
CHECKTABLE

Can any one help me?

Best Answer

While normal columns are stored in the actual row record (the structure on disk), LOB columns are stored on a different page, leaving a pointer to that page on the original page.

When you scan a table, all the data pages will be scanned, including the pointers to the LOB pages. If the timing is right, and you're running under READ UNCOMMITTED, you might scan the data page, but when the page containing the LOB data is scanned (by following the pointer in the referring record), it might have been changed/deleted in the meantime.

It could also be caused by corruption, in which case you should be able to reproduce the error again and again. In this case, run DBCC CHECKDB to check for corruption issues. If you can't reproduce it but it happens too often, see if you can't change the isolation level.

Related Solutions

Sql-server – DBCC CHECKDB WITH DATA_PURITY gives out of range error

Use DBCC PAGE:

DBCC TRACE(3604);
DBCC PAGE('dbname', 1, 19558, 3);

and check the slot 13.

Sql-server – Found errors in table after executing DBCC CHECKTABLE command

Realizing this situation is long over I'm still going to put in my 2 cents for anyone else finding themselves in a similar situation.

You have a fair amount of corruption in that table. Run a DBCC CHECKDB on the database ASAP.
I hope you have a good & recent backup. That's going to be your best bet for recovery.
If you don't have a recent backup then you have a number of lesser possibilities.
- Use the dreaded repair_allow_data_loss. This is your LAST option for a reason. It can and probably will cause you to lose some data. And by some it could be one column of one row all the way up to .. well .. all of it. And you won't have any idea how much was lost.
- Create a new database with the same structures and use something like SSIS to copy the data across. Still probably going to lose data here.

Regardless, if you have the time I would look over the answers given in Steve Stedman's Database Corruption Challenge. He posted corrupt databases and various people posted their solutions to fixing them. These solutions range from the normal (as above) to some interesting and unusual solutions. One or more of them may work for you and let you salvage your database without data loss.

Also, and this is important too, if you have a corrupted database it's probably corrupt for a reason. Check your IO substructure etc to make sure there isn't a problem there. And also check the other databases on that instance with CHECKDB to make sure you don't have additional problems.

Last but not least. You should be running regular backups, testing them, and running regular CHECKDBs on all databases for situations exactly like this. The sooner you understand you have a problem the better chance of fixing it without loss. Not to mention having good, recoverable backups just in case.

Best Answer

Related Solutions

Sql-server – DBCC CHECKDB WITH DATA_PURITY gives out of range error

Sql-server – Found errors in table after executing DBCC CHECKTABLE command

Related Question