Altiris Notification Server
SQL Tuning and Maintenance
Last update: 2/26/07
SQL Tuning and Maintenance
Page 1
Notice
The content in this document represents the current view of Altiris as of the date of publication. Because Altiris responds continually
to changing market conditions, this document should not be interpreted as a commitment on the part of Altiris. Altiris cannot
guarantee the accuracy of any information presented after the date of publication.
Copyright © 2007, Altiris, Inc. All rights reserved.
Altiris, Inc.
588 West 400 South
Lindon, UT 84042
Phone: (801) 226-8500
Fax: (801) 226-8506
BootWorks U.S. Patent No. 5,764,593.
RapiDeploy U.S. Patent No. 6,144,992.
Altiris, BootWorks, Inventory Solution, PC Transplant, RapiDeploy, and RapidInstall are registered trademarks of Altiris, Inc. in the
United States.
Carbon Copy is a registered trademark licensed to Altiris, Inc. in the United States and a registered trademark of Altiris, Inc. in other
countries.
Microsoft, Windows, and the Windows logo are trademarks, or registered trademarks of Microsoft Corporation in the United States
and/or other countries.
Other brands and names are the property of their respective owners.
Information in this document is subject to change without notice. For the latest documentation, visit www.altiris.com.
Page 2
SQL Tuning and Maintenance
Table of Contents
Table of Contents ........................................................................................................................ 3
Document Summary ................................................................................................................... 4
I/O Optimization ......................................................................................................................... 4
Raid Configuration.................................................................................................................. 4
TEMPDB ................................................................................................................................ 5
Transaction Log ...................................................................................................................... 5
Performance Counters for I/O ................................................................................................. 5
SQL Memory Configuration ....................................................................................................... 7
Processor ..................................................................................................................................... 9
Configuring the OS Swap File .................................................................................................. 11
Set Other Performance Counters .............................................................................................. 13
Configuring the Backup Type – Simple Backup ...................................................................... 24
Creating a Maintenance Plan for SQL Server........................................................................... 25
Defragging SQL ........................................................................................................................ 39
Running Maintenance Procedures ............................................................................................ 39
DBCC UPDATEUSAGE...................................................................................................... 39
sp_updatestats ....................................................................................................................... 40
sp_recompile ......................................................................................................................... 41
Advanced SQL Tuning For Windows 2000 Advanced Server, Windows 2000 Datacenter,
Server Microsoft Windows Server 2003, Enterprise Edition, or Windows Server 2003,
Datacenter Edition .................................................................................................................... 43
Summary ............................................................................................................................... 43
4GT Technical Reference ..................................................................................................... 43
Common 4GT Scenarios ....................................................................................................... 44
To enable 4GT ...................................................................................................................... 46
Problems Caused by the /3GB Switch .................................................................................. 46
Appropriate Usage of the /USERVA Switch ........................................................................ 47
Physical Address Extension (PAE) X86 overview ............................................................... 47
What Is PAE X86? ................................................................................................................ 47
Common PAE X86 Scenarios ............................................................................................... 48
To enable Physical Address Extension (PAE) X86 .............................................................. 48
Updates to PAE X86 ............................................................................................................. 49
AWE Memory SQL Server Performance Tuning Tips............................................................. 51
Defrag the drives in the Server ................................................................................................. 54
SQL Tuning and Maintenance
Page 3
Document Summary
The information in this document is written to coincide for the most part with the SQL Tuning –
Best Practices for Altiris Notification Servers document. Additions have been added that are
not included in the the SQL Tuning – Best Practices for Altiris Notification Servers
document. It is written as a process-oriented document to list the steps necessary to successfully
configure and tune SQL. Because this document is a work in process, this document is subject to
change at anytime.
I/O Optimization
Raid Configuration
The ideal RAID configuration for performance is 10. RAID Level 10 requires a minimum of 4
drives to implement. Two drives are mirrored and two are striped.
RAID 10 is implemented as a striped array whose segments are RAID 1 arrays
RAID 10 has the same fault tolerance as RAID level 1
RAID 10 has the same overhead for fault-tolerance as mirroring alone
High I/O rates are achieved by striping RAID 1 segments
Under certain circumstances, RAID 10 array can sustain multiple simultaneous drive failures
Page 4
SQL Tuning and Maintenance
TEMPDB
If you have multiple databases in use on your SQL Server, dedicate the TempDB for the Altiris
database by creating a SQL instance for the Altiris database.
Segregate the Altiris and TempDB databases on different RAID drives.
Transaction Log
Segregate the dat and transaction logs on different RAID drives
Performance Counters for I/O
From: http://www.sql-server-performance.com/performance_monitor_counters_io.asp
If your I/O subsystem is working efficiently, then each time SQL Server wants to write or read data,
it can without waiting. But if the load on the server is too great, then reads and writes will have to
wait, each taking their turn. This can significantly reduce SQL Server's performance.
One of the best ways to monitor your server's I/O subsystem is to use the PhysicalDisk Object:
Avg. Disk Queue Length to monitor each disk array in your server. If the Avg. Disk Queue Length
exceeds 2 for continuous periods (over 10 minutes or so) for each individual disk drive in an array,
then you probably have an I/O bottleneck for that array. You will need to calculate this figure
because Performance Monitor does not know how many physical drives are in arrays.
For example, if you have an array of 6 physical disks, and the Avg. Disk Queue Length is 10 for a
particular array, then the actual Avg. Disk Queue Length for each drive is 1.66 (10/6=1.66), which
is within the recommended 2 per physical disk.
If your server has an I/O bottleneck, consider these potential solutions adding drives to an array,
getting faster drives, adding cache memory to the controller card, using a different version of RAID,
getting a faster controller, or reducing the load on the server.
From: http://sqljunkies.com/Article/99EBD29D-8B59-4DF0-A2D2-EBB2DDF8A808.scuk
In the System Monitor there are five Physical Disk counters for each physical disk contained in the
Logical Drive that are key to identifying I/O bottleneck. Each disk should be investigated individually.
1. Avg. Disk Queue Length is the average number of both read and write requests that were
queued for the selected disk during the sample interval.
2. Avg. Disk sec/Read is the average time, in seconds, of a read of data from the disk.
3. Avg. Disk sec/Write is the average time, in seconds, of a write of data to the disk.
4. Disk Reads/sec is the rate of read operations on the disk.
5. Disk Writes/sec is the rate of write operations on the disk
First, on the System Monitor properties window, slide the time interval to only include the period of "slow
performance." Then calculate the I/Os per disk as follows.
Suppose you have a RAID 5 configuration with four physical disks, and you had the following information
from the System Monitor.
SQL Tuning and Maintenance
Page 5
Disk Reads/sec
120
Disk Writes/sec
150
Avg. Disk Queue Length 12
Avg. Disk Sec/Read
.035
Avg. Disk Sec/Write
.045
Raid Calculations:
Raid 0 -- I/Os per disk = (reads + writes) / number of disks
Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks
You can use the above RAID calculations to determine the I/Os per disk. 120 reads + (4 * 150 writes) / 4
physical disks = 180 I/Os per disk. This is over the general rule of 125 I/Os per disk capacity. This
system has a disk bottleneck.
You can determine that with 720 total I/Os, six physical disks would be required to resolve the disk
bottleneck. (720 / 125= 5.76). Adding even more disks will provide room for growth. You should calculate
for peak workloads and future growth.
The Average Disk queue length is the total for all physical disks in the RAID configuration. In the example
above, 12 for avg. disk queue length / 4 physical disk = 3 queued I/Os per disk. Anything over 2 is reason
to investigate further.
Next look at average disk per seconds. In general, Average Disk Sec/Read of 11 ms -15 ms or lower is
good. Average Disk Sec/Write of 12 ms or lower are good. Anything above this number is reason to
investigate further.
To include these counter within Perfmon you may need to type from a Start –Run window:
diskperf –y
Page 6
SQL Tuning and Maintenance
SQL Memory Configuration
1. Open up SQL Enterprise Manager.
2. Right-click on the server name and select Properties.
The SQL Server Properties dialog appears:
3. Verify that the Services are set to Autostart when the operating system starts.
SQL Tuning and Maintenance
Page 7
4. Click the Memory tab.
Dynamically configure SQL Server memory
Specify that Microsoft® SQL Server™ memory be configured immediately after you make changes to the server
properties.
Use a fixed memory size
Specify a fixed memory size for SQL Server.
Reserve physical memory for SQL Server
Reserve physical memory space for SQL Server equal to the memory setting. This means Microsoft Windows NT®
4.0 or Windows® 2000 does not swap out SQL Server's pages even if the pages can be used more readily when SQL
Server is idle.
Minimum query memory
Specify the minimum amount of memory that can be allocated per user for query execution. The default is 1024
kilobytes (KB).
Configured values
View or change the configured values for the options on this tab. If you change these values, click Running values to
see whether the changes have taken effect. If they have not, you must restart the instance of SQL Server for the
changes to be implemented.
Running values
View the current running values for the options on this tab. These values are read-only.
Page 8
SQL Tuning and Maintenance
The memory settings for an Altiris configuration is very dependent upon the location of SQL in
relation to Notification Server or Deployment server, the version of SQL (standard or enterprise
and the Operating System version. Only a couple of scenarios will be listed here.
If the SQL Server is running on the same computer as the NS and the version is SQL 2000
Standard, the “Use a fixed memory size (MB)” setting, limiting SQL to 1.5 GB of RAM in a 4
GB system is probably the best choice.
If the SQL Server is on a dedicated computer other than the NS and the SQL version is SQL
2000 Standard, the “Dynamically configure SQL Server memory, limiting SQL to 2 GB of RAM
in a 4 GB system is probably the best choice.
Processor
1. Click the Processor tab.
See the section of “Set Other Performance Counters” for measuring performance.
SQL Tuning and Maintenance
Page 9
Processor
Specify the processor you want the instance of Microsoft® SQL Server™ to use.
Maximum worker threads
Specify the maximum number of worker threads available to SQL Server processes.
Boost SQL Server priority on Windows
Specify whether an instance of SQL Server can run at a higher priority than other processes on the same computer.
The default is 0, which is a priority base of 7. If you set this option to 1, SQL Server runs at a priority base of 13 in
the Microsoft Windows NT® 4.0 or Windows® 2000 scheduler. It is recommended that you change the default only
on Windows NT 4.0 or Windows 2000 systems dedicated to SQL Server.
Use Windows NT fibers
Specify that you want an instance of SQL Server to use fibers instead of threads. When using fibers, SQL Server
allocates one thread per CPU and then allocates one fiber per concurrent user, up to the max worker threads value.
This setting takes effect after you restart the server.
Use all available processors
Specify that you want SQL Server to use all available processors for the parallel execution of queries.
Use processors
Specify the number of processors you want SQL Server to use for the parallel execution of queries.
Minimum query plan threshold for considering queries for parallel execution
Specify the threshold at which SQL Server creates and executes parallel plans. SQL Server creates and executes a
parallel plan for a query only when the estimated cost to execute a serial plan for the same query is higher than the
value set for this option.
Configured Values
View or change the configured values for the options on this tab. If you change these values, click Running values to
see whether the changes have taken effect. If they have not, you must restart the instance of SQL Server for the
changes to be implemented.
Running values
View the current running values for the options on this tab. These values are read-only.
Page 10
SQL Tuning and Maintenance
Configuring the OS Swap File
The swap file should be 1.5 times the amount of total system RAM
1. Right click the “My Computer” icon on the desktop and select Properties.
SQL Tuning and Maintenance
Page 11
Page 12
SQL Tuning and Maintenance
Set Other Performance Counters
Memory: Available Bytes, Pages/Sec
From: http://www.sql-server-performance.com/performance_monitor_counters_memory.asp
This counter Memory Object: Pages/Sec, measures the number of pages per second that are paged
out of RAM to disk, or paged into RAM from disk. The more paging that occurs, the more I/O overhead
your server experiences, which in turn can decrease the performance of SQL Server.
Assuming that SQL Server is the only major application running on your server, then this figure should
average near zero over a 24-hour period, except for occasional spikes, which are normal. If this is not
the case, and this counter averages greater than 1, but less than 20, you still won't notice much
performance degradation in SQL Server. But if the counter averages over 20 in a 24-hour period, then
your server most likely needs more RAM. The more RAM a server has, the less paging it has to
perform.
SQL Tuning and Maintenance
Page 13
When paging spikes do occur, this generally is a result of database backups or restores, transaction
log backups and restores, checkpoints, BCP or DTS activity, and other similar tasks. These spikes can
be safely ignored.
Generally, on a physical server dedicated to SQL Server with an adequate amount of RAM, paging
will average near zero. An adequate amount of RAM for SQL Server is a server that has a Buffer Hit
Cache Ratio (described in more detail later) of 99% and higher. If you have a SQL Server that has a
Buffer Hit Cache Ratio of 99% or higher for a period of 24 hours, but you are getting an average
paging level of over 1, this generally means that you may be running other applications on the
physical server other than SQL Server. If this is the case, you should remove those applications,
allowing SQL Server to be the only major application on the physical server.
If your SQL Server is not running any other applications, and paging exceeds 1 on average for a 24-hour
period, this could mean that you have changed the SQL Server memory settings. For optimum
performance, SQL Server should be allowed to take as much RAM as it wants for its own use without
having to compete for RAM with other applications.
Another way to check to see if your SQL Server has enough physical RAM is to check the Memory
Object: Available Bytes counter. This counter can be viewed from Performance Monitor or from the
NT Server, Windows 2000, or Windows 2003 Task Manager (see the Performance tab). This value
should be greater than 5 MB. If not, then your SQL Server needs more physical RAM.
On a server dedicated to SQL Server, SQL Server attempts to maintain from 4-10 MB of free physical
memory. The remaining physical RAM is used by the operating system and SQL Server. When the
amount of available bytes is less than 4 MB, most likely SQL Server is also paging (which it shouldn't)
and experiencing a performance hit. When this happens, you either need to increase the amount of
physical RAM in the server, reduce the load on the server, or change your SQL Server's memory
configuration settings appropriately
Page 14
SQL Tuning and Maintenance
Processor: % Privileged Time, % Processor Time
System: Processor Queue Length
SQL Tuning and Maintenance
Page 15
http://www.sql-server-performance.com/performance_monitor_counters.asp
Measuring the CPU activity of your SQL Server is a key way to identify potential CPU bottlenecks.
The Process Object: % Processor Time counter is available for each CPU (instance) in your
server, and measures the utilization of each individual CPU. If you have more than a single CPU,
or if you have a single hyperthreading CPU, then watching this counter for specific CPUs is not of
much value. Instead, monitor the _Total instance, which provides you with the total overall CPU
utilization for your server, which is a good overall indicator of how busy your server is.
As an alternative to the _Total instance, you can also use the System Object: % Total Processor
Time counter, which measures the average of all the CPUs in your server.
Generally speaking, if the total CPU utilization of your server exceeds 80% for continuous periods
(over 10 minutes or so), then you may have a CPU bottleneck. Some potential solutions to a CPU
bottleneck are to reduce the server load (tune those queries), get faster CPUs, or get more CPUs.
Another valuable indicator of CPU performance is the System Object: Processor Queue Length.
If the Processor Queue Length exceeds 2 per CPU for continuous periods (over 10 minutes or so),
then you probably have a CPU bottleneck. For example, if you have 4 CPUs in your server, the
Processor Queue Length should not exceed a total of 8 for the entire server.
If the Processor Queue Length regularly exceeds the recommended maximum, but the CPU
utilization is not correspondingly as high (which is typical), then consider reducing the SQL Server
"max worker threads" configuration setting. It is possible the reason that the Processor Queue
Length is high is because there are an excess number of worker threads waiting to take their turn.
By reducing the number of "maximum worker threads," what you are doing is forcing thread
pooling to kick in (if it hasn't already), or to take greater advantage of thread pooling.
Use both the Processor Queue Length and the % Total Process Time counters together to
determine if you have a CPU bottleneck. If both indicators are exceeding their recommended
amounts during the same continuous time periods, you can be assured there is a CPU bottleneck.
If the System Object: % Total Processor Time counter in your multiple CPU server regularly runs
over 80% or so, then you may want to start monitoring the System: Context Switches/Sec
counter. This counter measures how often NT Server switches between threads. Heavy context
switching hurts performance and should be minimized. If the System: Context Switches/Sec
counter nears 8000, then you should consider using NT Windows Fibers. Fibers are
subcomponents of threads that perform similarly to threads. The advantage of using them is that
they have less overhead when being switched between CPUs in a multiple CPU server.
This benefit does not show up unless the server's CPUs are running at near maximum, or the
Performance Monitor System: Context Switching/Sec counter nears 8000 switches per second
for continual periods (over 10 minutes), so don't select this option unless your server's CPUs are
nearly maxed out. You will also want to carefully test (before and after) the affect of this setting on
your server's performance, because you may not always get the results you expect when making
this change.
Sometimes, a performance monitor counter measures potential bottlenecks you may not think
about. For example, there is a Performance Monitor counter called System: % Total Privileged
Time. What this counter measures is what percent of the System: % Total Processor Time counter
is used for running Kernel Mode (sometimes also referred to as privileged mode) code. As you
may know, a CPU running under Windows NT, Windows 2000, or Windows 2003 can run in two
modes: kernel or user mode. Most, but not all, of the operating system code is run in kernel mode,
and some operating system and all user applications are run in user mode.
So what does all this mean? If you notice that the System: % Total Privileged Time counter is
running at greater than 20%, this is an indication that your server's I/O may be bottlenecked. Why?
Page 16
SQL Tuning and Maintenance
Because the I/O driver runs in kernel mode, and one indication of high I/O use is indicated by a
higher percentage of Privileged Time use. If this number is high, and the % Disk Time counter is
over 55%, you can be fairly sure that I/O is a bottleneck in your server.
Besides intensive I/O use, a high value for this counter can indicate potential network driver, disk
driver, or hardware problems. If you are getting a 25% or higher reading for the % Total Privileged
Time counter, but the % Disk Time counter is less than 55%, then most likely it is not an I/O
bottleneck, but a driver or hardware problem, and you should starting taking a look at these.
Network Interface: Bytes Total/sec, Current Bandwidth
From: http://www.sqlmag.com/Article/ArticleID/22222/sql_server_22222.html
The Bytes Total/sec counter, which is in the Network Interface object, can help you find a networkadapter bottleneck. Compare this number with your total available bandwidth. Generally, the counter
should show less than 50 percent of the available bandwidth.
From: http://www.sql-server-performance.com/q&a22.asp
SQL Tuning and Maintenance
Page 17
Current Bandwidth: This counter essentially what the maximum speed is for your network adapter
card, not what the current bandwidth being used at the moment is. If you know the bandwidth of your
network card, such as 10Mbs, 100Mbs, 1Gbs, then you really don't need this counter to tell you what
you already know. But, sometimes a network card may not be performing at the speed it should. For
example, I have seen many 10/100Mbs cards, run at unexpected speeds, such as a 100Mbs card
actually running at 10Mbs instead of 100Mbs because the card could not auto-negotiate the speed
correctly. If you think your network performance is slow, be sure to check to see that what you expect
to be getting from your card matches what you get from this counter.
SQL: SQLServer: Buffer Manager – Total pages, Buffer cache hit ratio, Cache Size, Page
Life Expectancy, Lazy Writes/Sec, Checkpoint Pages/sec
SQLServer: Memory Manager – Total Server Memory (KB), Target Server Memory
(KB),
SQLServer: SQL Statistics: Batch Requests/Sec, SQL Compilations/Sec, User Connections
SQL Server Locks Object: Number of Deadlocks/sec, Average Wait Time (ms
SQL Server Access Methods Object: Full Scans/sec
SQL Server Backup Device Object: Device Throughput Bytes/sec
Process: Working Set: sqlservr
Page 18
SQL Tuning and Maintenance
SQL Tuning and Maintenance
Page 19
From: http://www.sql-server-performance.com/performance_monitor_counters_memory.asp
Consider watching these two counters: SQLServer:Memory Manager: Total Server Memory (KB)
and SQLServer:Memory Manager: Target Server Memory (KB). The first counter,
SQLServer:Memory Manager: Total Server Memory (KB), tells you how much the mssqlserver service
is currently using. This includes the total of the buffers committed to the SQL Server BPool and the
OS buffers of the type "OS in Use".
The second counter, SQLServer:Memory Manager: Target Server Memory (KB), tells you how much
memory SQL Server would like to have in order to operate efficiently. This is based on the number of
buffers reserved by SQL Server when it is first started up.
If, over time, the SQLServer:Memory Manager: Total Server Memory (KB) counter is less than the
SQLServer:Memory Manager: Target Server Memory (KB) counter, then this means that SQL Server
has enough memory to run efficiently. On the other hand, if the SQLServer:Memory Manager: Total
Server Memory (KB) counter is more or equal than the SQLServer:Memory Manager: Target Server
Memory (KB) counter, this indicates that SQL Server may be under memory pressure and could use
access to more physical memory.
SQL Server performs faster and with less resources if it can retrieve data from the buffer cache
instead of reading it from disk. In some cases, memory intensive operations can force data pages out
of the cache before they ideally should be flushed out. This can occur if the buffer cache is not large
enough and the memory intensive operation needs more buffer space to work with. When this
happens, the data pages that were flushed out to make extra room must again be read from disk,
hurting performance.
There are three different SQL Server counters that you can watch to help determine if your SQL
Server is experiencing such a problem.

SQL Server Buffer Mgr: Page Life Expectancy: This performance monitor counter tells
you, on average, how long data pages are staying in the buffer. If this value gets below
300 seconds, this is a potential indication that your SQL Server could use more memory in
order to boost performance.

SQL Server Buffer Mgr: Lazy Writes/Sec: This counter tracks how many time a second
that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free
up buffer space. Generally speaking, this should not be a high value, say more than 20 per
second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL
Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages,
instead waiting for this to occur during regular checkpoints. If this value is high, then a
need for more memory is indicated.

SQL Server Buffer Mgr: Checkpoint Pages/Sec: When a checkpoint occurs, all dirty
pages are written to disk. This is a normal procedure and will cause this counter to rise
during the checkpoint process. What you don't want to see is a high value for this counter
over time. This can indicate that the checkpoint process is running more often than it
should, which can use up valuable server resources. If this has a high figure (and this will
vary from server to server), consider adding more RAM to reduce how often the checkpoint
occurs, or consider increasing the "recovery interval" SQL Server configuration setting.
These performance monitor counters should be considered advanced and only used to "refine" a
potential diagnosis of "not enough memory" for your SQL Server
Page 20
SQL Tuning and Maintenance
From: http://www.sql-server-performance.com/performance_monitor_counters_sql_server.asp
One cause of excess I/O on a SQL Server is page splitting. Page splitting occurs when an index or
data page becomes full, and then is split between the current page and a newly allocated page. While
occasional page splitting is normal, excess page splitting can cause excessive disk I/O and contribute
to slow performance.
If you want to find out if your SQL Server is experiencing a large number of page splits, monitor the
SQL Server Access Methods object: Page Splits/sec. If you find out that the number of page splits
is high, consider increasing the fill factor of your indexes. An increased fill factor helps to reduce page
splits because there is more room in data pages before it fills up and a page split has to occur.
What is a high Page Splits/sec? There is no simple answer, as it somewhat depends on your
system's I/O subsystem. But if you are having disk I/O performance problems on a regular basis, and
this counter is over 100 on a regular basis, then you might want to experiment with increasing the fill
factor to see if it helps or not
If you want to see how much physical RAM is devoted to SQL Server's data cache, monitor the
SQL Server Buffer Manager Object: Cache Size (pages). This number is presented in pages, so
you will have to take this number and multiply it by 8K (8,192) to determine the amount of RAM in K
that is being used.
Generally, this number should be close to the total amount of RAM in the server, less the RAM used
by NT, SQL Server, and any utilities you have running on the server.
If the amount of RAM devoted to the data cache is much smaller than you would expect, then you
need to do some investigating to find out why. Perhaps you aren't allowing SQL Server to dynamically
allocate RAM, and instead have accidentally specified that SQL Server use less RAM that it should
have access to for optimal performance. Whatever the cause, you need to find a solution, as the
amount of data cache available to SQL Server can significantly affect SQL Server's performance.
To get a feel of how busy SQL Server is, monitor the SQLServer: SQL Statistics: Batch
Requests/Sec counter. This counter measures the number of batch requests that SQL Server
receives per second, and generally follows in step to how busy your server's CPUs are. Generally
speaking, over 1000 batch requests per second indicates a very busy SQL Server, and could mean
that if you are not already experiencing a CPU bottleneck, that you may very well soon. Of course, this
is a relative number, and the bigger your hardware, the more batch requests per second SQL Server
can handle.
From a network bottleneck approach, a typical 100 Mbs network card is only able to handle about
3000 batch requests per second. If you have a server that is this busy, you may need to have two or
more network cards, or go to a 1 Gbs network card.
Some DBAs use the SQLServer: Databases: Transaction/Sec: _Total to measure total SQL Server
activity, but this is not a good idea. Transaction/Sec only measures activity that is inside a transaction,
not all activity, producing skewed results. Instead, always use the SQLServer: SQL Statistics: Batch
Requests/Sec counter, which measures all SQL Server activity.
SQL compilations of Transact-SQL code is a normal part of SQL Server's operation. But because
compilations chew up CPU and other resources, SQL attempts to reuse as many execution plans in
cache as possible (execution plans are created when compilations occur). The more execution plans
are reused, the less overhead there is on the server, and the faster overall performance there is.
SQL Tuning and Maintenance
Page 21
To find out how many compilations SQL Server is doing, you can monitor the SQLServer: SQL
Statistics: SQL Compilations/Sec counter. As you would expect, this measures how many
compilations are performed by SQL Server per second.
Generally speaking, if this figure is over 100 compilations per second, then you may be experiencing
unnecessary compilation overhead. A high number such as this might indicate that you server is just
very busy, or it could mean that unnecessary compilations are being performed. For example,
compilations can be forced by SQL Server if object schema changes, if previously parallelized
execution plans have to run serially, if statistics are recomputed, or if a number of other things occur.
In some cases, you have the power to reduce the number of unnecessary compilations.
If you find that your server is performing over 100 compilations per second, you should take the time
to investigate if the cause of this is something that you can control. Too many compilations will hurt
your SQL Server's performance
Since the number of users using SQL Server affects its performance, you may want to keep an eye on
the SQL Server General Statistics Object: User Connections. This shows the number of user
connections, not the number of users that are currently connected to SQL Server.
When interpreting this number, keep in mind that a single user can have multiple connections open,
and also that multiple people can share a single user connection. Don't make the assumption that this
number represents actual users. Instead, use it as a relative measure of how "busy" the server is.
Watch the number over time to get a feel if your server is being used more, or being used less
If your databases are suffering from deadlocks, you can track then by using the SQL Server Locks
Object: Number of Deadlocks/sec. But unless this number is relatively high, you want see much
here because the measure is by second, and it takes quite a few deadlocks to be noticeable.
But still, it is worth checking out if you are having a deadlock problem. Better yet, use the Profiler's
ability to track deadlocks. It will provide you with more detailed information. What you might consider
doing is to use the Number of Deadlocks/sec counter on a regular basis to get the "big" picture, and if
you discover deadlock problems with this counter, then use the Profiler to "drill" down on the problem
for a more detailed analysis.
If your users are complaining that they have to wait for their transactions to complete, you may want to
find out if object locking on the server is contributing to this problem. To do this, use the SQL Server
Locks Object: Average Wait Time (ms). You can use this counter to measure the average wait time
of a variety of locks, including: database, extent, Key, Page, RID, and table.
As the DBA, you have to decide what an acceptable average wait time is. One way to do this is to
watch this counter over time for each of the lock types, finding average values for each type of lock.
Then use these average values as a point of reference. For example, if the average wait time in
milliseconds of RID (row) locks is 500, then you might consider any value over 500 as potentially a
problem, especially if the value is a lot higher than 500, and extends over long periods of time.
If you can identify one or more types of locks causing transaction delays, then you will want to
investigate further to see if you can identify what specific transactions are causing the locking. The
Profiler is the best tool for this detailed analysis of locking issues
While table scans are a fact of life, and sometimes faster than index seeks, generally it is better to
have fewer table scans than more. To find out how many table scans your server is performing, use
the SQL Server Access Methods Object: Full Scans/sec. Note that this counter is for an entire
server, not just a single database. One thing you will notice with this counter is that there often
appears to a pattern of scans occurring periodically. In many cases, these are table scans SQL Server
is performing on a regular basis for internal use.
Page 22
SQL Tuning and Maintenance
What you want to look for are the random table scans that represent your application. If you see what
you consider to be an inordinate number of table scans, then break out the Profiler and Index Tuning
Wizard to help you determine exactly what is causing them, and if adding any indexes can help
reduce the table scans. Of course, SQL may just be doing its job well, and performing table scans
instead of using indexes because it is just plain more efficient. But you won't know unless you look
and see what is really happening under the covers
If you suspect that your backup or restore operations are running at sub-optimal speeds, you can help
verify this by using the SQL Server Backup Device Object: Device Throughput Bytes/sec. This
counter will give you a good feel for how fast your backups are performing. You will also want to use
the Physical Disk Object: Avg. Disk Queue Length counter to help collaborate your suspicions.
Most likely, if you are having backup or restore performance issues, it is because of an I/O bottleneck.
As the DBA, it will be your job to determine the I/O bottlenecks you may be experiencing and dealing
with them appropriately. For example, the cause of slow backups or restores could be something as
simple as a DTS job that is running at the same time, and could be fixed by rescheduled the job
A key counter to watch is the SQL Server Buffer Manager Object: Buffer Cache Hit Ratio. This
indicates how often SQL Server goes to the buffer, not the hard disk, to get data. The higher this ratio,
the less often SQL Server has to go to the hard disk to fetch data, and performance overall is boosted.
Unlike many of the other counters available for monitoring SQL Server, this counter averages the
Buffer Cache Hit Ratio from the time the last instance of SQL Server was restarted. In other words,
this counter is not a real-time measurement, but an average of all the days since SQL Server was last
restarted. Because of this, if you really want to get an accurate record of what is happening in your
Buffer Cache right now, you must stop and restart the SQL Server service, then letting SQL Server run
several hours of normal activity before you check this figure (in order to get a good reading).
If you have not restarted SQL Server lately, then the Buffer Cache Hit Ratio figure you see may not be
accurate for what is occurring now in your SQL Server, and it is possible that although your Buffer
Cache Hit Ratio looks good, it may really, in fact, not be good, because of the way this counter
averages this ratio over time.
In OLTP applications, this ratio should exceed 90-95%. If it doesn't, then you need to add more RAM
to your server to increase performance.
In OLAP applications, the ratio could be much less because of the nature of how OLAP works. In any
case, more RAM should increase the performance of SQL Server OLAP activity
SQL Tuning and Maintenance
Page 23
Configuring the Backup Type – Simple Backup
1. In SQL Enterprise Manager expand Databases – Altiris
2. Click on the Options tab.
3. From the Recovery Model dropdown select Simple.
4. Repeat this for each database that will be part of this maintenance plan.
Page 24
SQL Tuning and Maintenance
Creating a Maintenance Plan for SQL Server
1. In SQL Enterprise Manager expand SQL Server Group ~ (local) (Windows NT) ~
Management ~ Database Maintenance Plans.
2. Right mouse click on Database Maintenance Plans, select New Maintenance Plan.
The Database Maintenance Plan Wizard appears:
SQL Tuning and Maintenance
Page 25
3. Click Next. The Select Databases dialog appears:
4. Select the databases that will be part of this maintenance plan. This should include Altiris
and express. If the Alert Manager of NS is being used then Altiris_Incidents should also
be selected.
5. Click Next. The Update Data Optimization Information dialog appears:
Page 26
SQL Tuning and Maintenance
SQL Tuning and Maintenance
Page 27
Reorganize data and index pages
Cause the indexes on the tables in the database to be dropped and re-created with a new FILLFACTOR. The
FILLFACTOR determines how much empty space to leave on each page in the index, thereby reserving a
percentage of free space on each data page of the index to accommodate future expansion. As data is added to
the table, the free space fills because the FILLFACTOR is not maintained. Reorganizing data and index pages
can reestablish the free space.
Reorganize pages with the original amount of free space
Cause the indexes on the tables in the database to be dropped and re-created with the original FILLFACTOR
that was specified when the indexes were created.
Change free space per page percentage to
Cause the indexes on the tables in the database to be dropped and re-created with a new automatically
calculated FILLFACTOR, thereby reserving the specified amount of free space on the index pages. The higher
the percentage, the more free space is reserved on the index pages and the larger the index grows. Valid values
are from 0 through 100.
Update statistics used by query optimizer.
Cause the distribution statistics of each index created on user tables in the database to be resampled. The
distribution statistics are used by Microsoft® SQL Server™ to optimize navigation through tables during the
processing of Transact-SQL statements. To build the distribution statistics automatically, SQL Server
periodically samples a percentage of the data in the corresponding table for each index. This percentage is based
on the number of rows in the table and the frequency of data modification. Use this option to perform an
additional sampling using the specified percentage of data in the tables.
Sample % of the database
Generate distribution statistics by sampling the percentage of data in the tables. The higher the percentage, the
more accurate the statistics, but the longer the sampling takes. If the specified value does not generate a
sufficient sample, SQL Server determines an adequate sample size automatically. Valid values range from 1
through 100.
Remove unused space from database files
Remove any unused space from the database, thereby allowing the size of the data files to be reduced.
When it grows beyond
Remove unused space from the database only if the database exceeds the specified size, in megabytes (MB).
Amount of free space to remain after shrink
Determine the amount of unused space to remain in the database after the database is shrunk (the larger the
percentage, the less the database can shrink). The value is based on the percentage of the actual data in the
database. For example, a 100 MB database containing 60 MB of data and 40 MB of free space, with a free
space percentage of 50 percent, would result in 60 MB of data and 30 MB of free space (because 50 percent of
60 MB is 30 MB). Only excess space in the database is eliminated. Valid values are from 0 through 100.
Schedule
Set the frequency that the data optimization tasks (scheduled using SQL Server Agent) are executed. The
default is every Sunday at 1:00 AM.
Change
Change the default schedule.
6. Select Reorganize data and index pages.
7. Select Reorganize pages with the original amount of free space.
8. Select Remove Unused Space from database files.
9. Click the Change button in the Schedule section.
10. Select Weekly and provide the Occurs once at time.
Page 28
SQL Tuning and Maintenance
11. Click OK.
12. Click Next . The Database Integrity Check dialog appears:
SQL Tuning and Maintenance
Page 29
Check database integrity
Check the allocation and structural integrity of user and system tables, and indexes in the database, by running
the DBCC CHECKDB Transact-SQL statement. This ensures that any integrity problems with the database are
reported, thereby allowing them to be addressed later by a system administrator or database owner.
Include indexes
Check the data and index pages in the database during the integrity tests.
Attempt to repair any minor problems
Attempt to correct any minor problems detected during the database integrity tests automatically. When this
option is selected, the database will be put in single user mode each time the maintenance plan runs. It is
recommended that this option be selected.
Exclude indexes
Check only the data pages in the database during integrity tests. This does not check indexes. This option
executes faster than clicking Include indexes because fewer pages in the database are checked.
Perform these tests before doing backups
Cause the database and/or internal data integrity tests to be executed before backing up the database or
transaction log. If the integrity tests detect inconsistencies, any subsequent database or transaction log backup is
not backed up.
Schedule
Set the frequency that the data integrity tasks (scheduled using SQL Server Agent) are executed. The default is
every Sunday at 12:00 midnight.
Change
Change the default schedule.
13. Select Check Database Integrity.
14. Select Include Indexes.
15. Select Attempt to Repair Any Minor problems.
16. Select Perform these checks before doing backups.
17. Click the Change button.
18. Set Occurs to Weekly.
19. Specify the time for Occurs once at:.
Page 30
SQL Tuning and Maintenance
20. Click OK.
21. Click Next. The Specify the Database Backup Plan dialog appears:
SQL Tuning and Maintenance
Page 31
Back up the database as part of the maintenance plan
Cause the entire database to be backed up as part of the maintenance tasks. Backing up the database is important in
case of system or hardware failure (or user errors) that cause the database to be damaged in some way, thus
requiring a backed-up copy to be restored.
Verify the integrity of the backup on completion of the backup
Check that the backup set is complete and all volumes are accessible by executing the RESTORE VERIFYONLY
Transact-SQL statement.
Tape
Back up the database to the specified tape device. Only tape devices attached to the computer containing the
database are available.
Disk
Back up the database to disk.
Schedule
Set the frequency that the database backup tasks (scheduled using SQL Server Agent) are executed. The default is
every Sunday at 2:00 AM.
Change
Change the default schedule.
22. Select Back up the database as part of the maintenance plan.
23. Select Verify the integrity of the backup when complete.
24. Select Disk.
25. Click the Change button.
26. Set the Daily to every 1 days
27. Set the Occurs to Daily.
28. Specify the Occurs once at: setting.
29. Click OK.
Page 32
SQL Tuning and Maintenance
30. Click Next. The Specify Backup Disk Directory dialog appears:
Use the default backup directory
Back up the database to the default backup disk directory located on the computer that contains this database.
This is the \MSSQL\BACKUP directory for default instances of Microsoft® SQL Server™ 2000, and the
\MSSQL$instancename\BACKUP directory for named instances of SQL Server 2000.
Use this directory
Back up the database to the specified disk directory. Only disks located on the same computer as the database
can be used. Click the browse (...) button to change the default directory used to back up the database. Only
drives on the computer containing the SQL Server database being backed up can be selected.
Create a subdirectory for each database
Create a subdirectory under the specified disk directory containing the database backup for each database that is
being backed up as part of the maintenance plan.
Remove files older than
Delete database backups automatically that are older than the specified period. A history of database backups
should be maintained in the event that the database must be restored to a point in time earlier than the last
performed backup. Retain as many backups as disk space allows and as far in the past as necessary.
Backup file extension
Define the file extension used for each file that contains the database backup. The default file extension is .bak.
Note: Disk backup file names are generated automatically (for example, pubs_tlog_199803120203.bak where
199803120203 is the timestamp).
31. Select either to use the default backup directory or another directory as desired.
32. Check Remove files older than: and enter 1 Week.
33. Click Next. The Specify the Transaction Log Backup Plan dialog appears:
SQL Tuning and Maintenance
Page 33
34. Select Back up the transaction log as part of the maintenance plan.
35. Select Verify the integrity of the backup when complete.
36. Select Disk.
37. Click the Change button.
38. Set Occurs to Daily.
39. Set Daily to every 1 days.
40. Set the Daily frequency to Occurs every 1 Hour(s) between 12:00:00 AM and
11:59:00 PM.
41. Click OK.
42. Click Next. The Specify Transaction Log Backup Disk Directory dialog appears:
Page 34
SQL Tuning and Maintenance
Backup the transaction log as part of the maintenance plan
Cause the transaction log to be backed up as part of the maintenance plan. Backing up the transaction log is
necessary in order to recover the database to the point of failure.
Verify the integrity of the backup when complete
Check that the backup is complete and all volumes are accessible by executing the RESTORE VERIFYONLY
Transact-SQL statement.
Tape
Back up the database to the specified tape device. Only tape devices attached to the computer containing the
database are available.
Disk
Back up the database to disk
Schedule
Set the frequency that the transaction log backup tasks (scheduled using SQL Server Agent) are executed. The
default is every Monday through Friday at 12:00 midnight.
43. Select either to use the default backup directory or another directory as desired.
44. Check Remove files older than: and enter 1 Day(s).
45. Click Next. The Reports to Generate dialog appears:
SQL Tuning and Maintenance
Page 35
Write report to a text file in directory
Specify the full path and name of the text file into which the report is to be generated. The report contains
details of the steps executed by the maintenance plan, including any error information. The report maintains
version information by adding a date to the file name. The date is generated as a suffix to the file name but
before the extension, in the form _YYYYMMDDHHMM. For example: "DB Maintenance
Plan10_199804090838.txt".
Click the browse (...) button to change the default directory for the text file. Only directories on the computer
running the maintenance plan can be selected.
Delete text report files older than
Delete text report files automatically that are older than the specified period. A history of text report files should
be maintained so that you can check the maintenance tasks that have been executed in the past.
Send E-mail report to operator
Specify the operator to whom the generated report will be sent through SQL Mail. Click the browse (...) button
to change the properties of the specified operator using SQL Server Enterprise Manager.
New Operator
Create a new operator using SQL Server Enterprise Manager.
46. Select Write report to a text file in directory. The default location is Program
Files\Microsoft SQL Server\MSSQL\Log|.
47. Select Delete test report files older than: 2 Week(s).
48. Click Next. The Maintenance Plan History dialog appears:
Page 36
SQL Tuning and Maintenance
Write history to the msdb.dbo.sysdbmaintplan_history table on this server
Write the report as rows to this table on the server upon which the maintenance plan was executed. The report
contains the steps executed by the maintenance plan, including database name, activity, date, result (success or
failure), and any error information. It includes one row for each activity, per database, per execution date.
Limit rows in the table to
Specify the maximum number of rows in the table that represent history for this plan only. If the number of history
rows in the table for this plan exceeds this value, older rows for this plan (representing the earliest recorded history)
are deleted. Setting this value can prevent the table from becoming too large and filling the msdb database (if autogrow is not permitted). The default is 10,000.
Write history to the server
Write the report as rows to the msdb.dbo.sysdbmaintplan_history table on a remote server. Windows Authentication
is used to connect to the remote server. The report contains the steps executed by the maintenance plan, including
database name, activity, date, result (success or failure), and any error information. It includes one row for each
activity, per database, per execution date.
Click the browse (...) button to change the remote server to which the report is written. Only instances of
Microsoft® SQL Server™ can be selected.
Limit rows in the table to
Specify the maximum number of rows in the table that represent history for this plan only. If the number of history
rows in the table for this plan exceeds this value, older rows for this plan (representing the earliest recorded history)
are deleted. Setting this value can prevent the table from becoming too large and filling the msdb database (if autogrow is not permitted). The default is 10,000.
+
49. Select Write history to the msdb.dbo.sysdbmaintplan_history table on this sever.
50. Click Next. The Completing the Database Maintenance Plan Wizard dialog appears:
SQL Tuning and Maintenance
Page 37
51. Enter nservername_date for Plan name, for example ntbldrm4_22July2005.
52. Click Finish.
53. Verify that the SQLServerAgent on target server (‘local’) is running during the
scheduled execution of this job.”
54. Close SQL Enterprise Manager
Page 38
SQL Tuning and Maintenance
Defragging SQL
Several defrags can increase SQL performance.

Defrag all database indexes – The attached ‘all_index_defrag.sql’ script defrags all the
indexes used in the Altiris database. Run this against the Altiris database using SQL
query analyser.

Defrag SQL data and log volumes – Post upgrade the log files of the Altiris database can
be heavily fragmented. Use Enterprise Manager to defrag these volumes as this greatly
improves SQL performance.
declare @index_name nvarchar(255)
declare @table_name nvarchar(255)
declare index_cursor cursor for
select
si.name as index_name,
object_name(si.id) as table_name
from sysindexes si
left outer join sysobjects so on so.name=si.name
where objectproperty(si.id, N'IsUserTable') = 1
and objectproperty(si.id, N'IsUserTable') = 1
and si.name <> object_name(si.id)
and si.impid <> -1
open index_cursor
fetch next from index_cursor into @index_name, @table_name
while @@FETCH_STATUS = 0
begin
print 'Attempting defrag of index [' + @index_name + '] on table [' +
@table_name + ']'
dbcc INDEXDEFRAG( 0, @table_name, @index_name )
fetch next from index_cursor into @index_name, @table_name
end
close index_cursor
deallocate index_cursor
Running Maintenance Procedures
DBCC UPDATEUSAGE
Reports and corrects inaccuracies in the sysindexes table, which may result in incorrect space usage reports by
the sp_spaceused system stored procedure.
Syntax
DBCC UPDATEUSAGE
( { 'database_name' | 0 }
[ , { 'table_name' | 'view_name' }
SQL Tuning and Maintenance
Page 39
[ , { index_id | 'index_name' } ] ]
)
[ WITH [ COUNT_ROWS ] [ , NO_INFOMSGS ]
]
Arguments
'database_name' | 0
Is the name of the database for which to report and correct space usage statistics. Database names must conform
to the rules for identifiers. For more information, see Using Identifiers. If 0 is specified, then the current database
is used.
'table_name' | 'view_name'
Is the name of the table or indexed view for which to report and correct space usage statistics. Table and view
names must conform to the rules for identifiers.
index_id | 'index_name'
Is the identification (ID) number or index name of the index to use. If not specified, the statement processes all
indexes for the specified table or view.
COUNT_ROWS
Specifies that the rows column of sysindexes is updated with the current count of the number of rows in the table
or view. This applies only to sysindexes rows that have an indid of 0 or 1. This option can affect performance on
large tables and indexed views.
NO_INFOMSGS
Suppresses all informational messages.
Remarks
DBCC UPDATEUSAGE corrects the rows, used, reserved, and dpages columns of the sysindexes table for tables
and clustered indexes. Size information is not maintained for nonclustered indexes.
If there are no inaccuracies in sysindexes, DBCC UPDATEUSAGE returns no data. If inaccuracies are found and
corrected and the WITH NO_INFOMSGS option is not used, UPDATEUSAGE returns the rows and columns being
updated in sysindexes.
Use UPDATEUSAGE to synchronize space-usage counters. DBCC UPDATEUSAGE can take some time to run on large
tables or databases, so it should typically be used only when you suspect incorrect values returned by
sp_spaceused. sp_spaceused accepts an optional parameter to run DBCC UPDATEUSAGE before returning space
information for the table or index.
sp_updatestats
Runs UPDATE STATISTICS against all user-defined tables in the current database.
Syntax
sp_updatestats [[@resample =] 'resample']
Return Code Values
0 (success) or 1 (failure)
Arguments
Page 40
SQL Tuning and Maintenance
[@resample=] 'resample'
Specifies that sp_updatestats will use the RESAMPLE option of the UPDATE STATISTICS command. New statistics
will inherit the sampling ratio from the old statistics. If 'resample' is not specified, sp_updatestats updates
statistics using the default sampling. This parameter is varchar(8) with a default value of 'NO'.
Remarks
sp_updatestats displays messages indicating its progress. When the update is completed, it reports that statistics
have been updated for all tables.
Permissions
Only the DBO and members of the sysadmin fixed server role can execute this procedure.
Examples
This example updates the statistics for tables in the pubs database.
USE pubs
EXEC sp_updatestats
sp_recompile
Causes stored procedures and triggers to be recompiled the next time they are run.
Syntax
sp_recompile [ @objname = ] 'object'
Arguments
[@objname =] 'object'
Is the qualified or unqualified name of a stored procedure, trigger, table, or view in the current database. object is
nvarchar(776), with no default. If object is the name of a stored procedure or trigger, the stored procedure or
trigger will be recompiled the next time it is run. If object is the name of a table or view, all the stored procedures
that reference the table or view will be recompiled the next time they are run.
Return Code Values
0 (success) or a nonzero number (failure)
Remarks
sp_recompile looks for an object in the current database only.
The queries used by stored procedures and triggers are optimized only when they are compiled. As indexes or
other changes that affect statistics are made to the database, compiled stored procedures and triggers may lose
efficiency. By recompiling stored procedures and triggers that act on a table, you can reoptimize the queries.
Note Microsoft® SQL Server™ automatically recompiles stored procedures and triggers when it is
advantageous to do so.
Permissions
SQL Tuning and Maintenance
Page 41
Execute permissions default to the public role. Users that are not members of the sysadmin fixed server role or
the db_owner fixed database role can affect only their own tables.
Examples
This example causes the triggers and stored procedures that uses the titles table to be recompiled the next time
they are run.
EXEC sp_recompile titles
Page 42
SQL Tuning and Maintenance
Advanced SQL Tuning For Windows 2000 Advanced Server,
Windows 2000 Datacenter, Server Microsoft Windows Server 2003,
Enterprise Edition, or Windows Server 2003, Datacenter Edition
Summary
All operating systems really only have 4GB of memory that can have active memory addresses.
By default the OS gets 2GB of the active memory address space and the applications get the
other 2GB. One of the options that is available for Microsoft Windows Server 2003, Enterprise
Edition, or Windows Server 2003, Datacenter Edition operating systems is adding the /3GB
switch (also called is 4-gigabyte tuning (4GT)) in the boot.ini file. This changes the OS to only
get 1GB of memory address space leaving the applications with 3GB of active memory address
space. One gigabyte is sufficient for the operating system as long as the total physical memory is
under 16GB and the system is not graphic intense.
This 2 or 3 GB of memory is the total amount that the OS can actively manage; however each
process can have its own set of 2 to 3 GB of memory addressing but this memory has to be
cached.
When NS and SQL are installed on the same server, the NS process and the SQL process will
compete for the active memory causing each other to page out and often will actually cause hard
paging. Part of what makes SQL take so much memory is that it must buffer all the data that it
queries into memory. Good SQL performance means that it will try to keep data in the buffer
instead of having to go to disk.
With SQL Standard edition, both the SQL engine memory and its buffer must fit within the 2 or
3 GB of address space. SQL Enterprise version however gives another option of configuring
AWE (Address Windowing Extensions) that allows SQL to pull its buffer memory out of the 2
or 3 GB memory addressing space puts the buffer into the physical memory above the 4 GB line.
If NS and SQL are on the same box do not select the “Reserve physical memory for SQL”
option, otherwise the server may end up paging a lot.
AWE requires that Physical Address Extension (PAE) X86 is installed first.
4GT Technical Reference
The technology called 4-gigabyte tuning (4GT), also known as application memory tuning, or
the /3GB switch, is one of two technologies that increase the amount of physical memory
available to user mode applications. The other technology is Physical Address Extension
(PAE) X86.
4GT allows memory-intensive applications running on 32-bit versions of the Microsoft Windows
Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, operating systems
to use 50 percent more virtual memory by making less virtual memory available to the operating
system. In addition, 4GT can be used on Windows Server 2003, Standard Edition, but only in
SQL Tuning and Maintenance
Page 43
non-production environments.This subject will provide an overview of 4GT along with an indepth description of how 4GT works.
The technology called 4-gigabyte tuning (4GT), also known as application memory tuning, or
the /3GB switch, is one of two technologies that increase the amount of physical memory
available to user mode applications.
Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and
Windows Server 2003, Datacenter Edition, provide applications with a flat 32-bit virtual address
space that can describe up to 4 gigabytes (GB) of virtual memory. The address space is usually
split so that 2 GB of virtual address space is directly accessible to the applications and the other
2 GB is only accessible to the Windows executive software (also known as the kernel). Because
of this 2 GB virtual memory limit, applications that are memory intensive and that manage their
memory directly through their own caching methods, such as database management systems
(DBMS), can experience reduced performance.
4GT makes more of the computer’s virtual memory available to applications by making less
virtual memory available to the operating system. By enabling 4GT, applications are able to
access 3 GB of virtual memory instead of the 2 GB normally allocated for user mode processes.
This is a 50 percent increase in virtual memory, allowing more data to be cached and potentially
significantly increasing performance.
Common 4GT Scenarios
4GT is most commonly used when servers are hosting memory intensive applications, such as
database management systems, the performance of which is directly affected by the availability
of physical memory. However, it would be ineffective for every application to automatically be
provided with the 3 GB address space that 4GT allows. Thus, to provide a selective use of 4GT,
4GT must first be explicitly enabled in the operating system and the application must also be
explicitly configured to make use of the extended memory. 4GT should not be used if either of
the following is true:


Greater than 16 GB of physical memory are available and PAE X86 is enabled on the
server.
Important performance characteristics of the application are adversely affected by
limiting the kernel to 1 GB of RAM, for example, more than 1 GB of RAM might be
needed to support the maximum number of concurrent connections.
The technology called 4-gigabyte tuning (4GT) is a scale up component in the Windows
Server 2003 family. The Microsoft operating environment delivers scalability via two methods:
scale up and scale out. Scaling up refers to running a single application or image on a single
server and having the ability to incrementally add system hardware resources (processors and
memory) to increase overall system performance. Scaling out refers to distributing the
computing workload among multiple servers with the ability to add or subtract servers to
increase or decrease capacity.
Enterprises are required to scale flexibly to respond to spikes in business and to support the rapid
roll out of new products and services. It is therefore increasingly important that an organization’s
Page 44
SQL Tuning and Maintenance
computing infrastructure provides the ability to increase or decrease computing capacity almost
instantly, while continuing to deliver value. 4GT helps provide this scalability.
There are few restrictions regarding the environment in which 4GT can be enabled. 4GT has the
following hardware and software requirements:




x86-based processor
2 gigabytes (GB) or more of RAM
Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition
Windows Server 2003, Standard Edition, but only in non-production environments.
SQL Tuning and Maintenance
Page 45
4GT should not be used if either of the following is true:


Greater than 16 GB of physical memory are available and Physical Address Extension
(PAE) X86 is enabled on the server.
Important performance characteristics of the application are adversely affected by
limiting the kernel to 1 GB of RAM, for example, more than 1 GB of RAM might be
needed to support the maximum number of concurrent connections.
To enable 4GT
1. Open Windows Explorer
2. On the Tools menu, click Folder Options.
3. On the View tab, click Show hidden files and folders, clear the Hide protected
operating system files check box, and then click OK. If you are presented with a
warning dialog box, click Yes to continue.
4. In the root folder (for example, C:), locate the Boot.ini file and remove its read-only
attribute.
5. Open the Boot.ini file, and then add the /3GB parameter to the ARC path, as shown in the
following example for Windows Server 2003, Datacenter Edition:
multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003, Datacenter
Edition" /3GB
6. On the File menu, click Save.
7. Restore the read-only attribute to the Boot.ini file.
8. For the change to take effect, restart the computer.
Notes:To perform this procedure, you must be a member of the Administrators group on the
local computer, or you must have been delegated the appropriate authority. If the computer is
joined to a domain, members of the Domain Admins group might be able to perform this
procedure. As a security best practice, consider using Run as to perform this procedure.
Problems Caused by the /3GB Switch
When the 3GB switch reduces the amount of system space on the server, the total amount
of Page Table Entries are drastically reduced. If the server ever reaches the point where
there are no remaining free Page Table Entries, then a variety of out-of-memory related
issues arise. Memory symptoms include:






Applications or drivers might have requests for memory denied
Applications or the entire system might become unresponsive if threads cannot be
created
Event viewer may fail to display text, just icons
Registry access failures seen in the event logs
Swap file access failures seen in the event logs
"Harddisk9 read error at block 123456: status 0xC000009A" messages seen in the
event logs
To avoid this issue, the amount of free table entries should be increased to a minimum of 7,000.
This can be accomplished through the /USERVA boot.ini switch for Windows 2003 servers or a
Page 46
SQL Tuning and Maintenance
registry setting for Windows 2000 servers. See the following section for guidance on using the
USERVA switch.
Appropriate Usage of the /USERVA Switch
In Windows 2003, a new setting was added to facilitate changes in the amount of additional user
space memory provided by the /3GB switch. By default the /3GB switch establishes the cutoff
point at 3072 MB. Set /USERVA = 3008 in the boot.ini.
See KB 25079 for details
Physical Address Extension (PAE) X86 overview
Physical Address Extension (PAE) X86 allows software using the Address Windowing
Extensions (AWE) API set and running on a computer with an Intel Pentium Pro processor or
later, and more than 4 gigabytes (GB) of physical memory to map more physical memory into
the application's virtual address space.
Applications not using the AWE API set can also benefit from PAE X86 because the operating
system uses the larger physical memory to reduce paging and thus increase performance. This
can also benefit consolidation servers hosting multiple applications.
Applications that manipulate large amounts of data achieve better performance by keeping data
in memory instead of on disk. For example, PAE X86 can significantly improve the performance
of the following types of applications:



Databases, such as Microsoft SQL/E 7.0 or later
Scientific and engineering applications, such as computational fluid dynamics
Statistical analysis applications that do extensive data mining.
What Is PAE X86?
Physical Address Extension (PAE) X86 is one of two technologies that increase the amount of
physical or virtual memory available to user mode applications. The other technology is 4gigabyte tuning (4GT).
By default, servers running the 32-bit editions of Windows Server 2003, Enterprise Edition, and
Windows Server 2003, Datacenter Edition, support only 32-bit memory addressing and thus are
able to access only 4 gigabytes (GB) of physical memory. However, hardware that offers much
larger amounts of physical memory is available. Both the operating system and many
applications can benefit from using this additional memory.
PAE X86 allows servers running Windows Server 2003, Enterprise Edition, and Windows
Server 2003, Datacenter Edition, on a 32-bit hardware platform to access physical memory
beyond 4 GB. To do this, PAE changes the memory addressing from 32-bit addressing mode to
SQL Tuning and Maintenance
Page 47
64-bit addressing mode, allowing the operating system and high performance drivers and
applications access to the additional physical memory. When using the larger amount of physical
memory made available by PAE X86, operating system performance can be increased,
particularly when the server is hosting multiple applications. Applications can also have direct
access to the physical memory beyond 4 GB provided they use the Address Windowing
Extensions (AWE) API set.
When using PAE X86, all of the physical memory in the system is treated as general purpose
memory. The operating system is able to use this memory for caching and virtual memory
management without major changes.
Applications can also use this memory without major changes. The most noticeable difference is
that more applications can be running before paging occurs because there is more memory for
each process and its associated virtual address space. This also means that more processes can be
resident in memory. Because applications not needing larger physical memory do not need to be
modified or use the AWE API set, virtually all applications can benefit from PAE X86.
Common PAE X86 Scenarios
PAE X86 allows the Windows executive software (also known as the kernel) to take full
advantage of all available physical memory, including memory above 4 GB, up to 64 GB. This
can result in a significant reduction in paging operations and can improve the performance of the
server when multiple applications are hosted on a single computer, such as in application
consolidation scenarios.
Additionally, certain data-intensive applications, such as database management systems and
scientific and engineering software that need access to very large caches of data can also use
PAE to address memory beyond 4 GB. These applications can use the AWE API to access up to
64 GB of memory using a memory window inside their 4 GB process. Just four system calls are
used to declare the AWE window and to map additional physical memory inside that window.
Note: PAE X86 is not required on the 64-bit versions of the Windows Server 2003 family.
To enable Physical Address Extension (PAE) X86
9. Open Windows Explorer
10. On the Tools menu, click Folder Options.
11. On the View tab, click Show hidden files and folders, clear the Hide protected
operating system files check box, and then click OK. If you are presented with a
warning dialog box, click Yes to continue.
12. In the root folder (for example, C:), locate the Boot.ini file and remove its read-only
attribute.
13. Open the Boot.ini file, and then add the /PAE parameter to the ARC path, as shown in
the following example for Windows Server 2003, Datacenter Edition:
multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003, Datacenter
Edition" /PAE
14. On the File menu, click Save.
Page 48
SQL Tuning and Maintenance
15. Restore the read-only attribute to the Boot.ini file.
16. For the change to take effect, restart the computer.
Notes:To perform this procedure, you must be a member of the Administrators group on the
local computer, or you must have been delegated the appropriate authority. If the computer is
joined to a domain, members of the Domain Admins group might be able to perform this
procedure. As a security best practice, consider using Run as to perform this procedure.
This topic does not apply to Windows Server 2003, Web Edition
Updates to PAE X86
The following updates have been made to support the addition of Data Execution Prevention
(DEP), which is also known as no-execute page protection:


PAE is automatically enabled on computers running Windows Server 2003 with Service
Pack 1 (SP1) and Windows XP with Service Pack 2 (SP2) when DEP is enabled on a
computer with a processor that supports the no-execute page protection feature.
When PAE mode is enabled on Windows Server 2003, Standard Edition with SP1 and
Windows XP with SP2, physical address space is limited to 4 GB. Limiting physical
address space to 4 GB helps prevent driver compatibility issues with PAE mode.
Only specific hardware will support PAE X86, therefore, this feature is not enabled upon initial
installation of the operating system.
SQL Tuning and Maintenance
Page 49
Using AWE to increase performance
Many DBA's are aware that Enterprise Edition of SQL Server 2000 can use more than 2 GB of
memory. For most (albeit not all) systems, dedicating more memory to SQL Server translates
into better performance; therefore, if the system's performance matters to you, taking advantage
of additional memory is a good move. SQL Server can use up to 8 gigabytes of memory while
running on Windows 2000 Advanced Server and up to 64 gigabytes with Windows 2000 Data
Center Server.
The configuration option that allows SQL Server to use more than 2GB of memory is called
"AWE Enabled" -- AWE stands for Address Windowing Extensions.
To enable AWE, you must execute sp_configure system procedure as follows:
EXEC sp_configure 'awe enabled', 1
GO
RECONFIGURE WITH OVERRIDE
Windows 2000 Usage Considerations
Before you configure Windows 2000 for AWE memory, consider the following:


To enable Windows 2000 Advanced Server or Windows 2000 Datacenter Server to
support more than 4 GB of physical memory, you must add the /pae parameter to the
boot.ini file.
To enable Windows 2000 Advanced Server and Windows 2000 Datacenter Server to
support a 3-GB virtual address space, you must add the /3gb parameter to the boot.ini
file. This allows user applications to address 3 GB of virtual memory and reserves 1 GB
of virtual memory for the operating system.
However, if there is more than 16 GB of physical memory available on a computer, Windows
2000 needs 2 GB of virtual memory address space for system purposes and therefore can support
only a 2-GB virtual address space.
In order to allow AWE to use the memory range above 16 GB, be sure the /3gb parameter is not
in the boot.ini file. If it is, Windows 2000 will be unable to address any memory above 16 GB.
When allocating SQL Server AWE memory on a 32-GB system, Windows 2000 may require at
least 1 GB of available memory to manage AWE. Therefore, when starting an instance of SQL
Server with AWE enabled, it is recommend you do not use the default max server memory
setting, but instead limit it to 31 GB or less.
Note: This feature is available only in the SQL Server 2000 Enterprise and Developer editions.
Page 50
SQL Tuning and Maintenance
AWE Memory SQL Server Performance Tuning Tips
If you are using SQL Server 2000 Standard Edition under Windows NT 4.0 or Windows 2000
(any version), or are running SQL Server 2000 Enterprise Edition under Windows NT 4.0 or
Windows 2000 Server, or if your server has 4GB or less of RAM, the "awe enabled" option
should always be left to the default value of 0, which means that AWE memory is not being
used.
The AWE (Advanced Windowing Extensions) API allows applications (that are written to use
the AWE API) to run under Windows 2000 Advanced Server or Windows 2000 Datacenter
Server to access more than 4GB of RAM. SQL Server 2000 Enterprise Edition (not SQL
Server 2000 Standard Edition) is AWE-enabled and can take advantage of RAM in a server
over 4GB. If the operating system is Windows 2000 Advanced Server, SQL Server 2000
Enterprise Edition can us up to 8GB of RAM. If the operating system is Windows 2000
Datacenter Server, SQL Server 2000 Enterprise can use up to 64GB of RAM.
By default, if a physical server has more than 4GB of RAM, Windows 2000 (Advanced and
Datacenter), along with SQL Server 2000 Enterprise Edition, cannot access any RAM greater
than 4GB. In order for the operating system and SQL Server 2000 Enterprise Edition to take
advantage of the additional RAM, two steps must be completed.
Exactly how you configure AWE memory support depends on how much RAM your server
has. To configure Windows 2000 (Advanced or Datacenter), you must enter one of the
following switches in the boot line of the boot.ini file, and reboot the server:




4GB RAM: /3GB (AWE support is not used)
8GB RAM: /3GB /PAE
16GB RAM: /3GB /PAE
16GB + RAM: /PAE
The /3GB switch is used to tell SQL Server to take advantage of 3GB out of the base 4GB of
RAM that Windows 2000 supports natively. If you don't specify this option, then SQL Server
will only take advantage of 2GB of the first 4GB of RAM in the server, essentially wasting
1GB of RAM.
AWE memory technology is used only for the RAM that exceeds the base 4GB of RAM, that's
why the /3GB switch is needed to use as much of the RAM in your server as possible. If
your server has 16GB or less of RAM, then using the /3GB switch is important. But if your
server has more than 16GB of RAM, then you must not use the /3GB switch. The reason for
this is because the 1GB of additional RAM provided by adding the /3GB switch is needed by
the operating system in order to take advantage of all of the extra AWE memory. In other
words, the operating system needs 2GB of RAM itself to mange the AWE memory if your
server has more than 16GB of RAM. If 16GB or less of RAM is in a server, then the
operating system only needs 1GB of RAM, allowing the other 1GB of RAM for use by SQL
Server.
Once this step is done, the next step is to set the "awe enabled" option to 1 within SQL
Server Enterprise Edition, and then restart the SQL Server service. Only at this point will
SQL Server be able to use the additional RAM in the server.
One caution about using the "awe enabled" setting is that after turning it on, SQL Server no
longer dynamically manages memory. Instead, it takes all of the available RAM (except
about 128MB which is left for the operating system). If you want to prevent SQL Server
from taking all of the RAM, you must set the "max server memory" option (described in
Page 51
SQL Tuning and Maintenance
more detail later in this article) to a figure that limits SQL Server to the amount or RAM you
specify. (7.0, 2000) Updated 1-2-2004
*****
If you find that you are running into a memory bottleneck, and assuming you have the
money to spend, SQL Server 2000 Enterprise Edition can support up to 64GB of
RAM. How much RAM SQL Server 2000 Enterprise Edition can use depends on which
version of Windows 2000 or Windows 2003 you are using and how much RAM your server
can support. Assuming your server can handle it, SQL Server 2000 Enterprise Edition
supports up to 8GB under Windows Advanced Server, and up to 64GB under Windows Data
Center.
Normally, 32-bit CPUs, such as the Pentium family of processors, can only support up to
4GB of RAM because of its limited address space. To get around this limitation, SQL Server
2000 Enterprise Edition supports a feature called AWE (Address Windowing Extensions),
that allows up to 64GB of RAM to be addressed.
Assuming you configure the appropriate hardware and software, AWE support is not turned
automatically on, you have to do this step manually. To turn AWE support on, you must
change the "awe enabled" advanced SQL Server 2000 option from 0 to 1. For example, to
turn on AWE support:
SP_CONFIGURE 'show advanced options', 1
RECONFIGURE
GO
SP_CONFIGURE 'awe enabled', 1
RECONFIGURE
GO
AWE memory cannot be dynamically managed, like memory is normally managed in SQL
Server. This means that SQL Server will automatically grab all the RAM it can when it starts
(except for about 128MB, which is reserved for the operating system), but it will not release
any of this RAM until SQL Server is turned off. If your server is a dedicated SQL Server,
then this might be OK. But if you are running other software on the server, or are running
multiple instances of SQL Server, then you must specify the maximum amount of RAM that
SQL Server can grab when it is started. This can be done using the "max server memory"
configuration option. If you change this setting, you will have to stop and start the
mssqlserver service in order for the new setting to take affect.
To set the maximum amount of memory that AWE memory can access, you can use SQL
Server's "max server memory" configuration option. For example:
SP_CONFIGURE 'max server memory', 4096
RECONFIGURE
GO
In the above example, we are telling SQL Server to only use 4GB of RAM, leaving any other
RAM available in the server free for other applications.
While multiple instances of SQL Server can be used with AWE memory, you probably won't
want to, as it can be a headache to manage. In fact, running multiple instances of SQL
Server in AWE memory defeats the purpose of more RAM in the first place. Generally, your
Page 52
SQL Tuning and Maintenance
goal of using AWE memory should be to support a single, very large instance of SQL Server,
not lots of smaller instances running on a single server.
Assuming you have the budget, adding large amounts of RAM to your server can greatly
speed up many databases. [7.0, 2000] Updated 1-2-2004
*****
Microsoft considers AWE a premium feature, and because of this, it is not offered in all
versions of Windows 2000 and SQL Server 2000. Below is a chart showing the various
versions of Windows 2000 and SQL Server 2000 that support AWE memory.
SQL Server
2000
Enterprise
Edition
SQL Server
2000 Standard
Edition
SQL Server
2000 Personal
Edition
SQL Server
2000
Developer's
Edition
Windows 2000
Datacenter
Server
64GB
2GB
2GB
64GB
Windows 2000
Advanced
Server
8GB
2GB
2GB
8GB
Windows 2000
Server
4GB
2GB
2GB
4GB
Windows 2000
Professional
N.A.
N.A.
2GB
2GB
Windows
Version
Any combination above of 4GB or more is supported via AWE memory. So if you want to
take advantage of AWE memory, you have no choice to purchase Microsoft's premiumpriced software.
*****
If you use AWE memory, you can track its performance characteristics using some
special Performance Monitor counters found under the SQL Server Buffer Manager object.
They include:




AWE Lookup Maps/Sec: This counter measures how many times that a specific
database page was requested by SQL Server, was found in the buffer pool, and then
was mapped as AWE memory (or the server's virtual address space). This would be a
combination of the AWE Stolen Maps/Sec and AWE Write Maps/Sec described later.
AWE Stolen Maps/Sec: This counter measures how many times that a free
database buffer was taken by SQL Server and mapped as AWE memory.
AWE Write Maps/Sec: When SQL Server runs out of free buffers to map to AWE
memory, it has to write to a dirty buffer instead, which hurts performance because a
disk write has to occur to clean up the dirty buffer before it can be used. This counter
measures the number of times that SQL Server has to map a dirty buffer. If this
figure is high, more memory should be considered.
AWE Unmap Call/Sec: Sometimes SQL Server will unmap buffers from AWE
memory (because they have not been used lately). This counter measures how many
times SQL Server calls for an unmap operation, which can affect one or more buffers
at the same time.
SQL Tuning and Maintenance
Page 53

AWE Unmap Pages/Sec: Closely related to the above counter, this counter
specifically measures the number of SQL Server buffers that are unmapped.
Defrag the drives in the Server
Fragmentation of the hard drives in the SQL will also cause performance issue. The drives in the
SQL server should also be defragged regularly. A scheduled task can also be configured to
perform this. Below is a sample command line:
C:\WINDOWS\system32\defrag.exe C: /f /v
/f – forces defragmentation to run even if free space is low
/v – provides verbose output
Page 54
SQL Tuning and Maintenance
SQL Tuning and Maintenance
Page 55