BizTalk Server 2004 and BizTalk Server 2006 generate an "Error 7105" error message when BizTalk Services tries to read data in the BizTalk Messaging Management database or in the BizTalk MessageBox database (884415)



The information in this article applies to:

  • Microsoft BizTalk Server 2006 Standard Edition
  • Microsoft BizTalk Server 2006 Developer Edition
  • Microsoft BizTalk Server 2006 Enterprise Edition
  • Microsoft BizTalk Server 2004 Enterprise Edition
  • Microsoft BizTalk Server 2004 Developer Edition
  • Microsoft BizTalk Server 2004 Partner Edition
  • Microsoft BizTalk Server 2004 Standard Edition

SYMPTOMS

When the Microsoft BizTalk Services try to read data from one of the BizTalk Server databases that is stored in Microsoft SQL Server, an error message that is similar to the following is generated in the application log of the computer that is running BizTalk Server 2004: DESCRIPTION: Error: 7105, Severity: 22, State: 6 Page (1:3507395), slot 5 for text, ntext, or image node does not exist.

CAUSE

This problem is most frequently caused by inconsistencies and corruption in the SQL Server databases. There are many reasons that the inconsistencies and corruption may occur.

WORKAROUND

To work around this problem, you can delete the corrupted object according to DBCC CHECKDB suggestions. The DBCC CHECKDB command examines the allocation and the structural integrity of all the objects in the specified database. For example, use the following example to run the DBCC CHECKDB command for the current database and the pubs database:
-- Examine the current database.
DBCC CHECKDB
GO
-- Examine the pubs database without nonclustered indexes.
DBCC CHECKDB ('pubs', NOINDEX)
GO
The DBCC CHECKDB command is a CPU-intensive and disk-intensive operation. Each data page that requires checking must first be read from the disk into memory. Additionally, the DBCC CHECKDB command uses the tempdb database to sort. If you are performing transactions while the DBCC CHECKDB command is running, the transaction log continues to grow because the DBCC CHECKDB command blocks log truncation until the command is finished reading the log. We recommend that you run the DBCC CHECKDB command when the load on the server is light. If you run the DBCC CHECKDB command during heavy use, expect a performance hit on the transaction throughput and on the DBCC CHECKDB completion time.

To improve the performance of the DBCC CHECKDB command, use the following suggestions:
  • Run CHECKDB when the system usage is low.
  • Make sure that you are not performing other disk I/O operations, such as disk backups.
  • Put the tempdb database on a separate disk system or on a fast disk subsystem.
  • Provide sufficient room for the tempdb database to expand on the drive. Use DBCC with ESTIMATE ONLY to estimate how much space is required for the tempdb database.
  • Avoid running CPU-intensive queries or batch jobs.
  • Reduce active transactions while the DBCC command is running.
  • Use the NO_INFOMSGS option to reduce processing and tempdb usage significantly.
If you use CHECKDB with the system event log, you may see that a hardware-related event is causing the inconsistency. You can use the DBCC CHECKDB command with the PHYSICAL_ONLY option to examine the physical structure of the page and the record headers. This operation performs a quick check to see if hardware-induced errors are suspected.

Modification Type:MajorLast Reviewed:6/16/2006
Keywords:kbbiztalk2004-2006swept kbtshoot kbprb KB884415 kbAudDeveloper