Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
How to troubleshoot Msg 7105 in SQL Server
Article ID: 2015760 - View products that this article applies to.
A query may encounter Msg 7105 when Large Object (LOB) data referenced by a database page row cannot be accessed. The application will encounter a message that looks something like:
Msg 7105, Level 22, State 6, Line 1
Because this error is Severity Level 22, the connection is terminated by the server. This error message is also written into the SQL ERRORLOG file and Windows Application Event Log with EventID=7105.
This error can occur due to one of the following reasons:
See the Resolution and More Information sections to determine what is the cause for your specific problem and the appropriate solution.
If database corruption is the cause for this problem, then DBCC CHECKDB and/or DBCC CHECKTABLE should report errors. However, these commands will not report Msg 7105. The errors you encounter from CHECKDB will depend on what is damaged within the reference to LOB structures or the LOB structures themselves.
For example, if the database page row does not correctly reference a valid LOB page, you may see errors like these:
Msg 8929, Level 16, State 1, Line 1
Different scenarios for the problem can result in different combination of errors. In this example, Database Page 1:179, Slot 1 is referencing a LOB page that is not a valid page in the database (page 255:177). Page (1:177) is a valid LOB page but was never referenced by any database page. So in this situation, the problem is that the row in Slot 1 of Page 1:179 references page 255:177 instead of 1:177.
The key to determining whether DBCC CHECKDB errors are related to LOB page problems by looking for the phrases "off-row data" and "type LOB data".
Msg 8929 is an error related to the database page referencing the LOB pages.
In many situations involving these types of errors, repair will result in the deletion of the rows pointing to LOB data and the LOB data itself. The repair algorithm will attempt to only remove LOB fragments that affect the database rows in question but that cannot be guaranteed in all situations depending on what is damaged within the LOB "tree structure".
In the example shown here, the messages returned by a CHECKTABLE using REPAIR_ALLOW_DATA_LOSS look like:
Repair: Deleted record for object ID 2137058649, index ID 0, partition ID 72057594038910976, alloc unit ID 72057594039828480 (type In-row data), on page (1:179), slot 1. Indexes will be rebuilt.
The last message that says "Could not repair this error" is misleading. The error was actually repaired because the database page row that pointed to the invalid page (255:177) was deleted.
(http://go.microsoft.com/fwlink/?LinkId=151500)for other considerations.
Article ID: 2015760 - Last Review: April 1, 2010 - Revision: 1.0