The following command creates a Server Audit Specification and assigns it to the SQL Server 2008 Bible Audit: CREATE SERVER AUDIT SPECIFICATION [ServerAuditSpecification-20090204-212943]
Trang 1Part VIII Monitoring and Auditing
action groups The following command creates a Server Audit Specification and assigns it to the SQL
Server 2008 Bible Audit:
CREATE SERVER AUDIT SPECIFICATION
[ServerAuditSpecification-20090204-212943]
FOR SERVER AUDIT [SQL Server 2008 Bible Audit]
ADD (DBCC_GROUP), ADD (FULLTEXT_GROUP), ADD (DATABASE_CHANGE_GROUP) WITH (STATE = ON)
Modifying Server Audit Specifications
New Action Audit Types may be added to the Server Audit Specification if the Server Audit Specification
is disabled:
Alter Server Audit Specification name
Add (Action Group)
To redirect a Server Audit Specification to a new SQL Server Audit, both the Server Audit Specification
and the new SQL Server Audit must be disabled
Database Audit Specifications
Database Audit Specifications are created using the same UI dialog as the Server Audit Specification Like
the Server Audit Specification there may only be one Database Audit Specification per SQL Audit To
create multiple Database Audit Specifications there must be multiple SQL Audits — one per Database
Audit Specification
The critical point is that Database Audit Specifications can audit DML events such as select, insert,
update, and delete, as shown in Figure 61-3 You can also see the list of possible Database Audit Action
Types in the drop-down list
Viewing the Audit Trail
The easiest way to view the audit trail is to select the SQL Server Audit in Object Explorer and select
View Logs in the context menu This opens the Log File Viewer to the Audit Collection, as shown in
Figure 61-4 The filter is useful to narrow the event viewed
Using T-SQL, the logs can be read with thefn_get_audit_filefunction
Trang 2FIGURE 61-3
This Database Audit Specification will record every select statement executed by the dbo user in the
AdventureWorks2008 database, and pass the audit data to the SQL Server 2008 Bible SQL Audit
bucket
FIGURE 61-4
Viewing the audit history using Management Studio’s Log File Viewer Here, select statements issued
in AdventureWorks2008 are being audited on a per-table basis
Trang 3Part VIII Monitoring and Auditing
Summary
Extended Events is a powerful new auditing technology for Windows and SQL Server But by itself,
it takes a lot of work to use Extended Events SQL Audit is a powerful collection of objects, easily
configured, that extend and leverage Extended Events and makes it useful today If your shop is running
Enterprise Edition, I see no reason to continue with other auditing technologies such as tracing or
triggers for compliance and monitoring SQL Audit is the future
Major highlights of this chapter include the following:
■ Each instance may have multiple SQL Audits — collection buckets for audit data that can write to an audit file, application log, or security event log
■ Each SQL Audit can have one Server Database Specification and one Database Audit Specifica-tion writing to that SQL Audit Each Server or Database Audit SpecificaSpecifica-tion may have multiple events or actions that it’s auditing
■ Database Audit Specifications can audit DML statements: select, insert, update, and delete In addition, the audit details include user context information
This part covers another new monitoring technology targeted at enterprise servers Management Data
Warehouse is a strategic tool, both for Microsoft and the IT shops that adopt it
Trang 4Management Data
Warehouse
IN THIS CHAPTER
Collecting management data Configuring MDW
The default collection set
Denmark is primarily an Oracle country SQL Server accounts for perhaps
10% of the database servers, but that number is growing So at the
SQL Open World 2007 (hosted by Miracleas.dk)at Lalandia in Rødby,
Denmark, most of the attendees were Oracle DBAs and developers wanting to
learn more about SQL Server For me, as a presenter, it was a great time to learn
more about the gap between SQL Server and Oracle At Lalandia, the guests
stay in cottages near the conference center (and indoor beach, but that’s another
story) While walking to the cottages I asked the Oracle DBAs, ‘‘What could SQL
Server do better? What do you as Oracle DBAs take for granted with Oracle
that you don’t see in SQL Server?’’ The singular answer was that Oracle DBAs
build a data warehouse to gather performance stats, and then they use this data
warehouse to analyze the baselines and performance trends And they were right,
that’s a wonderful practice missing from the SQL Server community
Allow me to introduce the Management Data Warehouse
New to SQL Server 2008 Enterprise Edition, the Management Data Warehouse
(MDW) is a significant strategic development in the progress of SQL Server
The collection of management data is what has been missing in Microsoft’s plans
to take SQL Server to the next level Even if you don’t see much benefit to the
MDW now, believe me, it’s one of the most strategic SQL Server new features in
this decade
Of course, there are other third party systems that collect management data for
later analysis, and it’s not hard to develop one yourself But, with a well-designed
management data warehouse solution built into SQL Server 2008 Enterprise
Edition, it’s worth trying it before going down an alternative route
Trang 5Part VIII Monitoring and Auditing
Configuring MDW
As with any data warehouse, there are basically three key elements:
■ The collection of source data
■ The extract-transform-load (ETL), process that populates the data warehouse
■ The schema of the data warehouse itself
MDW is designed for large enterprises, so the assumption is that there’s a dedicated server for the MDW
database, but it’s possible to collect data from any server and post it to any server
MDW has a default collection set, default data warehouse schema, default programmability objects,
and default reports, but it’s possible to create and configure custom collection sets While the default
collection set has a lame name, it’s actually a rather powerful and complete collection set Don’t consider
designing your own, or extending the default set until you’ve mastered the details of the default
collection set
MDW can be configured and operate using only context menus, wizards, and property pages, but it’s
possible to create and control collection sets with T-SQL code
Configuring a data warehouse
It’s easy to configure and start a default configuration
The data warehouse that will receive the data must be created prior to configuring a collection that will
collect and send that data to the warehouse
To create a MDW data warehouse, connect Object Explorer to the server that will house the data
ware-house, open the server’s Management➪ Data Collection context menu and select Configure Management
Data Warehouse, which launches the wizard
The Configure Management Data Warehouse Wizard can perform one of two tasks In this case, select
the first task: Create or upgrade a management data warehouse This lets you select an existing database
or create a new database which will serve as the MDW data warehouse The wizard will create all the
required objects (tables, views, stored procedures, etc) in the new data warehouse
Configuring a data collection
The data collection is created on the server that will have its management data gathered by MDW So,
on the server that will be tracked, in Management Studio’s Object Explorer, open the server’s
Manage-ment➪ Data Collection context menu and select Configure Management Data Warehouse
Choosing the wizard’s second task option will set-up all the objects in the source server for collecting
the management data The only significant option is choosing the MDW database that will be the
desti-nation of the collected data
Trang 6Once data collection has been install, it can be enabled or disable on the source server using
Management➪ Data Collection context menu
The default collection actually includes three separate collection sets: Disk Usage, Query Statistics,
and Server Activity (shown in Figure 62-1) Each collection set can be started, stopped, and manually
uploaded using their respective context menus
FIGURE 62-1
In this view of MDW, the three collection sets are open in Object Explorer and the central portion of
the default MDW data warehouse schema is open in the database diagramming tool
The collection set can be further configured in the Collection Set Properties page, illustrated in
Figure 62-2 It’s opened from the collection set’s context menu
Each collection set may actually include multiple collection items, each defining a script or query that
will typically select management of performance data from SQL Server’s system stored procedures or
Dynamic Management Views (DMVs) The properties page is also used to set the ETL schedule and
retention duration
Trang 7Part VIII Monitoring and Auditing
FIGURE 62-2
The Collection Set Properties page is used to fine tune each collection set A key point on this page
is the duration retention
The MDW Data Warehouse
When initialized, MDW includes a default collection set which gathers a rather extensive set of
perfor-mance and operational data about SQL Server The default MDW data warehouse actually consists of:
■ 30 tables in the data warehouse database (some of which are shown in Figure 62-1)
■ 5 views, 64 stored procedures, and 9 user-defined functions all designed to extract information from the data warehouse
Trang 8The default MDW data warehouse supports three preconfigured reports To find the three reports, look
under the Management➪ Data Collection context menu in the source server
Summary
Management Data Warehouse is a great way to collect data for baselining performance, finding trends,
or diagnosing issues, which begs the question: what will you do with all that information? I believe that
MDW is the strategic foundation for lots of good things to come
As a side note, third-party vendors who create add-on software for Microsoft applications who survive
by dancing with an elephant — they had better be nimble and quick They need to exploit a feature gap
for a version of two and move on The feature gap in SQL Server 2008 is right here at the end of MDW
The third party vendors who are smart will write reports and create tools that analyze MDW data and
offer tuning advice
This chapter completes Part VIII — a survey of monitoring and auditing technologies in SQL Server
2008 No one can ever accuse SQL Server of not being transparent
The next part logically builds on this part and moves into the realm of the performance tuning and
optimization skill set
Trang 10Performance Tuning
and Optimization
IN THIS PART
Chapter 63
Interpreting Query Execution Plans
Chapter 64
Indexing Strategies
Chapter 65
Query Plan Reuse
Chapter 66
Managing Transactions, Locking, and Blocking
Chapter 67
Data Compression
Chapter 68
Partitioning
Chapter 69
Resource Governor
It seems everyone wants a quick fix
On one optimization job, I identified and prioritized numerous issues with
the schema, queries, and indexes that together would have reduced the
aggregate workload by 60–80 percent I thought I’d done a great job The
client didn’t think so They actually said they were hoping that as an MVP
I’d know of an undocumented ‘‘go fast’’ switch
The switch is in the design!
But once the schema and queries are right and the workload is known, it’s
time to tune the indexes and optimize the server From reading query
execution plans, to query paths and indexing, to data compression, this part
is filled with some of my favorite SQL Server topics If you thought left
outer joins were fun, well, you’re in for a real treat
If SQL Server is the box, this part is about making the box scream