SQL Server Tacklebox- P33 pps

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

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

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

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)

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

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