SQL performance monitoring

One of the primary responsibilities of the database administrator is the ongoing monitoring of SQL Server performance. Much of this monitoring can be automated, but for the most part, the monitoring results must be interpreted and acted upon in a systematic approach by the DBA. The monitoring job never ends, and it can become quite complex. Knowing what to monitor, when to monitor, and what constitutes acceptable and unacceptable behavior can become a full-time job. Making things worse is the fact that each SQL Server installation is different, making a global recommendation about what indicators identify unacceptable and acceptable performance very difficult.

INTRODUCTION

 Monitoring SQL Server can be a challenging process. SQL Server interacts heavily with every operating system subsystem. Some applications rely heavily on RAM, whereas others are CPU- or disk-intensive. SQL Server can be all three at the same time. SQL Server can also be very network-intensive, especially with distributed applications, replication, or database mirroring. Many database administrators find the whole process of monitoring and optimizing arcane and nebulous. A good understanding of the tools, as well as a familiarity with the different objects requiring monitoring, will go a long way to making your optimization process less intimidating.

Monitoring and Optimization Overview

SQL Server 2008 monitoring can essentially be divided in to five basic areas: System resources SQL Server itself The database The database application The network

Optimization Strategy
You must have some kind of plana strategy that will enable you to invest the right amount of time and the right amount of resources to maintain and improve the performance of your SQL Servers.

1.Create a performance baseline Without a baseline of your database server, it is very unlikely that you will be able to make changes to the server platform with complete confidence that the changes will accomplish the improvements you are looking for. A baseline contains measurements from all the systems previously mentioned (system resources, SQL Server, the database, the database application, and the network). When evaluating the baseline, you may identify areas that warrant immediate optimization. If changes are made, a new baseline must be created.

2.Complete periodic performance audits After the baseline is completed, periodic performance audits are performed to ensure that performance has not degraded from when the baseline was created.

3. Make changes and evaluate their impact After performing audits, you may find areas that require modification. As a rule, you should not make multiple changes at once. Instead, make one or two changes, and then evaluate the measurements that prompted the changes to be made. This makes it much easier to identify what changes have the greatest impact on performance.

4. Reset the baseline After completing all the modifications, create another baseline to measure future performance trends.

Creating a Baseline
Performance Counters Processor Counters Processor counters are used in conjunction with other counters to monitor and evaluate CPU performance and identify CPU bottlenecks.

 Processor: % Processor Time The % Processor Time counter displays the total percentage of time spent processing non-idle threads. On a multiple-processor machine, each individual processor can be monitored independently. CPU activity is a good indicator of SQL Server CPU activity, and is a key way to identify potential CPU bottlenecks. As a general rule, if total % Processor Time is consistently greater than 70 percent, you probably have a CPU bottleneck, and you should look at either optimizing current application processes, upgrading the CPU, or both.

 Process: % Processor Time (sqlservr) The Process: % Processor Time counter (when set to monitor information from the SQL Server process) can be used to determine how much of the total processing time can be attributed to SQL Server. System: Processor Queue Length The Processor Queue Length counter displays the number of threads waiting to be processed by a CPU. If the average queue length is consistently greater than two times the number of processors, then you may have a CPU bottleneck, because the processors cant keep up with the number of requests.
The Processor Queue Length and the % Processor Time counters together to determine if you have a CPU bottleneck. If both counters are out of acceptable ranges, there is most assuredly a CPU bottleneck.

 Processor time and queue length:

Both out of range: CPU bottleneck Only Queue length out of range: Configuration problem exists Max Worker threads set to lower value Ensure that the max worker threads server setting has not been set to a value that is too high for your system. (Use the max worker threads option to configure the number of worker threads available to Microsoft SQL Server processes. ) Solution: Change Max worker threads setting

Max Worker threads Setting

Disk Counters Several disk counters return disk read and write performance information, as well as data transfer information, for each physical disk or all disks. Avg. Disk Queue Length:
The Avg. Disk Queue Length counter returns the average number of read and write operations that were queued for an individual disk or all disks. The requests are queued because the disk or disks are too busy. This counter should remain below the number of physical disks multiplied by two. Disk Length < (2 * Physical Disks) Example: 10 Disk Array can have Queue length = 20 If value out of range:
Increase memory Spread database across multiple disks (RAID), Adding memory, if possible, to the disk controller may also alleviate the disk bottleneck.

 % Disk Time: This counter measures how busy a physical disk or hardware disk array is. It is the total of read and write activity on the disk or array. The % Disk Time counter shouldnt consistently run at more than 60 percent. Recommended Value:
% Disk Time <= 60% Solution:
Use faster disk drive Add disks to RAID array Move files to additional disk or server

Other Disk Counters

