Dynamics AX and SQL Server

More and more I am seeing clients requiring assistance with the Microsoft Dynamics Suite. Each of the products in the suite comes with a different set of performance issues and gotchas. In this article I will only be discussing the AX product and an easy tweak to make troubleshooting that product much easier from the perspective of the database administrator. This tweak is to enable the context info from within the administration console.

Enable Context Info

Some may call this a critical setting that must be activated on every transaction heavy Dynamics AX AOS server. One of the most common reasons is that DAX user sessions frequently block one another. Occasionally the blocking may be uncomfortably long.

In  order to enable this setting on each DAX AOS server, the following steps should be followed:

• Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesDynamicsServer6.01Original (installed configuration). The last key, Original (installed configuration), is the key name for the current server configuration. If your system uses a different configuration than the original installed configuration, navigate to the currently active configuration.
• Create a string registry value called ‘connectioncontext’ and set the value to 1.
• Restart the AOS.

The steps to implement this change is not terribly difficult. The risk is very low as well. There is very minimal cost for sending this additional info. That said, even on an extremely busy system for one client, we have yet to see a negative impact with this setting enabled.

Easy Troubleshooting for the DBA

Now that the context info is enabled within the application, this is where the pains of troubleshooting AX performance issues within the database becomes somewhat easier for the database administrator. Just enabling the setting doesn’t bring you to the promised land though. You still need to do a bit of work.

Once the setting is enabled, what actually happens is the AX application starts to send an extra chunk of data along with each connection to the database server. This chunk of data is the context info. The context info that AX decides to send along is not straight-forward to read however. The AX context info is sent to SQL Server as a varbinary.

What does it mean to be in varbinary format for you as the database administrator? This means that you still have a bit of work to do. Do you need to perform that extra work every time you look at the data? Well, the short answer is “it depends”! If you are smart about your tool-set (e.g. set of administration scripts) then you will save this extra work there. If you do not yet have a tool-set and rewrite your queries every time – you obviously fall at the far opposite end of the spectrum and will have much more work to do.

Whichever end of the spectrum you fall within, here is script to integrate into your scripts to help make your AX DBA work just a tad bit easier.

SELECT SUBSTRING(REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))), ' ',
','),
CHARINDEX(',',
REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))),
' ', ',')) + 1,
CHARINDEX(',',
REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))),
' ', ','),
CHARINDEX(',',
REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))),
' ', ',')) + 1)
- ( CHARINDEX(',',
REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))),
' ', ',')) )
- CASEWHEN CAST(s.context_info AS VARCHAR(256)) = ''
THEN 0
ELSE 1
END) AS DAXSessionID
, SUBSTRING(REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))), ' ',
','), 1,
CHARINDEX(',',
REPLACE(LTRIM(CAST(s.context_info AS VARCHAR(256))),
' ', ','))
- CASEWHEN CAST(s.context_info AS VARCHAR(256)) = ''
THEN 0
ELSE 1
END) AS DAXUser
, s.context_info
FROM sys.dm_exec_sessions s
WHERE ISNULL(CAST(s.context_info AS VARCHAR(256)),'') <> '';

So What does it DO?

So what value does this query actually bring you? I have talked about it making life easier by enabling the context info from within AX, but I didn’t dive into any details on what it will provide.

Looking at the query I just provided, one can surmise that the context info will provide two significant pieces of information. The first bit is the Session ID. This is not the spid within SQL Server. Rather this is the session id that is a different value within AX. The second piece of information that is highly valuable is the User that is tied to that AX Session. The AX application will show as the service account for the application on all spids within SQL Server. The spid and spid user are fairly useless when trying to figure out who is causing what level of pain since all users in SQL Server for AX will appear to be the same user. The SQL spid will be useless for the DAX admins because the spid will not match the DAX session id. Both of these factors will lead to an extra amount of frustration between the DBA and DAX Admin if in the middle of a performance slowdown.

Being able to extract the DAX User and Session ID from the context info will significantly reduce troubleshooting time when in the trenches trying to figure out who is running what from within the application. This reduces the chances of taking a guess and gives good solid evidence that can be taken back to the business users and try to improve their processes and the overall performance of the system.