Database Configuration Checklist
Version 1.2 (2009-06-23)
Assumptions:


Dedicated SQL Server 2005 or 2008 Server (does not run any other major applications besides
SQL Server)
Single instance of SQL Server dedicated to running Dynamics Ax database.
OS
 Set Advanced Performance Option->Processor scheduling: Best Performance of Background
Services.
 Set Advanced Performance Option->Memory usage: Best Performance of Programs (does not
apply to Windows Server 2008).
How::
Windows Server 2003:
My Computer->Properties->Advanced tab->Performance->Settings button->Advanced
tab->Choose Processor Scheduling-Adjust for best performance of Background Services,
Memory Usage-Adjust for best performance of Programs.
Windows Server 2008:
My Computer->Properties->Advanced System Settings->Advanced tab->Performance
Settings->Advanced tab->Choose How to Allocate Processor Resources->Adjust for Best
performance of background services.
Why:
SQL Server runs as a background service, so the Processor scheduling option “Background
services” is optimal (“Programs” is more optimal for interactive applications). SQL Server
maintains its own cache, so the Memory usage setting “Programs” is optimal (“System cache” is
more optimal for file and print servers).
 Ensure boot.ini parameter /USEPMTIMER is present on AMD64 systems.
References:
http://blogs.technet.com/perfguru/default.aspx
http://support.microsoft.com/kb/895980
SQL Instance – Service Config
 Run SQL Server service under a Domain Account with minimum necessary privileges.
References:
See http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd729f31282b04d/SQLSecurityOverviewforAdmins.doc for detailed prescriptive guidance on
configuring SQL Server service accounts.
AX Database Configuration Checklist v1.2
Page 1
 Grant SQL Server service account “lock pages in memory” privilege (Local Security Policy).
How:
See http://technet.microsoft.com/en-us/library/ms190730.aspx for detailed instructions. This
privilege is not automatically granted to local administrators.
References
http://blogs.msdn.com/psssql/archive/2007/10/18/do-i-have-to-assign-the-lock-privilege-forlocal-system.aspx
http://support.microsoft.com/kb/918483
http://blogs.msdn.com/slavao/archive/2005/08/31/458545.aspx
 Enable TCP/IP network protocol.
NOTE: This protocol may be automatically enabled when SQL Server is installed, depending on
the edition.
How:
http://msdn2.microsoft.com/en-us/library/ms191294.aspx
 Disable Hyperthreading
