Nielsen c61.tex V4 - 07/21/2009 4:02pm Page 1302 Part 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 the fn_get_audit_file function. 1302 www.getcoolebook.com Nielsen c61.tex V4 - 07/21/2009 4:02pm Page 1303 SQL Audit 61 FIGURE 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. 1303 www.getcoolebook.com Nielsen c61.tex V4 - 07/21/2009 4:02pm Page 1304 Part 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 Specification 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. 1304 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1305 Management Data Warehouse IN THIS CHAPTER Collecting management data Configuring MDW The default collection set D enmark 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. 1305 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1306 Part 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. 1306 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1307 Management Data Warehouse 62 Once 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 t hree 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. 1307 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1308 Part 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 The data warehouse is designed in a star schema design around a central snapshot table. Each snapshot is one point in time, or one ETL upload of the management data. 1308 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1309 Management Data Warehouse 62 The 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. 1309 www.getcoolebook.com Nielsen c62.tex V4 - 07/21/2009 4:03pm Page 1310 www.getcoolebook.com Nielsen p09.tex V4 - 07/21/2009 4:06pm Page 1311 Performance Tuning and Optimization IN THIS PART Chapter 63 Interpreting Query Execution Plans Chapter 64 Indexing Strategies Chapter 65 Query Plan R euse Chapter 66 Managing Transactions, Locking, and Blocking Chapter 67 Data Compression Chapter 68 Partitioning Chapter 69 Resource Governor I t 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. www.getcoolebook.com . 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. 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. 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