Configuring the instance of SQL Server for Dynamics AX

Improve SQL performance lead us to optimize AX performance, this post is one of posts to achieve that

1- Configuring max degree of parallelism

The max degree of parallelism option is a setting that affects the entire instance of SQL Server. Microsoft Dynamics AX workloads generally perform better when intra-query parallelism is disabled. However, the upgrade process benefits from parallelism, as do activities that are used exclusively for batch jobs or maintenance. Use the following settings when the system performs maintenance activities or an upgrade:

· Before an upgrade to a new release of Microsoft Dynamics AX, or before a large number of maintenance or batch activities, set max degree of parallelism to the smallest of the following values:

· 8

· The number of physical processor cores

· The number of physical processor cores per non-uniform memory access (NUMA) node

· When the Microsoft Dynamics AX database is used in a production environment, set max degree of parallelism to 1.

Use the following statements to set the value of max degree of parallelism.

Examine the output from the second sp_configure 'max degree of parallelism' statement, and confirm that the value has been changed. In the following query, the first sp_configure 'max degree of parallelism' statement sets the value of max degree of parallelism to 1. The second sp_configure 'max degree of parallelism' statement returns a value of 1.

EXEC sp_configure 'show advanced options', 1;

RECONFIGURE;

GO

EXEC sp_configure 'max degree of parallelism', 1;

RECONFIGURE;

GO

EXEC sp_configure;

For more information, see max degree of parallelism Option. For general guidelines, see Knowledge base article 329204, General guidelines to use to configure the MAXDOP option. For tips from the SQL Server team, visit the SQL Server Relational Engine team's blog, SQL Server Engine Tips.

2- Configuring max server memory

SQL Server dynamically acquires and frees memory as required. Typically, an administrator does not have to specify how much memory is allocated to SQL Server. However, the max server memory option can be useful in some environments. Make sure that sufficient memory is available for the operation of Windows Server. For more information, see Configure SQL Server and storage settings, later in this topic.

If you find that the dynamic allocation of memory adversely affects the operation of Windows Server, adjust the value of max server memory based on the available random access memory (RAM). For more information, see Effects of min and max server memory.

3- Monitoring available memory

Make sure that sufficient memory is available for the operation of Windows Server. For example, make sure that you run a dedicated instance of SQL Server on a server that has at least 4 gigabytes (GB) of memory. If the available memory for the server drops below 500 megabytes (MB) for extended periods, the performance of the server may degrade.

Use the Memory: Available Mbytes performance counter for the Windows Server operating system to determine whether the available memory drops below 500 MB for extended periods. If the available memory drops below 500 MB frequently or for extended periods, we recommend that you reduce the max server memory setting for SQL Server or increase the physical memory of the server.

Detailed guidance about memory management is beyond the scope of this topic. For more information about how to monitor memory and troubleshoot performance issues, see the Windows Server and SQL Server documentation.

4- Allocating storage for tempdb

We recommend that you determine the total size of the data files and transaction log files that are required for the tempdb database, and that you set a specific value. Do not use automatic growth, or autogrow, setting for space management. Instead, use autogrow as a safety mechanism, so that tempdb can grow if tempdb files use the space that was originally allocated to them. Follow this process to determine the number and placement of data files.

· Determine the number of processors that are available to SQL Server. Unless you are using an affinity mask, this number is same as the total number of processors that you see on the Performance tab of Windows Task Manager. When hyperthreading is not enabled, each processor corresponds to a processor core. Affinity masks and processor cores are beyond the scope of this topic. For more information, see the Windows Server and SQL Server documentation.

· Based on performance testing of the OLTP workload for Microsoft Dynamics AX, we recommend that you maintain one tempdb data file per processor. For more information, see the performance benchmark reports on PartnerSource or CustomerSource.

· Isolate tempdb on dedicated storage, if you can. We recommend that you move the primary data file and log file for tempdb to high-speed storage, if high-speed storage is available. The Microsoft Dynamics AX database runs in read committed snapshot isolation (RCSI) mode. In RCSI mode, row versions are stored in tempdb. By creating multiple files for tempdb data, even if these files reside on the same storage device, you can improve the performance of tempdb operations.

· Determine the size of the tempdb data files and log files. You must create one primary data file and one log file. Determine how many additional, secondary data files you require for the tempdb data. For best results, create data files of equal size. The total number of data files must equal the total number of processor cores. The aggregate size of the primary data file and all other data files must equal the total data size that you determined for the tempdb database.

For more information, see Optimizing tempdb performance.

· Resize the primary data file and log file for tempdb. Move the primary data file and log file to dedicated storage, if dedicated storage is available. The primary tempdb data file cannot be moved while the instance of SQL Server is running. To complete the move, you must use an ALTER DATABASE statement and restart the instance of SQL Server. For more information, see ALTER DATABASE.