% Disk Read
Time in percentage disk is performing read operations

% Disk Write
Time in percentage disk is performing write operations

Memory Counters: A lack of memory will have a direct impact on disk activity. When optimizing a server, adding memory should always be considered. Pages/Sec:
The Pages/Sec counter measures the number of pages per second

Available Bytes:
The Available Bytes counter indicates how much memory is available to processes.

Working Set (sqlservr):

The SQL Server instance of the Working Set counter shows how much memory is in use by SQL Server.

Memory: Pages / sec

Number of pages moved out of memory per second OR Number of pages moved into memory per second

Memory: Pages / sec

Memory: Pages / sec

Memory: Pages / sec

If Pages / sec is consistently high
Memory bottleneck Solution: Add more memory

Memory: Available Bytes

Memory available to processes

Process: Working Set(sqlservr)

Memory in use by SQL Server. If less than Min server memory setting and Max server memory setting Already more memory allocated to SQL server, possibly no action required If value very-very less, ensure other processes on server not affected

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

Percentage of time data was found in buffer without reading from disk Recommended value: 90%+ If < 90%, paging activity increases, causing more load on Disk system
disk I/O will be too high,

SQL Server: Buffer Manager: Page Life Expectancy

Number of seconds a page stay in buffer Recommended Value: 300 seconds Counter used along with Buffer Cache Hit Ratio counter to measure memory health

Network counters, a good way to measure the network traffic over a period of time to evaluate trends to determine if some type of scaling or load balancing may be in order. Bytes Total/SecThe Bytes Total/Sec counter measures the total number of bytes that are being sent back and forth between the server and the network.
Useful in analyzing network traffic trends If the server is configured exclusively for SQL Server, almost all of the traffic should belong to SQL Server.

Tip: Ensure that the network traffic being generated on the server is well within the capacity of the network connection.

SQL Server Counters

User Connections
Number of user connections that are currently connected to SQL Server Useful in monitoring and tracking connection trends to ensure that the server is configured to adequately handle all connections. Keep in mind that this counter displays the number of user connections, not users. Some applications will create more than one connection per user, whereas others may create only one connection, but support multiple users.

 Average Wait TimeThe Average Wait Time counter is an excellent counter to monitor and track the average amount of time that user requests for data resources have to wait because of concurrent blocks to the data. Deadlocks/SecDeadlocks occur when two or more transactions hold a lock on different resources and the transactions require access to the resources held by the opposing transaction.
Number of deadlocks per second

SQL Server Counters

SQL Server Access Methods: Page Splits/sec Page splits occur when SQL Server attempts to insert a row in a index page, but sufficient space not available SQL Server splits about half of the data out of the original page and moves it to a free page. Splitting causes excessive I/O, because logically contiguous data is no longer physically contiguous. The Page Splits/sec counter enables the monitoring of page split activity Excessive page splits will cause a steady deterioration of database performance. Solution: Rebuild the indexes

Dynamic Management Views

SQL Server 2008 provides many Dynamic Management Views (DMVs) that can be used in the gathering of baseline information, and for diagnosing performance problems. Some of these views offer the same information as performance counters, but in a relational and instantaneous format. Other views provide more specific database performance information.

Tools and Techniques for Monitoring Performance

Log File Viewer
1. 2. 3. 4. Management SQL server logs Choose log View SQL server log

Activity monitor
Identify every current process running on SQL server. What the processes are doing. 1. Process info. such as the user associated with the connection, the database context, the command presently running, as well as any wait status and blocking information

 Double-clicking a process will bring up the last command executed on that connection, and provide the capability to kill the process 2. Locks by process such as lock types, lock status, and locked resources

3. Locks by object The Locks by Object page provides even more detailed information about the objects being locked by various processes

Locking
Coordinates multiple accesses to the same data Ensures ACID Properties for transactions (Atomic, Consistent, Independent, Durable) Contention can reduce performance Locking granularity:
Row-Level, Page-Level, Table-Level, etc.

Lock Modes:
Shared, Exclusive, etc.

Deadlock Process
Deadlocks:
Two or more tasks permanently block each other based on resource locks

Example:
Process 1 locks the Customers table and requires access to the Orders Table Process 2 locks the Orders table and requires access to the Customers Table

Stored procedures
sp_who2 [process_ID] | [ACTIVE] sp_lock KILL spid

Profiler
Gather the performance information to Isolate and Correct data base problems Configuring procedures sp_trace_setevent sp_trace_setfilter sp_trace_setstatus sp_trace_create

Database Tuning Advisor (DTA)

Index usage can be analyzed. The Database Tuning Advisor (DTA) can be utilized to analyze existing indexes. The DTA can return recommendations for the addition of indexes, indexed views, and table partitioning.