BizTalk Server monitoring: View Count of Messages With Negative Reference Counts (RefCounts)

In the previous post, we analyze how you can monitor messages without reference counts (RefCounts), today it will be a similar topic, but this time we will be addressing messages with negative reference counts.

and the same question applies here:

  • Have you ever seen your Monitor BizTalk Server (BizTalkMgmtDb) job failing and complaining about the existence of messages with negative reference counts
  • Or do you ever want to know more about messages with negative RefCounts?
  • What are messages with negative RefCounts?
  • Do they show in the BizTalk Server Administration console? Are they impacting BizTalk Server performance?

Indeed messages with negative reference counts can appear from time to time in our environment, which you should definitely need to monitor. And to response to all previous questions:

What are messages with negative RefCounts?

Messages with negative RefCounts are messages in the MessageRefCountLogTotals with snRefCount less than zero. Once a refcount goes negative, the MessageBox cleanup jobs will not be able to clean up the corresponding messages.

Do they show in the BizTalk Server Administration console?

No, they don’t. The only way for you to know that exists messages with negative reference count is by:

  • Running the Monitor BizTalk Server (BizTalkMgmtDb) job
  • Executing the View Count of Messages With Negative RefCounts available on the BizTalk Health Monitor (maintenance)
  • Or executing a custom query against BizTalk Server databases.

Are they impacting BizTalk Server performance?

Yes, if they are too many.

As I mentioned before, the Monitor BizTalk Server SQL Agent job can detect these kinds of messages. In fact, it is able to identify any known issues in Management, MessageBox, or DTA databases. The job scans for the following issues:

  • Messages without any references
  • Messages without reference counts
  • Messages with negative reference counts
  • Messages with reference count less than 0
  • Message references without spool rows
  • Message references without instances
  • Instance state without instances
  • Instance subscriptions without corresponding instances
  • Orphaned DTA service instances
  • Orphaned DTA service instance exceptions
  • TDDS is not running on any host instance with the global tracking option enabled.

By default, the Monitor BizTalk Server job is configured and automated to run once in a week. Since the job is computationally intensive, it is recommended to schedule it during downtime/low traffic. The job fails if it encounters any issues; error string contains the number of issues found. Otherwise, it runs successfully.

Note: The Monitor BizTalk Server job only scans for issues. It does not fix the issues found.

However, are you ever curious to know how you can find these types of messages? Or did you already face the issue that you cannot open the BizTalk Health monitor because it is failing or you don’t have Internet connection to update them to the last version?

Well, now you have it here:

DECLARE @count bigint
SET @count = 0

SELECT @count = COUNT(*) FROM [dbo].[MessageRefCountLogTotals] WHERE [snRefCount] < 0

IF @count = 0
BEGIN
    SELECT 'There are no negative RefCounts'
END
ELSE
BEGIN
    SELECT COUNT(*) Count, [snRefCount] as 'RefCount Value' 
	FROM [dbo].[MessageRefCountLogTotals] 
	WHERE [snRefCount] < 0
    GROUP BY [snRefCount] 
    ORDER BY [snRefCount] 
END

Of course, needless to say, use it with care and thoughtfulness! It is preferred to call this query inside the BizTalk Health Monitor, and ideally, it is recommended to execute it during downtime/low traffic.

You need to run this script against BizTalkMsgBoxDB, and it will return the count of negative refcounts in the MessageRefCountLogTotals table. Equal to the script on the BizTalk Health Monitor.

Where can I download it?

You can download the SQL script here:

THIS SQL SCRIPT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND.

BizTalk Server monitoring: View Count of Messages Without Reference Counts (RefCounts)

Have you ever seen your Monitor BizTalk Server (BizTalkMgmtDb) job failing complaining about the existence of messages without reference counts or more know as messages without RefCounts? What are messages without RefCounts? Do they show in the BizTalk Server Administration console? Are they impacting BizTalk Server performance?

Indeed messages without reference counts can appear from time to time in our environment, which you should definitely need to monitor. And to response to all previous questions:

What are messages without RefCounts?

Messages without reference counts (RefCounts) are messages that don’t have correlating rows in the MessageRefCountLog tables and the MessageZeroSum table. Once they are in this state, the MessageBox cleanup job will not be able to clean up the corresponding messages.

Do they show in the BizTalk Server Administration console?

No, they don’t. The only way for you to know that exists messages without reference counts is by:

  • Running the Monitor BizTalk Server (BizTalkMgmtDb) job
  • Executing the View COunt of Messages Without RefCounts available on the BizTalk Health Monitor (maintenance)
  • Or executing a custom query against BizTalk Server databases.

Are they impacting BizTalk Server performance?

Yes, if they are too many.

As I mentioned before, the Monitor BizTalk Server SQL Agent job can detect these kinds of messages, in fact, it is able to identify any known issues in Management, MessageBox, or DTA databases. The job scans for the following issues:

  • Messages without any references
  • Messages without reference counts
  • Messages with reference count less than 0
  • Message references without spool rows
  • Message references without instances
  • Instance state without instances
  • Instance subscriptions without corresponding instances
  • Orphaned DTA service instances
  • Orphaned DTA service instance exceptions
  • TDDS is not running on any host instance with the global tracking option enabled.

