Reputation: 41
I am currently performance tuning a Microsoft Dynamics AX 2009 fully upgraded to the latest kernel / hotfix.
During this process I have come across database fill factor set to 80. Not sure why? I have altered it to 95 now - not daring the to make the final move to 100 just yet. Any thought on this?
Now the question I came here for:
What flags would be recommended on the SQL Server to support the Dynamics AX 2009?
As mentioned it is fully upgraded and its setup to call parameterized but with the DataAreaId as a literal in order to make a dedicated plan for each company.
During the past 10 years it has been performance tuned a few times. These flags are currently set: 1117, 1118, 1224, 2371, 4136, 4199, 7646
I would like to remove the 4136
Upvotes: 1
Views: 603
Reputation: 5107
Database performance tuning for AX in my experience requires the intersection of two expertises (AX and SQL Server) that rarely exist in one person. I would consider myself on the AX expert side of things and have enough SQL Server knowledge to be dangerous (or to get by). So be aware of this when reading the rest of this answer.
First, two general observations:
Now, in your question you mention two separate points:
In this example we have used 80% Fill Factor, however it doesn’t make sense to push without any benchmarking for the table. In most cases SQL Server index Fill factor will help to get well performed when Table having large number of rows and frequent update over the rows. Before setting the Fill Factor we need to analyse the Datatype of columns, actual cell size of the rows, Average number of rows in the pages and estimated updated size of row cell. This proper calculation derives an actual Fill factor value which need to be applied on the table.
If you want to go further down the rabbit hole of performance optimization for AX, I suggest the following articles. They are mostly for AX 2012, but parts should apply for AX 2009, too and provide a starting point:
Your question is in a very gray area of being on topic for Stack Overflow. You may have better luck on serverfault or Database Administrators.
Upvotes: 2