How:
This must be performed in the bios settings of the server.
Why:
Not all SQL Server workloads benefit from hyperthreading. Dynamics AX ERP has not been
extensively tested with hyperthreading, so the recommendation is to disable it.
References:
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
SQL Instance – Configuration
Max Degree of Parallelism (MAXDOP instance-wide)
 OLTP (normal operations0: Set Max Degree of Parallelism to 1
 UPGRADE (when upgrading to a new release of Ax): Set Max Degree of Parallelism to lesser of
{8, # of physical processor cores, # of physical processor cores per NUMA node}.
How:
Use sp_configure system stored procedure where n is the desired value:
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
GO
EXEC sp_configure;
Examine the output from the second sp_configure execution and confirm that the new value is in
the run_value column for the max degree of parallelism setting.
Why:
Dynamics AX OLTP workloads generally perform better when intraquery parallelism is
disabled, but the upgrade process benefits from parallelism.
AX Database Configuration Checklist v1.2
Page 2
References:
http://msdn2.microsoft.com/en-us/library/ms181007.aspx
http://support.microsoft.com/kb/329204
http://blogs.msdn.com/sqltips/archive/2005/09/14/466387.aspx
 Memory: Adjust MAX Server Memory (MB) according to available RAM (32/64 bit server):
NOTE: The following recommendations for configuring SQL Server:max server memory do not
apply to Windows Server 2008, only to earlier versions of the OS (Windows Server 2003).
Windows 2008 includes improvements to memory management that make explicitly setting
maximum SQL Server memory unnecessary (assuming the host is a dedicated to running a
single SQL Server instance); see http://support.microsoft.com/kb/918483.
Server RAM
(MB)
2,000
4,000
6,000
8,000
12,000
16,000
24,000
32,000
>32,000 <=
128,000
>128,000
SQLServer:max server memory
(MB)
1,600
3,000
4,500
6,500
10,000
14,000
22,000
30,000
(available RAM) – 2,000 to 4,000
/3GB
*
No
Yes
Yes
Yes
No
No
No
No
No
/PAE*
AWE*
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
4,000
No
Yes
Yes
*Denotes 32-bit only setting
Set Maximum Memory
How:
Use sp_configure to set the value of ‘max server memory (MB)’ as follows:
EXEC sp_configure 'max server memory (MB)', 10240;
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure;
This example sets the max server memory to 10,240MB (10GB). Replace the value 10240 with
the desired value. Examine the output from the second sp_configure execution and confirm that
the new value is in the run_value column.
Why:
Under the default setting, which is to use all available memory, SQL Server may leave no more
than 128MB physical memory free, and may not release memory fast enough if needed by the
Operating System. These settings generally assure that ample memory will be available. See
note above – max server memory setting does not apply to if SQL Server is running on Windows
Server 2008 OS.
References:
AX Database Configuration Checklist v1.2
Page 3
http://blogs.msdn.com/slavao/archive/2006/11/13/q-a-does-sql-server-always-respond-tomemory-pressure.aspx
http://support.microsoft.com/kb/918483
Set AWE
NOTE: Only configure on 32-bit systems as specified.
How:
Use sp_configure to set the value of ‘awe enabled’ as follows:
Examine the output from the second sp_configure execution and confirm that the new value is in
the run_value column. If the ‘lock pages in memory privilege’ has not been set for the service
account, an error is raised if you attempt to enable AWE (see section above).
Why:
If AWE is not enabled, SQL Server will be unable to address more than 2GB or 3GB of memory
(depending on /3GB switch), irrespective of how much physical RAM is available. When AWE
is enabled, the additional memory over 2GB or 3GB is available to SQL Server for data cache
buffers. 32-bit only, not applicable to native 64-bit SQL Server 2005 instances.
References:
http://msdn2.microsoft.com/en-us/library/ms190673.aspx
http://technet.microsoft.com/en-us/library/ms191481.aspx
http://technet.microsoft.com/en-us/library/ms187499.aspx
Set /PAE and /3GB switches in boot.ini
NOTE: Only configure on 32-bit systems as specified
How:
These options are set in the boot.ini file for the appropriate OS selection. If hot-swappable
memory is supported by the hardware, the functionality enabled by the /PAE switch is
automatically enabled.
Why:
/3GB is required to address memory >2GB on 32-bit systems, and /PAE is required to address
memory >4GB on 32-bit systems. Enabling /3GB limits memory available to the OS to a
maximum of 16GB, even if more physical RAM is installed..
References (see AWE section above)
 Monitor available memory to ensure that SQL Memory setting is correct.
How:
Use the sysmon performance counter Memory:Available Mbytes to determine if available
memory drops below 500MB, especially for sustained periods. You may need to reduce SQL
Server Max Memory if this happens regularly or for extended durations.
Why:
On a server with at least 4GB running a dedicated SQL Server workload, when available
memory goes below 500MB, especially for sustained periods, the server may experience
performance problems. It is out of scope of this document to provide guidance applicable in
AX Database Configuration Checklist v1.2
Page 4
every such situation, but if available memory exhibits this pattern, further investigation and
remediation may be necessary.
Tempdb database storage configuration
 Determine total size of data and transaction log required for tempdb to avoid autogrow, and
number of data files required based on # of processors (logical or physical).
How:
Determine the number of processors exposed to SQL Server. Unless you are using an affinity
mask (not covered here), this is the total number of processors you see in the Windows Task
Manager Performance tab. When hyperthreading is not enabled, each “processor” corresponds
to a processor core.
Why:
SQL Server creates one visible scheduler (for processing user requests) for each processor, and
we generally want to maintain one tempdb data file per processor. This recommendation is
based on performance testing on the Dynamics AX OLTP workload.
 Move tempdb primary data file and log file to high-speed storage (if available); at the same time,
resize data file proportionally to total size, and resize log file to required size.
How:
Moving tempdb primary data and/or transaction log file must be performed in two steps: first,
alter the database and move the files; second, restart SQL Server instance to complete the move.
The primary tempdb data file cannot be moved while SQL Server instance is running. NOTE:
tempdb data and transaction log files may reside on the same storage device.
See http://technet.microsoft.com/en-us/library/ms174269.aspx (Section G) for detailed
instructions on how to move tempdb database files.
Why:
Isolating tempdb on its own storage can improve performance. However, it is more critical to
separate user database data and transaction log files (see section below).
 Create additional data files depending on number of processor cores, of equal size, totaling the
data size determined in previous step, so that the aggregate size of data files including the
primary data file meets the total size requirement. All data files must be identical in size.
How:
Additional database data files can be created from SQL Server Management Studio (SSMS) UI
or by using the ALTER DATABASE command.
Why:
Creating multiple files for tempdb data, even if these files reside on the same storage device, can
improve performance of tempdb operations, especially for databases (such as the AX user
database, see below) that run in Read-Committed Snapshot Isolation (RCSI) mode. RCSI stores
row versions in tempdb.
References:
AX Database Configuration Checklist v1.2
Page 5
http://www.microsoft.com/technet/prodtechnol/sql/2005/workingwithtempdb.mspx contains a
comprehensive set of Best Practices for managing the tempdb database.
 If space is available on the drive where tempdb files are allocated, configure auto grow in MB
(100-500) rather than percent for both data and log files.
How:
Auto grow configuration can be set from the SSMS UI or by using ALTER TABLE command.
Why:
Auto grow should not be used for space management, but rather as a “relief valve” in case
tempdb files exhaust their initially allocated space. If files auto grow, the initial allocation
should be adjusted to avoid auto grow in the future. Configuring auto grow in MB rather than
percent increments allow for more predictable space allocation, and helps avoid extremely small
or large growth increments.
 Review tempdb data and log files to ensure that they are all sized correctly and that data files
remain of equal size.
How:
The easiest way to check is to use the database properties -> files UI in SQL Server Management
Studio; scan the data files size to ensure that they are the same and at their initial values. If not,
it means more space was required and one or more files grew, and the initial files sizes may have
to be adjusted accordingly to ensure that they files remain at the same size at all times.
AX User Database Configuration
 Set compatibility level to 90 (SQL 2005) or 100 (SQL 2008).
 Set Read-Committed Snapshot Isolation = true (cannot be performed through GUI).
How:
Execute the following command with no other active connections in the database:
ALTER DATABASE <ax database name>
SET READ_COMMITTED_SNAPSHOT ON;
Query the row in sys.sysdatabases and ensure that the column is_read_committed_snapshot_on =
1. Replace <ax database name> with the appropriate name.
Why:
Testing with Dynamics AX ERP shows superior performance when using Read Committed
Snapshot Isolation.
References:
http://technet.microsoft.com/en-us/library/ms175095.aspx includes complete instruction on
enabling RCSI.
http://technet.microsoft.com/en-us/library/ms188277.aspx includes a discussion contrasting Read
Committed Snapshot Isolation and Read Committed Isolation.
AX Database Configuration Checklist v1.2
Page 6
 Set Auto-Create Statistics, Auto Update Statistics= True; set Auto Update Statistics
Asynchronously = FALSE (this is a change from our previous recommendation).
How:
These settings can be enabled from SQL Server Management Studio (SSMS) UI or by issusing
the appropriate ALTER DATABASE statement.
Why:
Testing with Dynamics AX ERP shows superior performance when using these options.
 Ensure Auto Shrink = False.
How:
These settings can be enabled from SQL Server Management Studio (SSMS) UI or by issusing
the appropriate ALTER DATABASE statement.
Why:
Automatically shrinking database files can incur potentially severe performance problems. If it’s
necessary to shrink these files, it can be performed manually at a time designed by the DBA.
References:
http://blogs.msdn.com/sqlserverstorageengine/archive/2007/03/28/turn-auto-shrink-off.aspx
 If autogrow is configured, use MB (usually 100-500) rather than percent for both data and log
files.
How:
Autogrow configuration can be set from SQL Server Management Studio (SSMS) UI or by
issusing the appropriate ALTER or CREATE DATABASE statement.
Why:
When autogrow is specified in absolute increments rather than as a percent of the total size, the
effects of autogrow are easier to anticipate and manage. Percent-based autogrow setting can err
on either extreme, of creating too many small file increments in rapid succession, or creating
overly large increments.
Autogrow should be considered a “relief valve” to allow database files to grow when absolutely
necessary, rather than causing an error, but it should not be used as a long-term storage
management solution. When an autogrow event occurs, the DBA should respond by reviewing
the size of all database files and adjusting accordingly, to minimize the probability of future
autogrow events. Space should be periodically reviewed and adjusted when necessary based,
rather than having the system periodically expand files on its own.
Physical Storage Configuration
Note: Compliance is optional depending on storage resources available. Some SAN vendors may have
alternate recommendation that take precedence. Recommendations are listed in priority order.
 Perform sector alignment before allocating storage volumes to SQL Server on most SAN
environments.
AX Database Configuration Checklist v1.2
Page 7
NOTE: The following recommendations for sector alignment do not apply to Windows Server
2008. Partitions created under Windows 2008 are aligned to sector 1024 by default, which is an
acceptable setting.
How:
Consult with your SAN vendor if possible for specific guidance on the storage product you are
using. In the absence of vendor-specific recommendations, volume alignment should be set on a
64K offset for SQL Server. See the Predeployment I/O Best Practices paper referenced below
for detailed instructions. It is generally not necessary to perform volume alignment using
Windows Server 2008, but check with your SAN vendor if in doubt.
Why:
Sector alignment (or volume alignment) ensures that logical disk sectors conform to physical
sector boundaries on the disk geometry. Windows 2003 does not align sectors optimally for
SQL Server workloads by default, causing performance problems because each logical sector
spans two physical sectors.
References:
Predeployment I/O Best Practices
Physical Database Storage Design
 AX User database data files and transaction log files are on separate physical stores.
 Tempdb database files not on RAID 5 (RAID 1, 0+1, or 10 preferred).
 AX transaction log file is not on RAID 5 (RAID 1, 0+1, or 10 preferred).
 AX data files are not on RAID 5 (RAID 0+1, or 10 preferred).
 Tempdb database files are on separate physical store from user database files.
 Other database files (if any, such as databases for performance monitoring) are on separate
physical store from AX and Tempdb database files.
AX Database Configuration Checklist v1.2
Page 8