Note: The data files and transaction log files for tempdb can reside on the same storage device.

· If space is available on the drive where tempdb files are allocated, do not configure the autogrow property for data files and log files as a percentage. Instead, configure the autogrow property as a specific number of megabytes. If you can, configure the data files and log files to grow by 100 to 500 MB, depending on the available space. Monitor the data files, and when they grow, adjust the original allocation to prevent automatic growth later. If the autogrow property is configured in megabytes instead of as a percentage, the allocation of space is more predictable, and the chance of extremely small or large growth increments is reduced.

· Monitor the tempdb data files and log files to make sure that they are all sized correctly, and that all data files are of equal size. Use SQL Server Management Studio or a transact-SQL query to view the database properties. Verify that all the data files are of equal size, and that they have the same size as the value that you originally provided. If one or more files have grown, adjust the initial size of all files.

Configuring physical storage for SQL server of Dynamics AX

This post provides general recommendations for physical storage. Determine the applicability of these recommendations to your environment. Some storage area network (SAN) vendors may have alternative recommendations that take precedence. Recommendations are listed in order of priority.

• Many factors contribute to optimal I/O performance for a disk. By default, Windows Server 2008 aligns partitions. When you upgrade to Windows Server 2008, preexisting partitions are not automatically aligned and must be manually rebuilt to guarantee optimal performance. Therefore, until you rebuild the migrated partitions, alignment of disk partitions remains a relevant technology.

Check existing disks on the server, and be aware of the differences in the analysis of basic partitions and dynamic volumes. Rebuild the partitions, if you can, and appropriate and create all new partitions based on guidance from the SAN vendor. If the vendor does not provide recommendations, follow the best practices for SQL Server. See Disk Partition Alignment Best Practices for SQL Server.

The partition offset value must be a multiple of the stripe size. In other words, the expression, partition offset / stripe size, must resolve to an integer value.

• Create the tempdb database files, data files for the Microsoft Dynamics AX database, and Microsoft Dynamics AX log files on disk arrays of type RAID 1, RAID 0 + 1, or RAID 10. We recommend RAID 10 for these files. Do not use RAID 5.
• Store the data files for the Microsoft Dynamics AX database on separate physical stores from the transaction log files.
• Store the tempdb data files on a separate physical store from the data files and log files for the Microsoft Dynamics AX database.
• Store other database files on separate physical stores from the data files and log files for tempdb and the Microsoft Dynamics AX database.

Tune data access settings [AX 2012]

You might want to tune the database settings for Microsoft Dynamics AX to improve performance. Settings that you can tune include connections, query settings for the use of literals, string functions, or hints, concurrency mode used for database changes, and the table and index options, such as table and index data compression, and index fill factor and sort in tempdb settings.

Before changing settings, you should trace the usage of your Microsoft Dynamics AX database to ensure that you have clear understanding of performance under the current settings.

Test all tuning changes before implementing them in a production environment. In a test or development environment, make a single change and then test your system's performance before making another change.

Tune connections

The following table lists common connection issues, and also some adjustments to try in the Server Configuration Utility.

Symptom	Adjustments to try
Queries that return a large number of rows execute slowly.	Increase the Maximum buffer size value in small increments. If this adjustment has worked, the number of round trips to the database, as measured in Performance Monitor by a decrease in the value of SQL Server statistics: batchrequestsPerSecond value. Stop increasing the value when the rate of improvement diminishes. You may also want to change the Maximum buffer size value if you receive an error similar to the following: The total, internal size of the records in your joined Select statement is 29374 bytes, but Microsoft Dynamics is by default performance-tuned not to exceed 27646 bytes. It is strongly recommended that you split your tables(s) into smaller units. Maximum buffer size refers to the size of buffer the kernel allocates for holding input/output data to and from SQL Server. The buffer can be used to hold more than one row of the entire result set for output binding, and it should be allocated large enough to hold at least one row. The buffer size needed for one row depends on the number of tables joined (exist join excluded) and the size of the aggregated table columns. When large numbers of joins are used, or wide tables, a customer may encounter the issue that the maximum buffer size is less than the space needed to hold one row of the result set. Due to the way the kernel handles data binding, the aggregated table column size is always the width of the entire table. Therefore, attempting to resolve the issue by limiting the field projection list does not help. You can fix the issue by rewriting the join, or by increasing the Maximum buffer size value. Because large joins and wide rows may lead to performance issues, we use this limit to catch performance issues and ask customers to rethink their joins.
Results for ad hoc queries are returned slowly	Verify that the appropriate indexes are in place.

Tune queries

If queries in the system are running slowly, you may want to change settings for literals, string functions, or hints.

Adjust the use of hints

