462 Chapter10•MonitoringandTroubleshooting You can turn off the events in the Security Audit and Sessions sections by unchecking their respective check boxes. You can also uncheck the SQL:BatchStarting event because it only shows when commands are started not when they are completed. You will also want to check the box in the TextData column for the RPC:Completed event. This will leave the trace returning all the statements that are executed against the SQL Server instance (see Figure 10.13). Figure 10.12 Default SQL Profiler Event Selection MonitoringandTroubleshooting•Chapter10 463 When you run the SQL Profiler Trace by clicking the Run button, every statement being executed against the database instance is returned to the SQL Profiler application. If you are monitoring a high load database server, this will quickly become more data than you can sift through. You can reduce the amount of data by clicking the Column Filters button. This allows you to return only certain rows back to the client. By setting the trace to be filtered against the Duration column, you will see all statements executed against the database that take over 2.5 seconds (2500 milliseconds) to complete (see Figure 10.14). If this trace returns too much data, you can stop it, change the filter to a higher number, and then run it again. Figure 10.13 SQL Profiler Event Selection 464 Chapter10•MonitoringandTroubleshooting Next, begin performance tuning the queries by looking at your indexes and execution plans. As you can see in Figure 10.15, it becomes easy to identify which queries are long running and need to be tuned. Figure 10.15 SQL Server Profiler Showing Long Running Queries Figure 10.14 SQL Profiler Trace Set to Return Queries That Run for Longer Than 2.5 Seconds MonitoringandTroubleshooting•Chapter10 465 Performance Monitor The Performance Monitor includes hundreds of performance counters related directly to the performance of the SQL Server instance. Like the SQL Server Profiler, you have to know which counters to look at depending on the data you wish to see. If you want to look at memory issues, some counters to monitor are found under the SQLServer:Buffer Manager group. The buffer cache hit ratio and page life expectancy tells you how long the data is staying in the buffer cache and what the odds are that SQL Server will be able to find the data in memory. The higher the buffer cache hit ratio and page life expectancy, the better the chances that SQL Server will be able to find what it is looking for in RAM and will not need to read data from the disk. The less SQL Server needs to go to the disk, the better it will perform. Because the page life expediency data is in seconds, you may need to divide the value by 60 (for minutes) or 3600 (for hours). TE s T Da y Ti p When using SQL Server Profiler, remember that times filters are done in milliseconds, not seconds, for greater control. Ex a m Wa r n i n g SQL Server 2008 has many new performance monitor objects. While not all of them are covered here specifically, you should familiarize yourself with them. For disk issues, you can look at the physical disk counters. Some counters that give you the best insight are the following: current disks queue avg. disk sec / read avg. disk sec / write disk read / sec disk write / sec 466 Chapter10•MonitoringandTroubleshooting The current disks queue counter records the number of operations currently queued and waiting for disks to become available. The avg. disk sec / read and / write tell you how long it’s taking disks to respond to each operation. This number is critical to the health of your SQL Server. Any number over .01 seconds per operation is going to show as higher than normal CPU load and waits within the SQL Server. The read and write operations-per-second numbers tell you how much load is being placed on the disks by SQL Server and other operations. If the operations- per-second number is low and the seconds-per-operation number is high, you may have a disk performance issue that needs to be addressed. If you think that another application on the server is causing high disk IO, you can use performance monitoring to look that data as well. Under the Process group, you’ll find several counters including the IO Data Operations / sec counter. You can then select the application you think is causing the problem, as well as the SQL Server process, to see which is taking the IO. You can also add in all your applications to see which ones are taking the IO load. TE s T Da y Ti p There are many performance monitor counters with similar names. Pay careful attention when the exam refers to the avg. disk sec / read and disk reads / sec counters, for example, since these two counters have very different meanings. no T E Performance monitoring data can be scheduled and saved into a text file or database. When you are monitoring backup jobs, throughput to your backup devices is very important. However, monitoring the number of IOs per second doesn’t give you a true idea of how fast your backup is taking. In addition, you also need to subtract the IO of anything else writing to the disk. Because of this, Microsoft has included the SQL Server:Backup Device counter, which has the Device Throughput Bytes / sec. Doing some math will give you the throughput in kilobytes or mega- bytes per second. . long the data is staying in the buffer cache and what the odds are that SQL Server will be able to find the data in memory. The higher the buffer cache hit ratio and page life expectancy, the. the better the chances that SQL Server will be able to find what it is looking for in RAM and will not need to read data from the disk. The less SQL Server needs to go to the disk, the better. 465 Performance Monitor The Performance Monitor includes hundreds of performance counters related directly to the performance of the SQL Server instance. Like the SQL Server Profiler, you have