SQL performance monitoring

INTRODUCTIONOne 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.

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 OverviewSQL 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 StrategyYou 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 baselineWithout 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 auditsAfter 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 impactAfter 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 baselineAfter completing all the modifications, create another baseline to measure future performance trends.

Creating a BaselinePerformance CountersProcessor CountersProcessor counters are used in conjunction with other counters to monitor and evaluate CPU performance and identify CPU bottlenecks.

Processor: % Processor TimeThe % 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 LengthThe 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 bottleneckOnly Queue length out of range: Configuration problem exists Max Worker threads set to lower valueEnsure that the max worker threads server setting has not been set to a value that is too high for your system.(Use themax worker threadsoption to configure the number of worker threads available to Microsoft SQL Server processes.)Solution: Change Max worker threads setting

Max Worker threads Setting

Disk CountersSeveral 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 = 20If value out of range: Increase memorySpread 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

Other Disk Counters% Disk ReadTime in percentage disk is performing read operations

% Disk WriteTime 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 secondAvailable 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 / secNumber of pages moved out of memory per secondORNumber of pages moved into memory per second

Memory: Pages / sec

Memory: Pages / sec

Memory: Pages / secIf Pages / sec is consistently highMemory bottleneckSolution: Add more memory

Memory: Available BytesMemory 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 requiredIf value very-very less, ensure other processes on server not affected

SQL Server: Buffer Manager: Buffer Cache Hit RatioPercentage of time data was found in buffer without reading from diskRecommended value: 90%+If < 90%, paging activity increases, causing more load on Disk systemdisk I/O will be too high,

SQL Server: Buffer Manager: Page Life ExpectancyNumber of seconds a page stay in bufferRecommended Value: 300 secondsCounter 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 trendsIf 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 CountersUser Connections

Number of user connections that are currently connected to SQL ServerUseful 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 CountersSQL Server Access Methods: Page Splits/secPage splits occur when SQL Server attempts to insert a row in a index page, but sufficient space not availableSQL 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 ViewsSQL 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 MonitoringPerformanceLog File ViewerManagement SQL server logsChoose logView SQL server log

Activity monitor Identify every current process running on SQL server.What the processes are doing.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 process2. Locks by processsuch as lock types, lock status, and locked resources

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

LockingCoordinates multiple accesses to the same dataEnsures ACID Properties for transactions (Atomic, Consistent, Independent, Durable)Contention can reduce performanceLocking granularity: Row-Level, Page-Level, Table-Level, etc.Lock Modes: Shared, Exclusive, etc.

Deadlock ProcessDeadlocks:Two or more tasks permanently block each other based on resource locksExample:Process 1 locks the Customers table and requires access to the Orders TableProcess 2 locks the Orders table and requires access to the Customers Table

Stored proceduressp_who2 [process_ID] | [ACTIVE]sp_lockKILL spid

ProfilerGather the performance information to Isolate and Correct data base problemsConfiguring procedures sp_trace_seteventsp_trace_setfiltersp_trace_setstatussp_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.