- 5 minutes to read

FAQ and Troubleshooting BizTalk Server Logging to Nodinite

If you have any issues that you can not solve, contact our Support or send us an email at support@nodinite.com.

Login failed for user "NT AUTHORITY\ANONYMOUS LOGON"

Please review the Trusted for delegation user guide to make sure the Kerberos security protocol is operational.

"Could not allocate space for object"

The "Could not allocate space for object" error message usually results from a tempdb configuration issue within SQL Server. Please review the BizTalk Server Logging Recommendations user guide. When this problem happens, SQL fails to sort the data to be returned; hence, until you resolve this issue, the Logging from BizTalk fails(!).

When you first enable Logging from BizTalk, Nodinite is far behind. Hence, Nodinite will now copy everything from the BizTalk tracking database (BizTalkDTADb). This initial load may cause resource exhaustion. You may even run out of disk space allowed for the primary filegroup for the tempdb (usually, this happens on the SQL Server instance with the BizTalkDTADb database).

Failed to copy/insert Events from BizTalk to Nodinite","exception":"System.Data.SqlClient.SqlException (0x80131904): Could not allocate space for object 'dbo.SORT temporary run storage:  140865700167680' in database 'tempdb' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.\r\n   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)\r\n   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)\r\n   at System.Data.SqlClient.TdsParser.TryRun(

About Deadlocks

  • Getting locks is a natural behaviour for BizTalk Server. Nodinite, by design, provides a pragma to choose our thread as the deadlock victim to AID SQL Server to kill our attempt to get the data.

    • Nodinite retries the operation shortly, and no data is lost.
    • Deadlocks are a clear indication of a system under high stress.
      • Have you exhausted the available free memory?
      • Is the CPU load constantly > 90%?

  • Please review and implement our BizTalk Logging Recommendations to tune both Nodinite AND the BizTalk Server environments.

Questions to answer and actions to perform

Does the BizTalk Server environment perform well, or do you see performance-related problems there as well?

When was the last split? e.g. How old is the current Log Database?

What is the size of the current Log Database?

What is the size of the BizTalk Tracking database?

  • If the database is larger than 20-30 GB, you need to review the number of days to keep the data within BizTalk.

​For how long time do you keep events in the BizTalk Tracking database?

  • Do note that Nodinite replaces the long-term Logging functionality of BizTalk Tracking. You should only keep data in BizTalk for a few days. Our recommendation is 4-7 days to survive system related problems over long weekends. It would be helpful to use the latest Nodinite version since we add performance improvements over time.
  • Install and Update Tool
  • Update Nodinite

Copying Body and Context has been interrupted

If you encounter a situation where there is no processing of logged events from BizTalk, you should first contact our support. This problem typically occurs if your BizTalk Server environment experiences one or more of the following conditions (the list is not comprehensive):

  • Out of disk space
    • Incorrect restore
    • Referential integrity mismatch between the BizTalk MgsBoxDB and BizTalkDTADB
  • Extreme high load
    • BizTalk can write thousands of tracked events with the exact same timestamp (which is not normal)
  • Excessive tracking due to enabled pipeline tracking. Please review the Recommended tracking settings for BizTalk Server default pipelines user guide
  • Timeout is reported as a system error in the Nodinite Audit Log if you search for DTA as part of the function:
    DTA
    If any of these functions time out, you may have a problem with the BizTalk logging

If you need an instant resolution, you can try to execute the steps described below.

  1. Stop the Nodinite Logging Service
  2. Execute the script below
    1. Open SSMS
    2. Open a new query with the Nodinite Configuration Database
    3. Copy, modify and execute as appropriate

Note1: Replace the value for @logAgentValueId as appropriate for your configuration. Verify the actual value using the information from the Configure Microsoft BizTalk Server Logging Agent section.
Note2: Double the inital default value 5000 until the output returns a successful transfer of bodies or context.

DECLARE @temp DTADataTableType, @logAgentValueId INT = 1;
INSERT INTO @temp EXEC [Log_DTAGetTrackedData] 5000, @logAgentValueId , null, 0, 1;
EXEC [Log_DTAInsertTrackedData] @temp, @logAgentValueId, @printText=1
  1. Please attach the output to our support to get the situation documented and properly investigated in order to find the root cause.
  2. Restart the Nodinite Logging Service

What is the largest size for logged Context in BizTalk?

To find the largest context, execute the following command using SSMS and select to use the BizTalk tracking database (BizTalkDTADB):

SELECT MAX(datalength(imgpart)) FROM Tracking_Parts1 WITH (NOLOCK)

You can then find the message Id, either in the BizTalkDTADB or from the Admin Log View within Nodinite.