In Microsoft Dynamics AX, you can allow developers to override the index selected by the query optimizer. In most situations, allowing the query optimizer to select an index for a query results in improved performance.

Changes in the use of hints

The following changes to hints have been made:

· The OPTION (FIRSTFAST) hint is applied by default for form data sources. It can be suppressed, or set to a specific value. Use of this option appends an OPTION (FAST) to the SQL Server query.

· OPTION( FAST) is now set to what we expect the number of rows to be returned to the database in a single roundtrip. This is based on maximum buffer size.

· FASTFORWARD cursors are used for all user queries unless the query is a full text search.

Change table and index options

Table and index options that can be changed from within Microsoft Dynamics AX include table compression settings, and index compression, fill factor, and sort in tempdb settings.

Data compression options

If you have appropriate hardware, we recommend that you set all tables and indexes to use page-level compression. Compression saves disk space and memory consumption, but increases CPU consumption.

When page-level compression has been set, expect between 10-15 percent additional CPU consumption.

If you are concerned about CPU consumption, we recommend that you start by setting the ten largest tables in your system to use table compression.

Use the guidance in the following resources to help you determine how or whether to compress your tables and indexes:

· SQL Server Books online: Creating Compressed Tables and Indexes

· SQLCat article: Data Compression: Strategy, Capacity Planning and Best Practices

· Database Engine team blog post: Compression Strategies.  

Fill factor options

We recommend that you not set the fill factor options (fill factor and pad index) for all indexes. Only set fill factor values on indexes that show rapid fragmentation, where fragmentation has a performance penalty. Adjusting fill factor can be important for tables that you want to retrieve sequential rows from, for example, sales line.

We recommend that you work with your database administrators to identify the tables to set this value for.

Sort in tempdb

We recommend that you not set the sort in tembdp options for all indexes. Only enable sort in tempdb for indexes that show rapid fragmentation, where fragmentation has a performance penalty.

We recommend that you work with your database administrators to identify the tables to set this value for.

To change table and index options

1. Click System administration > Periodic > Database > SQL administration. Select all tables, all indexes, or a specific table or index, and then click Table and index options.

2. Select the options to set, and then click Save.

The SQL statement that will be executed is displayed at the bottom of the form.

Important

The changes that you have made will not be applied unless you specify that they should be applied by using the SQL administration form. To turn off data compression, click Enable compression, click None for the type of compression, and then close the Select table and index options form, and then click Apply compression in the SQL administration form.

3. To apply changes in the SQL administration form:

o For tables, click Table actions, and then click Apply compression.

o For indexes, click Index actions, and then click Reindex.

Change the concurrency mode

Concurrency mode settings enable you to reduce locking conflicts in your system. Set concurrency mode settings only at the table or statement level, not throughout your Microsoft Dynamics AX program.

Optimistic concurrency

An optimistic concurrency strategy does not lock data when the data is retrieved from the database for future modification. Therefore, no locks are held while filters and other business logic are being applied. Data is locked only when an update is performed. If any data has been changed by another transaction between the time of the retrieval and the time of the update, the change is detected and an Infolog exception is displayed.

Pessimistic concurrency

A pessimistic concurrency strategy uses an update lock to lock data when the data is retrieved from the database for future modification. Locks are held while filters and other business logic are being applied, in addition to being held during an update. Data cannot be changed by other transactions.

Acquiring an update lock for a large volume of rows increases the lock escalation from row level to table level in SQL Server. This can block other users and reduce transaction throughput.

Table-level concurrency settings

If the global concurrency mode is set to Optimistic concurrency mode enabled per table, table-level control of concurrency settings is available using the OccEnabled property.

Runtime update options

If you are encountering many update errors, you may want to use the runtime update options to help troubleshoot. These options are intended for temporary use only, as they might significantly slow performance.

Use Writes all UPDATE conflict exceptions to the log to write all update conflict exceptions to the log.

Use Update record version automatically to have Microsoft Dynamics AX search in memory for the recordID every time that that a record is updated, and then change the update values in all instances of the record.

If you have a table set to optimistic concurrency, and you are experiencing optimistic concurrency violations that affect the performance of the transactions that use the table, then first set the Writes all UPDATE conflict exceptions to the log option. If, from your analysis, it appears that the use of optimistic concurrency is causing a problem, then set the table to pessimistic concurrency.

To change concurrency settings

1. Click System administration > Setup > Database > Select concurrency mode.

2. Select the appropriate concurrency mode and runtime options for your environment.

3. Click Close.

Statement-level concurrency settings

You can use the optimisticlock or pessimisticlock keywords in a SELECT statement to override the global or table concurrency mode settings.

For more information, see the following topics:

· Best Practice Performance Optimizations: Database Design and Operations

· Transaction Integrity

· Exception Handling with try and catch Keywords

· Select Statement Syntax

· Table Properties