web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :

What happened to trace flags in Dynamics 365 for Finance and Operations?

GlenTurnbull Profile Picture GlenTurnbull 38

On previous versions, trace flags 1117, 1118, 1224, 2371 and 4199 were frequently recommended to improve the performance of AX 2009 and AX 2012 systems. An explanation of each can be found here:
https://blogs.msdn.microsoft.com/axinthefield/dynamics-ax-and-sql-server-trace-flags-quick-and-dirty/ 

These are no longer relevant or supported in SQL Azure - hence D365FFO production and sandbox environments in most cases (unless you’re “on premises”). However, in a few cases there are some similar options. Each of these are explained in turn below.

This article is intended as information only, as these settings are Microsoft controlled in the above-mentioned Dynamics 365 for Finance and Operations cloud environments.

 

Trace flags 1117, 1118

There is no tempdb database in SQL Azure, so these are no longer relevant.

Temporary tables are stored in the AXDB database instead, therefore there is no equivalent on production or sandbox environments.

The SysGlobalConfiguration table contains the parameters which enable the platform code to determine whether the environment is SQL Azure and tempdb does not exist, or vice versa. You can run the following SQL query against your AXDB database to see these for yourself:

Select value From SysGlobalConfiguration Where name in (‘BackEndDB’, ‘TempTableInAXDB’)

 

Trace flag 1224

The equivalent of trace flag 1224 is disabling lock escalation per table

In SQL Server, trace flag 1224 disables lock escalation based on the number of locks. Enabling this trace flag can reduce blocking caused by lock escalation—something that has occurred many times in implementations of previous versions.

With Dynamics 365 for Finance and Operations on SQL Azure, the alternative is to use the ALTER TABLE SET (LOCK_ESCALATION = {AUTO | TABLE | DISABLE}) option which controls lock escalation at the table level. Details can be found here: http://msdn.microsoft.com/en-us/library/ms190273.aspx 

While lock escalation and also disabling of page locks is already controlled by Microsoft for standard tables requiring it, you may wish to consider these two options for custom tables and indexes.

Lock escalation can be monitored real-time in LCS environment monitoring (SQL Insights-->SQL Now) as described in the following article: https://blogs.msdn.microsoft.com/axinthefield/dynamics-ax-live-performance/ 

Trace flag 2371

Already enabled by default on compatibility level 130 (“SQL Server 2016” databases).

The behaviour previously enabled by trace flag 2371 is now a default behaviour in SQL Server 2016 databases, as explained here: https://blogs.msdn.microsoft.com/psssql/2016/10/04/default-auto-statistics-update-threshold-change-for-sql-server-2016/ 

Trace flag 4199

The equivalent is to set the database property: QUERY_OPTIMIZER_HOTFIXES = ON

This is the standard setting for Dynamics 365 for Finance and Operations.

Additionally, on compatibility level 130 (“SQL Server 2016” databases) and upwards, even with the above setting turned off, optimizer fixes from previous versions would be included.

For further information, you can read about trace flag 4199 here:
https://support.microsoft.com/en-us/help/974006/sql-server-query-optimizer-hotfix-trace-flag-4199-servicing-model  

Comments

*This post is locked for comments