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
Trang 1data" 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
Trang 26 – Monitoring and notifications
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
Trang 3One 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
Trang 46 – Monitoring and notifications
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
Trang 5C HAPTER 7: S ECURING ACCESS
TO SQL S ERVER
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