There's this stored procedure written in SQL which retrieves historical order data and displays it on the Commerce Server Website. This SP uses almost 13 tables to retreive the data from (which includes custom and standard AX tables).
We added few indexes from AX to boost performance but in vain as when we run the Query Execution Plan, the Subtree cost of the index still shows more than 80%. SQL Server 2008 suggests new indexes which can be added via SQL to improve the performance of the query. I tried the indexes suggested by SQL and immediately the performance boost can be observed.
After some investigation, I found that the index added by SQL is different from index added via AX as AX doesn't have the capability to add the INCLUDE keyword when we create a new non-clustered index which SQL does as shown in the screenshot below
Here's something more about the include keyword from MSDN
Index with Included Columns
You can extend the functionality of nonclustered indexes by adding nonkey columns to the leaf level of the nonclustered index. By including nonkey columns, you can create nonclustered indexes that cover more queries. This is because the nonkey columns have the following benefits:
• They can be data types not allowed as index key columns.
• They are not considered by the Database Engine when calculating the number of index key columns or index key size.
An index with included nonkey columns can significantly improve query performance when all columns in the query are included in the index either as key or nonkey columns. Performance gains are achieved because the query optimizer can locate all the column values within the index; table or clustered index data is not accessed resulting in fewer disk I/O operations.
Issue
Whenever a synchronization is done, AX overwrites the indexes which we put through SQL
Resolution
a. Created the index via AX as a table method
b. Modified the Application Class/dbsynchronize method so that after synchronization it invokes the table method to create index (mentioned above in Step a)
So, by doing this we have the SQL Indexes intact as we are recreating the index once AX finishes it's synchronization thereby avoiding the overwritten part
That's one way of doing things, but to firmly control the database one could use one of our add-ons: Advanced Storage Management
ReplyDeleteDB-Admin armed with ASM is able to permanently set:
-table and index stay in filegroup of choice
-table partitioning
-included fields
-filtered indexes
-table compression
-index locking settings
Our solution is 100% DB Synchronize friendly- AX honours table options set using Advanced Storage Management. More on our website.
Regards
Cool, this will make your DBA's day by recreating indexes after each synchronization
ReplyDeleteThanks Dilip for this information.
ReplyDeleteCan you please give the code for "Modified the Application Class/dbsynchronize method "
Regards
Shibu P
thanks, can you please give the code for "Modified the Application Class/dbsynchronize method"
ReplyDelete