6 – Monitoring and notifications 160 In Chapter 5, DBA as Detective, I demonstrated how poorly-designed code can bring your server to a crawl, and offered some remedial measures. In this chapter, I want to shift the focus onto code that has been tested and approved and moved to production but, once there, causes resource issues with regard to CPU, RAM or Disk I/O. It may not be that the code itself causes SQL Server to use too many resources; it may be due more to some "confluence of circumstances," for example the code running at the same time as a maintenance process, such as an index rebuild, or code that results in an excessively high number of connections, at the time the OS is also performing a memory-intensive process. I am going to show how DBAs can be notified when such performance issues arise, and then how to proactively respond to them before the Help Desk is called or, worse, the user sends mail to you, your boss, your boss's boss and your mother and father, all of whom will shake their heads disapprovingly. OK, maybe that is just me, but you get the point. If you are in an enterprise environment, chances are you already have a monitoring solution in place for server administrators and you can piggy back off that alerting system and, with luck, it will include SQL-specific alerts that allow you to, for example, report blocked processes. If you don't have this luxury, then you have two choices: build your own monitoring solution, or buy in a third-party solution. While you can certainly build your own, the cost in terms of time and resources is going to be high. You can, for example, set up performance alerts using the native Windows Perfmon utility, or by setting native SQL alerts, which are part of SQL Agent. However, scripting all of these alerts requires some level of skill and patience. Although I do not demonstrate setting native SQL Alerts in this chapter because, to be quite honest, they are not part of my overall monitoring and notification strategy, Figure 6.11 does show where you would go to do this, along with a few samples of the type of events that you can monitor. Native SQL Alerts also allow you to capture performance metrics, but only for SQL performance counters, so disk space usage and CPU utilizations, for example, would require additional consideration. This may require use of gain Perfmon, or esoteric Windows Management Instrumentation (WMI) queries. 6 – Monitoring and notifications 161 Figure 6.11: Native SQL Alerts samples. Alternatively, you can acquire a third-party monitoring solution that is not only SQL-centric, but can be centrally managed. Once such product is Red Gate's SQL Response. Price is definitely a consideration when choosing a monitoring solution and, in my opinion, SQL Response works out to be much more affordable than rolling your own. This is not a sales pitch; it is just a demonstration of a product that is available to DBAs and one that happens to have become part of my tackle box for performance monitoring and diagnostics. The main performance metrics that you will want to monitor are CPU, Memory and I/O. As an example of a typical performance alert, I am going to configure an alert in SQL Response to monitor CPU utilization and then run a query that should push the CPU utilization above a set threshold. Figure 6.12 shows the SQL Response alert configuration window. For this demonstration, I have customized the standard "CPU utilization unusual" alert so that should fire if CPU utilization exceeds 70% for at least 5 seconds. The default is 90% for 10 seconds, which is more in line with what you would normally use to trigger this alert. 6 – Monitoring and notifications 162 Figure 6.12: Configuring CPU utilization alert in SQL Response. Notice also that there is a "send email to:" box where you can enter a single or group email address. Email notifications can be setup for all alerts or individually. To set up the email server, simply click on "Configure Email", in the same alerts window, and enter your SMTP email information, such as server name and reply to account. Now all I need to do is kick off a query that will raise the CPU above 70% for more than 5 seconds. The code from the previous chapter, with a slight modification to remove the "bad" code will work just fine, see Listing 6.3. After all, some otherwise "acceptable" code will still require a lot of resources to process. DECLARE @SQL_Alphabet varchar(26) SET @SQL_Alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' DECLARE @rnd_seed int SET @rnd_seed = 26 DECLARE @DT datetime SET @DT = '05/21/1969' DECLARE @counter int SET @counter = 1 DECLARE @tempVal NCHAR(40) 6 – Monitoring and notifications 163 WHILE @counter < 10000000000 BEGIN SET @tempVal = SUBSTRING(@SQl_alphabet, Cast(RAND() * @rnd_seed as int) + 1, CAST(RAND() * @rnd_seed as int) + 1) SET @counter = @counter + 1 END Listing 6.3: Modified code to raise CPU levels for testing. Of course, you won't generally know what code is causing the issue beforehand, so we'll also need a way to find out what code is causing the spike in resource utilization, so that it can be fine tuned to use fewer resources and so speed performance for other contending processes. I execute the query and wait. As the query is executing, I can monitor CPU utilization using the System Information application, which can be launched from Sysinternals Process Explorer (http://technet.microsoft.com/en- us/sysinternals/bb896653.aspx), as shown in Figure 6.13. Figure 6.13: Watching CPU utilization with System Information. 6 – Monitoring and notifications 164 You can certainly use Task Manager instead but I just happen to like the added eye candy of System Information and Process Explorer. Once the CPU utilization has hit 70% for 5 seconds, the alert is generated and emailed to me, as shown in Figure 6.14. Figure 6.14: Email notification from SQL Response of "unusual" CPU utilization. The alert contains limited information, but it would be easy to include in the mail message a key word, such as "unusual", to trigger a Level 1 alert (a high level alert for Blackberry users), since it is "unusual" to receive mail with the word "unusual" in it. However, perhaps you might want to be more specific and use something like "CPU activity unusual" to set the alert. At any rate, the alert did fire and so I was made aware of a potential issue before users complained or processes failed. With SQL Response, you can find out what caused the CPU spike simply by turning on the tracing option that instructs SQL Response to capture the code that was executing at the time that alert was generated. In order to enable this feature, simply click on "Server Properties" and select "Enable collection of trace . setting native SQL alerts, which are part of SQL Agent. However, scripting all of these alerts requires some level of skill and patience. Although I do not demonstrate setting native SQL Alerts. Native SQL Alerts samples. Alternatively, you can acquire a third-party monitoring solution that is not only SQL- centric, but can be centrally managed. Once such product is Red Gate's SQL. resource issues with regard to CPU, RAM or Disk I/O. It may not be that the code itself causes SQL Server to use too many resources; it may be due more to some "confluence of circumstances,"