By default, the Monitor BizTalk Server job is configured and automated to run once in a week. Since the job is computationally intensive, it is recommended to schedule it during downtime/low traffic. The job fails if it encounters any issues; error string contains the number of issues found. Otherwise, it runs successfully.

Note: The Monitor BizTalk Server job only scans for issues. It does not fix the issues found.

However, are you ever curious to know how you can find these types of messages? Or did you already face the issue that you cannot open the BizTalk Health monitor because it is failing or you don’t have Internet connection to update them to the last version?

Well, now you have it here:

DECLARE @nvcAppName nvarchar(256)

CREATE TABLE ##msgs_wout_refs (uidMessageID uniqueidentifier NOT NULL)
CREATE UNIQUE CLUSTERED INDEX [CIX_msg_wout_refs] ON [##msgs_wout_refs](uidMessageID)

INSERT INTO ##msgs_wout_refs (uidMessageID)
SELECT uidMessageID FROM Spool WHERE uidMessageID NOT IN(SELECT uidMessageID FROM MessageRefCountLogTotals UNION
															SELECT uidMessageID FROM MessageRefCountLog1 UNION 
															SELECT uidMessageID FROM MessageRefCountLog2 UNION
															SELECT uidMessageID FROM MessageZeroSum
														 )

DECLARE hostcursor CURSOR FOR 
SELECT nvcApplicationName FROM Applications WITH (NOLOCK) 
OPEN hostcursor
	FETCH NEXT FROM hostcursor INTO @nvcAppName
	WHILE (@@FETCH_STATUS = 0)
	BEGIN
		EXEC ('DELETE FROM ##msgs_wout_refs FROM ##msgs_wout_refs m, [dbo].[' + @nvcAppName + '_MessageRefCountLog] r WHERE m.uidMessageID = r.uidMessageID')
	FETCH NEXT FROM hostcursor INTO @nvcAppName
	END
CLOSE hostcursor
DEALLOCATE hostcursor

DECLARE @count bigint
SET @count=0
SELECT @count = count(*) from ##msgs_wout_refs

SELECT 'Messages w/o Refcounts:  ' + cast (@count as nvarchar(10))

DROP TABLE ##msgs_wout_refs

Of course, needless to say, use it with care and thoughtfulness! It is preferred to call this query inside the BizTalk Health Monitor, and ideally, it is recommended to execute it during downtime/low traffic.

You need to run this script against BizTalkMsgBoxDB, and it will return the count of messages that don’t have correlating rows in the MessageRefCountLog tables and the MessageZeroSum table and should align with the ‘Messages w/out RefCounts’ issue that MessageBoxViewer identifies. Equal to the script on the BizTalk Health Monitor.

Where can I download it?

You can download the SQL script here:

THIS SQL SCRIPT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND.

BizTalk Server Databases: Disaster Recovery, Troubleshooting and Best Practices whitepaper

BizTalk Server Databases: Disaster Recovery, Troubleshooting and Best Practices whitepaper

Finally, BizTalk Server Databases: Disaster Recovery, Troubleshooting and Best Practices whitepaper is published! I think this was my crazy project ever because I started during an MVP Summit, probably in 2013 with a very basic whitepaper of 7 pages about Disaster Recovery and my initial reviewer was Tord Glad Nordahl… for some reason I never finished or published the content and last year again during the MVP Summit I revived this idea and basically annoyed all the MVPs that were next to me that day to review the initial document again… bad idea for me because, probably to get revenge on me, they were the most demanding reviewers that I ever had, always asking for more content making, therefore, the whitepaper more complete. So, what was a 7-pages whitepaper becomes a 34-pages whitepaper.

BizTalk Server Databases: Disaster Recovery, troubleshooting and best practices

What to expect about BizTalk Server Databases: Disaster Recovery, Troubleshooting and Best Practices whitepaper

Microsoft BizTalk Server databases and the health of the databases are very important for a successful BizTalk Server messaging environment. BizTalk Server is an extremely database-intensive platform, persisting data to disk with high frequency, and one of the main reasons for that is because one of the primary design goals of BizTalk Server is to ensure that no messages are lost. Therefore, database performance is paramount to the overall performance of any BizTalk Server solution.

There are many factors that you need to take into consideration towards troubleshooting, maintaining, monitoring or recovering from disasters. This paper will provide you some important aspects to consider when working with BizTalk Server databases and addressing the most common and important aspects:

  • Size of databases and tables: performance degrades on High Size of BizTalk databases
  • Important consideration to avoid large BizTalk Databases
  • Separation of data files and log files (SQL Server disk I/O contention)
  • Important consideration BizTalk SQL Settings
  • Available tools for monitoring and troubleshooting
  • Recovering from disasters situations (Clean up your BizTalk databases)

However, the content is very valuable with regards to even preventing a disaster or limit the probability of it. After reading this paper you should be prepared for any disaster but also to preventing for happening because be able to prevent is better than resolving.

Where I can download it

You can download the whitepaper here:

BizTalk Server Databases: Disaster Recovery, Troubleshooting and Best Practices (1.14 MB)
BizTalk360

I would like to take this opportunity also to say thanks to my amazing reviewers: Steef-Jan Wiggers, Nino Crudele, Kent Weare, Mikael Hakansson and Salvatore Pellitteri for taking the time to review this whitepaper. And other people that were involved in making this “project” came true like Tord Glad Nordahl, Lex Hegt, Saravana Kumar and Sriram Hariharan.

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira