6 – Monitoring and notifications 165 data" for the monitored server, as shown in Figure 6.15 (most other monitoring solutions offer similar query gathering features). Figure 6.15: Enabling the capture of trace data. The trace data allows you to see what code is associated with the alert, or at least to correlate the notification to the query that was running at the time the alert was fired. Figure 6.16 shows the query that SQL Response collected with the alert, which is indeed the query that I ran to trigger the high CPU utilization alert in the first place. Figure 6.16: Capturing the query that triggered high CPU. With the query in hand you can begin the arduous task of tracking down the user or process that has caused the issue. And once you find them you will have the further unenviable task of informing them that their query has caused you much pain and suffering. However, I have found that, as a team, everyone is open to suggestions and few I have met in my travels through the data world really take 6 – Monitoring and notifications 166 offence at your scrutiny of their code. They have a job to do and they want to excel just like you. If you tell them there is a problem they will genuinely listen and try to fix it. As a DBA you have the ability to help and this team work is truly what is required. You may not like being awoken at 2:00AM by an alert for high CPU utilization, but it is important to not let that resentment spill over to other team members. Use the knowledge to fix the issue so that it will not happen again. Stopped services and disk space shortage Low disk space and failing SQL Services are probably the two most prevalent issues that a DBA will encounter. Stopped services are generally an issue when there is a maintenance window that requires a restart of a server and the SQL Agent service, for example, was not set to auto start. While this may happen once, it generally does not happen again, because it usually means that other jobs have not run, and if one of those jobs is a backup job things get ugly very quickly. Fortunately, SQL Response can monitor and alert for both of these special conditions. Figure 6.17 shows the SQL Response alerts for Disk Space and stopped services, either the SQL Agent service or SQL Server service, or both. Figure 6.17: Low disk space and SQL Server Agent not running. 6 – Monitoring and notifications 167 One of the things that I really like about SQL Response is that it alerts on the jobs scheduled by the SQL Agent, even if the SQL Agent is not running. What this means to me is that if I know I have a backup job set to run at 10:00 PM and the SQL Agent, which has a job to execute that backup, is not running, then SQL Response will not only notify me that the SQL Agent is not running but that that job did not run as scheduled. Disk space, as we have learned in previous chapters, can be compromised for a number of reasons, including uncontrolled log growth, TempDB filling up, and so on. As noted earlier, the DBA needs to be warned of the imminent danger while there is still time to act, not when all space is gone. Figure 6.18 shows the threshold setting for disk space in SQL Response. Figure 6.18: Disk space notification for 85%. Notice the alert is set to trigger when the disk has filled to 80% (and not 100%) full, which gives you no time to plan a strategy, such as investigating log or TempDB growth, or perhaps any large data file that is set to auto-grow by a very high percentage. 6 – Monitoring and notifications 168 Summary In most of the IT world, being a DBA is not a 9 to 5 job. Many organizations have tens or hundreds of servers that must work around the clock and so, sometimes, must DBAs. Notifications are necessary evils of the DBA world and you will be asked to carry mobile devices that will go off at all times of the day, and predictably at night, minutes after you have dozed off. Servers do not sleep and nor do their scheduled jobs. Backup failures, though not common, do happen and if you miss a backup because you were not notified of the failure, then you run the risk of data loss. To the DBA and those who manage DBAs and up the chain, data loss is unacceptable. You do not want to be the one to tell your boss that a failed backup occurred and no one responded and someone is desperately waiting for you to restore from the previous night's backup. Performance notifications are nearly as important. Time lost waiting for queries to complete, especially those queries that block other queries, is not acceptable to business. They do not want to know about the details of the code, they only want it to work and work correctly. Finding the issue, as I have said, is the first step to resolving it. With the tools and techniques outlined in this chapter, you should be able to quickly find issues and resolve 95% of them before others are even aware of them, which is what you ultimately desire. If you must bring up the problem, you can safely do it after the fact, when it has been eradicated. Telling your boss there was a problem and you were able to respond to it and resolve it is much better than him or her asking you about a problem that you were totally unaware of. 169 CHAPTER 7: SECURING ACCESS TO SQL SERVER Thus far in the book we have covered a lot of ground in terms of automating processes, battling data growth, troubleshooting code and getting notification of impending danger. Now, I want to turn to a subject that is also sure to be near and dear to every DBA's heart, and that is security. Securing SQL Server is a broad topic, worthy of an entire book in its own right. However, when securing access to a SQL Server instance, most DBAs think first of logins, users, or credentials; in other words, the mechanisms by which they control access to their databases. Such mechanisms are certainly the first line of defense when it comes to restricting access to the sensitive data that your databases store and it is these "outer defenses" that are the focus of this chapter. Of course, this aspect of security alone is a huge topic, and there is much work to be done by the DBA, or security administrator, in creating and managing users, logins and roles, assigning permissions, choosing authentication schemes, implementing password policies, and so on. Here, however, I am going to assume that this security infrastructure is in place, and instead focus on the techniques and scripts that DBAs can use on a day-to-day basis to monitor and maintain the users that have access to their databases, and their activity. Specifically, I'll show you how to: • Find out who has access to data. • Find out when and how they accessed the data. • Use a DDL trigger (created in Listing 1.2, in Chapter 1) to capture activity on database objects, such as deleting a table. • Implement a server-side trace to capture exactly what the users have been doing on a SQL instance. These scripts, collectively, can be rolled into our SQL Server tacklebox (otherwise known as the DBA Repository) so that you will know at a glance what accounts or groups have been granted access to the data on each of the servers you manage. Overview of security challenges As DBAs, believe it or not, we may not even be fully aware of exactly what data is being housed within the walls or, more accurately, pages of the databases we manage. We may know, for example, that the databases contain confidential . SQL Response can monitor and alert for both of these special conditions. Figure 6.17 shows the SQL Response alerts for Disk Space and stopped services, either the SQL Agent service or SQL Server. space and SQL Server Agent not running. 6 – Monitoring and notifications 167 One of the things that I really like about SQL Response is that it alerts on the jobs scheduled by the SQL Agent,. heart, and that is security. Securing SQL Server is a broad topic, worthy of an entire book in its own right. However, when securing access to a SQL Server instance, most DBAs think first of