Microsoft SQL Server 2008 R2 Unleashed

Ray Rankins Paul Bertucci Chris Gallelli Alex T. Silverstein Microsoft® SQL Server 2008 R2 UNLEASHED 800 East 96th S...

Author: Ray Rankins | Paul Bertucci | Chris Gallelli | Alex T. Silverstein

174 downloads 2109 Views 48MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Ray Rankins Paul Bertucci Chris Gallelli Alex T. Silverstein

Microsoft®

SQL Server 2008 R2 UNLEASHED

800 East 96th Street, Indianapolis, Indiana 46240 USA

Download from www.wowebook.com

Microsoft SQL Server 2008 R2 Unleashed Copyright © 2011 by Pearson Education, Inc. All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein. ISBN-13: 978-0-672-33056-8 ISBN-10: 0-672-33056-3

Library of Congress Cataloging-in-Publication Data is on file.

Acquisitions Editor Neil Rowe Development Editor Mark Renfrow

Project Editor Seth Kerney

Trademarks All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Sams Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The author(s) and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the CD or programs accompanying it. Pearson offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside of the U.S., please contact: International Sales +1-317-581-3793 [email protected]

Editor In Chief Karen Gettman

Managing Editor Sandra Schroeder

Printed in the United States of America First Printing September 2010

Bulk Sales

Publisher Paul Boger

Copy Editor Chuck Hutchinson Indexer Erika MIllen Proofreader Leslie Joseph Debbie Williams Technical Editor Rebecca M. Riordan J. Boyd Nolan Publishing Coordinator Romney French Multimedia Developer Dan Scherf Designer Gary Adair Compositor Mark Shirar

Download from www.wowebook.com

Contents at a Glance Introduction....................................................................................................1 Part I

Welcome to Microsoft SQL Server

1

SQL Server 2008 Overview..............................................................................9

2

What’s New in SQL Server 2008...................................................................35

3

Examples of SQL Server Implementations ...................................................51

Part II

SQL Server Tools and Utilities

4

SQL Server Management Studio ...................................................................63

5

SQL Server Command-Line Utilities ..........................................................103

6

SQL Server Profiler ......................................................................................121

Part III

SQL Server Administration

7

SQL Server System and Database Administration......................................165

8

Installing SQL Server 2008..........................................................................185

9

Upgrading to SQL Server 2008 ...................................................................227

10

Client Installation and Configuration .......................................................263

11

Security and User Administration ..............................................................291

12

Data Encryption..........................................................................................335

13

Security and Compliance............................................................................359

14

Database Backup and Restore .....................................................................377

15

Database Mail..............................................................................................427

16

SQL Server Scheduling and Notification ....................................................449

17

Administering SQL Server 2008 with PowerShell ......................................481

18

SQL Server High Availability ......................................................................523

19

Replication ..................................................................................................545

20

Database Mirroring .....................................................................................617

21

SQL Server Clustering .................................................................................655

22

Administering Policy-Based Management..................................................687

Part IV

Database Administration

23

Creating and Managing Databases .............................................................709

24

Creating and Managing Tables ...................................................................741

25

Creating and Managing Indexes ................................................................791

26

Implementing Data Integrity......................................................................811

27

Creating and Managing Views in SQL Server ............................................837

28

Creating and Managing Stored Procedures ................................................869

Download from www.wowebook.com

iv

29

Creating and Managing User-Defined Functions. .....................................917

30

Creating and Managing Triggers . ..............................................................949

31

Transaction Management and the Transaction Log . ................................995

32

Database Snapshots. .................................................................................1043

33

Database Maintenance. ............................................................................1069

Part V

SQL Server Performance and Optimization

34

Data Structures, Indexes, and Performance . ...........................................1091

35

Understanding Query Optimization . ......................................................1209

36

Query Analysis . ........................................................................................1301

37

Locking and Performance .........................................................................1341

38

Database Design and Performance . .........................................................1403

39

Monitoring SQL Server Performance. ......................................................1427

40

Managing Workloads with the Resource Governor . ...............................1493

41

A Performance and Tuning Methodology. ..............................................1519

Chapters on the CD Part VI

SQL Server Application Develop-

ment 42

What’s New for Transact-SQL in SQL Server 2008. .................................1551

43

Transact-SQL Programming Guidelines, Tips, and Tricks . ......................1637

44

Advanced Stored Procedure Programming and Optimization.................1733

45

SQL Server and the .NET Framework . .....................................................1787

46

SQLCLR: Developing SQL Server Objects in .NET . .................................1825

47

Using XML in SQL Server 2008 . ..............................................................1865

48

SQL Server Web Services . .........................................................................1927

49

SQL Server Service Broker . .......................................................................1959

50

SQL Server Full-Text Search . ....................................................................1997

Part VII

SQL Server Business Intelligence Features

51

SQL Server 2008 Analysis Services. ..........................................................2029

52

SQL Server Integration Services . ..............................................................2099

53

SQL Server 2008 Reporting Services . .......................................................2169

Part VIII

Bonus Chapters

54

Managing Linked and Remote Servers . ...................................................2243

55

Configuring, Tuning, and Optimizing SQL Server Options . ..................2273

56

SQL Server Disaster Recovery Planning. ..................................................2329 2353 Index

Download from www.wowebook.com

Contents

v

Table of Contents Introduction Part I 1

1

Welcome to Microsoft SQL Server SQL Server 2008 Overview

9

SQL Server Components and Features . .........................................................9 The SQL Server Database Engine.........................................................10 SQL Server 2008 Administration and Management Tools .................12 Replication . .........................................................................................15 Database Mirroring . ............................................................................17 Full-Text Search. ..................................................................................17 SQL Server Integration Services (SSIS).................................................18 SQL Server Analysis Services (SSAS) ....................................................19 SQL Server Reporting Services (SSRS) ..................................................20 SQL Server Service Broker. ..................................................................22 SQL Server 2008 R2 Editions . ......................................................................23 SQL Server 2008 Standard Edition ......................................................23 SQL Server 2008 Enterprise Edition ....................................................24 Differences Between the Enterprise and Standard Editions of SQL Server .......................................................25 Other SQL Server 2008 Editions..........................................................26 SQL Server Licensing Models. ......................................................................30 Web Edition ........................................................................................32 Developer Edition Licensing ...............................................................32 Express Edition Licensing....................................................................32 Compact Edition 3.5 Licensing ...........................................................32 Choosing a Licensing Model...............................................................32 Mixing Licensing Models ....................................................................33 Passive Server/Failover Licensing ........................................................33 Virtual Server Licensing.......................................................................33 Multiple Instances of SQL Server ........................................................34 Summary .......................................................................................................34 2

What’s New in SQL Server 2008

35

New SQL Server 2008 Features . ...................................................................35 New Storage Features ...........................................................................36 New Data Types ...................................................................................37 New Transact-SQL Constructs .............................................................37 New Performance Features ..................................................................38 New Security Features..........................................................................39

Download from www.wowebook.com

vi

New Database Administration Features . ............................................40 New SQL Server Management Studio Features ...................................41 PowerShell Integration . ......................................................................42 New Premium SQL Server Editions .....................................................42 SQL Server Utility for Multiserver Management ................................43 PowerPivot for Excel and SharePoint..................................................43 New Reporting Services Features . .......................................................44 SQL Server 2008 Enhancements. .................................................................45 SQL Server Management Studio..........................................................45 Dynamic Management Views. ............................................................45 Database Mirroring . ............................................................................46 SQLCLR Enhancements.......................................................................46 Replication Enhancements. ................................................................46 SQL Server Integration Services Enhancements .................................47 Service Broker Enhancements . ...........................................................47 Analysis Services Enhancements .........................................................48 Installation Enhancements. ................................................................49 Deprecated Features. ...........................................................................49 Summary .......................................................................................................50 3

Examples of SQL Server Implementations

51

Application Terms .........................................................................................52 OLTP Application Examples .........................................................................53 OLTP ERP Example ..............................................................................53 OLTP Shopping Cart Example.............................................................56 DSS Application Examples . ..........................................................................57 DSS Example One ................................................................................57 DSS Example Two . ..............................................................................58 DSS Example Three. ............................................................................59 Summary .......................................................................................................61 Part II 4

SQL Server Tools and Utilities SQL Server Management Studio

63

What’s New in SSMS .....................................................................................63 The Integrated Environment . ......................................................................64 Window Management .........................................................................65 Integrated Help . ..................................................................................68 Administration Tools . ..................................................................................71 Registered Servers.................................................................................71 Object Explorer . ..................................................................................73 Activity Monitor . ................................................................................75

Download from www.wowebook.com

Contents

vii

Log File Viewer ....................................................................................77 SQL Server Utility ................................................................................79 Development Tools . .....................................................................................85 The Query Editor .................................................................................85 Managing Projects in SSMS .................................................................93 Integrating SSMS with Source Control................................................95 Using SSMS Templates .........................................................................97 T-SQL Debugging ...............................................................................100 Multiserver Queries............................................................................101 Summary .....................................................................................................102 5

SQL Server Command-Line Utilities

103

What’s New in SQL Server Command-Line Utilities . ...............................104 The sqlcmd Command-Line Utility . .........................................................105 Executing the sqlcmd Utility.............................................................106 Using Scripting Variables with sqlcmd .............................................108 The dta Command-Line Utility . ................................................................109 The tablediff Command-Line Utility..........................................................112 The bcp Command-Line Utility .................................................................115 The sqldiag Command-Line Utility............................................................116 The sqlservr Command-Line Utility...........................................................118 Summary . ...................................................................................................119 6

SQL Server Profiler

121

What’s New with SQL Server Profiler .........................................................121 SQL Server Profiler Architecture . ...............................................................122 Creating Traces. ..........................................................................................123 Events.................................................................................................125 Data Columns....................................................................................127 Filters. ................................................................................................130 Executing Traces and Working with Trace Output ....................................132 Saving and Exporting Traces. .....................................................................132 Saving Trace Output to a File ............................................................133 Saving Trace Output to a Table .........................................................134 Saving the Profiler GUI Output.........................................................134 Importing Trace Files . .......................................................................135 Importing a Trace File into a Trace Table..........................................135 Analyzing Trace Output with the Database Engine Tuning Advisor138 Replaying Trace Data ..................................................................................138 Defining Server-Side Traces.........................................................................140 Monitoring Running Traces ..............................................................153 Stopping Server-Side Traces . .............................................................155

Download from www.wowebook.com

viii

Profiler Usage Scenarios ..............................................................................157 Analyzing Slow Stored Procedures or Queries ..................................157 Deadlocks . .........................................................................................158 Identifying Ad Hoc Queries. .............................................................159 Identifying Performance Bottlenecks . ..............................................160 Monitoring Auto-Update Statistics. ..................................................162 Monitoring Application Progress . ....................................................162 Summary .....................................................................................................164 Part III 7

SQL Server Administration SQL Server System and Database Administration

165

What’s New in SQL Server System and Database Administration. ...........165 System Administrator Responsibilities . .....................................................166 System Databases . ......................................................................................166 The master Database..........................................................................167 The resource Database .......................................................................168 The model Database ..........................................................................168 The msdb Database............................................................................168 The distribution Database .................................................................168 The tempdb Database ........................................................................169 Maintaining System Databases..........................................................169 System Tables ..............................................................................................170 System Views...............................................................................................171 Compatibility Views ..........................................................................172 Catalog Views . ..................................................................................175 Information Schema Views ...............................................................177 Dynamic Management Views............................................................179 System Stored Procedures . .........................................................................181 Useful System Stored Procedures.......................................................182 Summary . ...................................................................................................183 8

Installing SQL Server 2008

185

What’s New in Installing SQL Server 2008 ................................................185 Installation Requirements. .........................................................................186 Hardware Requirements ....................................................................186 Software Requirements ......................................................................188 Installation Walkthrough . .........................................................................192 Install Screens, Step by Step ..............................................................192 Other Options Available in the SQL Server Installation Center ......211 Installing SQL Server Using a Configuration File . ....................................212 Running an Automated or Manual Install........................................217

Download from www.wowebook.com

Contents

ix

Installing Service Packs and Cumulative Updates . ...................................218 Installing SP1 from the Command Line ...........................................220 Slipstream Installations. .............................................................................222 Summary . ...................................................................................................225 9

Upgrading to SQL Server 2008

227

What’s New in Upgrading SQL Server. ......................................................227 Using the SQL Server Upgrade Advisor (UA) .............................................228 Getting Started with the UA..............................................................229 The Analysis Wizard . ........................................................................230 The Report Viewer . ...........................................................................235 Destination: SQL Server 2008 or SQL Server 2008 R2 . .............................236 Side-by-Side Migration.......................................................................236 Upgrading In-Place . ..........................................................................242 Upgrading Using a Configuration File . .....................................................250 Slipstreaming Upgrades . ............................................................................251 Upgrading from SQL Server 7 or SQL Server 6.5 ..............................252 Upgrading Other SQL Server Components . ..............................................253 Upgrading Analysis Services ..............................................................253 Upgrading Reporting Services ...........................................................255 Summary .....................................................................................................261 10

Client Installation and Configuration

263

What’s New in Client Installation and Configuration ..............................263 Client/Server Networking Considerations. ................................................264 Server Network Protocols ..................................................................264 The Server Endpoint Layer ................................................................267 The Role of SQL Browser ...................................................................270 Client Installation .......................................................................................271 Installation Requirements .................................................................271 Installing the Client Tools.................................................................271 Installing SNAC . ...............................................................................272 Client Configuration ..................................................................................274 Client Configuration Using SSCM ....................................................275 Connection Encryption. ...................................................................278 Client Data Access Technologies . ..............................................................279 Provider Choices................................................................................280 Driver Choices ...................................................................................281 Connecting Using the Various Providers and Drivers ......................281 General Networking Considerations and Troubleshooting..............287 Summary .....................................................................................................289

Download from www.wowebook.com

x

11

Security and User Administration

291

What’s New in Security and User Administration . ...................................291 An Overview of SQL Server Security . ........................................................292 Authentication Methods. ...........................................................................294 Windows Authentication Mode ........................................................294 Mixed Authentication Mode . ...........................................................294 Setting the Authentication Mode. ....................................................295 Managing Principals . .................................................................................295 Logins.................................................................................................296 SQL Server Security: Users .................................................................298 User/Schema Separation ....................................................................301 Roles . .................................................................................................302 Managing Securables...................................................................................309 Managing Permissions ................................................................................311 Managing SQL Server Logins ......................................................................313 Using SSMS to Manage Logins ..........................................................313 Using T-SQL to Manage Logins . .......................................................317 Managing SQL Server Users . ......................................................................318 Using SSMS to Manage Users ............................................................318 Using T-SQL to Manage Users . .........................................................320 Managing Database Roles . .........................................................................321 Using SSMS to Manage Database Roles.............................................321 Using T-SQL to Manage Database Roles. ..........................................322 Managing SQL Server Permissions . ...........................................................322 Using SSMS to Manage Permissions..................................................323 Using T-SQL to Manage Permissions. ...............................................330 The Execution Context. .............................................................................331 Explicit Context Switching ...............................................................332 Implicit Context Switching . .............................................................333 Summary .....................................................................................................334 12

Data Encryption

335

What’s New in Data Encryption.................................................................336 An Overview of Data Security . ..................................................................336 An Overview of Data Encryption ...............................................................338 SQL Server Key Management......................................................................339 Extensible Key Management .............................................................341 Column-Level Encryption . ........................................................................343 Encrypting Columns Using a Passphrase..........................................344 Encrypting Columns Using a Certificate . ........................................346

Download from www.wowebook.com

Contents

xi

Transparent Data Encryption . ...................................................................350 Implementing Transparent Data Encryption....................................351 Managing TDE in SSMS . ...................................................................352 Backing Up TDE Certificates and Keys. ............................................353 Limitations of TDE . ..........................................................................355 Column-Level Encryption Versus Transparent Data Encryption. .............356 Summary . ...................................................................................................357 13

Security and Compliance

359

Exposure and Risk .......................................................................................360 Across the Life Cycle...................................................................................361 The Security Big Picture ..............................................................................362 Identity Access Management Components................................................364 Compliance and SQL Server .......................................................................366 SQL Server Auditing....................................................................................368 Setting Up Auditing via T-SQL ...................................................................372 SQL Injection Is Easy to Do ........................................................................374 Summary . ...................................................................................................376 14

Database Backup and Restore

377

What’s New in Database Backup and Restore ............................................377 Developing a Backup and Restore Plan . ....................................................378 Types of Backups. .......................................................................................379 Full Database Backups .......................................................................380 Differential Database Backups ...........................................................380 Partial Backups. .................................................................................381 Differential Partial Backups ...............................................................381 File and Filegroup Backups................................................................381 Copy-Only Backups ...........................................................................382 Transaction Log Backups ...................................................................382 Recovery Models .........................................................................................382 Full Recovery......................................................................................383 Bulk-Logged Recovery. ......................................................................384 Simple Recovery. ...............................................................................385 Backup Devices ...........................................................................................385 Disk Devices.......................................................................................386 Tape Devices ......................................................................................386 Network Shares ..................................................................................386 Media Sets and Families ....................................................................387 Creating Backup Devices ...................................................................387

Download from www.wowebook.com

xii

Backing Up a Database . .............................................................................388 Creating Database Backups with SSMS .............................................388 Creating Database Backups with T-SQL . ..........................................390 Backing Up the Transaction Log . ..............................................................393 Creating Transaction Log Backups with SSMS..................................394 Creating Transaction Log Backups with T-SQL. ...............................394 Backup Scenarios. .......................................................................................396 Full Database Backups Only ..............................................................396 Full Database Backups with Transaction Log Backups .....................396 Differential Backups. .........................................................................397 Partial Backups. .................................................................................398 File/Filegroup Backups. .....................................................................400 Mirrored Backups. .............................................................................401 Copy-Only Backups . .........................................................................402 Compressed Backups . .......................................................................402 System Database Backups ..................................................................403 Restoring Databases and Transaction Logs. ...............................................403 Restores with T-SQL ...........................................................................404 Restoring by Using SSMS...................................................................409 Restore Information. .........................................................................411 Restore Scenarios. .......................................................................................414 Restoring to a Different Database .....................................................414 Restoring a Snapshot . .......................................................................416 Restoring a Transaction Log . ............................................................416 Restoring to the Point of Failure . .....................................................417 Restoring to a Point in Time . ...........................................................419 Online Restores. ................................................................................421 Restoring the System Databases ........................................................421 Additional Backup Considerations . ...........................................................423 Frequency of Backups ........................................................................423 Using a Standby Server ......................................................................424 Snapshot Backups ..............................................................................425 Considerations for Very Large Databases..........................................425 Maintenance Plans ............................................................................426 Summary .....................................................................................................426 15

Database Mail

427

What’s New in Database Mail.....................................................................427 Setting Up Database Mail . .........................................................................428 Creating Mail Profiles and Accounts.................................................429 Using T-SQL to Update and Delete Mail Objects..............................432

Download from www.wowebook.com

Contents

xiii

Setting System-wide Mail Settings.....................................................433 Testing Your Setup .............................................................................433 Sending and Receiving with Database Mail . .............................................434 The Service Broker Architecture ........................................................434 Sending Email . ..................................................................................435 Receiving Email . ...............................................................................441 Using SQL Server Agent Mail. ....................................................................441 Job Mail Notifications .......................................................................442 Alert Mail Notifications . ...................................................................443 Related Views and Procedures . ..................................................................445 Viewing the Mail Configuration Objects ..........................................445 Viewing Mail Message Data. .............................................................446 Summary .....................................................................................................448 16

SQL Server Scheduling and Notification

449

What’s New in Scheduling and Notification .............................................450 Configuring the SQL Server Agent . ...........................................................450 Configuring SQL Server Agent Properties .........................................450 Configuring the SQL Server Agent Startup Account ........................452 Configuring Email Notification . ......................................................454 SQL Server Agent Proxy Account . ....................................................455 Viewing the SQL Server Agent Error Log ...................................................456 SQL Server Agent Security . ........................................................................458 Managing Operators . .................................................................................458 Managing Jobs. ...........................................................................................461 Defining Job Properties .....................................................................461 Defining Job Steps .............................................................................462 Defining Multiple Jobs Steps .............................................................464 Defining Job Schedules......................................................................465 Defining Job Notifications ................................................................467 Viewing Job History. .........................................................................468 Managing Alerts ..........................................................................................469 Defining Alert Properties ...................................................................469 Defining Alert Responses...................................................................472 Scripting Jobs and Alerts.............................................................................474 Multiserver Job Management .....................................................................476 Creating a Master Server....................................................................476 Enlisting Target Servers. ....................................................................477 Creating Multiserver Jobs ..................................................................477 Event Forwarding........................................................................................477 Summary . ...................................................................................................479

Download from www.wowebook.com

xiv

17

Administering SQL Server 2008 with PowerShell

481

What’s New with PowerShell......................................................................481 Overview of PowerShell . ............................................................................482 Start Using PowerShell Now..............................................................483 Common Terminology . ....................................................................483 Object-Based Functionality . .............................................................484 SQL Server Management Objects ......................................................484 WMI . .................................................................................................484 Installing PowerShell . .......................................................................485 PowerShell Console . .........................................................................485 Scriptable and Interactive. ................................................................486 Default Security . ...............................................................................486 Execution Policy . ..............................................................................487 Profiles . .............................................................................................487 Built-in Help Features . ......................................................................487 PowerShell Scripting Basics. .......................................................................490 A Few Basic Cmdlets..........................................................................490 Creating a PowerShell Script .............................................................491 Adding Comments . ..........................................................................491 Variables. ...........................................................................................491 Escaping Characters. .........................................................................492 Special Variable $_ . ...........................................................................493 Joining Variables and Strings ............................................................493 Passing Arguments. ...........................................................................494 Using Param. .....................................................................................494 Arrays . ...............................................................................................495 Operators . .........................................................................................496 Conditional Statements.....................................................................496 Functions . .........................................................................................497 Looping Statements . .........................................................................498 Filtering Cmdlets . .............................................................................499 Formatting Cmdlets. .........................................................................500 Dealing with CSV Files ......................................................................501 Dealing with Dates and Times ..........................................................502 -WhatIf/-Confirm Parameters............................................................503 PowerShell in SQL Server 2008. .................................................................503 Adding PowerShell Support...............................................................503 Accessing PowerShell . .......................................................................505 SQL Server PowerShell . .....................................................................506 SQL Provider . ....................................................................................507 SQL Cmdlets . ....................................................................................508 SQL Server Agent Support .................................................................509

Download from www.wowebook.com

Contents

xv

Step-By-Step Examples . ..............................................................................509 General Tasks .....................................................................................509 Scheduling Scripts..............................................................................510 Common OS-Related Tasks................................................................512 SQL Server–Specific Tasks ..................................................................514 Using the Provider .............................................................................515 Creating a Database Table .................................................................515 Performing a Database Backup..........................................................516 Checking Server Settings ...................................................................518 Checking the Database Usage ...........................................................519 Getting Table Properties ....................................................................520 Cmdlet Example: Invoke-SqlCmd .....................................................520 Cmdlet Example: Invoke-PolicyEvaluation ......................................521 Joining Columns................................................................................521 Retrieving an Entry............................................................................522 Summary .....................................................................................................522 18

SQL Server High Availability

523

What’s New in High Availability ................................................................524 What Is High Availability?. ........................................................................525 The Fundamentals of HA. ..........................................................................526 Hardware Factors ...............................................................................527 Backup Considerations ......................................................................527 Operating System Upgrades ..............................................................527 Vendor Agreements Followed............................................................528 Training Kept Up to Date ..................................................................528 Quality Assurance Done Well............................................................528 Standards/Procedures Followed.........................................................528 Server Instance Isolation ...................................................................528 Building Solutions with One or More HA Options. ..................................530 Microsoft Cluster Services (MSCS) ....................................................530 SQL Clustering . .................................................................................531 Data Replication . ..............................................................................534 Log Shipping. ....................................................................................535 Database Mirroring . ..........................................................................537 Combining Failover with Scale-Out Options....................................538 Other HA Techniques That Yield Great Results .........................................538 High Availability from the Windows Server Family Side ..........................540 Microsoft Virtual Server 2005............................................................541 Virtual Server 2005 and Disaster Recovery .......................................542 Summary .....................................................................................................542

Download from www.wowebook.com

xvi

19

Replication

545

What’s New in Data Replication ................................................................546 What Is Replication?. .................................................................................547 The Publisher, Distributor, and Subscriber Magazine Metaphor ...............549 Publications and Articles ...................................................................550 Filtering Articles. ...............................................................................550 Replication Scenarios . ................................................................................555 The Central Publisher Replication Model .........................................555 The Central Publisher with Remote Distributor Replication Model. ....557 The Publishing Subscriber Replication Model ..................................558 The Central Subscriber Replication Model .......................................559 The Multiple Publishers with Multiple Subscribers Replication Model ........................................................559 The Updating Subscribers Replication Model ...................................560 The Peer-to-Peer Replication Model ..................................................561 Subscriptions . .............................................................................................562 Anonymous Subscriptions (Pull Subscriptions) ................................563 The Distribution Database. ...............................................................564 Replication Agents . ....................................................................................565 The Snapshot Agent ..........................................................................566 The Log Reader Agent. ......................................................................569 The Distribution Agent. ....................................................................569 The Merge Agent . .............................................................................570 Other Specialized Agents . .................................................................571 Planning for SQL Server Data Replication . ...............................................572 Autonomy, Timing, and Latency of Data .........................................572 Methods of Data Distribution . .........................................................573 SQL Server Replication Types . ...................................................................574 Snapshot Replication .........................................................................574 Transactional Replication ..................................................................574 Merge Replication . ............................................................................575 Basing the Replication Design on User Requirements. .............................577 Data Characteristics ...........................................................................578 Setting Up Replication . ..............................................................................579 Creating a Distributor and Enabling Publishing ..............................580 Creating a Publication . .....................................................................584 Horizontal and Vertical Filtering. .....................................................592 Creating Subscriptions. .....................................................................594 Scripting Replication...................................................................................600 Monitoring Replication ..............................................................................603 Replication Monitoring SQL Statements...........................................603 Monitoring Replication within SQL Server Management Studio.....606

Download from www.wowebook.com

Contents

xvii

Troubleshooting Replication Failures................................................608 New and Improved Peer-to-Peer Replication ....................................609 The Performance Monitor . ...............................................................610 Replication in Heterogeneous Environments ...................................611 Backup and Recovery in a Replication Configuration......................612 Some Thoughts on Performance .......................................................613 Log Shipping. ....................................................................................614 Data Replication and Database Mirroring for Fault Tolerance and High Availability . ..........................................614 Summary . ...................................................................................................615 20

Database Mirroring

617

What’s New in Database Mirroring . ..........................................................617 What Is Database Mirroring?. ....................................................................618 Copy-on-Write Technology ...............................................................620 When to Use Database Mirroring .....................................................621 Roles of the Database Mirroring Configuration. .......................................621 Playing Roles and Switching Roles....................................................622 Database Mirroring Operating Modes. .............................................622 Setting Up and Configuring Database Mirroring. .....................................623 Getting Ready to Mirror a Database..................................................624 Creating the Endpoints . ...................................................................627 Granting Permissions . ......................................................................629 Creating the Database on the Mirror Server .....................................630 Identifying the Other Endpoints for Database Mirroring ................632 Configuring Database Mirroring by Using the Wizard ....................633 Monitoring a Mirrored Database Environment ................................639 Removing Mirroring . ........................................................................643 Testing Failover from the Principal to the Mirror. ....................................645 Client Setup and Configuration for Database Mirroring...........................647 Migrate to Database Mirroring 2008 as Fast as You Can ...........................649 Using Replication and Database Mirroring Together.................................651 Using Database Snapshots from a Mirror for Reporting............................652 Summary . ...................................................................................................654 21

SQL Server Clustering

655

What’s New in SQL Server Clustering . ......................................................656 How Microsoft SQL Server Clustering Works.............................................656 Understanding MSCS.........................................................................658 Extending MSCS with NLB................................................................662 How MSCS Sets the Stage for SQL Server Clustering........................663

Download from www.wowebook.com

xviii

Installing SQL Server Clustering. ...............................................................665 Configuring SQL Server Database Disks............................................666 Installing Network Interfaces . ..........................................................668 Installing MSCS . ...............................................................................668 Installing SQL Server . .......................................................................668 Failure of a Node . .............................................................................679 The Connection Test Program for a SQL Server Cluster...................681 Potential Problems to Watch Out for with SQL Server Clustering .....684 Summary .....................................................................................................685 22

Administering Policy-Based Management

687

Introduction to Policy-Based Management................................................687 Policy-Based Management Concepts..........................................................689 Facets..................................................................................................689 Conditions .........................................................................................693 Policies ...............................................................................................693 Categories...........................................................................................693 Targets ................................................................................................693 Execution Modes ...............................................................................694 Central Management Servers ............................................................695 Implementing Policy-Based Management. ................................................697 Creating a Condition Based on a Facet.............................................697 Creating a Policy. ..............................................................................699 Creating a Category. .........................................................................701 Evaluating Policies . ...........................................................................702 Importing and Exporting Policies . ...................................................703 Sample Templates and Real-World Examples. ...........................................704 Sample Policy Templates ...................................................................704 Evaluating Recovery Models..............................................................705 Implementing Surface Area Configuration Checks ..........................705 SQL Server Health Checks .................................................................705 Ensuring Object Naming Conventions.............................................706 Checking Best Practices Compliance ................................................706 Policy-Based Management Best Practices ...................................................706 Summary . ...................................................................................................707 Part IV 23

Database Administration Creating and Managing Databases

709

What’s New in Creating and Managing Databases....................................710 Data Storage in SQL Server . .......................................................................710

Download from www.wowebook.com

Contents

xix

Database Files . ............................................................................................711 Primary Files ......................................................................................712 Secondary Files ..................................................................................712 Using Filegroups ................................................................................713 Using Partitions .................................................................................716 Transaction Log Files .........................................................................716 Creating Databases. ....................................................................................717 Using SSMS to Create a Database......................................................718 Using T-SQL to Create Databases . ....................................................721 Setting Database Options. ..........................................................................722 The Database Options .......................................................................723 Using T-SQL to Set Database Options ...............................................725 Retrieving Option Information .........................................................726 Managing Databases . .................................................................................729 Managing File Growth.......................................................................729 Expanding Databases.........................................................................730 Shrinking Databases ..........................................................................731 Moving Databases. ............................................................................736 Restoring a Database Backup to a New Location..............................736 Using ALTER DATABASE....................................................................736 Detaching and Attaching Databases .................................................737 Summary .....................................................................................................740 24

Creating and Managing Tables

741

What’s New in SQL Server 2008.................................................................741 Creating Tables. ..........................................................................................742 Using Object Explorer to Create Tables ............................................742 Using Database Diagrams to Create Tables . .....................................743 Using T-SQL to Create Tables . ..........................................................744 Defining Columns ......................................................................................747 Data Types..........................................................................................747 Column Properties. ...........................................................................755 Defining Table Location .............................................................................761 Defining Table Constraints.........................................................................763 Modifying Tables. .......................................................................................765 Using T-SQL to Modify Tables ...........................................................766 Using Object Explorer and the Table Designer to Modify Tables.....769 Using Database Diagrams to Modify Tables......................................772 Dropping Tables ..........................................................................................773 Using Partitioned Tables .............................................................................774 Creating a Partition Function ...........................................................776 Creating a Partition Scheme..............................................................778 Creating a Partitioned Table. ............................................................779

Download from www.wowebook.com

xx

Adding and Dropping Table Partitions .............................................782 Switching Table Partitions . ...............................................................785 Creating Temporary Tables .........................................................................789 Summary . ...................................................................................................790 25

Creating and Managing Indexes

791

What’s New in Creating and Managing Indexes . .....................................791 Types of Indexes. ........................................................................................792 Clustered Indexes ..............................................................................792 Nonclustered Indexes ........................................................................793 Creating Indexes . .......................................................................................795 Creating Indexes with T-SQL.............................................................795 Creating Indexes with SSMS..............................................................800 Managing Indexes. .....................................................................................803 Managing Indexes with T-SQL ..........................................................803 Managing Indexes with SSMS ...........................................................806 Dropping Indexes .......................................................................................807 Online Indexing Operations.......................................................................807 Indexes on Views ........................................................................................809 Summary . ...................................................................................................810 26

Implementing Data Integrity

811

What’s New in Data Integrity.....................................................................811 Types of Data Integrity . .............................................................................812 Domain Integrity ...............................................................................812 Entity Integrity ..................................................................................812 Referential Integrity...........................................................................812 Enforcing Data Integrity . ...........................................................................812 Implementing Declarative Data Integrity .........................................812 Implementing Procedural Data Integrity . ........................................813 Using Constraints . .....................................................................................813 The PRIMARY KEY Constraint ..........................................................813 The UNIQUE Constraint . .................................................................815 The FOREIGN KEY Referential Integrity Constraint.........................816 The CHECK Constraint . ...................................................................820 Creating Constraints . .......................................................................821 Managing Constraints . .....................................................................827 Rules ............................................................................................................830 Defaults .......................................................................................................831 Declarative Defaults...........................................................................831 Bound Defaults ..................................................................................833 When a Default Is Applied ................................................................833 Restrictions on Defaults.....................................................................835 Summary .....................................................................................................836

Download from www.wowebook.com

Contents

27

Creating and Managing Views in SQL Server

xxi

837

What’s New in Creating and Managing Views . ........................................837 Definition of Views . ...................................................................................837 Using Views. ...............................................................................................839 Simplifying Data Manipulation ........................................................839 Focusing on Specific Data . ...............................................................840 Abstracting Data . ..............................................................................841 Controlling Access to Data. ..............................................................842 Creating Views . ..........................................................................................844 Creating Views Using T-SQL..............................................................845 Creating Views Using the View Designer..........................................849 Managing Views. ........................................................................................852 Altering Views ...................................................................................852 Dropping Views with T-SQL ..............................................................853 Managing Views with SSMS ..............................................................853 Data Modifications and Views. ..................................................................853 Partitioned Views . ......................................................................................854 Modifying Data Through a Partitioned View ...................................858 Distributed Partitioned Views . .........................................................859 Indexed Views . ...........................................................................................860 Creating Indexed Views.....................................................................861 Indexed Views and Performance.......................................................863 To Expand or Not to Expand ............................................................866 Summary .....................................................................................................867 28

Creating and Managing Stored Procedures

869

What’s New in Creating and Managing Stored Procedures.......................869 Advantages of Stored Procedures. ..............................................................870 Creating Stored Procedures. .......................................................................871 Creating Procedures in SSMS.............................................................872 Temporary Stored Procedures. ..........................................................879 Executing Stored Procedures.......................................................................880 Executing Procedures in SSMS ..........................................................881 Execution Context and the EXECUTE AS Clause .............................882 Deferred Name Resolution..........................................................................885 Identifying Objects Referenced in Stored Procedures.......................887 Viewing Stored Procedures . .......................................................................888 Modifying Stored Procedures. ....................................................................891 Viewing and Modifying Stored Procedures with SSMS.....................892 Using Input Parameters . ............................................................................893 Setting Default Values for Parameters ...............................................895 Passing Object Names as Parameters.................................................898

Download from www.wowebook.com

xxii

Using Wildcards in Parameters .........................................................899 Using Table-Valued Parameters . .......................................................901 Using Output Parameters............................................................................902 Returning Procedure Status ........................................................................904 Debugging Stored Procedures Using SQL Server Management Studio ......905 Using System Stored Procedures.................................................................908 Startup Procedures . ....................................................................................911 Summary . ...................................................................................................915 29

Creating and Managing User-Defined Functions

917

What’s New in SQL Server 2008.................................................................917 Why Use User-Defined Functions?. ...........................................................918 Types of User-Defined Functions. ..............................................................921 Scalar Functions.................................................................................921 Table-Valued Functions .....................................................................923 Creating and Managing User-Defined Functions. .....................................925 Creating User-Defined Functions ......................................................925 Viewing and Modifying User-Defined Functions .............................936 Managing User-Defined Function Permissions.................................941 Rewriting Stored Procedures as Functions. ................................................942 Creating and Using CLR Functions ............................................................944 Adding CLR Functions to a Database................................................944 Deciding Between Using T-SQL or CLR Functions . .........................946 Summary .....................................................................................................947 30

Creating and Managing Triggers

949

What’s New in Creating and Managing Triggers .......................................950 Using DML Triggers . ..................................................................................950 Creating DML Triggers.......................................................................951 Using AFTER Triggers. .......................................................................953 Using inserted and deleted Tables.....................................................957 Enforcing Referential Integrity by Using DML Triggers ...................961 Cascading Deletes . ............................................................................963 Cascading Updates. ...........................................................................965 INSTEAD OF Triggers .........................................................................967 Using DDL Triggers . ...................................................................................976 Creating DDL Triggers .......................................................................983 Managing DDL Triggers.....................................................................986 Using CLR Triggers......................................................................................988 Using Nested Triggers .................................................................................991 Using Recursive Triggers .............................................................................992 Summary . ...................................................................................................993

Download from www.wowebook.com

Contents

31

Transaction Management and the Transaction Log

xxiii

995

What’s New in Transaction Management . ................................................995 What Is a Transaction? . .............................................................................995 How SQL Server Manages Transactions. ....................................................996 Defining Transactions . ...............................................................................997 AutoCommit Transactions ................................................................997 Explicit User-Defined Transactions ...................................................998 Implicit Transactions . .....................................................................1003 Implicit Transactions Versus Explicit Transactions.........................1006 Transactions and Batches..........................................................................1007 Transactions and Stored Procedures .........................................................1009 Transactions and Triggers . .......................................................................1014 Triggers and Transaction Nesting ....................................................1015 Triggers and Multistatement Transactions ......................................1017 Using Savepoints in Triggers . .........................................................1019 Transactions and Locking . .......................................................................1021 READ_COMMITTED_SNAPSHOT Isolation ....................................1022 Coding Effective Transactions . ................................................................1022 Transaction Logging and the Recovery Process . .....................................1023 The Checkpoint Process ..................................................................1024 The Recovery Process. .....................................................................1028 Managing the Transaction Log........................................................1032 Long-Running Transactions......................................................................1037 Bound Connections . ................................................................................1039 Distributed Transactions . .........................................................................1040 Summary . .................................................................................................1041 32

Database Snapshots

1043

What’s New with Database Snapshots .....................................................1044 What Are Database Snapshots? . ..............................................................1044 Limitations and Restrictions of Database Snapshots ...............................1048 Copy-on-Write Technology . ....................................................................1050 When to Use Database Snapshots . ..........................................................1051 Reverting to a Snapshot for Recovery Purposes..............................1052 Safeguarding a Database Prior to Making Mass Changes ...............1053 Providing a Testing (or Quality Assurance) Starting Point (Baseline)................................................................1054 Providing a Point-in-Time Reporting Database ..............................1054 Providing a Highly Available and Offloaded Reporting Database from a Database Mirror . ..............................1055 Setup and Breakdown of a Database Snapshot . ......................................1056 Creating a Database Snapshot.........................................................1057 Breaking Down a Database Snapshot..............................................1062

Download from www.wowebook.com

xxiv

Reverting to a Database Snapshot for Recovery. .....................................1062 Reverting a Source Database from a Database Snapshot ................1063 Using Database Snapshots with Testing and QA ............................1064 Setting Up Snapshots Against a Database Mirror. ...................................1064 Reciprocal Principal/Mirror Reporting Configuration ....................1065 Database Snapshots Maintenance and Security Considerations .............1067 Security for Database Snapshots......................................................1067 Snapshot Sparse File Size Management...........................................1067 Number of Database Snapshots per Source Database .....................1067 Summary ...................................................................................................1068 33

Database Maintenance

1069

What’s New in Database Maintenance. ...................................................1070 The Maintenance Plan Wizard . ...............................................................1070 Backing Up Databases......................................................................1072 Checking Database Integrity ...........................................................1075 Shrinking Databases ........................................................................1076 Maintaining Indexes and Statistics .................................................1077 Scheduling a Maintenance Plan......................................................1080 Managing Maintenance Plans Without the Wizard . ..............................1084 Executing a Maintenance Plan . ...............................................................1088 Maintenance Without a Maintenance Plan . ...........................................1089 Database Maintenance Policies . ..............................................................1090 Summary . .................................................................................................1090 Part V 34

SQL Server Performance and Optimization Data Structures, Indexes, and Performance

1091

What’s New for Data Structures, Indexes, and Performance ...................1092 Understanding Data Structures . ..............................................................1093 Database Files and Filegroups . .................................................................1093 Primary Data File .............................................................................1095 Secondary Data Files........................................................................1095 The Log File .....................................................................................1096 File Management .............................................................................1096 Using Filegroups ..............................................................................1097 FILESTREAM Filegroups...................................................................1100 Database Pages . ........................................................................................1101 Page Types........................................................................................1102 Data Pages . ......................................................................................1103 Row-Overflow Pages ........................................................................1109 LOB Data Pages................................................................................1110 Index Pages ......................................................................................1112

Download from www.wowebook.com

Contents

xxv

Space Allocation Structures.......................................................................1113 Extents .............................................................................................1113 Global and Shared Global Allocation Map Pages ...........................1114 Page Free Space Pages ......................................................................1115 Index Allocation Map Pages ............................................................1115 Differential Changed Map Pages.....................................................1116 Bulk Changed Map Pages ................................................................1116 Data Compression.....................................................................................1117 Row-Level Compression ..................................................................1117 Page-Level Compression . ................................................................1119 The CI Record . ................................................................................1122 Implementing Page Compression ...................................................1122 Evaluating Page Compression .........................................................1123 Managing Data Compression with SSMS........................................1126 Understanding Table Structures. ..............................................................1127 Heap Tables ......................................................................................1129 Clustered Tables ...............................................................................1130 Understanding Index Structures. .............................................................1132 Clustered Indexes ............................................................................1133 Nonclustered Indexes ......................................................................1136 Data Modification and Performance . ......................................................1141 Inserting Data ..................................................................................1141 Deleting Rows ..................................................................................1144 Updating Rows.................................................................................1145 Index Utilization .......................................................................................1146 Index Selection..........................................................................................1149 Evaluating Index Usefulness.....................................................................1150 Index Statistics ..........................................................................................1153 The Statistics Histogram ..................................................................1155 How the Statistics Histogram Is Used .............................................1157 Index Densities . ..............................................................................1158 Estimating Rows Using Index Statistics ..........................................1159 Generating and Maintaining Index and Column Statistics ...........1161 SQL Server Index Maintenance . ..............................................................1169 Setting the Fill Factor ......................................................................1179 Reapplying the Fill Factor................................................................1181 Disabling Indexes ............................................................................1182 Managing Indexes with SSMS .........................................................1183 Index Design Guidelines...........................................................................1184 Clustered Index Indications ............................................................1185 Nonclustered Index Indications ......................................................1186 Index Covering . ..............................................................................1188

Download from www.wowebook.com

xxvi

Included Columns ...........................................................................1190 Wide Indexes Versus Multiple Indexes ...........................................1191 Indexed Views ...........................................................................................1192 Indexes on Computed Columns ..............................................................1193 Filtered Indexes and Statistics ..................................................................1195 Creating and Using Filtered Indexes...............................................1196 Creating and Using Filtered Statistics . ...........................................1198 Choosing Indexes: Query Versus Update Performance . .........................1199 Identifying Missing Indexes . ...................................................................1201 The Database Engine Tuning Advisor .............................................1201 Missing Index Dynamic Management Objects...............................1202 Missing Index Feature Versus Database Engine Tuning Advisor ....1203 Identifying Unused Indexes .....................................................................1205 Summary . .................................................................................................1208 35

Understanding Query Optimization

1209

What’s New in Query Optimization.........................................................1210 What Is the Query Optimizer? . ...............................................................1211 Query Compilation and Optimization. ...................................................1212 Compiling DML Statements............................................................1212 Optimization Steps . ........................................................................1213 Query Analysis . ........................................................................................1213 Identifying Search Arguments.........................................................1214 Identifying OR Clauses . ..................................................................1214 Identifying Join Clauses . ................................................................1215 Row Estimation and Index Selection . .....................................................1216 Evaluating SARG and Join Selectivity .............................................1216 Estimating Access Path Cost. ..........................................................1221 Using Multiple Indexes . .................................................................1228 Optimizing with Indexed Views .....................................................1236 Optimizing with Filtered Indexes . .................................................1239 Join Selection . ..........................................................................................1241 Join Processing Strategies ................................................................1241 Determining the Optimal Join Order .............................................1246 Subquery Processing . ......................................................................1248 Execution Plan Selection ..........................................................................1251 Query Plan Caching. ................................................................................1254 Query Plan Reuse.............................................................................1254 Query Plan Aging.............................................................................1256 Recompiling Query Plans ................................................................1257 Monitoring the Plan Cache.............................................................1258 Other Query Processing Strategies. ..........................................................1266 Predicate Transitivity .......................................................................1266

Download from www.wowebook.com

Contents

xxvii

Group by Optimization ...................................................................1267 Queries with DISTINCT ...................................................................1268 Queries with UNION .......................................................................1268 Parallel Query Processing. ........................................................................1268 Parallel Query Configuration Options ............................................1271 Identifying Parallel Queries . ...........................................................1272 Parallel Queries on Partitioned Objects ..........................................1273 Common Query Optimization Problems . ...............................................1274 Out-of-Date or Insufficient Statistics...............................................1274 Poor Index Design . .........................................................................1275 Search Argument Problems . ...........................................................1276 Large Complex Queries . .................................................................1277 Triggers. ...........................................................................................1278 Managing the Optimizer . ........................................................................1278 Optimizer Hints ...............................................................................1280 Forced Parameterization . ................................................................1285 Using the USE PLAN Query Hint ....................................................1287 Using Plan Guides ...........................................................................1290 Limiting Query Plan Execution with the Query Governor ............1298 Summary ...................................................................................................1300 36

Query Analysis

1301

What’s New in Query Analysis .................................................................1302 Query Analysis in SSMS . ..........................................................................1302 Execution Plan ToolTips ..................................................................1304 Logical and Physical Operator Icons...............................................1308 Analyzing Stored Procedures ...........................................................1315 Saving and Viewing Graphical Execution Plans .............................1316 Displaying Execution Plan XML .....................................................1317 Missing Index Hints ........................................................................1317 SSMS Client Statistics................................................................................1322 Using the SET SHOWPLAN Options ........................................................1324 SHOWPLAN_TEXT...........................................................................1324 SHOWPLAN_ALL . ...........................................................................1326 SHOWPLAN_XML . .........................................................................1327 Using sys.dm_exec_query_plan ................................................................1328 Query Statistics . .......................................................................................1330 STATISTICS IO..................................................................................1330 STATISTICS TIME .............................................................................1333 Using datediff() to Measure Runtime..............................................1336 STATISTICS PROFILE........................................................................1337 STATISTICS XML..............................................................................1337

Download from www.wowebook.com

xxviii

Query Analysis with SQL Server Profiler . ................................................1338 Summary . .................................................................................................1340 37

Locking and Performance

1341

What’s New in Locking and Performance................................................1341 The Need for Locking . .............................................................................1342 Transaction Isolation Levels in SQL Server ..............................................1342 Read Uncommitted Isolation ..........................................................1344 Read Committed Isolation . ............................................................1344 Read Committed Snapshot Isolation ..............................................1345 Repeatable Read Isolation. ..............................................................1346 Serializable Read Isolation . .............................................................1346 Snapshot Isolation . .........................................................................1347 The Lock Manager.....................................................................................1349 Monitoring Lock Activity in SQL Server . ................................................1350 Querying the sys.dm_tran_locks View ............................................1350 Viewing Locking Activity with SQL Server Profiler ........................1355 Monitoring Locks with Performance Monitor................................1357 SQL Server Lock Types . ............................................................................1359 Shared Locks ....................................................................................1360 Update Locks ...................................................................................1360 Exclusive Locks ................................................................................1361 Intent Locks .....................................................................................1362 Schema Locks...................................................................................1363 Bulk Update Locks ...........................................................................1363 SQL Server Lock Granularity . ..................................................................1364 Serialization and Key-Range Locking ..............................................1365 Using Application Locks. ................................................................1369 Index Locking . ................................................................................1372 Row-Level Versus Page-Level Locking .............................................1373 Lock Escalation . ..............................................................................1374 Lock Compatibility ...................................................................................1376 Locking Contention and Deadlocks.........................................................1377 Identifying Locking Contention .....................................................1378 Setting the Lock Timeout Interval . ................................................1380 Minimizing Locking Contention ....................................................1381 Deadlocks . .......................................................................................1382 Table Hints for Locking . ..........................................................................1393 Transaction Isolation–Level Hints ...................................................1393 Lock Granularity Hints. ..................................................................1395 Lock Type Hints . .............................................................................1395

Download from www.wowebook.com

Contents

xxix

Optimistic Locking . .................................................................................1396 Optimistic Locking Using the rowversion Data Type.....................1396 Optimistic Locking with Snapshot Isolation . ................................1399 Summary ...................................................................................................1401 38

Database Design and Performance

1403

What’s New in Database Design and Performance . ................................1403 Basic Tenets of Designing for Performance . ............................................1404 Logical Database Design Issues. ...............................................................1405 Normalization Conditions ..............................................................1405 Normalization Forms. .....................................................................1406 Benefits of Normalization ...............................................................1407 Drawbacks of Normalization ...........................................................1407 Denormalizing a Database . ......................................................................1408 Denormalization Guidelines ...........................................................1408 Essential Denormalization Techniques ...........................................1409 Database Filegroups and Performance. ....................................................1415 RAID Technology . ....................................................................................1417 RAID Level 0 ....................................................................................1418 RAID Level 1 ....................................................................................1419 RAID Level 10 ..................................................................................1420 RAID Level 5 ....................................................................................1421 SQL Server and SAN Technology . ............................................................1422 What Is a SAN? ................................................................................1423 SAN Considerations for SQL Server ................................................1423 Summary ...................................................................................................1425 39

Monitoring SQL Server Performance

1427

What’s New in Monitoring SQL Server Performance...............................1428 Performance Monitoring Tools. ...............................................................1429 The Data Collector and the MDW ..................................................1429 SQL Server Utility . ..........................................................................1451 SQL Server Extended Events. ..........................................................1455 Windows Performance Monitor . ....................................................1465 A Performance Monitoring Approach . ....................................................1477 Monitoring the Network Interface ..................................................1478 Monitoring the Processors. .............................................................1480 Monitoring Memory. ......................................................................1485 Monitoring the Disk System ...........................................................1488 Monitoring SQL Server’s Disk Activity............................................1490 Monitoring Other SQL Server Performance Items..........................1492 Summary ...................................................................................................1492

Download from www.wowebook.com

xxx

40

Managing Workloads with the Resource Governor

1493

Overview of Resource Governor ...............................................................1494 Resource Governor Components..............................................................1495 Classification....................................................................................1495 Workload Groups.............................................................................1496 Resource Pools .................................................................................1496 Configuring Resource Governor . .............................................................1498 Enabling Resource Governor ...........................................................1499 Defining Resource Pools . ................................................................1500 Defining Workload Groups . ...........................................................1502 Creating a Classification Function ..................................................1506 Monitoring Resource Usage ......................................................................1509 Modifying Your Resource Governor Configuration .................................1513 Deleting Workload Groups..............................................................1514 Deleting Resource Pools...................................................................1515 Modifying a Classification Function...............................................1516 Summary ...................................................................................................1517 41

A Performance and Tuning Methodology

1519

The Full Architectural Landscape .............................................................1520 Primary Performance and Tuning Handles ..............................................1521 A Performance and Tuning Methodology................................................1522 Designing In Performance and Tuning from the Start ...................1523 Performance and Tuning for an Existing Implementation ............1528 Performance and Tuning Design Guidelines. ..........................................1534 Hardware and Operating System Guidelines ..................................1534 SQL Server Instance Guidelines.......................................................1536 Database-Level Guidelines. .............................................................1537 Table Design Guidelines . ................................................................1537 Indexing Guidelines . ......................................................................1539 View Design Guidelines. .................................................................1541 Transact-SQL Guidelines. ................................................................1541 Application Design Guidelines. ......................................................1545 Distributed Data Guidelines . ..........................................................1546 High-Availability Guidelines . .........................................................1546 Tools of the Performance and Tuning Trade . ..........................................1547 Microsoft Out-of-the-Box ................................................................1547 Third-Party Performance and Tuning Tools....................................1548 Summary ...................................................................................................1550

Download from www.wowebook.com

Contents

xxxi

Chapters on the CD Part VI 42

SQL Server Application Development What’s New for Transact-SQL in SQL Server 2008

1551

MERGE Statement.....................................................................................1552 MERGE Statement Best Practices and Guidelines ...........................1558 Insert over DML . ......................................................................................1559 GROUP BY Clause Enhancements. ..........................................................1561 ROLLUP and CUBE Operator Syntax Changes ...............................1561 GROUPING SETS . ...........................................................................1562 The grouping_id() Function . ..........................................................1565 Variable Assignment in DECLARE Statement ..........................................1568 Compound Assignment Operators. .........................................................1568 Row Constructors. ....................................................................................1569 New date and time Data Types and Functions . ......................................1572 Date and Time Conversions ............................................................1575 Table-Valued Parameters . .........................................................................1576 Table-Valued Parameters Versus Temporary Tables.........................1580 Hierarchyid Data Type . ............................................................................1580 Creating a Hierarchy........................................................................1580 Populating the Hierarchy ................................................................1581 Querying the Hierarchy...................................................................1583 Modifying the Hierarchy .................................................................1587 Using FILESTREAM Storage ......................................................................1592 Enabling FILESTREAM Storage ........................................................1593 Setting Up a Database for FILESTREAM Storage .............................1596 Using FILESTREAM Storage for Data Columns...............................1597 Sparse Columns.........................................................................................1600 Column Sets.....................................................................................1600 Working with Sparse Columns........................................................1601 Sparse Columns: Good or Bad? .......................................................1604 Spatial Data Types .....................................................................................1605 Representing Spatial Data................................................................1606 Working with Geometry Data .........................................................1607 Working with Geography Data .......................................................1609 Spatial Data Support in SSMS..........................................................1611 Spatial Data Types: Where to Go from Here? .................................1614 Change Data Capture ...............................................................................1614 The Change Data Capture Tables....................................................1615 Enabling CDC for a Database. ........................................................1617 Enabling CDC for a Table. ..............................................................1617

Download from www.wowebook.com

xxxii

Querying the CDC Tables................................................................1619 CDC and DDL Changes to Source Tables .......................................1626 Change Tracking . .....................................................................................1627 Implementing Change Tracking .....................................................1628 Identifying Tracked Changes. .........................................................1630 Identifying Changed Columns........................................................1633 Change Tracking Overhead . ...........................................................1634 Summary ...................................................................................................1635 43

Transact-SQL Programming Guidelines, Tips, and Tricks

1637

General T-SQL Coding Recommendations. .............................................1638 Provide Explicit Column Lists.........................................................1638 Qualify Object Names with a Schema Name..................................1640 Avoid SQL Injection Attacks When Using Dynamic SQL ..............1643 Comment Your T-SQL Code ............................................................1652 General T-SQL Performance Recommendations . ....................................1653 UNION Versus UNION ALL Performance .......................................1654 Use IF EXISTS Instead of SELECT COUNT(*) ..................................1654 Avoid Unnecessary ORDER BY or DISTINCT Clauses ....................1654 Temp Tables Versus Table Variables Versus Common Table Expressions ..........................................................1654 Avoid Unnecessary Function Executions ........................................1656 Cursors and Performance . ..............................................................1656 Variable Assignment in UPDATE Statements..................................1659 T-SQL Tips and Tricks. ..............................................................................1663 Date Calculations ............................................................................1663 Sorting Results with the GROUPING Function ..............................1669 Using CONTEXT_INFO ...................................................................1671 Working with Outer Joins ...............................................................1673 Generating T-SQL Statements with T-SQL ......................................1682 Working with @@ERROR and @@ROWCOUNT..............................1683 De-Duping Data with Ranking Functions.......................................1684 In Case You Missed It: New Transact-SQL Features in SQL Server 2005 .....1687 The xml Data Type . .................................................................................1687 The max Specifier. ....................................................................................1688 TOP Enhancements . ................................................................................1689 The OUTPUT Clause . ...............................................................................1693 Common Table Expressions . ...................................................................1698 Recursive Queries with CTEs ...........................................................1700 Ranking Functions . ..................................................................................1708 The ROW_NUMBER Function.........................................................1708 The RANK and DENSE_RANK Functions ........................................1711

Download from www.wowebook.com

Contents

xxxiii

The NTILE Function ........................................................................1712 Using Row Numbers for Paging Results ..........................................1714 PIVOT and UNPIVOT ...............................................................................1718 The APPLY Operator . ...............................................................................1722 CROSS APPLY...................................................................................1722 OUTER APPLY . ................................................................................1723 TRY...CATCH Logic for Error Handling . ..................................................1724 The TABLESAMPLE Clause. ......................................................................1727 Summary . .................................................................................................1731 44

Advanced Stored Procedure Programming and Optimization

1733

T-SQL Stored Procedure Coding Guidelines. ...........................................1733 Calling Stored Procedures from Transactions .................................1735 Handling Errors in Stored Procedures . ...........................................1738 Using Source Code Control with Stored Procedures ......................1741 Using Cursors in Stored Procedures . .......................................................1743 Using CURSOR Variables in Stored Procedures ..............................1748 Nested Stored Procedures. ........................................................................1753 Recursive Stored Procedures ............................................................1755 Using Temporary Tables in Stored Procedures .........................................1759 Temporary Table Performance Tips .................................................1760 Using the table Data Type ...............................................................1762 Using Remote Stored Procedures ..............................................................1764 Stored Procedure Performance. ................................................................1764 Query Plan Caching ........................................................................1765 The SQL Server Plan Cache .............................................................1766 Shared Query Plans. ........................................................................1766 Automatic Query Plan Recompilation ............................................1767 Forcing Recompilation of Query Plans ...........................................1770 Using Dynamic SQL in Stored Procedures . .............................................1774 Using sp_executesql.........................................................................1776 Installing and Using .NET CLR Stored Procedures...................................1779 Adding CLR Stored Procedures to a Database.................................1780 T-SQL or CLR Stored Procedures?. ..................................................1781 Using Extended Stored Procedures . .........................................................1782 Adding Extended Stored Procedures to SQL Server ........................1782 Obtaining Information on Extended Stored Procedures ................1783 Extended Stored Procedures Provided with SQL Server .................1783 Using xp_cmdshell . ........................................................................1784 Summary ...................................................................................................1786

Download from www.wowebook.com

xxxiv

45

SQL Server and the .NET Framework

1787

What’s New in SQL Server 2008 and the .NET Framework . ...................1787 Getting Comfortable with ADO.NET 3.5 and SQL Server 2008 ..............1788 ADO.NET: Advanced Basics .............................................................1788 Developing with LINQ to SQL .................................................................1793 Getting Started.................................................................................1793 Going Deeper...................................................................................1796 Uncovering LINQ to SQL with Linqpad .........................................1798 Using ADO.NET Data Services. ................................................................1803 Getting Set Up .................................................................................1803 Essentials . ........................................................................................1803 Building Your Data Service ..............................................................1806 CRUD Operations ............................................................................1811 Leveraging the Microsoft Sync Framework . ............................................1816 Getting Started with MSF and Sync Services for ADO.NET............1817 Building Our Example OCA . ..........................................................1818 Summary ...................................................................................................1823 46

SQLCLR: Developing SQL Server Objects in .NET

1825

What’s New for SQLCLR in SQL Server 2008. .........................................1825 Developing Custom Managed Database Objects . ...................................1825 An Introduction to Custom Managed Database Objects................1826 Managed Object Permissions . ........................................................1827 Developing Managed Objects with Visual Studio 2008 .................1829 Developing Managed Stored Procedures. .......................................1830 Developing Managed User-Defined Functions (UDFs) . .................1835 Developing Managed User-Defined Types (UDTs). ........................1844 Developing Managed User-Defined Aggregates (UDAs) . ...............1853 Developing Managed Triggers . .......................................................1856 Using Transactions. .........................................................................1861 Using the Related System Catalogs . ...............................................1863 Summary ...................................................................................................1864 47

Using XML in SQL Server 2008

1865

What’s New in Using XML in SQL Server 2008.......................................1865 Understanding XML . ...............................................................................1866 Relational Data As XML: The FOR XML Modes. .....................................1866 RAW Mode .......................................................................................1867 AUTO Mode .....................................................................................1873 EXPLICIT Mode ...............................................................................1877 PATH Mode ......................................................................................1881

Download from www.wowebook.com

Contents

xxxv

FOR XML and the xml Data Type...................................................1884 XML As Relational Data: Using OPENXML . ...........................................1887 Using the xml Data Type . ........................................................................1890 Defining and Using xml Columns ..................................................1892 Using XML Schema Collections. ....................................................1894 The Built-in xml Data Type Methods .............................................1899 Indexing and Full-Text Indexing of xml Columns . ................................1918 Indexing xml Columns ...................................................................1918 Full-Text Indexing. ..........................................................................1924 Summary ...................................................................................................1925 48

SQL Server Web Services

1927

What’s New in SQL Server Web Services . ................................................1927 Web Services Migration Path . ..................................................................1928 Web Services History and Overview. .......................................................1928 The Web Services Pattern ................................................................1929 Building Web Services. .............................................................................1930 The AS HTTP Keyword Group .........................................................1934 The FOR SOAP Keyword Group ......................................................1938 Examples: A C# Client Application . ........................................................1942 Example 1: Running a Web Method Bound to a Stored Procedure from C# .............................................................1942 Example 2: Running Ad Hoc T-SQL Batches from a SQL Server Web Service .....................................................1947 Example 3: Calling a Web Method–Bound Stored Procedure That Returns XML. ......................................................1951 Using Catalog Views and System Stored Procedures ...............................1954 Controlling Access Permissions . ..............................................................1955 Summary . .................................................................................................1957 49

SQL Server Service Broker

1959

What’s New in Service Broker...................................................................1959 Understanding Distributed Messaging .....................................................1960 The Basics of Service Broker ............................................................1960 Designing a Sample System . ....................................................................1964 Understanding Service Broker Constructs. ..............................................1965 Defining Messages and Choosing a Message Type .........................1965 Setting Up Contracts for Communication. ....................................1970 Creating Queues for Message Storage . ...........................................1970 Defining Services to Send and Receive Messages. ..........................1973 Planning Conversations Between Services. ....................................1974 Service Broker Routing and Security . ......................................................1985

Download from www.wowebook.com

xxxvi

Using Certificates for Conversation Encryption.............................1985 A Final Note on the Sample System. ..............................................1992 Troubleshooting SSB Applications with ssbdiagnose.exe . ......................1993 Related System Catalogs . .........................................................................1994 Summary . .................................................................................................1996 50

SQL Server Full-Text Search

1997

What’s New in SQL Server 2008 Full-Text Search ....................................1998 Upgrade Options in SQL Server 2008. .....................................................1998 How SQL Server FTS Works . ....................................................................1999 Indexing...........................................................................................1999 Searching. ........................................................................................2001 Implementing SQL Server 2008 Full-Text Catalogs .................................2002 Setting Up a Full-Text Index . ...................................................................2003 Using T-SQL Commands to Build Full-Text Indexes and Catalogs . ...2003 Using the Full-Text Indexing Wizard to Build Full-Text Indexes and Catalogs . ...................................................2017 Full-Text Searches. ....................................................................................2020 CONTAINS and CONTAINSTABLE ..................................................2020 FREETEXT and FREETEXTTABLE. ...................................................2023 Full-Text Search Maintenance...................................................................2024 Full-Text Search Performance . .................................................................2025 Full-Text Search Troubleshooting . ...........................................................2026 Summary . .................................................................................................2028 Part VII 51

SQL Server Business Intelligence Features SQL Server 2008 Analysis Services

2029

What’s New in SSAS ..................................................................................2029 Understanding SSAS and OLAP ................................................................2030 Understanding the SSAS Environment Wizards ......................................2032 OLAP Versus OLTP...........................................................................2036 An Analytics Design Methodology. .........................................................2038 An Analytics Mini-Methodology.....................................................2038 An OLAP Requirements Example: CompSales International...................2040 CompSales International Requirements..........................................2040 OLAP Cube Creation . .....................................................................2042 Using SQL Server BIDS . ..................................................................2042 Creating an OLAP Database . ..........................................................2044 Generating a Relational Database . .................................................2081 Cube Perspectives . ..........................................................................2082 KPIs . ................................................................................................2082

Download from www.wowebook.com

Contents

xxxvii

Data Mining.....................................................................................2083 Security and Roles............................................................................2095 Summary ...................................................................................................2097 52

SQL Server Integration Services

2099

What’s New with SSIS ...............................................................................2100 SSIS Basics. ................................................................................................2100 SSIS Architecture and Concepts................................................................2105 SSIS Tools and Utilities . ...........................................................................2110 A Data Transformation Requirement .......................................................2113 Running the SSIS Wizard ..........................................................................2115 The SSIS Designer. ....................................................................................2126 The Package Execution Utility. ................................................................2135 The dtexec Utility ............................................................................2135 Running Packages ............................................................................2137 Running Package Examples.............................................................2140 The dtutil Utility. ............................................................................2141 dtutil Examples . ..............................................................................2144 Connection Projects in Visual Studio. .....................................................2145 Change Data Capture Addition with R2 ..................................................2147 Using bcp . ................................................................................................2147 Fundamentals of Exporting and Importing Data . .........................2151 File Data Types. ...............................................................................2153 Format Files. ....................................................................................2153 Using Views . ...................................................................................2163 Logged and Nonlogged Operations. ........................................................2163 Batches .............................................................................................2164 Parallel Loading ...............................................................................2164 Supplying Hints to bcp....................................................................2165 Summary ...................................................................................................2167 53

SQL Server 2008 Reporting Services

2169

What’s New in SSRS 2008 .........................................................................2169 Discontinued Functionality and Breaking Changes .......................2170 Enhancements . ...............................................................................2172 Tool and Service Enhancements . ...................................................2176 SharePoint Integration Improvements. ..........................................2177 Service Changes and Improvements . .............................................2178 Programming Enhancements . ........................................................2178 Reporting Services Architecture ................................................................2179 Installing and Configuring SSRS...............................................................2182 The Installation Sequence ...............................................................2182

Download from www.wowebook.com

xxxviii

SSRS Configuration Using RSCM ....................................................2186 Developing Reports. .................................................................................2190 Tools of the Trade ............................................................................2190 Report Basics . ..................................................................................2191 Overview of the Report Development Process ...............................2192 Data Planning and Preparation.......................................................2193 Using Shared Data Sources ..............................................................2193 Using Datasets .................................................................................2193 Using Shared Datasets .....................................................................2194 Developing Reports Using BIDS ......................................................2196 Working with the Tablix .................................................................2199 Understanding Expressions .............................................................2200 Report Design Fundamentals ..........................................................2202 Using the Data Visualization Controls: Sparkline, Indicator, and Data Bar .................................................................2204 Designing Reports Using Report Builder.........................................2213 Report Builder and Report Model Security .....................................2233 Enabling Report Builder ..................................................................2233 Management and Security . ......................................................................2234 Securing Reports ..............................................................................2234 Subscriptions. ..................................................................................2235 Report Execution Options ...............................................................2237 Performance and Monitoring . .................................................................2239 SSRS Trace Log .................................................................................2239 Execution Log . ................................................................................2240 Windows Event Log.........................................................................2240 Performance Counters .....................................................................2240 Summary ...................................................................................................2241 Part VIII 54

Bonus Chapters Managing Linked and Remote Servers

2243

What’s New in Managing Linked and Remote Servers ............................2244 Managing Remote Servers. .......................................................................2244 Remote Server Setup ........................................................................2246 Linked Servers . .........................................................................................2251 Distributed Queries..........................................................................2252 Distributed Transactions..................................................................2252 Adding, Dropping, and Configuring Linked Servers . .............................2253 sp_addlinkedserver . ........................................................................2253 sp_linkedservers . .............................................................................2260 sp_dropserver . .................................................................................2261 sp_serveroption. ..............................................................................2261

Download from www.wowebook.com

Contents

xxxix

Mapping Local Logins to Logins on Linked Servers . ..............................2263 sp_addlinkedsrvlogin. .....................................................................2263 sp_droplinkedsrvlogin . ...................................................................2265 sp_helplinkedsrvlogin. ....................................................................2266 Obtaining General Information About Linked Servers. ..........................2267 Executing a Stored Procedure via a Linked Server . .................................2268 Setting Up Linked Servers Using SQL Server Management Studio..........2269 Summary . .................................................................................................2272 55

Configuring, Tuning, and Optimizing SQL Server Options

2273

What’s New in Configuring, Tuning, and Optimizing SQL Server Options .............................................................2274 SQL Server Instance Architecture . ...........................................................2274 Configuration Options . ...........................................................................2275 Fixing an Incorrect Option Setting . ........................................................2283 Setting Configuration Options with SSMS...............................................2283 Obsolete Configuration Options . ............................................................2283 Configuration Options and Performance. ...............................................2284 access check cache bucket count ....................................................2284 access check cache quota . ..............................................................2285 ad hoc distributed queries . .............................................................2285 affinity I/O mask . ...........................................................................2286 affinity mask . ..................................................................................2287 Agent XP . ........................................................................................2289 awe enabled . ...................................................................................2289 backup compression default. ..........................................................2291 blocked process threshold . .............................................................2291 c2 audit mode . ................................................................................2291 clr enabled . .....................................................................................2292 common criteria compliance enabled . ..........................................2292 cost threshold for parallelism. ........................................................2293 cross db ownership chaining...........................................................2293 cursor threshold. .............................................................................2294 default full-text language . ..............................................................2294 default language . ............................................................................2296 EKM provider enabled . ...................................................................2298 filestream_access_level. ...................................................................2299 fill factor . ........................................................................................2299 index create memory. .....................................................................2300 in-doubt xact resolution. ................................................................2300 lightweight pooling . .......................................................................2301 locks . ...............................................................................................2301

Download from www.wowebook.com

xl

max degree of parallelism ...............................................................2302 max server memory and min server memory ................................2302 max text repl size. ...........................................................................2304 max worker threads . .......................................................................2305 min memory per query ...................................................................2306 nested triggers. ................................................................................2306 network packet size . .......................................................................2306 optimize for ad hoc workloads........................................................2307 PH_timeout . ....................................................................................2308 priority boost . .................................................................................2308 query governor cost limit ................................................................2309 query wait . ......................................................................................2310 recovery interval . ............................................................................2310 remote admin connections .............................................................2311 remote login timeout . ....................................................................2311 remote proc trans . ..........................................................................2312 remote query timeout. ....................................................................2312 scan for startup procs ......................................................................2313 show advanced options ...................................................................2313 user connections. ............................................................................2313 user options . ...................................................................................2315 XP-Related Configuration Options .................................................2316 Database Engine Tuning Advisor. ............................................................2317 The Database Engine Tuning Advisor GUI .....................................2317 The Database Engine Tuning Advisor Command Line ..................2321 Data Collection Sets..................................................................................2326 Summary . .................................................................................................2328 56

SQL Server Disaster Recovery Planning

2329

What’s New in SQL Server Disaster Recovery Planning...........................2330 How to Approach Disaster Recovery . ......................................................2330 Disaster Recovery Patterns...............................................................2332 Recovery Objectives. .......................................................................2336 A Data-Centric Approach to Disaster Recovery ..............................2337 Microsoft SQL Server Options for Disaster Recovery . .............................2338 Data Replication ..............................................................................2338 Log Shipping....................................................................................2339 Database Mirroring and Snapshots .................................................2341 The Overall Disaster Recovery Process . ...................................................2342 The Focus of Disaster Recovery .......................................................2342 sqldiag.exe . .....................................................................................2347 Planning and Executing a Disaster Recovery..................................2349

Download from www.wowebook.com

Contents

xli

Have You Detached a Database Recently?................................................2350 Third-Party Disaster Recovery Alternatives . ............................................2350 Summary . .................................................................................................2351 Index

2353

Download from www.wowebook.com

xlii

About the Authors Ray Rankins is owner and president of Gotham Consulting Services, Inc. (www.gothamconsulting.com), near Saratoga Springs, New York. Ray has been working with Sybase and Microsoft SQL Server for more than 23 years and has experience in database administration, database design, project management, application development, consulting, courseware development, and training. He has worked in a variety of industries, including financial, manufacturing, health care, retail, insurance, communications, public utilities, and state and federal government. His expertise is in database performance and tuning, query analysis, advanced SQL programming and stored procedure development, database design, data architecture, and database application design and development. Ray’s presentations on these topics at user group conferences have been very well received. Ray is coauthor of Microsoft SQL Server 2005 Unleashed, Microsoft SQL Server 2000 Unleashed (first and second editions), Microsoft SQL Server 6.5 Unleashed (all editions), Sybase SQL Server 11 Unleashed, and Sybase SQL Server 11 DBA Survival Guide, Second Edition, all published by Sams Publishing. As an instructor, Ray brings his real-world experience into the classroom, teaching classes on SQL, advanced SQL programming and optimization, database design, database administration, and database performance and tuning. Ray can be reached at [email protected]. Paul Bertucci is the founder of Database Architechs (www.dbarchitechs.com), a global database consulting firm with offices in the United States and Paris, France. He has more than 30 years of experience with database design, data architecture, data replication, performance and tuning, master data management (MDM), data provenance/digital DNA, distributed data systems, data integration, high availability, and systems integration for numerous Fortune 500 companies, including Intel, 3COM, Coca-Cola, Apple, Toshiba, Lockheed, Wells Fargo, Safeway, Sony, Charles Schwab, Cisco, Sybase, Symantec, Veritas, and Honda, to name a few. He has authored numerous database articles, data standards, and high-profile database courses, such as Sybase’s “Performance and Tuning” and “Physical Database Design” courses. Other Sams Publishing books that he has authored or coauthored include the highly popular Microsoft SQL Server 2000 Unleashed, ADO.NET in 24 Hours, Microsoft SQL Server High Availability, and Microsoft SQL Server 2005 Unleashed. Paul is a frequent speaker at industry conferences such as Informatica World, Oracle World, MDM Summits, and Microsoft-oriented conferences such as SQL Saturday’s, PASS conferences, Tech Ed’s, and SQL Server User Groups. He has deployed numerous systems with Microsoft SQL Server, Sybase, DB2, Postgres, MySQL, and Oracle database engines, and he has designed/architected several commercially available tools in the database, data modeling, performance and tuning, data integration, digital DNA, and multidimensional planning spaces. Formerly the Chief Data Architect at Symantec, Paul’s current working arrangement is as Autodesk’s Chief Enterprise Architect. Paul received his formal education in computer science and electrical engineering from the University of California, Berkeley (Go Bears!). He lives in the great Pacific northwest (Oregon) with his five children, Donny, Juliana, Nina, Marissa, and Paul Jr. Paul can be reached at [email protected] or [email protected].

Download from www.wowebook.com

Contents

xliii

Chris Gallelli is the president of CGAL Consulting Services, Inc. His company focuses on consulting services in the areas of database administration, database tuning, and database programming using Microsoft Visual Studio. Chris has more than 15 years of experience with SQL Server and more than 25 years in the field of information technology. He has a bachelor’s degree in electrical engineering and a master’s degree in business administration from Union College. Chris currently lives near Albany, New York, with his lovely wife, Laura, and two daughters, Rachael and Kayla. Other Sams Publishing books that he has coauthored include Microsoft SQL Server 2000 Unleashed and Microsoft SQL Server 2005 Unleashed. Chris can be reached at [email protected]. Alex T. Silverstein is owner and chief information officer of Unified Digital Group, LLC, a consulting and custom software development firm headquartered near Saratoga Springs, New York. He specializes in designing SQL Server and Microsoft .NET–powered solutions using the principles of agile development and the Rational Unified Process. Alex has more than a decade of experience providing application development, database administration, and training services worldwide to a variety of industries. He was also a coauthor for Microsoft SQL Server 2005 Unleashed and a contributing author for Microsoft SQL Server 2000 Unleashed, both published by Sams Publishing. You can reach Alex anytime via email at [email protected].

About the Contributing Author Hilary Cotter is a SQL Server MVP with more than 20 years of IT experience working for Fortune 500 clients. He is the author of a book on SQL Server Replication and coauthor of Microsoft SQL Server 2008 Management and Administration from Sams Publishing. Hilary has also written numerous white papers and articles on SQL Server and databases.

Download from www.wowebook.com

xliv

Dedication I would like to dedicate this book in loving memory of my grandmother, Gertrude Holdridge, who recently passed away at the “young” age of 87. You will be dearly missed, “Gramma Gert.” —Ray Rankins Dedicated to my children, for the countless times they heard me say “No, not now, I’m writing chapters!” Thanks, Paul Jr., Marissa, Nina, Juliana, and Donny; I love you all very much! —Paul Bertucci This book is dedicated to my Mom and Dad. My mother, Arlene Gallelli, is the perfect mom. Her love, kindness, and relentless support have helped me in all aspects of my life, including the creation of this book. My Dad, Joe Gallelli, is a great father and a great friend. He is an encyclopedia of knowledge, and I can always count on his wisdom and guidance. Thank you both. —Chris Gallelli My work on this book is dedicated to my father, Harry Silverstein, a fellow man of letters. For, while his stay with us on this planet was not nearly long enough, he left us with a feeling of kindness and a call to humanity and fellowship with all that has remained for a lifetime. Thank you, Harry, for having been you. —Alex T. Silverstein

Download from www.wowebook.com

Contents

xlv

Acknowledgments I would first like to thank my coauthors for their tireless efforts in helping to turn out a quality publication and their willingness to take on more work when needed to help keep things on track. I would also like to thank Neil Rowe at Sams Publishing for providing us the opportunity to write this book and for his seemingly infinite patience as we repeatedly missed our deadlines. I would also like to acknowledge my colleague and friend David Solomon for developing the Word macro used to extract the code listings and examples presented in the chapters so we could make them available on the included CD. His efforts made that task significantly easier. I would also like to thank David for his help reviewing some of my chapters. I would also like to acknowledge and thank Ross Mistry for providing content for the “Administering Policy Based Management” and “Automating SQL Server Tasks Using PowerShell” chapters. Most of all, I wish to thank my loving wife, Elizabeth, for her patience and understanding during the long days, late nights, and lost weekends spent working on yet another book. I’ll be getting to that “honey-do” list now, my dear. —Ray Rankins With any writing effort, there is always a huge sacrifice of time that must be made to properly research, demonstrate, and describe leading-edge subject matter. The brunt of the burden usually falls on those many people who are near and very dear to me. With this in mind, I desperately need to thank my family for allowing me to encroach on many months of what should have been my family’s “quality time.” However, with sacrifice also comes reward in the form of technical excellence and highquality business relationships. Many individuals were involved in this effort, both directly and indirectly, starting with the other authors (thanks RR, CG, and AS!), Steve Luk, Raymond Hardman, Jason Riedberger, John Martin, Gene Vilain, Yves Moison, Thierry Gerardin, Mark Ginnebaugh (of DesignMind), and Nathan Gustafson. Their expertise in and knowledge of database engines, SQL, performance and tuning, data replication, database mirroring, database snapshots, business intelligence, data integration, and high availability are unmatched. —Paul Bertucci Writing a book of this size and scope requires a tremendous amount of time and dedication. The time and dedication apply not only to the authors who are writing the book but also to their family members. My wife and daughters were very understanding while I was holed up working on this book, and that understanding helped make the book happen. My love and thanks to them. I would also like to thank many of my clients who embraced SQL Server 2008 and gave me the opportunity to use it in the real world. In particular, I would like to thank Ray McQuade and his company, Spruce Computer Systems. Spruce has had tremendous success with SQL Server 2005 and SQL Server 2008. —Chris Gallelli I would like to acknowledge the following people for helping make my contribution to this book possible: Ray Rankins, Paul Bertucci, Chris Gallelli, Neil Rowe, Gregory Abbruzzese, Frank Esposito, Jonathan Rubenstein, Linda Motzkin, Lane McCarthy, Bob

Download from www.wowebook.com

xlvi

Barter, Amatzia Segal, all the wonderful customers who keep Unified Digital in business, and, most importantly, El Shaddai. You all are the sine qua non of my world, and I thank you most heartily. —Alex T. Silverstein

We Want to Hear from You! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass our way. You can email or write me directly to let me know what you did or didn’t like about this book—as well as what we can do to make our books stronger. Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message. When you write, please be sure to include this book’s title and author as well as your name and phone or email address. I will carefully review your comments and share them with the author and editors who worked on the book. E-mail:

[email protected]

Mail:

Neil Rowe Executive Editor Sams Publishing 800 East 96th Street Indianapolis, IN 46240 USA

Reader Services Visit our website and register this book at informit.com/register for convenient access to any updates, downloads, or errata that might be available for this book.

Download from www.wowebook.com

Introduction Over the past decade, SQL Server has established itself as a robust and reliable database platform whose performance, scalability, and reliability meet the implementation needs of businesses and corporations from small desktop applications on up to multiterabyte enterprise-wide systems. The updates and enhancements in SQL Server 2008 and SQL Server 2008 R2 further solidify its position in the marketplace as a robust enterprise-wide database system that can compete on the same level as the other major enterprise-wide database products, providing a database engine foundation that can be highly available 7 days a week, 365 days a year.

NOTE The position of SQL Server 2008 as a leader in the market of enterprise-wide database management systems (DBMS) was confirmed in a report released by Forrester Research on June 30, 2009 (The Forrester Wave: Enterprise Database Management Systems, Q2 2009). In this report, Forrester analyst Noel Yuhanna indicated that Microsoft along with Oracle and IBM DB2 were the leaders in the DBMS market. The report from Forrester Research indicated that Microsoft’s strong commitment to its data platform starting with SQL Server 2005 and continuing with the latest iteration of the product, SQL Server 2008, had boosted Microsoft to the top of the DBMS market. Key findings in the report concluded that Microsoft received high scores in database programmability, security, availability, and application/data integration, and for delivering the best price performance for most business applications. The report also acknowledged that Microsoft “has shown increasing focus and commitment to going after the enterprise market,” and that SQL Server 2008 has “enabled Microsoft to take market share in moderately sized to large enterprises, delivering good performance, scalability, security, and availability functionality.” The report also indicated that “five years ago, hardly any enterprises ran multi-terabyte databases with SQL Server to support critical applications. Today, hundreds of enterprises are running 10-terabyte and larger transactional SQL Server databases.”

One of the biggest challenges we face writing the SQL Server Unleashed series of books is how to provide comprehensive, in-depth, all-inclusive coverage of all the features of SQL Server within a single book. Over the past few releases, the number of SQL Server features and components has increased, and many of these features and components (for example, SQL Server Integration Services, Reporting Services, and .NET Framework integration) provide material enough to warrant their own separate titles. To cover each topic sufficiently would require more information than could reasonably fit in print in a single volume. Thus, we had to make some hard decisions as to what to include in print. We decided that the printed portion of the book would provide detailed coverage of the core database server features and the day-to-day administrative and management aspects

Download from www.wowebook.com

2

Microsoft SQL Server 2008 R2 Unleashed

and tools of SQL Server 2008 and 2008 R2. We want to ensure that we provide enough of the necessary information, tips, and guidelines to get you started making effective use of these features. At the same time, there is a wealth of useful information we want to provide on additional SQL Server 2008 features and major components of SQL Server, such as SQL Server Integration Services, Reporting Services, Analysis Services, T-SQL programming, and SQL Server integration with the .NET Framework. Rather than leave this valuable information out entirely, we decided to include the chapters with this material on the CD provided with this book. Also, as in the past, the CD contains all our sample scripts, databases, and other code samples and material that support the book content. Our other main goal when writing this book was for it to be more than just a syntax reference. SQL Server Books Online is a fine resource as a syntax reference. This book attempts to pick up where Books Online leaves off, by providing, in addition to syntax where necessary, valuable insight, tips, guidelines, and useful examples derived from our many years of experience working with SQL Server. Although we do provide the core, and sometimes advanced, syntax elements for the SQL commands discussed, SQL Server Books Online provides a much more extensive syntax reference than would make sense to try to duplicate here. As a matter of fact, at times, we may even direct you to Books Online for more detail on some of the more esoteric syntax options available for certain commands. We hope that we have succeeded in meeting the goals we set out for this book and that it becomes an essential reference and source of expert information for you as you work with the either version of SQL Server 2008.

NOTE Although this book includes coverage of SQL Server 2008 R2, most of the material presented applies to SQL Server 2008 as well. Actually, there are few significant differences in the core product between SQL Server 2008 and SQL Server 2008 R2. Most of the new features are related to enhancements to Reporting Services. You can be comfortable using this book as a reference for either version of SQL Server 2008. When the book discusses features available only in the R2 release, this fact is specifically spelled out in the chapter.

Who This Book Is For This Unleashed book is intended for intermediate- to advanced-level users: for SQL Server administrators who want to understand SQL Server more completely to be able to effectively manage and administer their SQL Server environments, and for developers who want a more thorough understanding of SQL Server to help them write better TransactSQL (T-SQL) code and develop more robust SQL Server applications. If you are responsible for analysis, design, implementation, support, administration, or troubleshooting of SQL Server 2008, this book provides an excellent source of experiential information for you. You can think of this as a book of applied technology. The emphasis is on the more

Download from www.wowebook.com

Introduction

3

complex aspects of the product, including using the new tools and features, administering SQL Server, analyzing and optimizing queries, implementing data warehouses, ensuring high availability, and tuning SQL Server performance. This book is for both developers and SQL Server administrators who are new to SQL Server 2008 or SQL Server 2008 R2 as well as those who are already familiar with prior versions of SQL Server. At the beginning of each chapter is a brief summary of the major changes or new features or capabilities of SQL Server related to that topic. If you are already familiar with SQL Server, you can use this information to focus on the information in the chapters that covers the new features and capabilities in more detail. This book is intended to provide a behind-the-scenes look into SQL Server, showing you what goes on behind the various wizards and GUI-based tools so you can learn what the underlying SQL commands are. Although the GUI tools can make your average day-today operations much simpler, every database administrator should learn the underlying commands to the tools and wizards to fully unlock the power and capabilities of SQL Server.

What This Book Covers The book is divided into the following sections: . Part I, “Welcome to Microsoft SQL Server”—This part introduces you to the Microsoft SQL Server 2008 environment, the various editions of SQL Server that are available, and the capabilities of each edition in the various Windows environments. In addition, it provides an overview of and introduction to the new features found in SQL Server 2008 and SQL Server 2008 R2, which are covered in more detail throughout the rest of the book. . Part II, “SQL Server Tools and Utilities”—This part covers the tools and utility programs that SQL Server 2008 provides for you to administer and manage your SQL Server environments. You’ll find information on the various management tools you use on a daily basis, such as SQL Server Management Studio and the new SQLCMD command-line query tool, along with information on SQL Server Profiler. If you are not familiar with these tools, you should read this part of the book early on because these tools are often used and referenced throughout many of the other chapters in the book. . Part III, “SQL Server Administration”—This part discusses topics related to the administration of SQL Server at the database server level. It begins with an overview of what is involved in administering a SQL Server environment and then goes on to cover the tasks related to setting up and managing the overall SQL Server environment, including installing and upgrading to SQL Server 2008 and SQL Server 2008 R2 as well as installing SQL Server clients. This part also includes coverage of security and user administration, database backup and restore, replication, and using the Database Mail facility. Chapters on SQL Server clustering, database mirroring, and

Download from www.wowebook.com

4

Microsoft SQL Server 2008 R2 Unleashed

SQL Server high availability provide some expert advice in these areas. Task scheduling and notification using SQL Server Agent and using the new Policy Based Management feature are also discussed in this part. . Part IV, “SQL Server Database Administration”—This part delves into the administrative tasks associated with creating and managing a SQL Server 2008 database, including the creation and management of database objects, such as tables, indexes, views, stored procedures, functions, and triggers. It also provides coverage of the Database Snapshots and an overview of database maintenance tasks and responsibilities. . Part V, “SQL Server Performance and Optimization”—This part provides information to help you get the best performance out of SQL Server. It begins with a discussion of data structures, indexes, and performance, key items to understand to help ensure good database performance. It then builds on that information with chapters on query optimization and analysis, locking, database design and performance, and ways to manage workloads using the new Resource Governor; then it finishes with a methodology for monitoring and optimizing SQL Server performance. . Part VI, “SQL Server Application Development”—This part includes a comprehensive overview of what’s new in T-SQL in SQL Server 2008 and SQL Server 2008 R, TSQL programming guidelines, tips, and tricks, and advanced stored procedure programming and optimization. In addition, chapters in this Part provide an overview of .NET integration with SQL Server and creating .NET CLR objects information, working with XML in SQL Server, and working with additional SQL Server components that are not part of the core database engine such as Web Services, Service Broker, and Full-Text Search. . Part VII, “SQL Server Business Intelligence Features”—This Part includes a comprehensive overview of SQL Server 2008 R2’s built-in business intelligence features: Analysis Services, Integration Services, and Reporting Services, with a specific focus on the enhancements to Reporting Services introduced with the R2 release. . Bonus Chapters on the CD—This Part provides a few chapters for which there just wasn’t room enough to include elsewhere in the book. These chapters provide expert advice and information on managing remote and linked servers, configuring, tuning and optimizing SQL Server, and planning for SQL Server Disaster Recoverys. . Book Materials on the CD—Also included on the CD are many of the code samples, scripts, databases, and other materials that supplement various chapters. This has always been one of the most valuable reasons to buy books in the Unleashed series. It is our goal not just to discuss a SQL technique or solution, but to also provide working samples and examples that actually do it. Learning by seeing is essential for understanding.

Download from www.wowebook.com

Introduction

5

In addition to the included CD content, please visit the web page for this book at www.samspublishing.com periodically for any updated or additional bonus material as it becomes available.

Conventions Used in This Book Names of commands and stored procedures are presented in a special monospaced computer typeface. We have tried to be consistent in our use of uppercase and lowercase for keywords and object names. However, because the default installation of SQL Server doesn’t make a distinction between upper- and lowercase for SQL keywords or object names and data, you might find some of the examples presented in either upper- or lowercase. Code and output examples are presented separately from regular paragraphs and are also in a monospaced computer typeface. The following is an example: select object_id, name, type_desc from sys.objects where type = ‘SQ’ object_id ----------1977058079 2009058193 2041058307

name ------------------------------QueryNotificationErrorsQueue EventNotificationErrorsQueue ServiceBrokerQueue

type_desc ------------SERVICE_QUEUE SERVICE_QUEUE SERVICE_QUEUE

When syntax is provided for a command, we have followed these conventions:

Syntax Element

Definition

command

These are command names, options, and other keywords.

placeholder

Monospaced italic indicates values you provide.

{}

You must choose at least one of the enclosed options.

[]

The enclosed value/keyword is optional.

()

Parentheses are part of the command.

|

You can select only one of the options listed.

,

You can select any of the options listed.

[...]

The previous option can be repeated.

Download from www.wowebook.com

6

Microsoft SQL Server 2008 R2 Unleashed

Consider the following syntax example: grant {all | permission_list} on object [(column_list)] to {public | user_or_group_name [, [...]]}

In this case, object is required, but column_list is optional. Note also that items shown in plain computer type, such as grant, public, and all, should be entered literally, as shown. Placeholders are presented in italic, such as permission_list and user_or_group_name. A placeholder is a generic term for which you must supply a specific value or values. The ellipsis ([...]) in the square brackets following user_or_group_name indicates that multiple user or group names can be specified, separated by commas. You can specify either the keyword public or one or more user or group names, but not both. Some of the examples presented in this book make use of the AdventureWorks2008 and AdventureWorks2008R2 databases, which are not automatically installed with SQL Server 2008 or SQL Server 2008 R2. To install the AdventureWorks sample databases, you must first download the installer from the Microsoft SQL Server Samples and Community Projects website at http://www.codeplex.com/sqlserversamples.

NOTE Most of the examples presented in this book that use the AdventureWorks database can be run in either AdventureWorks2008 or AdventureWorks2008R2. Structurally, these databases are identical. However, the following tables in AdventureWorks2008R2 have different data values for some of the columns: . Person . SalesPerson . SalesOrderHeader . SalesTerritory . Shift . TransactionHistory If any of the examples use any of these tables, you may see different results depending on whether you run them in AdventureWorks2008 or AdventureWorks2008R2. When necessary, it will be stated in the chapter which version of the AdventureWorks database was used to generate the results displayed. Although it is not necessary to install both versions of the AdventureWorks database, it is possible to install both versions in the same SQL Server instance if you wish.

For many of the examples presented in Part V, larger tables than what are available in the AdventureWorks database were needed to demonstrate many of the concepts with more meaningful examples. For many of the chapters in this part, as well as some other chapters throughout the book, the examples come from the bigpubs2008 database. A copy of the database, along with an Entity-Relationship (ER) diagram and table descriptions, is also on the CD.

Download from www.wowebook.com

Introduction

7

To install the bigpubs2008 database on your system so you can try the various examples, do the following: 1. Copy the bigpubs2008.mdf file into the SQL Server data folder where you want it to reside. 2. After copying the file to the destination folder, ensure that the Read-Only property of the bigpubs2008.mdf file is not enabled (this can happen when the file is copied from the CD). Right-click the file in Windows Explorer and select Properties to bring up the Properties dialog. Click the Read-Only check box to remove the check mark. Click OK to save the changes to the file attributes. 3. Attach the bigpubs2008 database by using a command similar to the following: sp_attach_single_file_db ‘bigpubs2008’, N’D:\MSSQL\DATA\MSSQL.1\MSSQL\Data\bigpubs2008.mdf

Note that you might need to edit the path to match the location where you copied the bigpubs2008.mdf file. Alternatively, you can attach the database by using SQL Server Management Studio. To do this, right-click the Databases node in the Object Explorer and select Attach. When the Attach Databases dialog appears, click the Add button, locate the bigpubs2008.mdf file, and click OK. In the bottom window pane, click the transaction log file entry (it should say Not Found in the message column) and click the Remove button. Next, click the OK button to attach the database. A new transaction log file is automatically created in the same folder as the bigpubs2008.mdf file. For more information on attaching database files, see Chapters14, “Database Backup and Restore,” and 23, “Creating and Managing Databases.”

NOTE In addition to the bigpubs2008 database, the .mdf file for the database used for examples in Chapter 51, “SQL Server Analysis Services,” is also provided. To install the CompSales database, do the following: 1. Copy the CompSales.mdf file into the SQL Server data folder where you want it to reside. 2. Ensure that the Read-Only property of the CompSales.mdf file is not enabled. 3. Attach the CompSales database by using a command similar to the following (edit the path to match the location of the CompSales.mdf file on your system): sp_attach_single_file_db ‘CompSales’, N’D:\MSSQL\DATA\MSSQL.1\MSSQL\Data\CompSales.mdf

Download from www.wowebook.com

8

Microsoft SQL Server 2008 R2 Unleashed

Good Luck! If you have purchased this book, you are on your way to getting the most from SQL Server 2008 or SQL Server 2008 R2. You have already chosen a fine platform for building database applications, one that can provide outstanding performance and rock-solid reliability and availability at a reasonable cost. With this book, you now have the information you need to make the best of it. Many of us who worked on this book have been using SQL Server since it was first released. Writing about each new version challenges us to reassess our understanding of SQL Server and the way it works. It’s an interesting and enjoyable process, and we learn a lot writing each of these books. We hope you get as much enjoyment and knowledge from reading this book as we have from writing it.

Download from www.wowebook.com

CHAPTER

1

SQL Server 2008 Overview

IN THIS CHAPTER . SQL Server Components and Features . SQL Server 2008 R2 Editions . SQL Server Licensing Models

Exactly what is SQL Server 2008? When you first install the product, what are all the pieces you get, what do they do, and which of them do you need? At its core, SQL Server 2008 is an enterprise-class database management system (DBMS) that is capable of running anything from a personal database only a few megabytes in size on a handheld Windows Mobile device up to a multiserver database system managing terabytes of information. However, SQL Server 2008 is much more than just a database engine. The SQL Server product is made up of a number of different components. This chapter describes each of the pieces that make up the SQL Server product and what role each plays. Each of these topics is dealt with in more detail later in the book. In addition, this chapter looks at the environments that support SQL Server 2008 and SQL Server 2008 R2 and the features available in each of the various SQL Server editions.

SQL Server Components and Features The main component of SQL Server 2008 is the Database Engine. Before you can use the other components and features of SQL Server 2008, which are discussed in the following sections, you need to have an instance of the Database Engine installed.

Download from www.wowebook.com

10

CHAPTER 1

SQL Server 2008 Overview

The SQL Server Database Engine The Database Engine is the core application service in the SQL Server package for storing, processing, and securing data with SQL Server 2008. The SQL Server 2008 Database Engine is a Windows service that can be used to store and process data in a relational format, as XML documents, and new for 2008, as spatial data. The following are the main responsibilities of the Database Engine: . Provide reliable storage for data . Provide a means to rapidly retrieve this data . Provide consistent access to the data . Control access to the data through security . Enforce data integrity rules to ensure that the data is reliable and consistent. Each of these responsibilities is examined in greater detail in later chapters in this book. For now, this chapter provides just a brief overview on each of these points to show how Microsoft SQL Server fulfills these core responsibilities. Reliable Storage Reliable storage starts at the hardware level. This isn’t the responsibility of the Database Engine, but it’s a necessary part of a well-built database. Although you can put an entire SQL database on a single IDE or SATA drive (or even burn a read-only copy on a CD), it is preferable to maintain the data on RAID arrays. The most common RAID arrays can survive hardware failures at the disk level without loss of data.

NOTE For more information on the reliability characteristics and performance implications of the various RAID configurations and guidelines for implementing RAID configurations with SQL Server, see Chapter 38, “Database Design and Performance.”

Using whatever hardware you have decided to make available, the Database Engine manages all the data structures necessary to ensure reliable storage of your data. Rows of data are stored in pages, and each page is 8KB in size. Eight pages make up an extent, and the Database Engine keeps track of which extents are allocated to which tables and indexes.

NOTE A page is an 8KB chunk of a data file, the smallest unit of storage available in the database. An extent is a collection of eight 8KB pages.

Another key feature the Database Engine provides to ensure reliable storage is the transaction log. The transaction log makes a record of every change that is made to the database.

Download from www.wowebook.com

SQL Server Components and Features

11

For more information on the transaction log and how it’s managed, see Chapter 31, “Transaction Management and the Transaction Log.”

1

NOTE It is not strictly true that the transaction log records all changes to the database; some exceptions exist. Operations on binary large objects—data of type image and text— can be excepted from logging, and bulk copy loads into tables can be minimally logged to get the fastest possible performance. Rapid Data Access SQL Server allows the creation of indexes, enabling fast access to data. See Chapter 34, “Data Structures, Indexes, and Performance,” for an in-depth discussion of indexes. Another way to provide rapid access to data is to keep frequently accessed data in memory. Excess memory for a SQL Server instance is used as a data cache. When pages are requested from the database, the SQL Server Database Engine checks to see if the requested pages are already in the cache. If they are not, it reads them off the disk and stores them in the data cache. If there is no space available in the data cache, the least recently accessed pages (that is, those that haven’t been accessed in a while since they were read into memory) are flushed out of the data cache to make room for the newly requested pages. If the pages being flushed contain changes that haven’t been written out yet, they are written to disk before being flushed from memory. Otherwise, they are simply discarded.

NOTE With sufficient memory, an entire database can fit completely into memory, providing the best possible I/O performance for the database. Consistent Data Access Getting to your data quickly doesn’t mean much if the information you receive is inaccurate. SQL Server follows a set of rules to ensure that the data you receive from queries is consistent. The general idea with consistent data access is to allow only one client at a time to change the data and to prevent others from reading data from the database while it is undergoing changes. Data and transactional consistency are maintained in SQL Server by using transactional locking. Transactional consistency has several levels of conformance, each of which provides a trade-off between accuracy of the data and concurrency. These levels of concurrency are examined in more detail in Chapter 37, “Locking and Performance.” Access Control SQL Server controls access by providing security at multiple levels. Security is enforced at the server, database, schema, and object levels. Server-level access is enforced either by

Download from www.wowebook.com

12

CHAPTER 1

SQL Server 2008 Overview

using a SQL Server username and password or through integrated network security, which uses the client’s network login credentials to establish identity. SQL Server security is examined in greater detail in Chapter 11, “Security and User Administration.” Data Integrity Some databases have to serve the needs of more than a single application. A corporate database that contains valuable information might have a dozen different departments wanting to access portions of the database for different needs. In this kind of environment, it is impractical to expect the developers of each application to agree on an identical set of standards for maintaining data integrity. For example, one department might allow phone numbers to have extensions, whereas another department may not need that capability. One department might find it critical to maintain a relationship between a customer record and a salesperson record, whereas another might care only about the customer information. The best way to keep everybody sane in this environment—and to ensure that the data stays consistent and usable by everyone—is to enforce a set of data integrity rules within the database itself. This is accomplished through data integrity constraints and other data integrity mechanisms, such as triggers. See Chapter 26, “Implementing Data Integrity,” for details.

SQL Server 2008 Administration and Management Tools SQL Server 2008 and SQL Server 2008 R2 provide a suite of tools for managing and administering the SQL Server Database Engine and other components. The following sections provide an overview of the primary tools for day-to-day administration, management, and monitoring of your SQL Server environments. SQL Server Management Studio (SSMS) SSMS is the central console from which most database management tasks can be coordinated. SSMS provides a single interface from which all servers in a company can be managed. SSMS is examined in more detail in Chapter 4, “SQL Server Management Studio.” Figure 1.1 shows SSMS being used for some everyday administration tasks. Figure 1.1 shows a list of registered servers in the upper-left pane. Below that is the Object Explorer, which lets you browse the contents of the databases within a SQL Server instance. The bigpubs2008 database has been expanded, and the right pane shows the columns for the authors table.

Download from www.wowebook.com

SQL Server Components and Features

13

1 FIGURE 1.1 SSMS, showing a list of columns for the authors table in the bigpubs2008 database. Following are some of the tasks you can perform with SSMS. Most of these tasks are discussed in detail later in the book: . Completely manage many servers in a convenient interface . Set server options and configuration values, such as the amount of memory and number of processors to use, default language, and default location of the data and log files . Manage logins, database users, and database roles . Create, edit, and schedule automated jobs through the SQL Server Agent . Back up and restore databases and define maintenance plans . Create new databases . Browse table contents . Create and manage database objects, such as tables, indexes, and stored procedures . Generate DDL scripts for databases and database objects . Configure and manage replication . Create, edit, execute, and debug Transact-SQL (T-SQL) scripts . Define, implement, manage, and invoke SQL Server Policies

Download from www.wowebook.com

14

CHAPTER 1

SQL Server 2008 Overview

. Enable and disable features of SQL Server . Manage and organize scripts into projects and save versions in source control systems such as Visual SourceSafe

NOTE Much of SQL Server Managements Studio’s interaction with SQL Server is done through standard T-SQL statements. For example, when you create a new database through the SSMS interface, behind the scenes, SSMS generates a CREATE DATABASE SQL statement to be executed in the target server. Essentially, whatever you can do through the SSMS GUI, you can do with T-SQL statements. As a matter of fact, nearly every dialog in SSMS provides the capability to generate the corresponding T-SQL script for the action(s) it performs. This capability can be very useful as a timesaver for tasks that you need to perform repeatedly, avoiding the need to step through the options presented in the GUI. If you’re curious about how SSMS is accomplishing something that doesn’t provide the capability to generate a script, you can run SQL Profiler to capture the commands that SSMS is sending to the server. You can use this technique to discover some interesting internal information and insight into the SQL Server system catalogs.

SQL Server Configuration Manager SQL Server Configuration Manager is a tool provided with SQL Server 2008 for managing the services associated with SQL Server and for configuring the network protocols used by SQL Server. Primarily, SQL Server Configuration Manager is used to start, pause, resume, and stop SQL Server services and to view or change service properties. SQL Server Agent SQL Server Agent is a scheduling tool integrated into SSMS that allows convenient definition and execution of scheduled scripts and maintenance jobs. SQL Server Agent also handles automated alerts—for example, if the database runs out of space. SQL Server Agent is a Windows service that runs on the same machine as the SQL Server Database Engine. The SQL Server Agent service can be started and stopped through either SSMS, the SQL Server Configuration Manager, or the ordinary Windows Services Manager. In enterprise situations in which many SQL Server machines need to be managed together, the SQL Server Agent can be configured to distribute common jobs to multiple servers through the use of Multiserver Administration. This capability is most helpful in a wide architecture scenario, in which many SQL Server instances are performing the same tasks with the databases. Jobs are managed from a single SQL Server machine, which is responsible for maintaining the jobs and distributing the job scripts to each target server. The results of each job are maintained on the target servers but can be observed through a single interface. If you had 20 servers that all needed to run the same job, you could check the completion status of that job in moments instead of logging in to each machine and checking the status 20 times.

Download from www.wowebook.com

SQL Server Components and Features

15

1

The SQL Server Agent also handles event forwarding. Any system events recorded in the Windows system event log can be forwarded to a single machine. This gives a busy administrator a single place to look for errors. More information about how to accomplish these tasks, as well as other information on the SQL Server Agent, is available in Chapter 16, “SQL Server Scheduling and Notification.” SQL Server Profiler The SQL Server Profiler is a GUI interface to the SQL Trace feature of SQL Server that captures the queries and results flowing to and from the database engine. It is analogous to a network sniffer, although it does not operate on quite that low a level. The Profiler can capture and save a complete record of all the T-SQL statements passed to the server and the occurrence of SQL Server events such as deadlocks, logins, and errors. You can use a series of filters to pare down the results when you want to drill down to a single connection or even a single query. You can use the SQL Profiler to perform these helpful tasks: . You can capture the exact SQL statements sent to the server from an application for which source code is not available (for example, third-party applications). . You can capture all the queries sent to SQL Server for later playback on a test server. This capability is extremely useful for performance testing with live query traffic. . If your server is encountering recurring access violations (AVs), you can use the Profiler to reconstruct what happened leading up to an AV. . The Profiler shows basic performance data about each query. When your users start hammering your server with queries that cause hundreds of table scans, the Profiler can easily identify the culprits. . For complex stored procedures, the Profiler can identify which portion of the procedure is causing the performance problem. . You can audit server activity in real-time. More information on SQL Server Profiler is available in Chapter 6, “SQL Server Profiler.”

Replication Replication is a server-based tool that you can use to synchronize data between two or more databases. Replication can send data from one SQL Server instance to another, or it can replicate data to Oracle, Access, or any other database that is accessible via ODBC or OLE DB. SQL Server supports three kinds of replication: . Snapshot replication . Transactional replication . Merge replication

Download from www.wowebook.com

16

CHAPTER 1

SQL Server 2008 Overview

The availability and functionality of replication might be restricted, depending on the edition of SQL Server 2008 you are running.

NOTE Replication copies the changes to data from your tables and indexed views, but it does not normally re-create indexes or triggers at the target. It is common to have different indexes on replication targets than on the source to support different requirements.

Snapshot Replication With snapshot replication, the server takes a picture, or snapshot, of the data in a table at a single point in time. Usually, if this operation is scheduled, the target data is simply replaced at each update. This form of replication is appropriate for small data sets, infrequent update periods (or for a one-time replication operation), or management simplicity. Transactional Replication Initially set up with a snapshot, the server maintains downstream replication targets by reading the transaction log at the source and applying each change at the targets. For every insert, update, and delete operation, the server sends a copy of the operation to every downstream database. This is appropriate if low-latency replicas are needed. Transactional replication can typically keep databases in sync within about five seconds of latency, depending on the underlying network infrastructure. Keep in mind that transactional replication does not guarantee identical databases at any given point in time. Rather, it guarantees that each change at the source will eventually be propagated to the targets. If you need to guarantee that two databases are transactionally identical, you should look into Distributed Transactions or database mirroring. Transactional replication might be used for a website that supports a huge number of concurrent browsers but only a few updates, such as a large and popular messaging board. All updates would be done against the replication source database and would be replicated in near-real-time to all the downstream targets. Each downstream target could support several web servers, and each incoming web request would be balanced among the web farm. If the system needed to be scaled to support more read requests, you could simply add more web servers and databases and add the database to the replication scheme. Merge Replication With snapshot and transactional replication, a single source of data exists from which all the replication targets are replenished. In some situations, it might be necessary or desirable to allow the replication targets to accept changes to the replicated tables and merge these changes together at some later date. Merge replication allows data to be modified by the subscribers and synchronized at a later time. This synchronization could be as soon as a few seconds, or it could be a day later. Merge replication would be helpful for a sales database that is replicated from a central SQL Server database out to several dozen sales laptops. As the sales personnel make sales calls, they can add new data to the customer database or change errors in the existing

Download from www.wowebook.com

SQL Server Components and Features

17

1

data. When the salespeople return to the office, they can synchronize their laptops with the central database. Their changes are submitted, and the laptops get refreshed with whatever new data was entered since the last synchronization. Immediate Updating Immediate updating allows a replication target to immediately modify data at the source. This task is accomplished by using a trigger to run a distributed transaction. Immediate updating is performance intensive, but it allows for updates to be initiated from anywhere in the replication architecture. More details on replication are available in Chapter 19, “Replication.”

Database Mirroring The database mirroring feature available in SQL Server 2008 provides a solution for increasing database availability. Essentially, database mirroring maintains two copies of a single database that reside on different instances of SQL Server, typically on server instances that reside on computers in different locations. In a typical database mirroring scenario, one server instance serves as the primary database to which the client applications connect, and the other server instance acts as a hot or warm standby server. Database mirroring involves re-applying every modification operation that occurs on the primary database onto the mirror database as quickly as possible. This is accomplished by sending every active transaction log record generated on the primary server to the mirror server. The log records are applied to the mirror database, in sequence, as quickly as possible. Unlike replication, which works at the logical level, database mirroring works at the level of the physical log record. The mirror database is an exact copy of the primary database. For more information on setting up and using database mirroring, see Chapter 20, “Database Mirroring.”

Full-Text Search SQL Server 2008 provides the capability to issue full-text queries against plain characterbased data in your SQL Server tables. This capability is useful for searching large text fields, such as movie reviews, book descriptions, or case notes. Full-text queries can include words and phrases, or multiple forms of a word or phrase. Full-Text Search capabilities in Microsoft SQL Server 2008 are provided by the Microsoft Full-Text Engine for SQL Server (MSFTESQL). The MSFTESQL service works together with the SQL Server Database Engine. You specify tables or entire databases that you want to index. The full-text indexes are built and maintained outside the SQL Server database files in special full-text indexes stored in the Windows file system. You can specify how often the full-text indexes are updated to balance performance issues with timeliness of the data.

Download from www.wowebook.com

18

CHAPTER 1

SQL Server 2008 Overview

The SQL Server Database Engine supports basic text searches against specific columns. For example, to find all the rows where a text column contained the word guru, you might write the following SQL statement: select * from resume where description like ‘%guru%’

This statement finds all the rows in the resume table where the description contains the word guru. This method has a couple problems, however. First, the search is slow. Because the Database Engine can’t index text columns, a full table scan has to be done to satisfy the query. Even if the data were stored in a varchar column instead of a text column, an index may not help because you’re looking for guru anywhere in the column, not just at the beginning, so the index cannot be used to locate the matching rows. (Chapter 34 contains more information on avoiding such situations.) What if you wanted to search for the word guru anywhere in the table, not just in the description column? What if you were looking for a particular set of skills, such as “SQL” and “ability to work independently”? Full-text indexing addresses these problems. To perform the same search as before with full-text indexing, you might use a query like this: select * from resume where contains(description, ‘guru’)

To perform a search that looks for a set of skills, you might use a query like this: select * from resume where contains(*, ‘SQL and “ability to work independently”’)

For more information on setting up and searching Full-Text Search indexes, see Chapter 50, “SQL Server Full-Text Search” (on the CD).

SQL Server Integration Services (SSIS) SSIS is a platform for building high-performance data integration solutions and workflow solutions. You can build extract, transform, and load (ETL) packages to update data warehouses, interact with external processes, clean and mine data, process analytical objects, and perform administrative tasks. Following are some of the features of SSIS: . Graphical tools and wizards for building, debugging, and deploying SSIS packages . Workflow functions, such as File Transfer Protocol (FTP), SQL statement execution, and more . SSIS Application Programming Interfaces (APIs) . Complex data transformation for data cleansing, aggregation, merging, and copying

Download from www.wowebook.com

SQL Server Components and Features

19

. An email messaging interface

1

. A service-based implementation . Support for both native and managed code (C++ or any common language runtime [CLR]–compliant language, such as C# or J#) . An SSIS object model SSIS is a tool that helps address the needs of getting data—which is often stored in many different formats, contexts, file systems, and locations—from one place to another. In addition, the data often requires significant transformation and conversion processing as it is being moved around. Common uses of SSIS might include the following: . Exporting data out of SQL Server tables to other applications and environments (for example, ODBC or OLE DB data sources, flat files) . Importing data into SQL Server tables from other applications and environments (for example, ODBC or OLE DB data sources, flat files) . Initializing data in some data replication situations, such as initial snapshots . Aggregating data (that is, data transformation) for distribution to/from data marts or data warehouses . Changing the data’s context or format before importing or exporting it (that is, data conversion) For more information on creating and using SSIS packages, see Chapter 52, “SQL Server Integration Services.”

SQL Server Analysis Services (SSAS) SSAS provides online analytical processing (OLAP) and data mining functionality for business intelligence (BI) solutions. SSAS provides a rich set of data mining algorithms to enable business users to mine data, looking for specific patterns and trends. These data mining algorithms can be used to analyze data through a Unified Dimensional Model (UDM) or directly from a physical data store. SSAS uses both server and client components to supply OLAP and data mining functionality for BI applications. SSAS consists of the analysis server, processing services, integration services, and a number of data providers. It has both server-based and client-/local-based analysis services capabilities. This essentially provides a complete platform for SSAS. The basic components within SSAS are all focused on building and managing data cubes. SSAS allows you to build dimensions and cubes from heterogeneous data sources. It can access relational OLTP databases, multidimensional data databases, text data, and any other source that has an OLE DB provider available. You don’t have to move all your data into a SQL Server database first; you just connect to its source. In addition, SSAS allows a

Download from www.wowebook.com

20

CHAPTER 1

SQL Server 2008 Overview

designer to implement OLAP cubes, using a variety of physical storage techniques directly tied to data aggregation requirements and other performance considerations. You can easily access any OLAP cube built with SSAS via the Pivot Table Service, you can write custom client applications by using Multidimensional Expressions (MDX) with OLE DB for OLAP or ActiveX Data Objects Multidimensional (ADO MD), and you can use a number of third-party OLAP-compliant tools. MDX enables you to formulate complex multidimensional queries. SSAS is commonly used to perform the following tasks: . Perform trend analysis to predict the future. For example, based on how many widgets you sold last year, how many will you sell next year? . Combine otherwise disconnected variables to gain insight into past performance. For example, was there any connection between widget sales and rainfall patterns? Searching for unusual connections between your data points is a typical data mining exercise. . Perform offline summaries of commonly used data points for instant access via a web interface or custom interface. For example, a relational table might contain one row for every click on a website. OLAP can be used to summarize these clicks by hour, day, week, and month and then to further categorize them by business line. Included for Analysis Services in SQL Server 2008 R2 is PowerPivot for Excel and PowerPivot for SharePoint. PowerPivot for Excel and SharePoint are client and server components that integrate Analysis Services with Excel and SharePoint. PowerPivot for Excel is an add-in that allows you to create PowerPivot workbooks that can assemble and relate large amounts of data from different sources. PowerPivot workbooks typically contain large, multidimensional datasets that you create in a separate client application and use with PivotTables and PivotCharts in a worksheet. The PowerPivot add-in removes the one million row limit for worksheets and provides rapid calculations for the large data that you assemble. PowerPivot for SharePoint extends SharePoint 2010 and Excel Services to add server-side processing, collaboration, and document management support for the PowerPivot workbooks that you publish to SharePoint. Together, the PowerPivot client add-in and server components provide an end-to-end solution that furthers business intelligence data analysis for Excel users on the workstation and on SharePoint sites. SSAS is a complex topic. For more information on MDX, data cubes, and ways to use data warehousing analysis services, see Chapter 52, “SQL Server 2008 Analysis Services.”

SQL Server Reporting Services (SSRS) SQL Server Reporting Services is a server-based reporting platform that delivers enterprise, web-enabled reporting functionality so you can create reports that draw content from a variety of data sources, publish reports in various formats, and centrally manage security and subscriptions.

Download from www.wowebook.com

SQL Server Components and Features

21

Reporting Services includes the following core components:

1

. A complete set of tools you can use to create, manage, and view reports . A report server component that hosts and processes reports in a variety of formats, including HTML, PDF, TIFF, Excel, CSV, and more . An API that allows developers to integrate or extend data and report processing into custom applications or to create custom tools to build and manage reports There are two design tools for building reports: Report Designer, a powerful development tool integrated with Visual Studio, and Report Builder 3.0, which is a simpler point-andclick tool that you use to design ad hoc reports. Both report design tools provide a WYSIWYG experience. Reports are described using the Report Definition Language (RDL). RDL contains the description of the report layout, formatting information, and instructions on how to fetch the data. After a report is defined, it can be deployed on the report server, where it can be managed, secured, and delivered to a variety of formats, including HTML, Excel, PDF, TIFF, and XML. Various delivery, caching, and execution options are also available, as are scheduling and historical archiving. One major set of enhancements in SQL Server 2008 R2 includes the new and enhanced features in Reporting Services, which includes . New features for SharePoint integration with Reporting Services—These features include support for multiple SharePoint Zones, support for the SharePoint Universal Logging service, and a query designer for SharePoint Lists as a data source. . Report parts—These are reusable report items that are stored on a report server or on a SharePoint site integrated with a report server. . Shared datasets—These datasets can be shared, stored, processed and cached externally from the report, thus providing a consistent set of data that can be shared by multiple reports. . Cache refresh plans—These plans allow you to cache reports or shared dataset query results on first use or from a schedule. . Sparklines and data bars—These simple charts convey a lot of information in a little space, often inline with text. Sparklines and data bars are often used in tables and matrices. . Indicators—These minimal gauges convey the state of a single data value at a glance. Indicators can be used by themselves in dashboards or free-form reports, but they are most commonly used in tables or matrices to visualize data in rows or columns. . Calculating aggregates of aggregates—You can now create expressions that calculate an aggregate of an aggregate.

Download from www.wowebook.com

22

CHAPTER 1

SQL Server 2008 Overview

. Better report pagination—Page breaks on tablix data regions (table, matrix, and list), groups, and rectangles give you better control of report pagination. . Map reports—Report Designer now provides a Map Wizard and Map Layer Wizard to add maps and map layers to your report to help visualize data against a geographic background. A map layer displays map elements based on spatial data from a map in the Map Gallery, from a SQL Server query that returns SQL Server spatial data, or from an Environmental Systems Research Institute, Inc. (ESRI) shapefile. . Business Intelligence Development Studio Support for SQL Server 2008 Reports and Report Server projects—Business Intelligence Development Studio now supports working with both SQL Server 2008 and SQL Server 2008 R2 reports, and with Report Server projects in the SQL Server 2008 R2 version of Business Intelligence Development Studio. . Improved Previewing of Report—Report Builder 3.0 provides a better preview experience with the introduction of edit sessions that enable the reuse of cached datasets when previewing reports. Reports render more quickly when using the cached datasets. Report Manager has also been updated in the SQL Server 2008 R2 release to provide an improved user experience and look and feel. This includes an updated color scheme and layout in an effort to provide easier navigation to manage report properties and Report Server items. You can now use a new drop-down menu on each report or Report Server item in a folder to access the various configuration options for the report or item you choose. Following are some of the key enhancements to Report Manager in SQL Server 2008 R2: . Workflow has been improved for viewing and managing reports and report server items. You can use a new drop-down menu to access various configuration options for each report or report server item in a folder. . The need to render a report before accessing and configuring report properties when in default view has been eliminated. . The visible display area is now larger in the Report Viewer when rendering reports. . An updated Report Viewer toolbar includes some updates to the toolbar controls, as well as the capability to export report data to an Atom service document and data feeds. For more information on designing and deploying reports using Reporting Services and more information on the extensive R2 enhancements, see Chapter 53, “SQL Server 2008 Reporting Services.”

SQL Server Service Broker SQL Server Service Broker provides a native SQL Server infrastructure that supports asynchronous, distributed messaging between database-driven services. Service Broker handles all the hard work of managing coordination among the constructs required for distributed messaging, including transactional delivery and storage, message typing and validation, multithreaded activation and control, event notification, routing, and security.

Download from www.wowebook.com

SQL Server 2008 R2 Editions

23

1

Service Broker is designed around the basic functions of sending and receiving messages. An application sends messages to a service, which is a name for a set of related tasks. An application receives messages from a queue, which is a view of an internal table. Service Broker guarantees that an application receives each message exactly once, in the order in which the messages were sent. Service Broker can be useful for any application that needs to perform processing asynchronously or that needs to distribute processing across a number of computers. An example would be a bicycle manufacturer and seller who must provide new and updated parts data to a company that implements a catalog management system. The manufacturer must keep the catalog information up-to-date with its product model data, or it could lose market share or end up receiving orders from distributors based on out-of-date catalog information. When the parts data is updated in the manufacturer’s database, a trigger could be invoked to send a message to Service Broker with information about the updated data. Service Broker would then asynchronously deliver the message to the catalog service. The catalog service program would then perform the work in a separate transaction. When this work is performed in a separate transaction, the original transaction in the manufacturer’s database can commit immediately. The application avoids system slowdowns that result from keeping the original transaction open while performing the update to the catalog database. For more information on using Service Broker, see Chapter 49, “SQL Server Service Broker” (on the CD).

SQL Server 2008 R2 Editions You can choose from several editions of SQL Server 2008 R2. The edition you choose depends on your database and data processing needs, as well as the Windows platform on which you want to install it. For actual deployment of SQL Server in a production environment, you can choose from any edition of SQL Server 2008 except Developer Edition and Evaluation Edition. Which edition you choose to deploy depends on your system requirements and need for SQL Server components. This following sections examine the different editions of SQL Server and discusses their features and capabilities. Using this information, you can better choose which edition provides the appropriate solution for you.

SQL Server 2008 Standard Edition The Standard Edition of SQL Server 2008 is the version intended for the masses—those running small- to medium-sized systems who don’t require the performance, scalability, and availability provided by Enterprise Edition. Standard Edition scalability is limited to up to four processors. There is no built-in memory limitation in SQL Server 2008 Standard Edition; it can utilize as much memory as provided by the operating system.

Download from www.wowebook.com

24

CHAPTER 1

SQL Server 2008 Overview

SQL Server 2008 Standard Edition includes the following features: . CLR procedures, functions, and data types . SQL Server Analysis Services . Service Broker . Reporting Services . SQL Server Integration Services . Full-Text Search . Built-in XML support . Spatial Indexes . SQL Server Profiler and performance analysis tools . SQL Server Management Studio . Policy Based Management . Replication . Two-node failover clustering . Database mirroring (safety full mode only) . Log shipping . Backup Compression (available in R2 only) The Standard Edition can be installed on any of the Windows 2003 SP2 and Windows 2008 Server platforms, as well as Windows XP Professional, Windows Vista Ultimate, Enterprise, or Business Editions, and Windows 7 Ultimate, Enterprise, or Professional Editions. The Standard Edition should meet the needs of most departmental and small- to mid-sized applications. However, if you need more scalability, availability, advanced security or performance features, or comprehensive analysis features, you should implement the Enterprise Edition of SQL Server 2008.

SQL Server 2008 Enterprise Edition The Enterprise Edition of SQL Server 2008 is the most comprehensive and complete edition available. It provides the most scalability and availability of all editions and is intended for systems that require high performance and availability, such as large-volume websites, data warehouses, and high-throughput online transaction processing (OLTP) systems. SQL Server 2008 Enterprise Edition supports as much memory and as many CPUs as supported by the operating system on which it is installed. It can be installed on any of the Windows 2003 SP2 and Windows 2008 Server platforms. In addition, SQL Server 2008 Enterprise Edition provides performance enhancements, such as parallel queries, indexed views, and enhanced read-ahead scanning.

Download from www.wowebook.com

SQL Server 2008 R2 Editions

25

Which version is right for you? The next section explores the feature sets of Enterprise and Standard Editions so you can decide which one provides the features you need.

1 Differences Between the Enterprise and Standard Editions of SQL Server For deploying SQL Server 2008 in a server environment, either the Standard Edition or Enterprise Edition of SQL Server is a logical choice. To help you decide between the two editions, Table 1.1 compares the major features that each edition supports.

TABLE 1.1 SQL Server 2008 Feature Comparison: Enterprise and Standard Editions Feature

Enterprise Edition

Standard Edition

Max number of CPUs

8

4

64-bit support

Yes

Yes

CLR runtime integration

Yes

Yes

Full-Text Search

Yes

Yes

Native XML Support

Yes

Yes

FILESTREAM Support

Yes

Yes

Spatial Data Support

Yes

Yes

SQL Server Integration Services

Yes

Yes

Database Mail

Yes

Yes

Policy Based Management

Yes

Yes

SQL Profile

Yes

Yes

Integration Services with Basic Transforms

Yes

Yes

Integration Services with Advanced Yes Data Mining and Cleansing Transforms

No

Star Join Query Optimization

Yes

No

Change Data Capture

Yes

No

Service Broker

Yes

Yes

Reporting Services

Yes

Yes

Replication

Yes

Yes

Log Shipping

Yes

Yes

Database mirroring

Yes

Yes (Single REDO thread with Safety FULL only)

Download from www.wowebook.com

26

CHAPTER 1

SQL Server 2008 Overview

TABLE 1.1 SQL Server 2008 Feature Comparison: Enterprise and Standard Editions Feature

Enterprise Edition

Standard Edition

Database snapshots

Yes

No

Indexed views

Yes

Yes (Can be created, but automatic matching by Query Optimizer not supported)

Updatable distributed partitioned views

Yes

No

Table and index partitioning

Yes

No

Online index operations

Yes

No

Parallel index operations

Yes

No

Parallel DBCC

Yes

No

Online page and file restoration

Yes

No

Fast Recovery

Yes

No

Data Compression

Yes

No

Compressed Backups

Yes

Yes

Resource Governor

Yes

No

Fine Grained Encryption

Yes

No

Transparent Data Encryption

Yes

No

Failover clustering

Yes

Yes (2-node only)

Multiple-instance support

Yes (50 instances maximum)

Yes (16 instances maximum)

PowerPivot for SharePoint

Yes (R2 only) No

Application and Multi-Server Management (R2 Only)

Yes

Yes (as a managed instance only)

Other SQL Server 2008 Editions The Standard and Enterprise Editions of SQL Server 2008 are intended for server-based deployment of applications. In addition, the following editions are available for other specialized uses: . Workgroup Edition . Developer Edition . Web Edition

Download from www.wowebook.com

SQL Server 2008 R2 Editions

27

. Express Edition

1

. Compact Edition Workgroup Edition SQL Server 2008 Workgroup Edition is intended for small organizations that need a database with no limits on database size or number of users but may not need the full capabilities of the Standard Edition. SQL Server 2008 Workgroup Edition can be used as a front-end web server or for departmental or branch office applications. Workgroup Edition includes most of the core database features and capabilities of the SQL Server Standard Edition except for the following: . It is limited to two CPUs and a maximum of 4GB of memory. . It does not support failover clustering. . Database mirroring support is limited to being a witness only. . It does not include Analysis Services. . It provides limited support for Integration Services and Reporting Services features. Workgroup Edition can be installed in any of the following environments: . Any Windows 2003 Server editions . Any Windows 2008 Server editions . Windows 7 . Windows Vista . Windows XP Developer Edition The Developer Edition of SQL Server 2008 is a full-featured version intended for development and end-user testing only. It includes all the features and functionality of Enterprise Edition, at a much lower cost, but the licensing agreement prohibits production deployment of databases using Developer Edition. To provide greater flexibility during development, Developer Edition can be installed in any of the following environments. . Any Windows 2003 Server editions . Any Windows 2008 Server editions . Windows 7 . Windows Vista . Windows XP Web Edition SQL Server 2008 Web Edition is a lower total-cost-of-ownership option, similar to the Workgroup Edition, but intended for small- to large-scale web hosts and websites.

Download from www.wowebook.com

28

CHAPTER 1

SQL Server 2008 Overview

Web Edition includes most of the core database features and capabilities of the SQL Server Standard Edition with the following key differences: . It is limited to a maximum of 4 CPUs. . Unlike the Workgroup Edition, memory in this edition is constrained only by the OS maximum memory limits. . It does not support failover clustering. . Database mirroring support is limited to being a witness only. . It does not include Analysis Services. . It includes only the basic version of SQL Server Management Studio (which lacks advanced features such as IntelliSense and version control support). . It provides limited support for Integration Services and Reporting Services features. Web Edition can be installed in any of the following environments. . Any Windows 2003 Server editions . Any Windows 2008 Server editions . Windows 7 . Windows Vista . Windows XP Express Edition SQL Server Express Edition is a free, lightweight, embeddable, and redistributable version of SQL Server 2008. It includes a stripped-down version of SQL Server Management Studio, called SQL Server Management Studio Express, for easily managing a SQL Server Express instance and its databases. The Express Edition of SQL Server 2008 is intended for users who are running applications that require a locally installed database, often on mobile systems, and who spend at least some time disconnected from the network. The core database engine of Express Edition is the same as the other SQL Server editions, so as your needs grow, your applications seamlessly work with the rest of the SQL Server product family. The Express Edition can be installed in any of the following environments: . Any Windows 2003 Server editions . Any Windows 2008 Server editions . Windows 7 . Windows Vista . Windows XP Express Edition supports most of the same features as the Workgroup Edition, with the following exceptions:

Download from www.wowebook.com

SQL Server 2008 R2 Editions

29

. It is limited to using a maximum of one CPU and 1GB of memory.

1

. It limits the maximum database size to 4GB. . It does not include Full-Text Search, Reporting Services, or Analysis Services. . It does not include SQL Server Integration Services. . It supports Service Broker as a client only. . It does not include SSMS. . It can participate in replication only as a subscriber. If you need a bit more than the Express Edition offers, but not as much as the Workgroup Edition, Microsoft also provides the Express Edition with Advanced Services. The Express Edition with Advanced Services includes support for Full-Text Search and limited support of Reporting Services for web reporting. SQL Server Compact 3.5 Edition SQL Server Compact 3.5 is a free, embedded version of SQL Server intended for building standalone and occasionally connected applications for mobile devices, desktops, and web clients on Windows platforms. The Compact 3.5 Edition provides general T-SQL compatibility and a costbased Query Optimizer similar to that in SQL Server 2008. Developers who are familiar with SQL Server 2008 should feel comfortable developing for SQL Server Compact 3.5. SQL Server Compact 3.5 Edition has a small footprint, requiring only about 2–3MB. It can connect directly with a SQL Server 2008 database through remote execution of T-SQL statements, and it also supports replication with SQL Server 2008 databases as a merge replication subscriber so that data can be accessed and manipulated offline and synchronized later with a server-based version of SQL Server 2008. SQL Server 2008 R2 Premium Editions SQL Server 2008 R2 introduces two new premium editions to meet the needs of large-scale datacenters and data warehouses: . SQL Server 2008 R2 Datacenter . SQL Server 2008 R2 Parallel Data Warehouse SQL Server 2008 R2 Datacenter Edition is built on SQL Server 2008 R2 Enterprise and is designed to deliver a high-performing data platform that provides the highest levels of scalability for large application workloads, virtualization and consolidation, and management for an organization’s database infrastructure. The Datacenter Edition provides the following key features: . Application and Multi-Server Management for enrolling, gaining insights into, and managing over 25 instances . Highest virtualization support for maximum ROI on consolidation and virtualization . High-scale complex event processing with SQL Server StreamInsight

Download from www.wowebook.com

30

CHAPTER 1

SQL Server 2008 Overview

. Support for more than 8 processors and up to 256 logical processors for highest levels of scale . Support for memory limits up to the OS maximum SQL Server 2008 R2 Parallel Data Warehouse Edition is a highly scalable data warehouse appliance-based solution that delivers performance at low cost through a massively parallel processing (MPP) architecture and compatibility with hardware partners providing the ability to scale your data warehouse to tens and hundreds of terabytes. Following are some key features of the Parallel Data Warehouse Edition: . Tens to hundreds of terabytes enabled by MPP architecture . Advanced data warehousing capabilities such as Star Join Queries and Change Data Capture . Integration with SSIS, SSRS, and SSAS . Support for the industry standard data warehousing hub and spoke architecture and parallel database copy

SQL Server Licensing Models In addition to feature sets, one of the determining factors in choosing a SQL Server edition is cost. With SQL Server 2008, Microsoft provides two types of licensing models: processor-based licensing and server-based licensing. Processor-based licensing requires a single license for each physical CPU in the machine that is running a Microsoft Server product. This type of license includes unlimited client device access. Additional server licenses, seat licenses, and Internet connector licenses are not required. You must purchase a processor license for each installed processor on the server on which SQL Server 2008 will be installed, even if some processors will not be used for running SQL Server. The only exception is for systems with 16 or more processors that allow partitioning of the processors into groups so the SQL Server software can be delegated to a subset of the processors.

NOTE For licensing purposes, Microsoft bases the number of CPUs in a machine on the number of CPU sockets on the motherboard, not the number of cores on the CPU chip itself. Thus, although a dual-core or quad-core processor chip may appear to the operating system as two or four CPUs, at the time of this writing, each of these types of chips is still considered a single CPU for licensing purposes if it occupies only a single CPU socket on the motherboard.

For those who prefer the more familiar server/client access license (CAL), or for environments in which the number of client devices connecting to SQL Server is small and known, two server/CAL-based licensing models are also available:

Download from www.wowebook.com

SQL Server Licensing Models

31

1

. Device CALs—A device CAL is required for a device (for example, PC, workstation, terminal, PDA, mobile phone) to access or use the services or functionality of Microsoft SQL Server. The server plus device CAL model is likely to be the more costeffective choice if there are multiple users per device (for example, in a call center). . User CALs—A SQL server user CAL is required for a user (for example, an employee, a customer, a partner) to access or use the services or functionality of Microsoft SQL Server. The server plus user CAL model is likely to be more cost effective if there are multiple devices per user (for example, a user who has a desktop PC, laptop, PDA, and so forth). The server/CAL licensing model requires purchasing a license for the computer running SQL Server 2008 as well as a license for each client device or user that accesses any SQL Server 2008 installation. A fixed number of CALs are included with a server license and the server software. Additional CALs can be purchased as needed. Server/per-seat CAL licensing is intended for environments in which the number of clients per server is relatively low, and access from outside the company firewall is not required. Be aware that using a middle-tier or transaction server that pools or multiplexes database connections does not reduce the number of CALs required. A CAL is still required for each distinct client workstation that connects through the middle tier. (Processor licensing might be preferable in these environments due to its simplicity and affordability when the number of clients is unknown and potentially large.) The pricing listed in Table 1.2 is provided for illustrative purposes only and is based on pricing available at the time of publication. These estimated retail prices are subject to change and might vary from reseller pricing.

TABLE 1.2 SQL Server 2008 R2 Estimated Retail Pricing Licensing Option

Enterprise Edition

Standard Edition

Workgroup Edition

Parallel Data Warehouse and Datacenter Editions

Processor Licensing

$28,749 per processor

$7,499 per $3,899 per $57,498 per processor processor processor

Server/per-seat CAL license with 5 workgroup CALs

N/A

N/A

$739

N/A

Server/per-seat CAL license with 5 CALs

N/A

$1,849

N/A

N/A

Server/per-seat CAL license with 25 CALs

$13,969

N/A

N/A

N/A

Download from www.wowebook.com

32

CHAPTER 1

SQL Server 2008 Overview

Web Edition Licensing The Express Edition of SQL Server 2008 is available via free download from www. microsoft.com/sql. Developers can redistribute it with their applications at no cost by simply registering for redistribution rights with Microsoft. The Express Edition does not require a CAL when it is used on a standalone basis. If it connects to a SQL Server instance running Enterprise Edition, Standard Edition, or Workgroup Edition, a separate user or device CAL is required for the device running Express Edition unless the SQL Server instance it connects to is licensed using the per-processor model.

Developer Edition Licensing The Developer Edition of SQL Server 2008 is available for a fixed price of $50. The Developer Edition is licensed per developer and must be used for designing, developing, and testing purposes only.

Express Edition Licensing The Express Edition of SQL Server 2008 is available via free download from www. microsoft.com/sql. Developers can redistribute it with their applications at no cost by simply registering for redistribution rights with Microsoft. The Express Edition does not require a CAL when it is used on a standalone basis. If it connects to a SQL Server instance running Enterprise Edition, Standard Edition, or Workgroup Edition, a separate user or device CAL is required for the device running Express Edition unless the SQL Server instance it connects to is licensed using the per-processor model.

Compact Edition 3.5 Licensing SQL Server 2008 Mobile Edition is available as a downloadable development product for mobile applications. You can deploy SQL Server Mobile to an unlimited number of mobile devices if they operate in standalone mode (that is, the device does not connect to or use the resources of any SQL Server system not present on the device). If the device connects to a SQL Server instance that is not on the device, a separate user or device CAL is required unless the SQL Server instance it connects to is licensed using the per-processor model.

Choosing a Licensing Model Which licensing model should you choose? Per-processor licensing is generally required in instances in which the server will be accessed via the Web. This type of licensing includes servers used in Internet situations or servers that will be accessed from both inside and outside an organization’s firewall. Per-processor licensing might also be appropriate and cost effective for internal environments in which there are a very large number of users in relation to the number of SQL Server machines. An additional advantage to the perprocessor model is that it eliminates the need to count the number of devices connecting to SQL Server, which can be difficult to manage on an ongoing basis for a large organization.

Download from www.wowebook.com

SQL Server Licensing Models

33

Using the server/per-seat CAL model is usually the most cost-effective choice in internal environments in which client-to-server ratios are low.

1

Mixing Licensing Models You can mix both per-processor and server/CAL licensing models in your organization. If the Internet servers for your organization are segregated from the servers used to support internal applications, you can choose to use processor licensing for the Internet servers and server/CAL licensing for internal SQL Server instances and user devices. Keep in mind that you do not need to purchase CALs to allow internal users to access a server already licensed via a processor license: The processor licenses allow access to that server for all users.

Passive Server/Failover Licensing In SQL Server 2008, two or more servers can be configured in a failover mode, with one server running as a passive server so that the passive server picks up the processing of the active server only in the event of a server failure. SQL Server 2008 offers three types of failover support: . Database mirroring . Failover clustering . Log shipping If your environment uses an active/passive configuration in which at least one server in the failover configuration does not regularly process information but simply waits to pick up the workload when an active server fails, no additional licenses are required for the passive server. The exception is if the failover cluster is licensed using the per-processor licensing model and the number of processors on the passive server exceeds the number of processors on the active server. In this case, additional processor licenses must be acquired for the number of additional processors on the passive computer. In an active/active failover configuration, all servers in the failover configuration regularly process information independently unless a server fails, at which point one server or more takes on the additional workload of the failed server. In this environment, all servers must be fully licensed using either per-processor licensing or server/CAL licensing. Keep in mind that in some log shipping and database mirroring configurations, the standby (passive) server can be used as a read-only reporting server installation. Under this usage, the standby server is no longer “passive” and must be licensed accordingly.

Virtual Server Licensing Virtualization is defined broadly as the running of software on a “virtual environment.” A virtual environment exists when an operating system is somehow emulated (that is, does not run directly on the physical hardware). When you’re running virtualization software on a system, one or several applications and their associated operating systems can run on one physical server inside their respective virtual environments.

Download from www.wowebook.com

34

CHAPTER 1

SQL Server 2008 Overview

Running SQL Server 2008 inside a virtual operating environment requires at least one license per virtual operating environment. Within each virtual operating environment, the license allows you to run one or more instances of SQL Server 2008. The license for a virtual operating environment can be a server/CAL license or a processor-based license. If using a processor-based license, you must purchase a processor license for each processor that the virtual machine accesses. The total number of physical and virtual processors used by the virtual operating system environments cannot exceed the number of software licenses assigned to that server. However, if you are running Enterprise Edition and all physical processors in the machine have been licensed, you may run an unlimited number of virtual operating environments on that same machine.

Multiple Instances of SQL Server An option to virtualization is multi-instancing. With multi-instancing, multiple copies of SQL Server can be run concurrently in a single instance of an OS. Multi-instancing for SQL Server 2008 can take place both in a virtual environment or in a physical environment. Although multi-instancing offers a relatively high degree of isolation between copies of SQL Server 2008, this isolation takes place at the application level (instead of at the OS level). In SQL Server 2008, the Workgroup and Standard Editions now allow you to run any number of instances of the server software in one physical or virtual operating system environment on the licensed server. Previously, only the Enterprise Edition of the server license allowed multi-instancing.

Summary This chapter examined the various platforms that support SQL Server 2008 R2 and reviewed and compared the various editions of SQL Server 2008 that are available. Which platform and edition are appropriate to your needs depends on scalability, availability, performance, licensing costs, and limitations. The information provided in this chapter should help you make the appropriate choice. Chapter 2, “What’s New in SQL Server 2008,” takes at closer look at the new features and capabilities provided with the various SQL Server 2008 editions.

Download from www.wowebook.com

CHAPTER

2

What’s New in SQL Server 2008

IN THIS CHAPTER . New SQL Server 2008 Features . SQL Server 2008 Enhancements

SQL Server 2005 provided a number of significant new features and enhancements over what was available in SQL Server 2000. This is not too surprising considering there was a five-year gap between these major releases. Microsoft SQL Server 2008 is not as much of a quantum leap forward from SQL Server 2005, but it provides a number of new features and enhancements to further extend the performance, reliability, availability, programmability, and ease of use of SQL Server. This chapter explores the new features provided in SQL Server 2008 and SQL Server 2008 R2, as well as many of the enhancements to previously available features.

New SQL Server 2008 Features So what does SQL Server 2008 have to offer over SQL Server 2005? Following is an overview of the new features provided in SQL Server 2008: . New storage features—FILESTREAM storage, sparse columns and column sets, row-level and page-level data compression . New data types—Date, Time, and DATETIME2 data types; Hierarchyid data type; spatial data types; userdefined table type . New Transact-SQL (T-SQL) constructs—Compound operators, GROUPING SETS, MERGE statement, row constructors, table-valued parameters, INSERT over DML, new date and time functions . New performance features—Filtered indexes and statistics, FORCESEEK query hint, hash values for

Download from www.wowebook.com

36

CHAPTER 2

What’s New in SQL Server 2008

finding similar queries in the plan cache, Plan Guide Successful and Plan Guide Unsuccessful event classes, Guided/Misguided Plan Executions/sec Performance Monitor counters, LOCK ESCALATION option for ALTER TABLE, hot-add CPUs . New security features—Transparent data encryption, Extensible Key Management, SQL Server Audit . New database administration features—Backup compression, Change Data Capture, Change Tracking, the Data Collector, Policy-Based Management, SQL Server Extended Events, Resource Governor . New SQL Server management features—Transact-SQL Debugger, IntelliSense, error list window, multiserver queries, PowerShell integration SQL Server 2008 R2 further enhances SQL Server 2008 with the following new features: . Two new premium editions to meet the needs of large-scale datacenters and data warehouses: . SQL Server 2008 R2 Datacenter . SQL Server 2008 R2 Parallel Data Warehouse . SQL Server Utility for Multi-Server Management . PowerPivot for Excel and SharePoint . A number of new Reporting Services features including Report Builder 3.0, report parts, shared datasets, Sparklines and data bars, indicators, calculating aggregates of aggregates, maps, lookup functions The following sections take a closer look at each of these new features and, where appropriate, provide references to subsequent chapters where you can find more information and detail about the new features.

New Storage Features SQL Server 2008 provides a set of new features to reduce storage requirements and improve performance. One of the new features is FILESTREAM storage. FILESTREAM storage is a property that can be applied to varchar(max) columns; it enables SQL Server applications to store unstructured data, such as documents and images, directly in the NTFS file system while still maintaining the behavior of a database column. The advantages of FILESTREAM storage are improved performance and increased size of BLOB data, expanding from the 2GB limit of image columns to the available space in the file system. For more information on using FILESTREAM storage, see Chapter 42, “What’s New for Transact-SQL in SQL Server 2008.” Other storage features introduced in SQL Server 2008 are sparse columns and column sets. Sparse columns are ordinary columns that have an optimized storage format for null values. If you use sparse columns, you can also define a column set on the table that will return all sparse columns in the table. A column set is an untyped XML representation that combines all the sparse columns of a table into a structured output. For more information

Download from www.wowebook.com

New SQL Server 2008 Features

37

on defining sparse columns and column sets, see Chapter 24, “Creating and Managing Tables.”

2

Row-level and page-level data compression also are introduced in SQL Server 2008. Data compression helps to reduce both storage and memory requirements as the data is compressed both on disk and when brought into the SQL Server data cache. Row-level compression isn’t true data compression but implements a more efficient storage format for fixed-length data. Page-level compression is true data compression, using both column prefix and dictionary-based compression. For more information on implementing data compression, see Chapter 24.

New Data Types SQL Server 2008 introduces a handful of new data types. Two of the most welcome of these are the new DATE and TIME data types. These new data types allow you to store dateonly and time-only values. In addition, SQL Server now supports the DATETIME2 and DATETIMEOFFSET data types. DATETIME2 is a variation of the DATETIME data type that supports datetime values from 0001-01-01 to 9999-12-31 23:59:59.999999. DATETIMEOFFSET supports UTC-based datetime values that are time zone aware. The new Hierarchyid data type is a common language runtime (CLR) user-defined type (UDT) that provides a mechanism for representing and storing a tree structure in a table in an efficient manner. This data type is useful for storing data that represents a parent child, tree-like structure such as an organizational structure or a graph of links between web pages. Spatial data types are introduced in SQL Server 2008 as well. There are two new spatial data types: geometry and geography. The geometry data type supports planar, or Euclidean (flat-earth), data. The geography data type stores ellipsoidal (round-earth) data, such as GPS latitude and longitude coordinates. These new data types support the storage and manipulation of spatial data objects such as linestrings, points, and polygons. SQL Server 2008 also introduces a new user-defined table type that can be used as parameters in stored procedures and functions, as well as for defining table variables in a batch or the body of a stored procedure or function. For more information and examples on using the new SQL Server 2008 data types, see Chapter 42.

New Transact-SQL Constructs What would a new SQL Server release be without new T-SQL commands and constructs to further expand the power and capabilities of the T-SQL language? SQL Server 2008 is no exception (although SQL Server 2008 R2 is an exception because no new T-SQL constructs are introduced in R2). The new constructs provided in SQL Server 2008 include . Compound operators—New operators that provide a shorthand method of performing an operation and assigning a value to a local variable (for example, +=, *=).

Download from www.wowebook.com

38

CHAPTER 2

What’s New in SQL Server 2008

. GROUPING SETS—New operator added to the GROUP BY clause to perform multiple grouping operations in a single query. . MERGE statement—New DML statement that can perform INSERT, UPDATE, or DELETE operations on a target table based on the results of a join with a source table. . Row constructors—An enhancement to the VALUES clause that allows multiple row inserts within a single INSERT statement. Also provides the ability to use the VALUES clause to create a pseudo table of values in a subquery or common table expression. . Table-valued parameters—New parameter type that can be assigned the new userdefined table types. Table-valued parameters enable you to pass a table variable containing multiple rows of data to a stored procedure or function without the need to create a temporary table. To coincide with the new DATE and TIME data types, SQL Server 2008 also introduces a few new date and time functions: . SYSDATETIME()—Returns the current system datetime as a DATETIME2(7) value . SYSDATETIMEOFFSET()—Returns the current system datetime as a DATETIMEOFFSET(7) value . SYSUTCDATETIME—Returns the current system datetime as a DATETIME2(7) value representing the current UTC time . SWITCHOFFSET (DATETIMEOFFSET, time_zone)—Changes the DATETIMEOFFSET value from the stored time zone offset to the specified time zone . TODATETIMEOFFSET (datetime, time_zone)—Converts a local datetime value for the specified time zone to a DATETIMEOFFSET UTC value For more information and examples on using the new SQL Server 2008 T-SQL constructs, see Chapter 42.

New Performance Features SQL Server 2008 also introduces some new features and enhancements for monitoring, managing, and improving query performance. Among these new features are filtered indexes and statistics. A filtered index is a nonclustered index defined on a subset of data using a filter predicate to index only a portion of rows in the table. Filtered statistics are statistics defined on a subset of data in the table using a filter predicate. A well-designed filtered index can improve query performance, reduce index maintenance costs, and reduce index storage costs compared with full-table indexes, especially when columns contain a large number of rows with null or a single value that isn’t searched on but can skew the index and statistics. For more information on creating and using filtered indexes and statistics, see Chapter 34, “Data Structures, Indexes, and Performance.” SQL Server 2008 provides FORCESEEK as a new table and query hint for controlling how SQL Server optimizes a query; it forces the optimizer to use only an index seek operation to access the data in the referenced table or view. For more information on using the FORCESEEK hint, see Chapter 35, “Understanding Query Optimization.”

Download from www.wowebook.com

New SQL Server 2008 Features

39

2

Plan guides were a feature introduced in SQL Server 2005. Plan guides can be used to optimize the performance of queries when you cannot or do not want to change the text of the query directly (for example, when queries in a third-party database application are not performing as expected). SQL Server 2008 provides additional features related to plan guides to make implementing and managing them easier. Among these features are new event classes (Plan Guide Successful and Plan Guide Unsuccessful) that can be monitored via SQL Server Profiler to determine when plan guides are being applied. There are also two new Performance Monitor counters (Guided/Misguided Plan Executions/sec) that you can use to monitor via Performance Monitor how often plan guides are being used or not being used. SQL Server 2008 also now generates hash values for query plans in the plan cache. The sys.dm_exec_query_stats and sys.dm_exec_requests dynamic management views (DMVs) now provide query hash and query plan hash values that you can use to help find similar queries in the plan cache. Locating similar queries can help you determine the aggregate resource usage for similar queries and similar query execution plans so that you can better focus your query tuning efforts and help identify which queries may get the most benefit from using plan guides. For more information on query plans and using plan guides, see Chapter 35. To provide greater control of locking, SQL Server 2008 offers the new LOCK ESCALATION table option. This option specifies the allowed methods of lock escalation for a table. The default is AUTO, which allows the Database Engine to select the appropriate lock escalation level for the query if a table is partitioned. You can also specify TABLE to force full tablelevel locking whether or not a table is partitioned. A third option, DISABLE, prevents escalation to a table-level lock in most cases. For more details on locking and the LOCK ESCALATION option, see Chapter 37, “Locking and Performance.” One additional new feature in SQL Server 2008 Enterprise Edition is hot-add CPU. Hot-add CPU is the capability to dynamically add CPUs to a running system. Additional CPUs can be made available logically by online hardware partitioning, virtually through a virtualization layer, or even physically by adding new hardware on systems that support adding physical CPUs while the system is online. Hot-add CPU, which requires hardware support, is available only when you’re running Windows Server 2008 Datacenter or Enterprise Edition.

New Security Features SQL Server 2005 provided the capability to encrypt data at the column level. However, this encryption was not transparent to the end users or applications. Encrypting and decrypting the data required coding changes to use the built-in encryption and decryption functions. SQL Server 2008 introduces transparent data encryption (TDE), which allows for encrypting the entire database without affecting client applications. The purpose of TDE is to protect sensitive data in the event a database file or backup is stolen. Encryption is done in real-time at the page level as the data is written to disk and decrypted as the data is read from disk. The encryption is based on a database encryption key (DEK), which is a symmetric key secured by using a certificate stored in the master database of the server or an asymmetric key protected by an Extensible Key Management (EKM) module.

Download from www.wowebook.com

40

CHAPTER 2

What’s New in SQL Server 2008

Extensible Key Management, which is also new with SQL Server 2008, enables you to store the keys used to encrypt data separately from the data it protects. SQL Server 2008 EKM enables the encryption keys that protect the database files to be stored in a removable device such as a smartcard, USB device, or a software-based Extensible Key Management (EKM)/Hardware Security Module (HSM) module. EKM facilitates separation of duties by taking key management out of the hands of the database administrators. For more information on implementing and using transparent data encryption and extensible key management, see Chapter 12, “Data Encryption.” SQL Server already provides a number of existing audit methods (SQL Trace, C2 audit mode, DDL triggers). In addition to these, SQL Server 2008 adds an additional audit method: SQL Server Audit. SQL Server Audit, based on the new Extended Events feature, allows you to monitor server- or database-level events or groups of events. You can set up and monitor audit events at the server or database level and audit the audit actions themselves. For more information on SQL Server Audit, see Chapter 13, “Security and Compliance.”

New Database Administration Features SQL Server 2008 introduced backup compression for Enterprise Edition. With SQL Server 2008 R2, backup compression is supported in Standard and all higher editions (every edition of SQL Server 2008 and later can restore a compressed backup, however). In addition to the space savings provided by compressed backups, compressing a backup also typically increases backup speed because it requires less device I/O. However, the I/O cost savings comes at the expense of increased CPU usage caused by the compression process. For more information on compressing backups, see Chapter 14, “Database Backup and Restore.” Policy-Based Management is a new mechanism in SQL Server 2008 for managing one or more instances of SQL Server 2008. SQL Server Policy-Based Management can help to simplify management operations such as setting database options across multiple servers, checking SQL Server configurations, or enforcing naming conventions, helping to reduce the total cost of ownership (TCO) of administering multiple SQL Server instances. SQL Server Management Studio (SSMS) can be used to define and implement policies for managing SQL Server instances, databases, or other SQL Server objects as well as ondemand checking and enforcement of policies. Checking and enforcement of these policies can also be scheduled using SQL Server Agent. For more information on Policy-Based Management in SQL Server, see Chapter 22, “Administering Policy Based Management.” Currently, several options are available for troubleshooting or getting information about SQL Server–generated events: SQL Server Profiler, SQL Server Log, dynamic management views and functions, SQL Trace, trace flags, Windows Application and System logs, performance counters, and so on. SQL Server 2008 introduces a new event infrastructure, Extended Events. Extended Events is a general-purpose event-handling system for server systems. Currently, the Extended Events infrastructure supports the correlation of data from SQL Server and, under certain conditions, the correlation of data from the operating system and database applications. Extended Events has the potential to make other trou-

Download from www.wowebook.com

New SQL Server 2008 Features

41

bleshooting options obsolete in future releases and become the common denominator for troubleshooting purposes. As mentioned previously, the new SQL Server Audit feature is based on Extended Events. For more information on configuring and using Extended Events for monitoring SQL Server 2008, see Chapter 39, “Monitoring SQL Server Performance.”

2

Resource Governor, another new technology in SQL Server 2008, enables you to manage and control the allocation of resources for SQL Server according to workload. Similarly sized queries or requests that can, and should be, treated the same are assigned to a workload group as the requests are received. Each workload group is associated to a pool of resources that represents the physical resources for SQL Server (currently, for SQL Server 2008, these resources are CPU and memory). Limits are specified on resource consumption for these incoming requests. In an environment where multiple distinct workloads are present on the same server, Resource Governor enables you to differentiate these workloads and allocate shared resources as they are requested, based on the limits you specify. For more information on implementing and configuring Resource Governor, see Chapter 40, “Managing Workloads with the Resource Governor.” Change Data Capture (CDC) and Change Tracking are new features in SQL Server 2008 with similar names but different purposes. CDC is an asynchronous mechanism that captures all changes of a data row from the transaction log and stores them in change tables. The information captured is available in relational format and can be accessed by client applications such as extract, transform, and load (ETL) processes. All intermediate values of a row are stored. Using Change Data Capture, you can avoid using expensive techniques such as triggers, time stamp columns, and join queries to identify and capture the changes made to data. Change Tracking, on the other hand, is a lightweight synchronous mechanism that tracks data modifications but records only the fact that a row has changed. Applications can use Change Tracking to identify which rows have changed for a user table and refresh their data stores with the latest values from these rows by requerying the table. For more information on using CDC and Change Tracking, see Chapter 42.

New SQL Server Management Studio Features SQL Server Management Studio (SSMS) was first introduced in SQL Server 2005. SSMS is a full-featured, robust SQL Server administration and development tool. However, there was clearly room for improvement, and SQL Server 2008 provides some long-awaited enhancements. One of the most anticipated (and missed) features in SSMS was a built-in T-SQL debugger. Prior to SQL Server 2005, SQL Server Enterprise Manager had a built-in T-SQL Debugger. A lot of users were disappointed a T-SQL debugger was not included with this version of SSMS. To debug T-SQL, you needed to install Visual Studio (VS). Fortunately, a built-in debugger returns to SSMS in SQL Server 2008. Another long-awaited feature for SSMS is IntelliSense. IntelliSense is a useful feature in the Query Editor for looking up language elements and object names without having to leave

Download from www.wowebook.com

42

CHAPTER 2

What’s New in SQL Server 2008

the editor. IntelliSense can even automatically complete and insert language elements directly into your code. In conjunction with IntelliSense, SSMS also provides the error list window The error list window displays all errors and warnings produced by IntelliSense as you develop your code in the Database Engine Query Editor. You can double-click the error message entry to jump to the error location. As you fix errors, they are automatically removed from the error list window. One other new capability built in to SSMS in SQL Server 2008 is multiserver queries. This feature allows you to execute T-SQL statements against multiple servers defined in a server group at the same time. If you open a Query Editor from the server group in the Registered Servers window, the T-SQL statements in the current Query Editor are executed against all the servers in the group. The results from the query can be merged into a single results pane or can be returned in separate results panes for each server. For more details on these new features in SSMS, see Chapter 4, “SQL Server Management Studio.”

PowerShell Integration SQL Server 2008 provides integrated support for Windows PowerShell, a powerful scripting shell that enables administrators and developers to automate server administration and application deployment. The Windows PowerShell language supports more complex logic than Transact-SQL scripts, enabling SQL Server administrators to build more robust and complex administration scripts. SQL Server provides two snap-ins to Windows PowerShell for creating scripts to manage SQL Server: . A SQL Server provider, which enables a simple navigation mechanism similar to file system paths where the drive is associated with a SQL Server management object model and the nodes are based on the object model classes. This allows you to use familiar commands such as cd and dir to navigate the paths similar to the way you navigate folders in a command prompt window. . A set of cmdlets, which are commands used in Windows PowerShell scripts to specify a SQL Server action, such as running a SQLCMD script containing Transact-SQL or XQuery statements For more information on managing SQL Server using PowerShell, see Chapter 17, “Administering SQL Server 2008 with PowerShell.”

New Premium SQL Server Editions SQL Server 2008 R2 introduces two new premium-level editions of SQL Server: Datacenter Edition and Parallel Data Warehouse. Built on SQL Server 2008 R2 Enterprise, SQL Server 2008 R2 Datacenter is designed to deliver a high-performing data platform that provides the highest levels of scalability for large application workloads, virtualization and consolidation, and management for an

Download from www.wowebook.com

New SQL Server 2008 Features

43

organization’s database infrastructure. Datacenter helps enable organizations to cost-effectively scale their mission-critical environment. Key features of Datacenter include . Application and multiserver management for enrolling, gaining insights, and managing more than 25 instances

2

. Highest virtualization support for maximum return on investment (ROI) on consolidation and virtualization . High-scale complex event processing with SQL Server StreamInsight . Support for more than 8 processors and up to 256 logical processors SQL Server 2008 R2 Parallel Data Warehouse is a highly scalable data warehouse appliancebased solution. Parallel Data Warehouse delivers performance at low cost through a massively parallel processing (MPP) architecture and compatibility with hardware partners, allowing you to scale your data warehouse to tens and even hundreds of terabytes. Key features provided by Parallel Data Warehouse include . Advanced data warehousing capabilities such as Star Join Queries and Change Data Capture . Integration with SSIS, SSRS, and SSAS . Support for industry-standard data warehousing hub-and-spoke architecture and parallel database copy

SQL Server Utility for Multiserver Management SQL Server 2008 R2 features new SSMS dashboards for observing information on more than one server from the same screen by utilizing the new SQL Server Utility. The SQL Server Utility models an organization’s SQL Server–related entities in a unified view. Utility Explorer and SQL Server Utility viewpoints in SQL Server Management Studio provide administrators a holistic view of SQL Server resource health. Entities that can be viewed in the SQL Server Utility include . Instances of SQL Server . Data-tier applications . Database files . Volumes SQL Server Utility is covered in more detail in Chapters 4 and 39.

PowerPivot for Excel and SharePoint PowerPivot is a new tool that integrates SQL Server with Microsoft Excel and SharePoint to create a self-service business intelligence (BI) solution for the enterprise. PowerPivot for Excel and SharePoint are client and server components that integrate Analysis Services with Excel and SharePoint. PowerPivot for Excel is an add-in that allows you to create PowerPivot workbooks that can assemble and relate large amounts of data from different

Download from www.wowebook.com

44

CHAPTER 2

What’s New in SQL Server 2008

sources. PowerPivot for SharePoint extends SharePoint 2010 and Excel Services to add server-side processing, collaboration, and document management support for the PowerPivot workbooks that you publish to SharePoint. Together, the PowerPivot client add-in and server components provide an end-to-end solution that furthers business intelligence data analysis for Excel users on the workstation and on SharePoint sites. For more information on PowerPivot, see Chapter 51, “Analysis Services.”

New Reporting Services Features SQL Server 2008 R2 introduces a number of new features for Reporting Services. The Reporting Services enhancements are probably the most significant aspect of the R2 release. One of the key changes in SQL Server 2008 R2 is an updated version of the Report Manager. The SQL Server 2008 R2 Report Manager provides an improved user experience via interface changes, including an updated color scheme and layout, in an effort to provide easier navigation for managing report properties and Report Server items. Following are some of the key enhancements to Report Manager in R2: . An improved workflow for viewing and managing reports and Report Server items through the use of a new drop-down menu to access various configuration options for each report or Report Server item in a folder . Elimination of the need to render a report before accessing and configuring report properties when in default view . Increased screen space for the Report Viewer when rendering reports . An updated Report Viewer toolbar, which includes some updates to the toolbar controls, as well as the capability to export report data to an Atom service document and data feeds The set of new and enhanced features in SQL Server 2008 R2 for Reporting Services includes . Report parts—You can store these reusable report items on a Report Server or on a SharePoint site that is integrated with a Report Server. . Sparklines and data bars—These simple charts convey a lot of information in a little space, often inline with text. . Indicators—These minimal gauges convey the state of a single data value at a glance. Indicators can be used by themselves in dashboards or free-form reports. . Calculation of aggregates of aggregates—You can now create expressions that calculate an aggregate of an aggregate. . Improved report pagination—Reporting Services provides more control over report pagination including dynamic updating of page names and numbers when a report is run, as well as disabling page breaks entirely. . Map reports—Report Designer now provides a Map Wizard and Map Layer Wizard so that you can add maps and map layers to your report to help visualize data against a geographic background.

Download from www.wowebook.com

SQL Server 2008 Enhancements

45

. Shared datasets—This Report Server feature can retrieve data from shared data sources that connect to external data sources, providing a way to share a query to help provide a consistent set of data for multiple reports. . Cache refresh plans—These plans allow you to cache reports or shared dataset query results on first use or from a schedule.

2

. Improved previewing of reports—Report Builder 3.0 provides a better preview experience with the introduction of edit sessions that enable the reuse of cached datasets when you are previewing reports, which allows reports to render more quickly. For more information on designing and deploying reports using Reporting Services and more information on the extensive set of new Reporting Services features in R2, see Chapter 53, “SQL Server 2008 Reporting Services.”

SQL Server 2008 Enhancements In addition to the brand new features in SQL Server 2008, there are a number of enhancements to existing features provided by SQL Server 2008 and SQL Server 2008 R2. The following sections provide an overview of the major enhancements.

SQL Server Management Studio In addition to the new SSMS features discussed previously, SSMS has also received a number of enhancements in SQL Server 2008; you are now able to do the following: . Customize the columns displayed by the Object Explorer Details window. . Display the properties of a selected item from Object Explorer Details at the bottom of the window. . View a color-coded status bar at the bottom of the window for Transact-SQL and MDX code editors which provide information about the editor connection. The status bar changes color when a code editor opens multiple connections. . Customize the tab name for items in the title bar of the code editor windows. . Configure the number of rows returned when you open tables via the Object Browser. . Create and manage plan guides via the Programmability folder in Object Browser.

Dynamic Management Views SQL Server 2008 adds five new dynamic management views to return memory-related information about SQL Server: . sys.dm_os_memory_brokers—Returns information about memory brokers, the components that track memory allocations . sys.dm_os_memory_nodes—Returns memory allocation information for memory allocated through SQL Server Memory Manager

Download from www.wowebook.com

46

CHAPTER 2

What’s New in SQL Server 2008

. sys.dm_os_nodes—Returns information about SQL OS memory nodes, internal structures of SQL OS that abstract hardware processor locality . sys.dm_os_process_memory—Returns complete information about memory allocated to SQL Server process space . sys.dm_os_sys_memory—Describes the memory state for the operation system In addition, the cpu_ticks_in_ms column in the sys.dm_os_sys_info dynamic management view has been discontinued, and two new columns, sqlserver_start_time_ms_ticks and sqlserver_start_time, have been added.

Database Mirroring SQL Server 2008 provides a number of enhancements to database mirroring, mostly related to performance of database mirroring, including compression of the transaction log records being streamed to the mirror database, asynchronous write-ahead on the incoming log stream and read-ahead during the undo phase, and improved use of the log send buffers. For more information on database mirroring and the improvements, see Chapter 20, “Database Mirroring.”

SQLCLR Enhancements SQL Server 2008 extends the SQLCLR by extending the 8KB size limit for CLR user-defined types and CLR user-defined aggregates, supporting the definition of ordered table-valued functions, providing support for multiple input parameters for user-defined aggregates, and including the option to define static methods as user-defined functions. For more information on the enhancements to SQL CLR, see Chapter 46, “Creating .NET CLR Objects in SQL Server 2008.”

Replication Enhancements SQL Server 2008 introduces a number of usability and manageability enhancements for peer-to-peer replication and the Replication Monitor. Peer-to-peer replication includes the following significant usability and manageability improvements: . A new option, enabled by default, that allows the Distribution Agent to detect conflicts during synchronization and to stop applying changes at the affected row. . The capability to add nodes to a replication topology without quiescing the topology. . The capability to configure a topology visually in the Configure Peer-to-Peer Topology Wizard. The Topology Viewer enables you to perform common configuration tasks, such as adding new nodes, deleting nodes, and adding new connections between existing nodes. The Replication Monitor includes the following usability improvements: . Most of the Replication Monitor grids allow you to specify which columns to view, sort by multiple columns, and filter rows in the grid based on column values.

Download from www.wowebook.com

SQL Server 2008 Enhancements

47

. The Common Jobs tab for the Publisher node has been renamed to Agents. . The single Warnings and Agents tab for the publication node has been split into separate Warnings and Agents tabs to emphasize the difference between administering performance warnings and monitoring replication agents.

2

For more information on configuring and using replication in SQL Server 2008, see Chapter 19, “Replication.”

SQL Server Integration Services Enhancements Integration Services in SQL Server 2008 received enhancements and improvements as well. Following are some of these enhancements: . Improvements in the parallel execution of data flow pipeline paths on multiprocessor systems, going beyond the SQL Server 2005 limit of two engines. . A new script environment. Visual Studio for Applications (VSA) has been replaced with Visual Studio Tools for Applications (VSTA). VSTA allows the development of scripts written on Visual C# and Visual Basic, providing support for the Script Task and Script Component. VSTA also supports debugging and adding managed assemblies to a script at design time. . Increased performance and improved caching options for Lookup Transformations. . Data profiling to improve data quality by identifying potential data quality problems. . Support for the new Change Data Capture feature in SQL Server 2008, providing an effective method for performing incremental data loads from source tables to data marts and data warehouses. For more information on using SQL Server Integration Services in SQL Server 2008, see Chapter 52, “SQL Server Integration Services.”

Service Broker Enhancements SQL Server 2008 provides the following enhancements to Service Broker: . Support for conversation priorities. This support allows administrators and developers to specify that messages for important Service Broker conversations are sent and received before messages from less important conversations to ensure that low-priority work does not block higher-priority work. . The new ssbdiagnose command-prompt utility to analyze and diagnose Service Broker configurations and conversations. . A new performance object and counters that report how often Service Broker dialogs request transmission objects and how often inactive transmission objects are written to work tables in tempdb. . Support for Service Broker in SQL Server Management Studio via new Service Broker Elements in Object Explorer.

Download from www.wowebook.com

48

CHAPTER 2

What’s New in SQL Server 2008

For more information on the new features and capabilities of Service Broker, see Chapter 49.

Analysis Services Enhancements SQL Server 2008 also introduces some new features and enhancements to Analysis Services. Following are some of the primary improvements: . A new Aggregation Designer makes it easier to browse and modify aggregation designs. . Aggregation design and usage-based optimization wizards have been simplified and enhanced. . New AMO warning messages alert users when they depart from design best practices or make logical errors in database design. . Simplified and enhanced cube and dimension wizards help you create better cubes and dimensions in fewer steps. . A new Attribute Relationship designer makes it easier to browse and modify attribute relationships. . A new Key Columns dialog box makes editing key columns easier. . Key columns can now be edited in the Properties panel. . An updated Dimension Structure tab helps make modifying attributes and hierarchies easier. . A new storage structure is available and performance has been enhanced in all backup and restore scenarios. . When creating a mining structure, you can now divide the data in the mining structure into training and testing sets. . You can now attach filters to a mining model and apply the filter during both training and testing. Applying a filter to the model lets you control the data used to train the model and lets you more easily assess the performance of the model on subsets of the data. . Cross-validation is now available in the Mining Accuracy Chart view of the Data Mining Designer. . SQL Server 2008 supports the creation, management, and use of data mining models from Microsoft Excel when you use the SQL Server 2008 Data Mining add-ins for Office 2007. . You are able to add aliases to columns in a mining model to make it easier to understand column content and reference the column in DMX statements. For more information on the new features and capabilities of SQL Server Analysis Services (SSAS), see Chapter 51.

Download from www.wowebook.com

SQL Server 2008 Enhancements

49

Installation Enhancements Starting with SQL Server 2008 Service Pack 1, you can now perform slipstream installations of SQL Server 2008. Slipstream is the integration of the original installation media files with a service pack and/or a cumulative update so that they can be installed in a single step.

2

SQL Server 2008 also provides the capability to selectively uninstall cumulative updates and/or service packs via the Programs and Features control panel. For more information on installing and upgrading SQL Server 2008, see Chapters 8, “Installing SQL Server 2008,” and 9, “Upgrading to SQL Server 2008.”

Deprecated Features In addition to the new and enhanced features in SQL Server 2008, it’s important to note the features for which support has been discontinued. Table 2.1 lists the unsupported/deprecated features along with their replacements, if any.

TABLE 2.1 Deprecated Features in SQL Server 2008 Deprecated Feature

Replacement

sp_addalias

None

DUMP and LOAD statements

BACKUP and RESTORE

BACKUP LOG WITH NO_LOG and BACKUP LOG WITH TRUNCATE_ONLY

None; however, changing the database to simple recovery clears the transaction log

BACKUP TRANSACTION

BACKUP LOG

sp_helpdevice

sys.backupdevices catalog view

60, 65, and 70 compatibility levels

Support is provided only for compatibility levels 80 and higher

User groups (sp_addgroup, sp_changegroup, sp_dropgroup, sp_helpgroup)

Roles

Northwind and pubs databases

AdventureWorks database

To help keep track of deprecated features so that you can identify potential future upgrade and compatibility problems, SQL Server 2008 provides the SQL Server: Deprecated Features performance counter and the Deprecation Announcement and Deprecation Final Support event classes, which you can monitor via SQL Server Profiler or SQL Trace.

Download from www.wowebook.com

50

CHAPTER 2

What’s New in SQL Server 2008

Summary SQL Server 2008 provides a number of new and long-awaited features and enhancements. This chapter provides an overview of the new features and enhancements that ship with SQL Server 2008 and SQL Server 2008 R2. To learn more, refer to the other chapters referenced here. However, before we get into covering the features and capabilities of SQL Server 2008 and SQL Server 2008 R2, we’ll first take a look at some real-world production implementations of SQL Server to give you an idea of what is possible with SQL Server in both the online transaction processing (OLTP) world and in the decision support systems (DSS)/business intelligence (BI) realms.

Download from www.wowebook.com

CHAPTER

3

Examples of SQL Server Implementations

IN THIS CHAPTER . Application Terms . OLTP Application Examples . DSS Application Examples

As you will see in this chapter, companies use SQL Server for many types of applications and on most tiers now. Gone are the days when you would second guess yourself choosing to use SQL Server over a competing database engine (such as Oracle or DB2 on a UNIX platform) to ensure you got optimal transactional throughput, high availability, and the highest performance. In fact, SQL Server outnumbers both of these database vendors in installed sites globally. Microsoft SQL Server has arrived! The SQL Server Unleashed team has gathered a few showcase SQL Server–based applications to give you an example of what is possible with SQL Server in both the online transaction processing (OLTP) world and in the decision support systems (DSS)/business intelligence (BI) realms. Each example in this chapter comes from real-life database applications running in production environments at major organizations around the world. In general, all the examples in this book come from our direct customer experiences. We often translate those real-life customer implementations into AdventureWorks2008 or bigpubs2008 database terms so that you can easily re-create them for your own use. This chapter describes two OLTP applications: one is a traditional ERP system using SQL Server as the database layer, and the other is an online shopping system with shopping carts and both high-availability and high-performance requirements.

Download from www.wowebook.com

52

CHAPTER 3

Examples of SQL Server Implementations

On the DSS/BI side, this chapter presents a traditional conformed-dimension star schema data warehouse implementation for a high-tech company and then shows you what this looks like implemented as an online analytical processing (OLAP) cube created by Analysis Services. Under the DSS/BI examples, this chapter describes a hybrid distributed reporting example that uses multiple SQL Server technologies to get the most out of a complex application environment in the healthcare industry.

Application Terms Online transaction processing, or OLTP, is a class of applications that facilitate and manage transaction-oriented processing, typically for data entry, complex business processes (such as order entry), and retrieval transactions. The term transaction in the context of computer or database transactions is a finite set of changes that are grouped together and can be undone together if any one piece does not complete (or fails). Often, however, we speak of transactions as a business “unit of work” that can span multiple database transactions as one logical business transaction. The term OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automated teller machine (ATM) application for a bank is a classic example of this type of OLTP transaction. In many applications, efficient OLTP applications may depend on sophisticated transaction management software and/or database optimization tactics to facilitate the processing of large numbers of concurrent users and updates to an OLTP-oriented database. In a geographic-distributed database system, OLTP brokering programs are used to distribute transaction processing among multiple computers on a network. These days, central OLTP is often underneath the covers and integrated into most service-oriented architectures (SOAs) and exposed as web services that can be easily orchestrated for different application functionality. Decision support systems (DSS) have been around since the late 1960s, beginning with model-driven DSS and running the gamut of financial planning systems, spreadsheets, and massive multidimensional databases more recently. We speak of data warehouses, data marts, executive information systems, OLAP cubes, and business intelligence when referring to DSS. All enable complex decision support capabilities, multidimensional data analysis, online analytical processing, business intelligence, spatial DSS, and complex querying and reporting capabilities. DSS system categories are . Data analysis systems that support the manipulation, aggregation, and transformation of data for a specific task or purpose

Download from www.wowebook.com

OLTP Application Examples

53

. Pure analysis information systems that enable a series of decision-oriented databases and small models . Complex accounting and financial models that calculate and forecast behavior based on business events and financial results . Predictive models that estimate the consequences of actions on the basis of simulation models . Optimization models that provide insight and possible actions a business can take by generating an optimal solution consistent with a series of constraints

3

Microsoft has the capability to fully address the first three types and is only now venturing into predictive and optimization modeling. The examples in this chapter illustrate a classic data warehouse (star schema/snowflake, multidimensional, measures/facts), a small distributed data mart, and an OLAP cube. For each example in this chapter, we try to describe the overall purpose of the application, the major use cases, and the technology and architecture on which they were deployed. Where appropriate, we might showcase a data model diagram, a relational schema, or a distributed topology that gives you some insight into why the implementation was done a specific way. You are likely to recognize some use cases that may be the same in your environment and therefore possibly apply the same techniques or solutions to serve you as well.

OLTP Application Examples The following sections describe what the major Enterprise Resource Planning (ERP) vendor SAP AG has implemented using SQL Server for its database layer.

OLTP ERP Example SAP business solutions are composed of a comprehensive range of products that empower an enterprise with a flexible, end-to-end solution. A critical challenge in implementing an SAP solution is the selection of a data platform to deliver the advanced features and capabilities needed to support the most demanding workloads. The Microsoft SQL Server database software (either SQL Server 2008 or SQL Server 2005) is the relational database management system (RDBMS) of choice for deploying secure, reliable, highly available, high-performing, and scalable SAP installations. Plus, SQL Server high-availability features can minimize downtime for any SAP implementation. The company’s flagship applications are the NetWeaver-based SAP ERP/Business Suites and SAP R/3 industry solutions. Since 1993, SAP and Microsoft have been working together to provide a deeply integrated Microsoft platform with SAP solutions. Microsoft is currently

Download from www.wowebook.com

54

CHAPTER 3

Examples of SQL Server Implementations

the most selected platform for R/3 and SAP application deployments: more than 56,000 SAP application installations run on Windows, which is more than all other platforms combined. Of these, more than 23,000 SAP application installations worldwide are running with SQL Server as the RDBMS. In fact, this $11.5 billion company uses its own software for its internal ERP purposes completely deployed on the Microsoft SQL Server platform. As you can see in Figure 3.1, SAP’s ERP footprint is a three-tier architecture consisting of a variety of client types, a horizontally scalable application server tier, and a highly available, high-performance database tier.

GUI

WEB GUI

RFC

HTML/SOAP client

Web Services client

....

Client Tier

Application Server 1

Application Server 2

....

Application Server n

Application Tier

SAP DB

SQL Server 2008

Database Tier

FIGURE 3.1 SAP multitier architecture with SQL Server as the database layer. The SAP multitiered client/server architecture is composed of three levels: . Client/Presentation Tier—This tier supports SAP graphic user interfaces (GUIs) such as SAP GUI, SAP WebGUI, and other products that connect to the SAP NetWeaver Application Server using one of the supported interfaces. The client tier also includes applications to access SAP using Web Services. For example, applications including smart clients and Microsoft Office applications can integrate SAP data, such as when the Microsoft Excel spreadsheet software is used with Web Services. Applications that use the SAP RFC interface are also part of the presentation tier. Especially in the Microsoft world, connecting to the application tier via RFC became common with the SAP .NET connector, which offers a bandwidth of .NET classes and methods that are mapped to SAP Business Application Programming Interfaces (BAPIs) that are accessible via RFC.

Download from www.wowebook.com

OLTP Application Examples

55

3

. Application Tier—This tier can contain multiple SAP NetWeaver Application Server instances. However, it needs to contain at least one application instance. If multiple instances are used in one system, each application instance is typically run on separate server hardware or virtual machines. The application tier and database tier can run on the same server hardware on small-scale systems and in some very large hardware configurations. The complete processing of the business transactions and workflow is handled on the application side. No business logic is pushed down for execution into the database layer. The database tier is used for data storage only. Technically, an SAP application instance is a collection of processes called work processes in SAP terminology. Based on a configuration profile for each individual instance, these work processes fulfill different tasks and requests. To share user contexts and user data, the work processes of one instance share larger areas of memory. The business logic itself was originally programmed in a 4GL language called ABAP; it has now been supplemented by the possibility to code business logic in Java as well. . Database Tier—This tier supports the SAP database, including the SAP Business Suite or R/3 and other SAP applications hosted on SQL Server. The database tier typically runs one database schema for each SAP product using separate server hardware. The database servers can be connected to a storage area network (SAN), Network Attached Storage (NAS), or locally attached storage. Each SAP application process establishes two connections to SQL Server (as shown in Figure 3.2). There is no sharing of connections between the different SAP processes of an instance. SAP does not use connection pooling. Every one of the processes establishes Application Server mySAP Work Process

Database Interfaces (DBSL) Data Read Connections Read uncommitted, Create Stored Procedures

SQL SNAC ODBC / OLE DB

Data Modification Connections Updates, Inserts, Deletes, Server-side cursors (committed reads)

SAP DB SQL Server 2008

Database Tier

FIGURE 3.2 SAP multiple connections to SQL Server.

Download from www.wowebook.com

56

CHAPTER 3

Examples of SQL Server Implementations

connections at startup and keeps them until the process is shut down or restarted. SAP uses Multiple Active Result Sets (MARS) and multiple open client-side cursors that can use the same connection. Each connection is used for different purposes. One performs uncommitted reads of the data or creates stored procedures as needed. The other connection is for data modifications such as updates, inserts, deletes, and server-side cursors. The application tier has been optimized around using these connections. We featured this ERP application because SAP has proven to the world how rock solid SQL Server is and that the smallest company to companies as large as SAP itself can safely and confidently deploy on SQL Server without hesitation.

OLTP Shopping Cart Example This shopping cart example features an Internet-based e-commerce implementation for a leading health and vitamin retailer. At the center of this high-availability application is the shopping cart and a global ordering and fulfillment capability. Approximately 5,000 to 10,000 users are online concurrently at any one time, and this application supports up to 50 million hits per day. A key to this application is that it is “stateless,” and all database calls are extremely simple and shallow. This web-facing application is built on JRUN but features SQL Server at the database layer, as shown in Figure 3.3.

eCommerce – with SQL Clustering C: Windows 2003 MSCS Advanced Server

Active

Cluster Group Resources

Network

JRUN/IIS

SQL Server 2008 (physical)

SQL Server 2008 (Virtual SQL Server)

SCSI

ASQL\ASPSERV1

SQL Server 2008 (physical)

Passive

Windows 2003 Advanced Server MSCS Active/Passive

ASPProd1 Local Binaries

Q:

MS DTC SQL Agent

E:

Master DB

F:

TempDB

G:

HOE DB

Quorum Disk

C:

ASPProd2 Local Binaries

FIGURE 3.3 An e-commerce Internet application with a SQL Server database tier.

Download from www.wowebook.com

DSS Application Examples

57

This e-commerce application is just a part of a much larger Application Service Provider (ASP) platform. This ASP company houses hundreds of other companies’ applications in multiple data centers around the globe. To ensure high availability, this ecommerce application was built on a two-node Active/Passive SQL Clustering configuration. In the four years that this application has been running, the database tier has achieved a 99.99% uptime with rolling updates at both the operating system and SQL Server levels. The OLTP database on SQL Server is approximately 10TB and utilizes log shipping to create a reasonably current disaster recovery (DR) copy (that has never been utilized!). Ninety percent of the reporting is done off the DR copy (approximately one-hour old data on average). This is fully within the service-level requirements needed by the health and vitamin company.

3

It’s important to note here is that if availability falls below 99.99 (four 9s), the ASP company must pay fairly large financial penalties as a part of its agreement with its customers. Each physical server in the cluster is a Dell 8 CPU server with 256GB RAM on SQL Server 2008 Enterprise editions on Windows 2003 Advanced Servers. This has been a rock-solid implementation from the very start.

DSS Application Examples The DSS/BI examples start with a traditional star schema data warehouse deployment for a Silicon Valley high-tech company. The same data has also been deployed as an OLAP cube created by Analysis Services. The last example, describes a hybrid distributed reporting system that, uses multiple SQL Server technologies such as data replication, database mirroring, and database snapshots to get the most out of a complex healthcare industry application environment.

DSS Example One A Silicon Valley computer company implemented a traditional data warehouse using a star schema approach. A star schema provides multiple paths (dimensions) to the central data facts. As you can see in Figure 3.4, a decision support user can get to the Sales Units, Sales Price, and Sales Returns through Geographic, Time, and Product dimensions. This allows the user to ask questions such as “What were net sales for North America for a particular month for a specific computer product?” SQL Server Integration Services (SSIS) packages populate this data warehouse and conformed dimensions on a daily basis with deltas (new data changes only). The data warehouse is unavailable for about one hour each night as daily updates are rolled into this deployment.

Download from www.wowebook.com

58

CHAPTER 3

Examples of SQL Server Implementations

FIGURE 3.4 Star schema data warehouse for global computer sales. This SQL Server instance is isolated from the OLTP application where the data is sourced. There are about 500–600 data warehouse users of this data globally. This data warehouse is approaching 5TB in size.

DSS Example Two The same Silicon Valley computer company also implemented some of the same data in a more complex Analysis Services OLAP cube for data mining purposes. The company had many things it did not know about its sales data and wanted to do complex trending and forecasting to better understand the demand for products worldwide. Figure 3.5 shows the OLAP cube built in Analysis Services for this complex business intelligence purpose. Several demand forecasting and product sales trending models were developed to allow this company to predict sales by each of its products for each geographic region.

Download from www.wowebook.com

DSS Application Examples

All Geo

All Time Year

TIME

GEOGRAPHY

Major Geo

Quarter

Country

Month

Channel Customer

Jan09 Feb09 Mar09 Apr09 450

996

Returns Net Sales

20 430

35

1203 22 1181

PRODUCT

TI

Product Type Product Line Product Family SKU

PRODUCT

GEOGRAPHY

M

961

333 14 319

E

Sales Units

3

All Product

59

OLAP Cube

FIGURE 3.5 Multidimensional OLAP cube in Analysis Services.

DSS Example Three This last example features a multitechnology hybrid data reporting solution that provides real-time reporting along with point-in-time reporting for a major healthcare organization in the Pacific Northwest. This solution starts with real-time data replication from its online transactional systems where all hospital transactions are taking place. This includes patient events, medications administered, surgeries done, hospital charges, and so on. By distributing this data to a highly available two-node SQL Cluster, the hospital is able to realize all its real-time reporting requirements that center around providing all known information for a particular patient in the hospital at any time. Figure 3.6 shows this OLTP-to-SQL cluster real-time, continuous data replication and the real-time reporting enabled by this data distribution.

Download from www.wowebook.com

60

CHAPTER 3

Examples of SQL Server Implementations

Database Mirroring Topology with Snapshots Real-Time Reporting Users Network

Role: PARTNER SQL Server 2008

Role: PARTNER SQL Server 2008

Clustered

Active Replication

OLTP Application

Principal Server

Mirror Server Health Provider DB

Mirroring

translog

Passive

Principal Server

Health Provider DB translog Database Snapshot

Network SQL Server 2008

Point-in-Time Reporting Users

FIGURE 3.6 Hybrid SQL Server reporting configuration.

Download from www.wowebook.com

Summary

61

Another major reporting requirement for this health organization is not a real-time requirement, but rather a leisurely hourly snapshot, point-in-time reporting requirement. A much larger group of users must be served by this noncritical reporting need and cannot impact the real-time reporting environment in any way. To satisfy this point-in-time, noncritical reporting need, the health organization leveraged SQL Server database mirroring from the replicated SQL Server Health Provider DB. From the mirror, hourly database snapshots are created to satisfy all the point-in-time reporting needs of the organization. This configuration has been extremely stable since the SQL Server 2005 deployment.

3

Summary This chapter described some truly interesting SQL Server–based implementations. These examples reflect how major software vendors such as SAP have utilized SQL Server as the core of their ERP data tier, how Internet-based companies rely on SQL Server to host their e-commerce applications, and how SQL Server can be used to fulfill various decision support and business intelligence needs of major corporations. We selected these examples because they are rock solid and reflect potentially similar scenarios that you may be faced with. It is this flexibility and reliability that will allow you to be successful as well. The next chapter delves into the functionality of the SQL Server Management Studio environment.

Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

4

SQL Server Management Studio

IN THIS CHAPTER . What’s New in SSMS . The Integrated Environment . Administration Tools . Development Tools

SQL Server Management Studio (SSMS) is an integrated application that provides access to most of the graphical tools you can use to perform administrative and development tasks on SQL Server 2008. SSMS was introduced with SQL Server 2005 and replaced the Enterprise Manager, Query Analyzer, and Analysis Manager that were available in SQL Server 2000. Microsoft consolidated all those tools into one, with a focus on providing a tool that suits the needs of both developers and database administrators (DBAs). SSMS is a complicated tool that provides an entry point to almost all of SQL Server’s functionality. The functionality that is accessible from SSMS is entirely too much to cover in one chapter. The aim of this chapter is to give a basic overview of SSMS while touching on the features that are new to SQL Server 2008. Others chapters in this book discuss the components of SSMS and provide more detailed coverage.

What’s New in SSMS SSMS is loaded with new features in SQL Server 2008. This tool was introduced in SQL Server 2005, and it brought quite a bit of change with it. There is also quite a bit of change with SQL Server 2008, but the basic look-and-feel of the application remains much the same as it was in SQL Server 2005. The standout features in the SQL Server 2008 SSMS include four new features geared toward the administrator and

Download from www.wowebook.com

64

CHAPTER 4

SQL Server Management Studio

three new features geared toward the developer. Of course, all these features could be used by both administrators and developers. The new administrator features in SSMS include a beefed-up Activity Monitor, a new Object Search option, a customizable Object Explorer Details window, and a new management tool named SQL Server Utility that was added with SQL Server 2008 R2. The Activity Monitor now contains four separate graphs that look like graphs displayed in Task Manager, and they pull information similar to what you might see in System Monitor. The Object Search option allows you to search for database objects by name while changes to the Object Explorer Details window significantly expand the amount of available information and allow the user to change the information that is displayed. Finally, the new SQL Server Utility allows for the capture of resource information across multiple servers and provides one unified view for the display of this information. Enhancements that are focused on the developer include IntelliSense in the Query Editor, an integrated Transact-SQL (T-SQL) Debugger, and a Multiserver Query execution option. IntelliSense helps with the completion of T-SQL code as you write it. This feature was much anticipated for SQL Server 2005, but it never made it to the released code. That anticipation continued with SQL Server 2008, and fortunately, Microsoft has delivered. This feature should not disappoint, and it will ultimately improve your productivity. A debugging tool that is integrated into SSMS is another great new feature. Those who have developed stored procedures with thousands of lines of code will particularly appreciate this new feature. You can set breakpoints, evaluate variables, and step through the code line by line. This debugging capability applies to all T-SQL in the query editor window. Multiserver queries is the last standout feature offered with SQL Server 2008. This feature allows you to run a single query against more than one server. The results returned from each server are displayed in a single result window. If you’re managing many servers, this feature can be a real timesaver. This chapter further explores the new features in SSMS. It first examines the features at the environmental level, focusing on how SSMS behaves and how to best utilize the environment. Next, it looks at the administrative tools and what changes have been made to help you better manage your SQL Server environment. Finally, this chapter looks at the development tools available with SSMS and changes made to improve your SQL Server development experience.

The Integrated Environment If you have been working with SQL Server for a long time, you may remember the SQL Enterprise Manager that came with SQL Server 6.5. In some respects, with SSMS, Microsoft has moved back to the paradigm that existed then. Like the SQL Server 6.5 Enterprise Manager, SSMS provides an integrated environment where developers and DBAs alike can perform the database tasks they need. Say goodbye to Query Analyzer, Analysis Manager, and a number of other desparate tools used in SQL Server 2000 and say hello to SSMS, which provides “one-stop shopping” for most of your database needs.

Download from www.wowebook.com

The Integrated Environment

65

Window Management Figure 4.1 shows a sample configuration for the SSMS main display. The environment and windows displayed are completely customizable, with the exception of the document window area. Figure 4.1 shows the document window area displaying the Object Explorer Details page. The Object Explorer Details page is the default, but other pages, such as a query editor window, can take the focus in this tab-oriented section of the SSMS display.

4

FIGURE 4.1 The SSMS main display.

The dialogs that form the rest of the SSMS display are referred to as components and include the Registered Servers and Object Explorer windows shown in Figure 4.1, as well as a number of other components that can be displayed via the View menu found at the top of the SSMS display. You can configure each of the component windows in a number of ways; for example, you can have them float, or you can hide, dock, autohide, or display them as tabbed documents in the document window area. The configuration that you choose for your SSMS display depends on the type of work you do with SQL Server as well as the type of person you are. The Auto Hide feature causes the component window to shrink to a tab along the left or right side of the display. When you mouse over the tab, the window automatically expands and stays expanded as long as the mouse cursor remains in the component window area. Auto Hide helps maximize the working real estate available in the document window for query development and the

Download from www.wowebook.com

CHAPTER 4

66

SQL Server Management Studio

like. Docking many windows can clutter the screen, but this feature allows you to view many different types of information all at once. This is a matter of personal preference, and SSMS has made it very easy to change.

TIP You can reposition the component windows by dragging and dropping them to the desired locations. When you are in the middle of a drag and drop, rectangular icons with arrows are displayed at different locations on the SSMS window surface. If you mouse over one of these arrowed icons to select the window location, you see the window destination highlighted. If you release your mouse button while the destination is highlighted, the window docks in that position. Some users at first ignore the arrow icons and keep hovering the window over the location where they want the window to go. Hovering the window over the desired location does not allow you to effectively dock it. You should save yourself some time and aggravation and use the arrow icons for drag-and-drop positioning.

The SSMS window environment include nonmodal windows that are sizable. The nonmodal windows allows you to perform multiple tasks at one time without needing to open another instance of the SSMS application. In SQL Server 2000, the Enterprise Manager users were forced to open another instance of the application during many administrative tasks to be able to continue with other work. With SSMS, you can launch a backup with the Back Up Database dialog and then continue working with the Object Explorer or other components in SSMS while the backup is running. This capability is a great timesaver and helps improve overall productivity. Your ability to size the dialog boxes is another user-friendly feature that may seem minor but is quite handy on certain windows. For example, the SQL Server 2000 Enterprise Manager Restore dialog had a fixed size. Viewing the backup set information in this relatively small (nonsizable) dialog box was a challenge. The Restore dialog in SQL Server 2008’s SSMS can contain a slew of information related to the backup sets available for restore. The capability to size the windows allows for much more information to be displayed. The tabbed document window area provides some usability improvements as well. This area, as described earlier, is fixed and is always displayed in SSMS. Component windows can be displayed in this area, along with windows for the Query Editor, diagrams, and other design windows. If desired, you can change the environment from a tabbed display to multiple-document interface (MDI) mode. In this mode, each document is opened in its own window within the document window. The MDI mode manages windows like the SQL Server 2000 Query Analyzer and may be more user-friendly for some people. You can

Download from www.wowebook.com

The Integrated Environment

67

change to MDI mode by selecting Tools, Options and then selecting MDI Environment from the General page. One particularly useful window that can be displayed in the document window is the Object Explorer Details page. This new window displays information relative to the node selected in the Object Explorer and includes options to produce detailed reports and graphs. The Object Explorer Details page is displayed in the document window by default when SSMS is launched, but you can also display it by pressing F7 or choosing Object Explorer Details from the View menu.

4

The Object Explorer Details page has been vastly improved in SQL Server 2008. If you’re familiar with the previous version, you can see in Figure 4.1 that there is much more information displayed in SQL Server 2008 than there was in 2005. The nice part is that you can customize the information that is displayed and save those changes so that they are used the next time you open SSMS. For example, when you right-click on a column heading (such as Name), you see all the columns available for display. Only a handful are displayed by default, but more than 30 available columns relate to databases. The columns that are available depend on the type of object selected in the Object Explorer window.

TIP You can copy some or all of the information shown in the Object Explorer Details window and paste it into another application such as Excel for a quick and easy report. For example, you can select the Databases node in Object Explorer, highlight the data shown in the Object Explorer Details page, press Ctrl+C to copy the data, and then paste it into Excel. All the columns related to database (including Headings) are captured and give you an easy way to review information about all your databases.

Another significant change in the Object Explorer Details page is the Object Search box. The Object Search box, located at the top of the Object Explorer Details page (next to the Search label), allows you to search for objects by name. You can use wildcards (for example, Product%), or you can type a specific name you are looking for. The results are displayed in the Object Explorer Details page. Keep in mind that the objects that are searched depend on what is selected in the Object Explorer window. For example, if you highlight the Databases node, you search all the databases on your SQL Server instance. If you select a specific database, only that database is searched.

Download from www.wowebook.com

CHAPTER 4

68

SQL Server Management Studio

TIP In SQL Server 2000, you could select multiple objects for scripting by selecting the items from the Object Explorer tree in Enterprise Manager. You cannot use the Object Explorer tree to perform this operation with SQL Server 2008, and this has generated some confusion. The solution is the Object Explorer Details page, which provides a means for performing multiple selections of the objects it displays. You can hold down the Ctrl key and click only those items you want to script. After you select the items you want, you simply right-click one of the selected items and choose the preferred scripting method. This method also works with scheduled jobs displayed in the Object Explorer Details page. SQL Server 2000 did not offer this capability.

Integrated Help SSMS offers an expanded set of help facilities as well as improved integration into the application environment. The Help sources have been expanded to include both local and online resources. Local help is similar to the Help resources available in past versions and references files installed on your machine during the installation process. Local help includes the local SQL Server Books Online resources. Local help files are static and are updated only if another documentation installation is run on the local machine. Online help provides access to content that is not static and can be updated with the latest changes. Three default online resources are provided by default: . MSDN Online—MSDN Online contains the latest version of the MSDN documentation, including the latest quarterly releases. . Codezone Community—Codezone Community includes a set of third-party websites that have partnered with Microsoft and provide a wealth of information from sources outside Microsoft. . Questions—The Questions option allows you to search the forum archives for answers to questions that others have already asked. It also allows you to post your own questions. The help resources you use on your machine are configurable. You can choose to search online resources first, followed by local help, or you can choose an option that searches local help resources first, followed by online resources. You can also choose specific Codezone online resources to search, or you can eliminate the search of all online resources. Figure 4.2 shows the online help Options window, which allows you to configure your Help options. You access this dialog by selecting Tools, Options. The Help resources you select are used when you search for content within the Help facility. When you use both local and online resources options, you see results from multiple locations in your search results. Figure 4.3 shows a sample Books Online Document Explorer window with results from a search on “Management Studio.” Notice that the panel on the right side of the window lists entries under Local Help, MSDN Online, Codezone Community, and Questions. Each of these sections contains search results that

Download from www.wowebook.com

The Integrated Environment

69

FIGURE 4.2 Setting Help options.

4

FIGURE 4.3 A Books Online search. you can access by simply clicking on that area. The number of search results for each section is displayed in parentheses after the section name. One other significant change to the help facilities in SSMS is the addition of Dynamic Help. Dynamic Help is a carryover from the Visual Studio environment. It is a help facility

Download from www.wowebook.com

70

CHAPTER 4

SQL Server Management Studio

that automatically displays topics in a Help window that are related to what you are doing in SSMS. For example, if you are working in a query window and type the word SELECT to start your query, the Dynamic Help window displays several topics related to the SELECT statement. If you are working in the Object Explorer, it displays Help topics related to the Object Explorer.

NOTE There is some processing overhead associated with Dynamic Help. You may find that your SSMS environment runs a bit slower when you use this feature.

Dynamic Help is one of the component windows that you can dock or position on the SSMS surface. To use Dynamic Help, you select Help, Dynamic Help. Figure 4.4 shows an example of the SSMS environment with the Dynamic Help window docked on the right side of the window. The Dynamic Help topics in this example are relative to the SELECT keyword that is typed in the query editor window in the middle of the screen.

FIGURE 4.4 Dynamic Help.

Download from www.wowebook.com

Administration Tools

71

Administration Tools The tools available with SSMS can be broadly categorized into tools that are used for administering SQL Server and tools that are used for developing or authoring new SQL Server objects. As a matter of practice, developers use some of the administrative tools, and administrators use some of the development tools. SSMS comes with an expanded set of tools to help with SQL Server administrative tasks. It builds on the functionality that was available in SQL Server 2005 and adds some new tools and functionality to help ease the administrative burden.

Registered Servers 4

Registered servers is a concept in SQL Server 2008 that represents a division between managing servers and registering servers. With the SQL Server 2000 Enterprise Manager, the Microsoft Management Console (MMC) tree was displayed on the left side of the Enterprise Manager screen, and it contained servers that had been registered via that tree. Any registered servers or groups were listed in the tree, along with any of the associated objects. Registered servers are managed and displayed in the Registered Servers component window. Figure 4.5 shows an example of the Registered Servers window, with several server groups and their associated registered servers. You can add new groups or servers any time so that you have a handy way of organizing the servers you work with.

FIGURE 4.5 The Registered Servers window.

Download from www.wowebook.com

72

CHAPTER 4

SQL Server Management Studio

The servers listed in Figure 4.5 are all Database Engine servers. These server types are the conventional SQL Server instances, like those you could register in the SQL Server 2000 Enterprise Manager. You can also register several other types of servers. The icons across the top of the Registered Servers window indicate the types of servers that can be registered. In addition to Database Engine servers, you can also register servers for Analysis Services, Reporting Services, SQL Server Mobile, and Integration Services. The Registered Servers window gives you one consolidated location to register all the different types of servers available in SQL Server 2008. You simply click the icon associated with the appropriate server type, and the registered servers of that type are displayed in the Registered Servers tree.

NOTE The SQL Server 2008 Registered Servers window enables you to register servers that are running SQL Server 2005, SQL Server 2000, and SQL Server 7.0. You can manage all the features of SQL Server 2005 and SQL Server 2000 with SQL Server 2008 tools. You can also have both sets of tools on one machine. The SQL Server 2000, SQL Server 2005, and SQL Server 2008 tools are compatible and function normally together. Management tools from prior SQL Server versions cannot be used to manage SQL Server 2008 instances. For example, the SQL Server 2000 Enterprise Manager cannot be used to manage SQL Server 2008. You can connect the Query Analyzer to a SQL Server 2008 instance and run queries, but the Object Explorer and other tools are not compatible with SQL Server 2008.

When a server is registered, you have several options available for managing the server. You can right-click the server in the Registered Servers window to start or stop the related server, open a new Object Explorer window for the server, connect to a new query window, or export the registered servers to an XML file so that they can be imported on another machine.

TIP The import/export feature can be a real timesaver, especially in environments where many SQL servers are managed. You can export all the servers and groups registered on one machine and save the time of registering them all on another machine. For example, you can right-click the Database Engine node, select Export, and then choose a location to store the XML output file. Then all you need to do to register all the servers and groups on another machine is move the file to that machine and import the file.

Download from www.wowebook.com

Administration Tools

73

Object Explorer The Object Explorer window that existed in the SQL Server 2000 Query Analyzer was integrated into SSMS in SQL Server 2005. SQL Server 2008 continues to use an integrated Object Explorer that behaves like SQL Server 2005.. The most significant feature for those folks managing a large number of database objects is the capability to populate the Object Explorer tree asynchronously. This may not hit home for folks who deal with smaller databases, but it can be a real time saver for those that are dealing with many databases on a single SQL Server instance or for those that work with databases that have a significant number of database objects. The Object Explorer tree in SSMS displays immediately and allows navigation in the tree and elsewhere in SSMS while the population of the tree is taking place.

4

The Object Explorer is adaptive to the type of server it is connected to. For a Database Engine server, the databases and objects such as tables, stored procedures, and so on are displayed in the tree. If you connect to an Integration Services server, the tree displays information about the packages defined on that type of server. Figure 4.6 shows an example of the Object Explorer with several different types of SQL Server servers displayed in the tree. Each server node has a unique icon that precedes the server name, and the type of server is also displayed in parentheses following the server name.

FIGURE 4.6 Multiple server types in Object Explorer.

The objects displayed in the Object Explorer tree can be filtered in SQL Server 2008. The number of filters is limited, but those that are available can be helpful. For example, you can filter the tables displayed in Object Explorer based on the name of the table, the

Download from www.wowebook.com

74

CHAPTER 4

SQL Server Management Studio

schema that it belongs to, or the date on which it was created. Again, for those who deal with large databases and thousands of database objects, this feature is very helpful. Administrators also find the enhanced scripting capabilities in the Object Explorer very useful. The scripting enhancements are centered mostly on the administrative dialog boxes. These dialogs now include a script button that allows you to see what SSMS is doing behind the scenes to effect your changes. In the past, the Profiler could be used to gather this information, but it was more time-consuming and less integrated than what is available now. Figure 4.7 shows an example of an administrative dialog, with the scripting options selected at the top. You can script the commands to a new query window, a file, the Windows Clipboard, or a job that can be scheduled to run at a later time.

FIGURE 4.7 Scripting from administrative dialogs.

Aside from these features, many of the features and much of the functionality associated with the Object Explorer is similar to what was found in SQL Server 2000 and is almost identical to what was found in SQL Server 2005. Keep in mind that there are some additional nodes in the Object Explorer tree and that some of the objects are located in different places. For example, the Management node now contains nodes for Policy Management, Data Collection, and the Resource Governor, which are all new in SQL Server 2008.

Download from www.wowebook.com

Administration Tools

75

One often-overlooked Object Explorer feature is the reports option that was added in SQL Server 2005 and still exists in SQL Server 2008. This option is available by right-clicking on a node in the Object Explorer. Reports are not available for every node in the Object Explorer tree, but many of them do have this option. Most reports are found in the toplevel nodes in the tree. For example, if you right-click on a database in the Object Explorer tree and then select Reports and Standard Reports, you see more than a dozen available reports. These reports include Disk Usage, Backup and Restore Events, Top Transactions by Age, and a host of others. Graphs are included with some reports, and you can export or print all these reports. Figure 4.8 shows an example of the Disk Usage report for the AdventureWorks2008 database.

4

FIGURE 4.8 A Disk Usage Object Explorer Details report. The graphs are easy to read, and some sections of the report can be expanded to provide more detail. Bullets at the bottom of a report are nodes that can be expanded. For example, the bullet Disk Space Used by Data Files at the bottom of Figure 4.8 can be expanded to display details about each of the data files.

Activity Monitor The Activity Monitor has seen some dramatic changes in SQL Server 2008. These changes build on the foundation established in SQL Server 2005 and help provide much more information related to the performance of your SQL Server instance. Before we get into the details of the Activity Monitor, let’s make sure you know where to find it. It is no longer found in the Management node of the Object Explorer. Instead, you right-click on the name of the server instance in the Object Explorer, and you see a selection for Activity Monitor.

Download from www.wowebook.com

76

CHAPTER 4

SQL Server Management Studio

When the Activity Monitor launches, you see a new display with four different graphs, as shown in Figure 4.9. The graphs include % Processor Time (from SQL Server), Waiting Tasks, Database I/O and Batch Requests. These graphs give you a quick performance snapshot for your SQL Server in one spot without having to launch System Monitor or some other monitoring tool to view this kind of information. You also find more detailed performance information below the graphs. This information is grouped into four categories: Processes, Resource Waits, Data File I/O and Recent Expensive Queries. Clicking on the expand button for one of these categories presents the details you are looking for. These details contain drop-down headings that allow you to filter the results and view only the information you need.

FIGURE 4.9 SQL Server 2008 Activity Monitor.

The Processes Details window contains information similar to what was displayed in the SQL Server 2005 Activity Monitor. These details include information similar to what is returned with the sp_who system stored procedure. The server process ID (SPID) is listed in a column named Session ID, and the related information for each SPID is displayed in the remaining columns. If you right-click on a particular process, you can see the details of that process. You can then kill that process or launch the SQL Server Profiler to trace the activity for the process. Figure 4.10 shows an example of the expanded Processes details window. The Resource Waits window (that is displayed below the Process window) can help you identify bottlenecks on your server. It details the processes waiting for other resources on the server. The amount of time a process is waiting and the wait category (what the process is waiting for) are found in this display. If you click on the Cumulative Wait Time column, the rows are sorted by this column and you can find the wait category that has been waiting the longest. This sorting capability applies to all the columns in the display.

Download from www.wowebook.com

Administration Tools

77

FIGURE 4.10 Processes Details window in the Activity Monitor.

4

The Data File I/O window lists each database and its related database files. The amount of disk I/O experienced by each of the files is detailed in the columns of this display. You can isolate the database and files that are most heavily hit with read or write activity as well as the databases that may be suffering from poor I/O response with this screen. Finally, the Recent Expensive Queries window displays information similar to what you can obtain using catalog views. It provides statistics for all the databases on the instance and is a quick and easy way to find and tune expensive SQL statements. If you right-click on a row in the display and click Edit Query Text, you can see the entire SQL text associated with the query. You are able to click on one of the column headings such as CPU to sort the display according to the metric you feel defines cost. Best of all, you can rightclick on a row and choose Show Execution Plan, and you have the Query Plan ready for analysis.

NOTE When you mouse over the column headers in the detailed windows, ToolTips give you more information about the columns. This information includes the system view that the information is gathered from and where you can look in Books Online to obtain further information.

Log File Viewer The Log File Viewer is another nonmodal window that is essential for administering your SQL Server. Like the Activity Monitor, it houses information that was previously displayed in the document window in the SQL Server 2000 Enterprise Manager. It can display log files that are generated from several different sources, including Database Mail, SQL Server Agent, SQL Server, and Windows NT.

Download from www.wowebook.com

78

CHAPTER 4

SQL Server Management Studio

The Log File Viewer can be launched from the related node in the SSMS Object Explorer. For example, you can select the Management node and expand SQL Server Error Logs. If you double-click one of the error logs listed, a new Log File Viewer window is launched, displaying the SQL Server log file entries for the log type selected (see Figure 4.11).

FIGURE 4.11 SQL Server logs displayed in the Log File Viewer.

NOTE By default, entries are shown in the SQL Server Log File Viewer from newest to oldest. This is different from the default order in the SQL Server 2000 Enterprise Manager, which displayed the log file entries from oldest to newest.

Download from www.wowebook.com

Administration Tools

79

One of the first things you notice when you launch the Log File Viewer is that a tree structure at the top-left corner of the screen shows the log files you are viewing. You can see that there are four different log types available: Database Mail, SQL Agent, SQL Server, and Windows NT. You can choose to display multiple log files within a given log type (for example, the current SQL Server log and Archive #1), or you can select logs from different sources. For example, you can display all the current log entries for SQL Server and the current log entry for the SQL Server Agent. When multiple logs are selected, you can differentiate between the rows shown on the right side of the Log File Viewer by looking at the Log Source column and the Log Type column. The Log Source values match up with the names shown in the tree structure where the log was selected. The Log Type column shows the type of log, such as SQL Agent or SQL Server. Rows from the different log types are displayed together and sorted according to the date on which the row was created. The sort order cannot be changed.

4

TIP You can rearrange the order of the columns shown in the Log File Viewer. You simply click the column header and drag the column to the desired location. When you are viewing rows for more than one log type or multiple logs, it is best to drag the Log Type and Log Source columns to a location that is easily viewed so that you can distinguish between the entries.

Other noteworthy features in the Log File Viewer include the capability to filter and load a log from an external source. You can filter on dates, users, computers, the message text, and the source of the message. You can import log files from other machines into the view by using the Load Log facility. This facility works hand-in-hand with the Export option, which allows you to export the log to a file. These files can be easily shared so that others can review the files in their own Log File Viewer.

SQL Server Utility The SQL Server Utility was added in SQL Server 2008 R2 and is geared toward multiserver management. It provides several new hooks in the SSMS environment that improve visibility and control across multiple SQL Server environments. Access to these new hooks is provided through a new Utility Explorer that can be displayed within your SSMS environment. This Utility Explorer has a tree-like structure similar to the Object Explorer, and it provides rich content related to the health and integrity of the SQL Server environments you have selected to manage using the SQL Server Utility. Figure 4.12 shows an example of the type of information the Utility Explorer can display.

Download from www.wowebook.com

80

CHAPTER 4

SQL Server Management Studio

FIGURE 4.12 Utility Explorer content.

The SQL Server Utility must first be configured to facilitate the display of information in the Utility Explorer. The configuration is relatively straightforward, but you must meet several requirements before starting it. The following requirements apply to the utility control point (UCP), which is the SQL Server instance capturing the information and the SQL Server instances being managed by the UCP: . SQL Server must be version 10.50 or higher. . The SQL Server instance type must be Database Engine. . The SQL Server Utility must operate within a single Windows domain or domains with two-way trust relationships. . On Windows Server 2003, the SQL Server Agent service account must be a member of Performance Monitor User group. . The SQL Server service accounts on the UCP and all managed instances of SQL Server must have read permission to Users in Active Directory.

Download from www.wowebook.com

Administration Tools

81

In addition, the UCP must be running the Data Center, Developer, or Enterprise Edition of SQL Server. When you have met these requirements, you are ready to start using the SQL Server Utility. The first steps are to establish a UCP and to enroll SQL Server instances for the UCP to manage. This is accomplished by selecting View on the SSMS menu bar and then selecting Utility Explorer. A content pane is displayed in SSMS that contains options for configuring the SQL Server Utility (see Figure 4.13). It also contains links to video that can guide you through each step.

4

FIGURE 4.13 Utility Configuration Steps.

The first thing to do when configuring the SQL Server Utility is to click on the Create a Utility Control Point (UCP) link on the Getting Started tab. This initiates a wizard that will guide you through a five-step process that creates the UCP. The first wizard screen that outlines these steps is shown in Figure 4.14.

Download from www.wowebook.com

82

CHAPTER 4

SQL Server Management Studio

FIGURE 4.14 Create Utility Control Point Wizard screen.

The first step of the wizard is the most critical because you choose the SQL Server Instance that will be the UCP. The SQL Server instance you select in this step will store the information related to the UCP and any other instances enrolled within that UCP. The information collected by the UCP is stored in a database named sysutility_mdw created on the UCP instance. This database drives the health and status information displayed in the Utility Explorer. After you complete the wizard steps to create a UCP, the UCP appears in the Utility Explorer Tree, and summary information about the UCP is displayed in the Utility Explorer Content tab. The UCP is the top-most node in the tree and contains other child nodes that contain the different types of information managed by the UCP. An example of the Utility Explorer tree is shown in Figure 4.15. The first child node displayed in the Utility Explorer tree is named Deployed Data-tier Applications. A data-tier application, or DAC, is a single entity that contains all the database objects and related instance objects used by an application. This includes tables, stored procedures, SQL Server Logins, and so on. DACs can be created from a Visual Studio 2010 data-tier application project or by using the Extract Data-Tier Application Wizard in SSMS. The full scope of DAC capabilities is beyond the scope of this chapter, but it is important to see how they fit into the Utility Explorer Display.

Download from www.wowebook.com

Administration Tools

83

FIGURE 4.15 Utility Explorer tree.

NOTE

4

Two different SQL Server features use the same DAC acronym. The aforementioned data-tier application is one of them, but a dedicated administrator connection is also referred to as a DAC.

After creating a DAC deployment package, you can deploy it to another SQL Server instance. This deployment creates the related database, the database objects along with the related server objects. If the server to which the DAC is deployed is managed by the UCP, you can show the deployed DAC information by clicking on the Deployed Datatier Applications node of the Utility Explorer. The next node in the Utility Explorer tree, named Managed Instances, contains information about SQL Server instances enrolled in the UCP. Enrolling an instance essentially means you want to manage the instance through the UCP and gather information about it. You can easily enroll this instance by right-clicking on the Managed Instances node and selecting Enroll Instance. Each instance enrolled in the UCP is listed at the top of the Utility Explorer Content tab. When a managed instance is selected from this list, a set of resource and policy information is made available in the lower half of the window. The available tabs in this window which define the type of information that is captured include CPU Utilization, Storage Utilization, Policy Details and Property Details. Figure 4.16 shows two managed instances and the related CPU Utilization graphs for the top-most SQL Server instance. The last node, Utility Administration, can be used to manage policy, security, and data warehouse settings for a SQL Server Utility. These settings drive the SQL Server Utility summary screen and set thresholds across the entities defined in the utility. Figure 4.17 shows an example of the Policy information that can be managed with Utility Administration.

Download from www.wowebook.com

84

CHAPTER 4

SQL Server Management Studio

FIGURE 4.16 Managed Instances.

FIGURE 4.17 Utility Administration.

Download from www.wowebook.com

Development Tools

85

The Policy tab is one of three tabs available on the Utility Administration window. You can see in Figure 4.17 that there are also Security and Data Warehouse tabs. The Security tab allows you to manage permissions for logins that can administer or read from the UCP. Logins can be assigned to the Utility Reader role on this screen, which allows them to connect to the SQL Server Utility and read information from the Utility Explorer in SSMS. The Data Warehouse tab allows you to adjust the amount of time data will be retained in the UCP data warehouse. The default time period is one year. Over time, the amount of data collected in the UCP data warehouse can be substantial. By default, each managed instance enrolled in the UCP sends configuration and performance data to the UCP every 15 minutes. Consequently, the space used by the utility management data warehouse (UMDW) needs to be monitored. The UMDW database, named sysutility_mdw, is listed as a user database in the Object Explorer.

4

Development Tools SSMS delivers an equally impressive number of features for database developers. Many of the features were available with SQL Server 2005, but SQL Server 2008 has added some new ones as well. T-SQL Debugging, IntelliSense in the Query Editor, and multiserver queries are a few of those new tools for developers found in SQL Server 2008. These new tools and the other essential developer tools from SSMS are discussed in the following sections.

The Query Editor The Query Editor sits at the top of the list for development tools in SSMS. The Query Editor, as its name indicates, is the editing tool for writing queries in SSMS. It contains much of the functionality that was contained in SQL Server 2000’s Query Analyzer. The capability to write T-SQL queries, execute them, return results, generate execution plans, and use many of the other features you may be familiar with in Query Analyzer are also available with the Query Editor. One main difference with the Query Editor is that is has been integrated into the SSMS environment. In SQL Server 2000, the Query Analyzer was a separate application with its own independent interface. In SQL Server 2008, SSMS houses the query-editing capabilities along with all the administrative capabilities.

Download from www.wowebook.com

86

CHAPTER 4

SQL Server Management Studio

NOTE The biggest upside to the integration of the query-editing tool into the SSMS environment is that you can find almost anything you need to administer or develop on your SQL Server database in one spot. There is no need to jump back and forth between applications. One possible downside, however, is that SSMS may be much more than some database developers need.

Clicking the New Query button, opening a file, and selecting the Script to File option from a list of database objects in the Object Explorer are just a few of the ways to launch the Query Editor. Figure 4.18 shows the query editor window with a sample SELECT statement from the AdventureWorks2008 database. The query editor window is displayed on the right side of the screen and the Object Explorer on the left side.

FIGURE 4.18 The query editor window in SSMS. The basic editing environment within the Query Editor is similar to Query Analyzer. The top portion of the query editor window contains the query. The bottom portion contains the results of an executed query. The results can be displayed as text, displayed in a grid format, or output as XML. However, in the Query Editor, windows are by default managed differently than with Query Analyzer. Multiple query editor windows are displayed in a tabbed format; in comparison, Query Analyzer displayed a separate window for each query.

Download from www.wowebook.com

Development Tools

87

TIP The tabbed document display has some advantages, but you can set an option in SSMS that causes the Query Editor to behave much like the Query Analyzer. To do this, you select Tools, Options to launch the Options dialog. The default page has a section named Environmental Layout. If you choose the MDI Environment option, you set SSMS in MDI mode instead of the tabbed layout. IntelliSense IntelliSense has finally made it to the SQL Server Query Editor. This much-anticipated tool was slated for SQL Server 2005, but it was pulled before making it to the marketplace. Fortunately, it made it to SQL Server 2008, and it was worth the wait. This is especially true for those developers who have been working with Visual Studio or other Microsoft development tools that have this feature.

4

IntelliSense is a handy tool that helps you complete queries as you are typing them in the query editor window. Start typing and you will see. For example, type SELECT * FROM A in the query editor window, and a drop-down appears in the query editor window after you start typing the first letter after the FROM clause. The drop-down, in this case, contains the databases and tables from which you can select data. If you type in a stored procedure name to execute, a drop-down shows you the parameters that the stored procedure accepts. Type SYS. in the query editor window, and you see a drop-down of all the objects available in the SYS schema. This includes catalog views and the related columns that these views contain. If you type in a query that is incorrect, IntelliSense places a red squiggly line under the part of the query that is syntactically incorrect. The value of this tool will become more apparent as you use it. It can be confusing at times, but it will ultimately speed up your development time. It can also reduce the number of times you need to go to Books Online or some other help source and will make your development life easier.

NOTE IntelliSense works only with SQL Server 2008 databases. If you start typing a query against a database from a prior version, the handy IntelliSense drop-downs do not appear. Query Editor Types The Query Editor in SQL Server 2008 enables you to develop different types of queries. You are not limited to database queries based on SQL. You can use the Query Editor to develop all types of SQL Server Scripts, including those for SQL Server Analysis Services (SSAS) and SQL Server Mobile Edition. The SSAS queries come in three different flavors: multidimensional expressions (MDX), data mining expressions (DMX), and XML for analysis (XMLA). Only one selection exists for creating SQL Server Mobile Edition scripts.

Download from www.wowebook.com

88

CHAPTER 4

SQL Server Management Studio

You see these new query options when you create a new query. When you select New from the SSMS menu, you can choose what type of query to create. You use the Database Engine Query choice to create a T-SQL query against the Database Engine. The other new query options correspond to SSAS and SQL Server Mobile Edition. The SSMS toolbar has icons that correspond to each type of query that can be created. Each query type has a code pane that works much the same way across all the different types of queries. The code pane, which is the topmost window, color-codes the syntax that is entered, and it has sophisticated search capabilities and other advanced editing features that make it easy to use. Disconnected Editing SQL Server 2008 is able to use the code editor without a database connection. When creating a new query, you can choose to connect to a database or select Cancel to leave the code pane disconnected. To connect to the database later, you can right-click in the code pane window and select the Connect option. You can also disconnect the Query Editor at any time or choose the Change Connection option to disconnect and connect to another database all at once. Along with disconnected editing are some changes to the Windows behavior that are worth noting. The biggest changes relate to the behavior of query windows currently open at the time a file is opened for editing. With SQL Server 2000 Query Analyzer, the currently selected window would be populated with the contents of the file you were opening. Prior to this replacement, a prompt would be displayed asking whether you wanted to save your results. If the query window was empty, the contents would be replaced without the prompt for saving. With SQL Server 2008, a new query window is opened every time a new file is opened. The new window approach is faster but can lead to many more open windows in the document window. You need to be careful about the number of windows/connections you have open. Also, you need to be aware that the tabbed display shows only a limited number of windows. Additional connections can exist even if their tabs are not in the active portion of the document window. Editing sqlcmd Scripts in SSMS sqlcmd is a command-line utility introduced in SQL Server 2008. You can use it for ad hoc interactive execution of T-SQL statements and scripts. It is basically a replacement for the ISQL and OSQL commands used in versions prior to SQL Server 2005. (OSQL still works with SQL Server 2008, but ISQL has been discontinued.) You can write, edit, and execute sqlcmd scripts within the Query Editor environment. The Query Editor in SSMS treats sqlcmd scripts in much the same way as other scripts. The script is color-coded and can be parsed or executed. This is possible only if you place the Query Editor in SQLCMD mode, which you do by selecting Query, SQLCMD Mode or selecting the SQLCMD mode icon from the SSMS toolbar. Figure 4.19 shows a sample sqlcmd script in SSMS that can be used to back up a database. This example illustrates the power and diversity of a sqlcmd script that utilizes both T-SQL

Download from www.wowebook.com

Development Tools

89

and sqlcmd statements. It uses environment variables set within the script. The script variables DBNAME and BACKUPPATH are defined at the top of the script with the SETVAR command. The BACKUP statement at the bottom of the script references these variables, using the convention $(variablename), which substitutes the value in the command.

4

FIGURE 4.19 Editing a sqlcmd script in SSMS.

sqlcmd scripts that are edited in SSMS can also be executed within SSMS. The results are

displayed in the results window of the query editor window, just like any other script. After you test a script, you can execute it by using the sqlcmd command-line utility. The sqlcmd command-line utility is a powerful tool that can help automate script execution. For more information on using sqlcmd in SSMS, refer to the Books Online topic “Editing SQLCMD Scripts with Query Editor.” The sqlcmd command-line utility is discussed in more detail in Chapter 5, “SQL Server Command-Line Utilities.”

Regular Expressions and Wildcards in SSMS SSMS has a robust search facility that includes the use of regular expressions. Regular expressions provide a flexible notation for finding and replacing text, based on patterns within the text. Regular expressions are found in other programming languages and applications, including the Microsoft .NET Framework. The regular expressions in SSMS work in

Download from www.wowebook.com

90

CHAPTER 4

SQL Server Management Studio

much the same way as these other languages, but there are some differences in the notation. The option to use regular expressions is available whenever you are doing a find or replace within an SSMS script. You can use the find and replace option in the code pane or results window. You can use the Find and Replace option from the Edit menu or press either the Ctrl+F or Ctrl+H shortcut keys to launch the Find and Replace dialog box. Figure 4.20 shows an example of the Find and Replace dialog that utilizes a regular expression. This example is searching for the text Customer, preceded by the @ character and not followed by the Id characters. This kind of search could be useful for searching a large stored procedure where you want to find the customer references but don’t want to see the variables that contain customer in the first part of the variable name.

FIGURE 4.20 A find and replace with regular expressions. You use regular expressions only when the Use check box in the Find and Replace dialog is selected. When this option is selected, you can choose either Regular Expressions or Wildcards. Wildcard searches work much the same way in SSMS as they do in file searches. For example, if you want to find any references to the word zip, you could enter *zip* in the Find What text box. The wildcard options are limited but very effective for simple searches. Regular expressions have a much more extensive number of available search options. When you choose the option to use regular expressions, the arrow button is enabled to the right of the text box where you enter your search text. If you click this button, you are given an abbreviated list of regular expression characters that you can use in your searches. A brief description of what each character represents in the search is listed next to the character. For a complete list of characters, you can choose the Complete Character List option at the bottom of the list. This option brings you to the Books

Download from www.wowebook.com

Development Tools

91

Online topic “How to: Search with Regular Expressions,” which gives a comprehensive review of all the characters.

4

Enhanced Performance Output The Query Editor in SSMS has an extensive set of options available for capturing and distributing performance-related data. It contains many of the familiar performance features that you may have grown accustomed to in SQL Server 2000 Query Analyzer— plus more. If you’re familiar with the SQL Server 2005 performance output, you will find that that the SQL Server 2008 performance output has changed very little. The Execution Plan tab that is displayed in the results window and the Results and Messages tab are still there in SQL Server 2008. The Execution Plan tab can be populated with two different types of plans: estimated plans and actual plans. The actual execution plan shows the plan that was used in generating the actual query results. The actual plan is generated along with the results when the Include Actual Execution Plan option is selected. This option can be selected from the SSMS toolbar or from the Query menu. Figure 4.21 shows an example of an actual execution plan generated for a query against the AdventureWorks2008 database.

FIGURE 4.21 Displaying an actual execution plan in Query Editor.

The familiar treelike structure that was also present in SQL Server 2000 is still used in SQL Server 2005 and SQL Server 2008. The ToolTips displayed when you mouse over a node in the execution plan include additional information; you can see that information in a

Download from www.wowebook.com

92

CHAPTER 4

SQL Server Management Studio

more static form in the Properties window if you right-click the node and select Properties. The display is generally easy to read and should be read from right to left.

NOTE The Manage Indexes and Manage Statistics options available in the SQL Server 2000 Query Analyzer are not present in the Query Editor in SQL Server 2008. Those options in Query Analyzer were accessible by right-clicking a node in the query plan. You can use the Database Engine Tuning Advisor (DTA) in SQL Server 2008 to analyze the Query Editor statements or open the Table Designer to manage the indexes on a specific table.

Query plans generated in the Query Editor are easy to distribute in SQL Server 2008. You have several options for capturing query plan output so that you can save it or send it to someone else for analysis. If you right-click an empty section of the Execution Plan window, you can select the Save Execution Plan As option, which allows you to save the execution plan to a file. By default, the file has the extension .sqlplan. This file can be opened using SSMS on another machine to display the graphical output. The query plan can also be output in XML format and distributed in this form. You make this happen by using the SET SHOWPLAN_XML ON option. This option generates the estimated execution plan in a well-defined XML document. The best way to do this is to turn off the display of the actual execution plan and execute the SET SHOWPLAN_XML ON statement in the code pane window. Next, you set the Query Editor to return results in grid format and then execute the statements for which you want to generate a query plan. If you double-click the grid results, they are displayed in the SSMS XML editor. You can also save the results to a file. If you save the file with the .sqlplan extension, the file displays the graphical plan when opened in SSMS. Using the Query Designer in the Query Editor A graphical query design tool is accessible from the query editor window where you write your queries. This is a great option that was missing in SQL Server 2000. With SQL Server 2000, you could access a graphical query designer by opening a table in Enterprise Manager and selecting Query, but this option was disconnected from the Query Analyzer environment, where the queries were authored. This tool was introduced in SQL Server 2005 and remains generally unchanged in SQL Server 2008. With SQL Server 2008, you can right-click in the query editor window and choose Design Query in Editor. A dialog box appears, allowing you to add tables to the graphical query designer surface. The selected tables are shown in a window that allows you to select the columns you want to retrieve. Selected columns appear in a SELECT statement displayed at the bottom of the Query Designer window. Figure 4.22 shows an example of the Query Designer window that contains two tables from the AdventureWorks2008 database. The two tables selected in this figure are related, as indicated by the line between them.

Download from www.wowebook.com

Development Tools

93

4

FIGURE 4.22 Designing queries in the Query Editor. The T-SQL statements are generated automatically as you select various options on the Query Designer screen. If you select Sort Type, an ORDER BY clause is added. If you choose an alias for a column, it is reflected in the T-SQL. If tables are related, the appropriate joins are generated. When you click OK on the Query Designer window, the related T-SQL is automatically placed in the query editor window. You can edit the T-SQL as needed or use it as is. You can imagine the time savings you can achieve by using this tool.

TIP The Query Designer has a very impressive feature that allows you to view a T-SQL query visually. If you copy a valid T-SQL statement, open the Query Designer, and paste the T-SQL into the SQL pane at the bottom of the Query Designer, it tries to resolve the T-SQL into a graphical display. The tables in the FROM clause are shown in the designer panel, and information related to the selected columns is listed as well. The Query Designer cannot resolve all T-SQL statements and may fail to generate a visual display for some complex T-SQL.

Managing Projects in SSMS Project management capabilities like those available in Visual Studio are available in SSMS. Queries, connections, and other files that are related can be grouped into projects. A project or set of projects is further organized or grouped as a solution. This type of organization is the same as in the Visual Studio environment.

Download from www.wowebook.com

94

CHAPTER 4

SQL Server Management Studio

Projects and solutions are maintained and displayed with the Solution Explorer. The Solution Explorer contains a tree-like structure that organizes the projects and files in the solution. It is a component window within SSMS that you launch by selecting View, Solution Explorer. Figure 4.23 shows an example of the Solution Explorer. The solution in this example is named EmployeeUpgrade, and it contains two projects, named Phase1 and Phase2. Each project contains a set of connections, a set of T-SQL scripts, and a set of miscellaneous files.

FIGURE 4.23 Solutions and projects listed in the Solution Explorer. The first thing to do when using the project management capabilities in SSMS is to add a project. To do this, you select File, New, and when the New dialog appears, you select Project to add a new project. When adding the new project, you are given a choice of the type of project, and you must select either SQL Server Scripts, Analysis Services Scripts, or SQL Mobile Scripts. Each one of these project types is geared toward the respective SQL Server technology. The solution that is related to the project is created at the same time that the project is created. The Solution Name is entered at the bottom of the New Project window and an option to create a separate directory for the solution is provided. There is no option to create the solution separately. After the project is added, you can add the related connections and files. To add a new connection, you simply right-click the Connections node. The Connections entries allow you to store SQL Server connection information that relates to the project you are working on. For example, you could have a connection to your test environment and another

Download from www.wowebook.com

Development Tools

95

connection to the production environment that relates to the project. When a connection is included in the project, you can double-click it, and a new query window for that connection is established. SQL script files are added to a project in a similar fashion to connections: You right-click the Queries node and select the New Query option. A new query editor window appears, allowing you to enter the T-SQL commands. Any T-SQL script is viable for this category, including those that relate to database objects such as stored procedures, triggers, and tables.

4

You can also add existing files to a project. To do this, you right-click the project node, select Add, and then select Existing Item. The file types listed in the drop-down at the bottom of the Add Existing Item dialog include SQL Server files (*.sql), SQL deadlock files (*.xdl), XML files (*.xml), and execution plan files (*.sqlplan). SQL Server files are added, by default, to the Queries node. All the other file types are added to the Miscellaneous node. The connection entries are not stored in a separate file but are contained in the project file itself.

Integrating SSMS with Source Control SSMS has the capability to integrate database project files into a source control solution. Source control provides a means for protecting and managing files. Source control applications typically contain features that allow you to track changes to files, control and track who uses the files, and provide a means for tagging the files with a version stamp so that the files can be retrieved at a later time, by version. SSMS can integrate with a number of different source control applications. Visual SourceSafe is Microsoft’s basic source control solution, but other source control applications can be used instead. The source control client application must be installed on the machine on which SSMS is running. When the installation is complete, you can set the source control application that SSMS will use within SSMS. To do this, you select Tools, Options and navigate to the Source Control node. The available source control clients are listed in the Current Source Control Plug-in drop-down. The link between SSMS and the source control application is the database solution. After a solution is created, it can be added to the source control. To add a solution to a source control application, you open the Solution Explorer and right-click the solution or any of the projects in the solution. You then see the Add Solution to Source Control option. You must then log in to the source control application and select a source control project to add the solution to. When the solution is added to a source control application, all the related projects and project files are added as well. The projects and files in the source control application have additional options available in the Solution Explorer. Figure 4.24 shows a sample solution added to a source control application. A subset of the source control options available when you right-click project files are shown in this figure as well.

Download from www.wowebook.com

96

CHAPTER 4

SQL Server Management Studio

FIGURE 4.24 Source control options in the Solution Explorer.

The options related to source control are listed toward the bottom of the options list. The options that are available depend on the status of the selected file. For example, if a file has been checked out, additional options are displayed that relate to checking the file back in. Following are some of the common source control options: . Check Out for Edit—This option allows you to get a copy of the file from the source control application so that you can modify the file. When you check out the file, the source control provider can keep track of the user who has checked out the file, and it can also prevent other users from checking out the file. . Check In—This option copies the locally modified file into the source control solution. The file must first be checked out for editing before you can use the Check In option. A new version for the file is established, and any prior versions of the file are retained as well. . Get Latest Version—This option gets a read-only copy of the latest version of the project file from the source control application. The file is not checked out with this option. . Compare—This option enables you to compare versions of source control files. The default comparison that is shown is between the file in the source control application and the local file on your machine. . Get—This option is similar to the Get Latest Version option, but it retrieves a readonly copy of the file. With this option, a dialog box appears, allowing you to select the file(s) that you want to retrieve. . View History—This option lists all versions of the files checked into the source control application. The History dialog box has many options that you can use with the different versions of the file. You can view differences between versions of the

Download from www.wowebook.com

Development Tools

97

files, view the contents of a specific version, generate reports, or get an older version of the file. . Undo Checkout—This option changes the checkout status in the source control application and releases the file to other source control users. Any changes made to the local copy of the file are not added to the source control version. Other source control options are available via the Source Control menu in SSMS. You select an item in the Solution Explorer and then select File, Source Control. You can use this menu to check the status of a file by using the SourceSafe Properties option, set source control properties, launch the source control application, and perform other source control operations.

4

Using SSMS Templates Templates provide a framework for the creation of database objects in SSMS. They are essentially boilerplate files that help generate scripts for common database objects. They can speed up the development of these scripts and help enforce consistency in the generation of the underlying database objects. The Template Explorer is a component window available in SSMS and replaces the Template tab available in the SQL Server 2000 Query Analyzer. Figure 4.25 shows the Template Explorer and the available SQL Server template folders. Separate templates also exist for Analysis Services and SQL Server Mobile Edition. You can view them by selecting the related icon at the top of the Template Explorer. You access the available templates by expanding the template folder in the Template Explorer tree. For example, if you expand the Index folder, you see six different types of index templates. If you double-click one of the templates, a new query editor window appears, populated with the template script. Figure 4.26 shows the template script displayed when you open the Create Index Basic template. The template script contains template parameters that have the following format within the script:

You can manually replace these parameters in the script, or you can use the Specify Values for Template Parameters option from the Query menu to globally replace the parameters in the script with the desired values. Selecting Query, Specify Values for Template Parameters launches the Specify Values for Template Parameters dialog box, which enables you to enter the parameter values (see Figure 4.27).

Download from www.wowebook.com

98

CHAPTER 4

SQL Server Management Studio

FIGURE 4.25 The SSMS Template Explorer.

FIGURE 4.26 The template script for creating a basic index.

FIGURE 4.27 The Specify Values for Template Parameters dialog box.

Download from www.wowebook.com

Development Tools

99

TIP When you use the Specify Values for Template Parameters option, some parameters may be missed if the parameter text has been altered. For example, if you add a carriage return after parameter_name, the Parameters dialog box does not list that parameter. It is best to leave the template script unchanged before you specify values for the parameters. You should make changes to the script after the values have been specified.

After you enter the parameter values and click OK, the values are reflected in the script. For example, the values shown in Figure 4.27 for the basic index template result in the following script:

4

-- ============================================= -- Create index basic template -- ============================================= USE AdventureWorks2008 GO CREATE INDEX NC_Address_Person ON Person.Address ( PostalCode ) GO

You also have the option of creating your own custom templates. These templates can contain parameters just like those available with the default templates. You can also create your own template folder that will be displayed in the Template Explorer tree. To create a new template folder, you right-click the SQL Server Templates node in the Template Explorer tree and select New, Folder. A new folder appears in the tree, and you can specify a new folder name. Figure 4.28 shows the Template Explorer with a set of custom templates found under the _mytemplates folder. The code pane in this figure shows the contents of a new custom template named sys.objectSelectWithParameters. This custom template contains two parameter declarations: object_type and modify_date. When you select the Specify Values for Template Parameters options for this custom template, you have the opportunity to change the values, just as you can with the default templates.

NOTE When you double-click a template in the Template Explorer tree, you create a script based on the template. Changes made to the script do not affect the template; they affect only the script generated from the template. To change the actual template, you need to right-click the template and select Edit. After you complete your changes, you need to make sure to save the template.

Download from www.wowebook.com

100

CHAPTER 4

SQL Server Management Studio

Also, you should keep in mind that there is no requirement to have parameters in your templates. Templates are handy tools for accessing any code snippet you might use. After the code snippet is added as a template, you can open a new query editor window based on the template or simply drag and drop the template from the Template Explorer to an existing query editor window, and the code for the template is pasted into the window.

FIGURE 4.28 A custom template example.

T-SQL Debugging Finally, you are able to debug T-SQL from within the SQL Server development environment. Yes, you could do this kind of thing using Visual Studio, but database developers should be able to debug in the environment where they generally develop their SQL statements—within SSMS. SQL Server 2008 provides this capability, and it works well. The trickiest part of debugging may be starting the debugger. It is not all that difficult but may be less than obvious for some. For example, let’s say you want to debug a stored procedure. To do this, you right-click on the stored procedure in the Object Explorer and select Script Stored Procedure As, Execute To, New Query Editor Window, and a script for executing the procedure is generated. If the stored procedure has parameters, you add the SQL to assign a value to those parameters to the script. Now you are ready to debug this script and the related stored procedure. To initiate debugging, you click on the green arrow on the SQL Server menu bar. When you start debugging, several new debugging windows are added to the SSMS display, and the query editor window shows a yellow arrow in the left margin next to the line in the script

Download from www.wowebook.com

Development Tools

101

that is about to be run. You can now use the debug toolbar at the top of the SSMS screen to step through your code. If you click the Step Into button, the current statement executes, and the script progresses to the next available statement. Figure 4.29 shows an example of the T-SQL Debugging Environment while debugging is in progress. The debugging environment enables you to view values assigned to variables, review the call stack, set breakpoints, and perform debugging much like you would do in development environments such as Visual Studio.

4

FIGURE 4.29 The T-SQL Debugging Environment.

Multiserver Queries Another slick new option available with SQL Server 2008 is the capability to execute a script on multiple servers at once. Multiserver queries allow the contents of a single query editor window to be run against all the servers defined in a given registered server group. After the group is created and servers are registered in the group, you can right-click on the group and select the New Query option to create a query window that can be run against all the servers in the group. Click on the Execute button, and the query is run against all the servers. Figure 4.30 shows a server group named MyTestGroup containing three servers registered in that group, a sample query to run against these servers, and a single result window that shows the results of the query for all servers in the group.

Download from www.wowebook.com

102

CHAPTER 4

SQL Server Management Studio

FIGURE 4.30 Multiserver query execution. Multiserver queries are relatively easy to use. The results window includes a Server Name column that allows you to determine which server the result came from. These queries are backward compatible and allow you to run against prior versions of SQL Server, including SQL Server 2005. The only caveat is that you must first create a registered server group and the related registered servers before you run the query, but you already know that this task is also relatively easy.

Summary The number of tools and features available in SSMS is extensive and can be daunting when you first enter the environment. Remember that you can customize this environment and hide many of the windows that are displayed. You can start with a fairly simple SSMS configuration that includes the Object Explorer and a query editor window. This configuration may allow you to accomplish a majority of your SQL Server tasks. As you become more familiar with the environment, you can introduce new tools and features to help improve your overall productivity. The discussion of SSMS does not end with this chapter. Further details related to SSMS are covered throughout this book. You can use the new features described in this chapter as a starting point and look to other chapters for more detailed discussion of database features accessible through SSMS. Chapter 5 looks at the SQL Server utilities that can be run from the command prompt. These tools allow you to perform some of the same tasks available in SSMS. The capability to launch these utilities from the command line can be useful when you’re automating tasks or accessing SQL Server when a GUI tool such as SSMS is not available.

Download from www.wowebook.com

CHAPTER

5

SQL Server CommandLine Utilities

IN THIS CHAPTER . What’s New in SQL Server Command-Line Utilities . The sqlcmd Command-Line Utility . The dta Command-Line Utility

This chapter explores various command-line utilities that ship with SQL Server. These utilities give administrators a different way to access the database engine and its related components. In some cases, they provide functionality that is also available with SQL Server’s graphical user interface (GUI). Other command-line utilities provide functionality that is available only from the command prompt. For each utility, this chapter provides the command syntax along with the most commonly used options. For the full syntax and options available for the utility, see SQL Server Books Online.

. The tablediff CommandLine Utility . The bcp Command-Line Utility . The sqldiag Command-Line Utility . The sqlservr Command-Line Utility

NOTE This chapter focuses on command-line utilities that are core to SQL Server and the SQL Server database engine. Several other command-line utilities that are used less frequently or geared toward other SQL Server services are not covered in this chapter. These utilities include dtexec and dtutil, which can be used with SQL Server Integration Services (SSIS). Reporting Services has the rs, rsconfig, and rskeymgmt command-line utilities. Lastly, there are several executable files documented as utilities in Books Online (such as ssms, which opens the SQL Server Management Studio) that have limited parameters and are basically used to launch their related applications.

Table 5.1 lists the command-line utilities discussed in this chapter. This table lists the physical location of each utility’s

Download from www.wowebook.com

104

CHAPTER 5

SQL Server Command-Line Utilities

executable. The location is needed to execute the utility in most cases, unless the associated path has been added to the Path environmental variable.

TABLE 5.1 Command-Line Utility Installation Locations Utility

Install Location

sqlcmd

x:\Program Files\Microsoft SQL Server\100\Tools\Binn

dta

x:\Program Files\Microsoft SQL Server\100\Tools\Binn

tablediff

x:\Program Files\Microsoft SQL Server\100\COM

bcp

x:\Program Files\Microsoft SQL Server\100\Tools\Binn

sqldiag

x:\Program Files\Microsoft SQL Server\100\Tools\Binn

sqlservr

x:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn

NOTE The tablediff utility is installed when SQL Server replication is installed. If you can’t find the tablediff.exe in the location specified in Table 5.1, check to see whether the replication was installed.

When you are testing many of these utilities, it is often easiest to set up a batch file (.BAT) that contains a command to change the directory to the location shown in Table 5.1. After you make this directory change, you can enter the command-line utility with the relevant parameters. Finally, you should enter a PAUSE command so that you can view the output of the utility in the command prompt window. Following is an example you can use to test the sqlcmd utility (which is discussed in more detail later in this chapter): CD “C:\Program Files\Microsoft SQL Server\100\Tools\Binn” SQLCMD -S(local) -E -Q “select @@servername” pause

After you save the commands in a file with a .BAT extension, you can simply double-click the file to execute it. This approach is much easier than retyping the commands many times during the testing process.

What’s New in SQL Server Command-Line Utilities The SQL Server command-line utilities available in SQL Server 2008 are basically the same as those offered with SQL Server 2005. This has some key benefits for those who are familiar with the 2005 utilities. Very little has changed in the syntax, and batch files or scripts you have used with these utilities in the past should continue to work unchanged.

Download from www.wowebook.com

The sqlcmd Command-Line Utility

105

A few command-line utilities have been added in SQL Server 2008, however, and some have been removed. The sqlps utility is new to SQL Server 2008. This utility can be used to run PowerShell commands and scripts. The sqlps utility and the PowerShell Windows–based command-line management tool are discussed in detail in Chapter 17, “Administering SQL Server 2008 with PowerShell.” Utilities removed from SQL Server 2008 include sac. The sac utility can be used in SQL Server 2005 to import or export settings available in the graphical Surface Area Configuration (SAC) tool. Both the sac command-line utility and SAC graphical tool have been removed. Similar functionality is now available via policy-based management and the Configuration Manager tool.

The sqlcmd Command-Line Utility

5

The sqlcmd command-line utility is the next generation of the isql and osql utilities that you may have used in prior versions of SQL Server. It provides the same type of functionality as isql and osql, including the capability to connect to SQL Server from the command prompt and execute T-SQL commands. The T-SQL commands can be stored in a script file, entered interactively, or specified as command-line arguments to sqlcmd.

NOTE The isql and osql command-line utilities are not covered in this chapter. The isql utility was discontinued in SQL Server 2005 and is not supported in SQL Server 2008. The osql utility is still supported but will be removed in a future version of SQL Server. Make sure to use sqlcmd in place of osql to avoid unnecessary reworking in the future.

The syntax for sqlcmd follows: sqlcmd [{ { -U login_id [ -P password ] } | –E trusted connection }] [ -z new password ] [ -Z new password and exit] [ -S server_name [ \ instance_name ] ] [ -H wksta_name ] [ -d db_name ] [ -l login time_out ] [ -A dedicated admin connection ] [ -i input_file ] [ -o output_file ] [ -f < codepage > | i: < codepage > [ < , o: < codepage > ] ] [ -u unicode output ] [ -r [ 0 | 1 ] msgs to stderr ] [ -R use client regional settings ] [ -q “cmdline query” ] [ -Q “cmdline query” and exit ] [ -e echo input ] [ -t query time_out ] [ -I enable Quoted Identifiers ] [ -v var = “value”...] [ -x disable variable substitution ] [ -h headers ][ -s col_separator ] [ -w column_width ] [ -W remove trailing spaces ]

Download from www.wowebook.com

106

[ [ [ [ [ [ [ [

-k -y -b -a -L -p -X -?

CHAPTER 5

SQL Server Command-Line Utilities

[ 1 | 2 ] remove[replace] control characters ] display_width ] [-Y display_width ] on error batch abort ] [ -V severitylevel ] [ -m error_level ] packet_size ][ -c cmd_end ] [ c ] list servers[clean output] ] [ 1 ] print statistics[colon format]] [ 1 ] ] disable commands, startup script, environment variables [and exit] show syntax summary ]

The number of options available for sqlcmd is extensive, but many of the options are not necessary for basic operations. To demonstrate the usefulness of this tool, we look at several different examples of the sqlcmd utility, from fairly simple (using few options) to more extensive.

Executing the sqlcmd Utility Before we get into the examples, it is important to remember that sqlcmd can be run in several different ways. It can be run interactively from the command prompt, from a batch file, or from a Query Editor window in SSMS. When run interactively, the sqlcmd program name is entered at the command prompt with the required options to connect to the database server. When the connection is established, a numbered row is made available to enter the T-SQL commands. Multiple rows of T-SQL can be entered in a batch; they are executed only after the GO command has been entered. Figure 5.1 shows an example with two simple SELECT statements that were executed interactively with sqlcmd. The connection in this example was established by typing sqlcmd at the command prompt to establish a trusted connection to the default instance of SQL Server running on the machine on which the command prompt window is opened.

FIGURE 5.1 Executing sqlcmd interactively. The capability to edit and execute sqlcmd scripts was added to SSMS with SQL Server 2005. A sqlcmd script can be opened or created in a Query Editor window within SSMS. To edit these scripts, you must place the editor in SQLCMD Mode. You do so by selecting Query, SQLCMD Mode or by clicking the related toolbar button. When the editor is put in SQLCMD Mode, it provides color coding and the capability to parse and execute the

Download from www.wowebook.com

The sqlcmd Command-Line Utility

107

commands within the script. Figure 5.2 shows a sample sqlcmd script opened in SSMS in a Query Editor window set to SQLCMD Mode. The shaded lines are sqlcmd commands.

5

FIGURE 5.2 Executing and editing sqlcmd scripts in SSMS. The most common means for executing sqlcmd utility is via a batch file. This method can provide a great deal of automation because it allows you to execute a script or many scripts by launching a single file. The examples shown in this section are geared toward the execution of sqlcmd in this manner. The following simple example illustrates the execution of sqlcmd, using a trusted connection to connect to the local database, and the execution of a simple query that is set using the –Q option: sqlcmd -S (local) -E -Q”select getdate()”

You can expand this example by adding an output file to store the results of the query and add the –e option, which echoes the query that was run in the output results: sqlcmd -S (local) -E -Q”select getdate()” -o c:\TestOutput.txt –e

The contents of the c:\TestOutput.txt file should look similar to this: select getdate() ———————————2008-09-10 20:29:05.645 (1 rows affected)

Using a trusted connection is not the only way to use sqlcmd to connect to a SQL Server instance. You can use the –U and –P command-line options to specify the SQL Server user and password. sqlcmd also provides an option to specify the password in an environmental variable named sqlcmdPASSWORD, which can be assigned prior to the sqlcmd execution and eliminates the need to hard-code the password in a batch file.

Download from www.wowebook.com

108

CHAPTER 5

SQL Server Command-Line Utilities

sqlcmd also provides a means for establishing a dedicated administrator connection (DAC)

to the server. The DAC is typically used for troubleshooting on a server that is having problems. It allows an administrator to get onto the server when others may not be able to. If the DAC is enabled on the server, a connection can be established with the –A option and a query can be run, as shown in the following example: sqlcmd -S (local) -A -Q”select getdate()”

If you need to manage more complex T-SQL execution, it is typically easier to store the TSQL in a separate input file. The input file can then be referenced as a sqlcmd parameter. For example, say that you have the following T-SQL stored in a file named C:\TestsqlcmdInput.sql: BACKUP DATABASE Master TO DISK = ‘c:\master.bak’ BACKUP DATABASE Model TO DISK = ‘c:\model.bak’ BACKUP DATABASE MSDB TO DISK = ‘c:\msdb.bak’

The sqlcmd execution, which accepts the C:\TestsqlcmdInput.sql file as input and executes the commands within the file, looks like this: sqlcmd -S (local) -E -i”C:\TestsqlcmdInput.sql” -o c:\TestOutput.txt –e

The execution of the preceding example backs up three of the system databases and writes the results to the output file specified.

Using Scripting Variables with sqlcmd sqlcmd provides a means for utilizing variables within sqlcmd input files or scripts. These scripting variables can be assigned as sqlcmd parameters or set within the sqlcmd script.

To illustrate the use of scripting variables, let’s change our previous backup example so that the database that will be backed up is a variable. A new input file named c:\BackupDatabase.sql should be created, and it should contain the following command: BACKUP DATABASE $(DatabaseToBackup) TO DISK = ‘c:\$(DatabaseToBackup).bak’

The variable in the preceding example is named DatabaseToBackup. Scripting variables are referenced using the $( ) designators. These variables are resolved at the time of execution, and a simple replacement is performed. This allows variables to be specified within quotation marks, if necessary. The –v option is used to assign a value to a variable at the command prompt, as shown in the following example, which backs up the model database:

Download from www.wowebook.com

The dta Command-Line Utility

109

sqlcmd -S (local) -E -i”C:\BackupDatabase.sql” -v DatabaseToBackup = model

If multiple variables exist in the script, they can all be assigned after the –v parameter. These variables should not be separated by a delimiter, such as a comma or semicolon. Scripting variables can also be assigned within the script, using the :SETVAR command. The input file from the previous backup would be modified as follows to assign the DatabaseToBackup variable within the script: :SETVAR DatabaseToBackup Model BACKUP DATABASE $(DatabaseToBackup) TO DISK = ‘c:\$(DatabaseToBackup).bak’

Scripts that utilize variables, sqlcmd commands, and the many available options can be very sophisticated and can make your administrative life easier. The examples in this section illustrate some of the basic features of sqlcmd, including some of the features that go beyond what is available with osql.

The dta Command-Line Utility 5 dta is the command-line version of the graphical Database Engine Tuning Advisor. Both

the command-line utility and graphical tool provide performance recommendations based on the workload provided to them. The syntax for dta is as follows: Dta [ -? ] | [ [ -S server_name[ \instance ] ] { { -U login_id [-P password ] } | –E } { -D database_name [ ,...n ] } [-d database_name ] [ -Tl table_list | -Tf table_list_file ] { -if workload_file | -it workload_trace_table_name } { -s session_name | -ID session_ID } [ -F ] [ -of output_script_file_name ] [ -or output_xml_report_file_name ] [ -ox output_XML_file_name ] [ -rl analysis_report_list [ ,...n ] ] [ -ix input_XML_file_name ] [ -A time_for_tuning_in_minutes ] [ -n number_of_events ] [ -m minimum_improvement ] [ -fa physical_design_structures_to_add ] [ -fp partitioning_strategy ] [ -fk keep_existing_option ]

Download from www.wowebook.com

110

CHAPTER 5

SQL Server Command-Line Utilities

[ -fx drop_only_mode ] [ -B storage_size ] [ -c max_key_columns_in_index ] [ -C max_columns_in_index ] [ -e | -e tuning_log_name ] [ -N online_option] [ -q ] [ -u ] [ -x ] [ -a ] ]

An extensive number of options is available with this utility, but many of them are not required to do basic analysis. At a minimum, you need to use options that provide connection information to the database, a workload to tune, a tuning session identifier, and the location to store the tuning recommendations. The connection options include –S for the server name, –D for the database, and either –E for a trusted connection or –U and –P, which can be used to specify the user and password. The workload to tune is either a workload file or workload table. The –if option is used to specify the workload file location, and the –it option is used to specify a workload table. The workload file must be a Profiler trace file (.trc), SQL script (.sql) that contains T-SQL commands, or SQL Server trace file (.log). The workload table is a table that contains output from a workload trace. The table is specified in the form database_name.owner_name.table_name. The tuning session must be identified with either a session name or session ID. The session name is character based and is specified with the –s option. If the session name is not provided, a session ID must be provided instead. The session ID is numeric and is set using the –ID option. If the session name is specified instead of the session ID, the dta generates an ID anyway. The last options required for a basic dta execution identify the destination to store the dta performance recommendations, which can be stored in a script file or in XML. The –of option is used to specify the output script filename. XML output is generated when the –or or –ox option is used. The –or option generates a filename if one is not specified, and the –ox option requires a filename. The –F option can be used with any of the output options to force an overwrite of a file with the same name, if one exists. To illustrate the use of dta with basic options, let’s look at an example of tuning a simple SELECT statement against the AdventureWorks2008R2 database. To begin, you use the following T-SQL, which is stored in a workload file named c:\myScript.sql: USE AdventureWorks2008R2 ; GO select * from Production.transactionHistory where TransactionDate = ‘9/1/04’

Download from www.wowebook.com

The dta Command-Line Utility

111

The following example shows the basic dta execution options that can be used to acquire performance recommendations: dta -S xpvirtual1 -E -D AdventureWorks2008R2 -if c:\MyScript.sql -s MySessionX -of C:\MySessionOutputScript.sql -F

NOTE dta and other utilities executed at the command prompt are executed with all the

options on a single line. The preceding example and any others in this chapter that are displayed on more than one line should actually be executed at the command prompt or in a batch file on a single line. They are broken here because the printed page can accommodate only a fixed number of characters.

5

The preceding example utilizes a trusted connection against the AdventureWorks2008R2 database, a workload file named c:\MyScript.sql, and a session named MySessionX, and it outputs the performance recommendations to a text file named c:\MySessionOutputScript.sql. The –F option is used to force a replacement of the output file if it already exists. The output file contains the following performance recommendations: se [AdventureWorks2008R2] go CREATE NONCLUSTERED INDEX [_dta_index_TransactionHistory_5] ON [Production].[TransactionHistory] ( [TransactionDate] ASC ) INCLUDE ( [TransactionID], [ProductID], [ReferenceOrderID], [ReferenceOrderLineID], [TransactionType], [Quantity], [ActualCost], [ModifiedDate]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY] go

In short, the dta output recommends that a new index be created on the TransactionDate column in the TransactionHistory table. This is a viable recommendation, considering that there was no index on the TransactionHistory.TransactionDate column, and it was used as a search argument in the workload file.

Download from www.wowebook.com

112

CHAPTER 5

SQL Server Command-Line Utilities

Many other options (that go beyond basic execution) can be used to manipulate the way dta makes recommendations. For example, a list can be provided to limit which tables the dta looks at during the tuning process. Options can be set to limit the amount of time that the dta tunes or the number of events. These options go beyond the scope of this chapter, but you can gain further insight into them by looking at the graphical DTA, which contains many of the same types of options. You can refine your tuning options in the DTA, export the options to an XML file, and use the –ix option with the dta utility to import the XML options and run the analysis.

The tablediff Command-Line Utility The tablediff utility enables you to compare the contents of two tables. It was originally developed for replication scenarios to help troubleshoot nonconvergence, but it is also very useful in other scenarios. When data in two tables should be the same or similar, this tool can help determine whether they are the same, and if they are different, it can identify what data in the tables is different. The syntax for tablediff is as follows: tablediff [ -? ] | { -sourceserver source_server_name[\instance_name] -sourcedatabase source_database -sourcetable source_table_name [ -sourceschema source_schema_name ] [ -sourcepassword source_password ] [ -sourceuser source_login ] [ -sourcelocked ] -destinationserver destination_server_name[\instance_name] -destinationdatabase subscription_database -destinationtable destination_table [ -destinationschema destination_schema_name ] [ -destinationpassword destination_password ] [ -destinationuser destination_login ] [ -destinationlocked ] [ -b large_object_bytes ] [ -bf number_of_statements ] [ -c ] [ -dt ] [ -et table_name ] [ -f [ file_name ] ] [ -o output_file_name ] [ -q ] [ -rc number_of_retries ] [ -ri retry_interval ]

Download from www.wowebook.com

The tablediff Command-Line Utility

113

[ -strict ] [ -t connection_timeouts ] }

The tablediff syntax requires source and destination connection information to perform a comparison. This information includes the servers, databases, and tables that will be compared. Connection information must be provided for SQL Server authentication but can be left out if Windows authentication can be used. The source and destination parameters can be for two different servers or the same server, and the tablediff utility can be run on a machine that is neither the source nor the destination. To illustrate the usefulness of this tool, let’s look at a sample comparison in the AdventureWorks2008R2 database. The simplest way to create some data for comparison is to select the contents of one table into another and then update some of the rows in one of the tables. The following SELECT statement makes a copy of the AddressType table in the AdventureWorks2008R2 database to the AddressTypeCopy table:

5

select * into Person.AddressTypeCopy from Person.AddressType

In addition, the following statement updates two rows in the AddressTypeCopy table so that you can use the tablediff utility to identify the changes: UPDATE Person.AddressTypeCopy SET Name = ‘Billing New’ WHERE AddressTypeId = 1 UPDATE Person.AddressTypeCopy SET Name = ‘Shipping New’, ModifiedDate = ‘20090918’ WHERE AddressTypeId = 5

The tablediff utility can be executed with the following parameters to identify the differences in the AddressType and AddressTypeCopy tables: tablediff -sourceserver “(local)” -sourcedatabase “AdventureWorks2008R2” -sourceschema “Person”-sourcetable “AddressType” -destinationserver “(local)” -destinationdatabase “AdventureWorks2008R2” -destinationschema “Person” -destinationtable “AddressTypeCopy” -f c:\TableDiff_Output.txt

The destination and source parameters are the same as in the previous example, except for the table parameters, which have the source AddressType and the destination AddressTypeCopy. The execution of the utility with these parameters results in the following output to the command prompt window:

Download from www.wowebook.com

114

CHAPTER 5

SQL Server Command-Line Utilities

User-specified agent parameter values: -sourceserver (local) -sourcedatabase AdventureWorks2008R2 -sourceschema Person -sourcetable AddressType -destinationserver (local) -destinationdatabase AdventureWorks2008R2 -destinationschema Person -destinationtable AddressTypeCopy -f c:\TableDiff_Output Table [AdventureWorks2008R2].[Person].[AddressType] on (local) and Table [AdventureWorks2008R2].[Person].[AddressTypeCopy] on (local) have 2 differences. Fix SQL written to c:\TableDiff_Output.sql. Err AddressTypeID Col Mismatch 1 Name Mismatch 5 ModifiedDate Name The requested operation took 0.296875 seconds.

The output first displays a summary of the parameters used and then shows the comparison results. In this example, it found the two differences that are due to updates performed on AddressTypeCopy. In addition, the –f parameter used in the example caused the tablediff utility to output a SQL file that can be used to fix the differences in the destination table. The output file from this example looks as follows: — Host: (local) — Database: [AdventureWorks2008R2] — Table: [Person].[AddressTypeCopy] SET IDENTITY_INSERT [Person].[AddressTypeCopy] ON UPDATE [Person].[AddressTypeCopy] SET [Name]=’Billing’ WHERE [AddressTypeID] = 1 UPDATE [Person].[AddressTypeCopy] SET [ModifiedDate]=’2002-06-01 00:00:00.000’, [Name]=’Shipping’ WHERE [AddressTypeID] = 5 SET IDENTITY_INSERT [Person].[AddressTypeCopy] OFF

NOTE The tablediff utility requires the source table to have at least one primary key, identity, or ROWGUID column. This gives the utility a key that it can use to try to match a corresponding row in the destination table. If the –strict option is used, the destination table must also have a primary key, identity, or ROWGUID column.

Download from www.wowebook.com

The bcp Command-Line Utility

115

Keep in mind that several different types of comparisons can be done with the tablediff utility. The –q option causes a quick comparison that compares only record counts and looks for differences in the schema. The –strict option forces the schemas of each table to be the same when the comparison is run. If this option is not used, the utility allows some columns to be of different data types, as long as they meet the mapping requirements for the data type (for example, INT can be compared to BIGINT). The tablediff utility can be used for many different types of comparisons. How you use this tool depends on several factors, including the amount and type of data you are comparing.

The bcp Command-Line Utility You use the bcp (bulk copy program) tool to address the bulk movement of data. This utility is bidirectional, allowing for the movement of data into and out of a SQL Server database. bcp uses the following syntax:

5

bcp {[[database_name.][owner].]{table_name | view_name} | “query”} {in | out | queryout | format} data_file [-mmax_errors] [-fformat_file] [-x] [-eerr_file] [-Ffirst_row] [-Llast_row] [-bbatch_size] [-n] [-c] [-N] [-w] [-V (60 | 65 | 70 | 80)] [-6] [-q] [-C { ACP | OEM | RAW | code_page } ] [-tfield_term] [-rrow_term] [-iinput_file] [-ooutput_file] [-apacket_size] [-Sserver_name[\instance_name]] [-Ulogin_id] [-Ppassword] [-T] [-v] [-R] [-k] [-E] [-h”hint [,...n]”]

Some of the commonly used options—other than the ones used to specify the database, such as user ID, password, and so on—are the –F and –L options. These options allow you to specify the first and last row of data to be loaded from a file, which is especially helpful in large batches. The –t option allows you to specify the field terminator that separates data elements in an ASCII file. The –E option allows you to import data into SQL Server fields that are defined with identity properties.

TIP The BULK INSERT T-SQL statement and SSIS are good alternatives to bcp. The BULK INSERT statement is limited to loading data into SQL Server, but it is an extremely fast tool for loading data. SSIS is a sophisticated GUI that allows for both data import and data export, and it has capabilities that go well beyond those that were available in SQL Server 2000’s Data Transformation Services (DTS).

Download from www.wowebook.com

116

CHAPTER 5

SQL Server Command-Line Utilities

This section barely scratches the surface when it comes to the capabilities of bcp. For a more detailed look at bcp, refer to the section, “Using bcp” in Chapter 52, “SQL Server Integration Services.”

The sqldiag Command-Line Utility sqldiag is a diagnostic tool that you can use to gather diagnostic information about

various SQL Server services. It is intended for use by Microsoft support engineers, but you might also find the information it gathers useful in troubleshooting a problem. sqldiag collects the information into files that are written, by default, to a folder named SQLDIAG, which is created where the file sqldiag.exe is located (for example, C:\Program Files\Microsoft SQL Server\100\Tools\binn\SQLDIAG\). The folder holds files that contain information about the machine on which SQL Server is running in addition to the following types of diagnostic information: . SQL Server configuration information . SQL Server blocking output . SQL Server Profiler traces . Windows performance logs . Windows event logs The syntax for sqldiag changed quite a bit in SQL Server 2005, but very little has changed in SQL Server 2008. Some of the options that were used in versions prior to SQL Server 2005 are not compatible with the current version. The full syntax for sqldiag is as follows: sqldiag { [/?] } | { [/I configuration_file] [/O output_folder_path] [/P support_folder_path] [/N output_folder_management_option] [/C file_compression_type] [/B [+]start_time] [/E [+]stop_time] [/A SQLdiag_application_name] [/T { tcp [ ,port ] | np | lpc | via } ] [/Q] [/G] [/R] [/U] [/L] [/X] } | { [START | STOP | STOP_ABORT] } | { [START | STOP | STOP_ABORT] /A SQLdiag_application_name }

Download from www.wowebook.com

The sqldiag Command-Line Utility

117

NOTE Keep in mind that many of the options for sqldiag identify how and when the sqldiag utility will be run. The utility can be run as a service, scheduled to start and stop at a specific time of day, and it can be configured to change the way the output is generated. The details about these options are beyond the scope of this chapter but are covered in detail in SQL Server Books Online. This section is intended to give you a taste of the useful information that this utility can capture.

By default, the sqldiag utility must be run by a member of the Windows Administrators group, and this user must also be a member of the sysadmin fixed SQL Server role. To get a flavor for the type of information that sqldiag outputs, open a command prompt window, change the directory to the location of the sqldiag.exe file, and type the following command: sqldiag

5

No parameters are needed to generate the output. The command prompt window scrolls status information across the screen as it collects the diagnostic information. You see the message “SQLDIAG Initialization starting...” followed by messages that indicate what information is being collected. The data collection includes a myriad of system information from MSINFO32, default traces, and SQLDumper log files. When you are ready to stop the collection, you can press Ctrl+C. If you navigate to the sqldiag output folder, you find the files created during the collection process. In this output folder, you should find a file with MSINFO32 in its name. This file contains the same type of information that you see when you launch the System Information application from Accessories or when you run MSINFO32.EXE. This is key information about the machine on which SQL Server is running. This information includes the number of processors, the amount of memory, the amount of disk space, and a slew of other hardware and software data. You also find a file named xxx_sp_sqldiag_Shutdown.out, where xxx is the name of the SQL Server machine. This file contains SQL Server–specific information, including the SQL Server error logs, output from several key system stored procedures, including sp_helpdb and sp_configure, and much more information related to the current state of SQL Server. You find other files in the sqldiag output directory as well. Default trace files, log files related to the latest sqldiag execution, and a copy of the XML file containing configuration information are among them. Microsoft documentation on these files is limited, and you may find that the best way to determine what they contain is simply to open the files and review the wealth of information therein.

Download from www.wowebook.com

118

CHAPTER 5

SQL Server Command-Line Utilities

The sqlservr Command-Line Utility The sqlservr executable is the program that runs when SQL Server is started. You can use the sqlservr executable to start SQL Server from a command prompt. When you do that, all the startup messages are displayed at the command prompt, and the command prompt session becomes dedicated to the execution of SQL Server.

CAUTION If you start SQL Server from a command prompt, you cannot stop or pause it by using SSMS, Configuration Manager, or the Services applet in the Control Panel. You should stop the application only from the command prompt window in which SQL Server is running. If you press Ctrl+C, you are asked whether you want to shut down SQL Server. If you close the command prompt window in which SQL Server is running, SQL Server is automatically shut down.

The syntax for the sqlserver utility is as follows: sqlservr [-sinstance_name] [-c] [-dmaster_path] [-f] [-eerror_log_path] [-lmaster_log_path] [-m] [-n] [-Ttrace#] [-v] [-x] [-gnumber] [-h]

Most commonly, you start SQL Server from the command prompt if you need to troubleshoot a configuration problem. The –f option starts SQL Server in minimal configuration mode. This allows you to recover from a change to a configuration setting that prevents SQL Server from starting. You can also use the –m option when you need to start SQL Server in single-user mode, such as when you need to rebuild one of the system databases. SQL Server functions when started from the command prompt in much the same way as it does when it is started as a service. Users can connect to the server, and you can connect to the server by using SSMS. What is different is that the SQL Server instance running in the command prompt appears as if it is not running in some of the tools. SSMS and SQL Server Service Manager show SQL Server as being stopped because they are polling the SQL Server service, which is stopped when running in the command prompt mode.

TIP If you simply want to start the SQL Server service from the command prompt, you can use the NET START and NET STOP commands. These commands are not SQL Server specific but are handy when you want to start or stop SQL Server, especially in a batch file. The SQL Server service name must be referenced after these commands. For example, NET START MSSQLSERVER starts the default SQL Server instance.

Download from www.wowebook.com

Summary

119

Summary SQL Server provides a set of command-line utilities that allow you to execute some of the available SQL Server programs from the command prompt. Much of the functionality housed in these utilities is also available in graphical tools, such as SSMS. However, the capability to initiate these programs from the command prompt is invaluable in certain scenarios. Chapter 6, “SQL Server Profiler,” covers a tool that is critical for performance tuning in SQL Server 2008. SQL Server Profiler provides insight by monitoring and capturing the activity occurring on a SQL Server instance. It is a “go-to” tool for many DBAs and developers because of the wide variety of information that it can capture.

5 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

6

SQL Server Profiler

IN THIS CHAPTER . What’s New with SQL Server Profiler . SQL Server Profiler Architecture . Creating Traces . Executing Traces and Working with Trace Output

This chapter explores the SQL Server Profiler, one of SQL Server’s most powerful auditing and analysis tools. The SQL Server Profiler gives you a basic understanding of database access and helps you answer questions such as these:

. Saving and Exporting Traces . Replaying Trace Data . Defining Server-Side Traces . Profiler Usage Scenarios

. Which queries are causing table scans on my invoice history table? . Am I experiencing deadlocks, and, if so, why? . What SQL queries is each application submitting? . Which were the 10 worst-performing queries last week? . If I implement this alternative indexing scheme, how will it affect my batch operations? SQL Server Profiler records activity that occurs on a SQL Server instance. The tool has a great deal of flexibility and can be customized for your needs. You can direct SQL Server Profiler to record output to a window, file, or table. You can specify which events to trace, the information to include in the trace, how you want that information grouped, and what filters you want to apply.

What’s New with SQL Server Profiler The SQL Server 2008 Profiler is essentially the same as the SQL Server 2005 profiler. This is not surprising because many new features that were added with SQL Server 2005 addressed gaps identified in previous versions. The changes made in SQL Server 2008 are generally minor and include several new trace events, one new trace column, and several other minor changes to the profiler GUI screens.

Download from www.wowebook.com

122

CHAPTER 6

SQL Server Profiler

SQL Server Profiler Architecture SQL Server 2008 has both a server and a client-side component for tracing activity on a server. The SQL trace facility is the server-side component that manages queues of events initiated by event producers on the server. Extended stored procedures can be used to define the server-side events that are to be captured. These procedures, which define a SQL trace, are discussed later in this chapter, in the section, “Defining Server-Side Traces.” The SQL Profiler is the client-side tracing facility. It comes with a fully functional GUI that allows for real-time auditing of SQL Server events. When it is used to trace server activity, events that are part of a trace definition are gathered at the server. Any filters defined as part of the trace definition are applied, and the event data is queued for its final destination. The SQL Profiler application is the final destination when client-side tracing is used. The basic elements involved in this process are shown in Figure 6.1. Event Producers

Filters

Queue

Event Consumers

ODS

Query Processor SQL Server Profiler UI Lock Manager Flat File Log Manager Table Error Log Event Log OLE–DB ••• •••

User Defined

FIGURE 6.1 SQL Server Profiler’s architecture. This figure illustrates the following four steps in the process when tracing from the SQL Server Profiler: 1. Event producers, such as the Query Processor, Lock Manager, ODS, and so on, raise events for the SQL Server Profiler. 2. The filters define the information to submit to SQL Server Profiler. A producer will not send events if the event is not included in the filter.

Download from www.wowebook.com

Creating Traces

123

3. SQL Server Profiler queues all the events. 4. SQL Server Profiler writes the events to each defined consumer, such as a flat file, a table, the Profiler client window, and so on. In addition to obtaining its trace data from the event producers listed in step 1, you can also configure SQL Profiler so that it obtains its data from a previously saved location. This includes trace data saved in a file or table. The “Saving and Exporting Traces” section, later in this chapter, covers using trace files and trace tables in more detail.

Creating Traces Because SQL Server Profiler can trace numerous events, it is easy to get lost when reading the trace output. You need to roughly determine the information you require and how you want the information grouped. For example, if you want to see the SQL statements that each user is submitting through an application, you could trace incoming SQL statements and group them by user and by application.

6

When you have an idea about what you want to trace, you should launch the SQL Server Profiler by selecting Start, then SQL Server 2008, then Performance Tools, and finally SQL Server Profiler. You also can launch it from within SSMS from the Tools menu. When you launch the Profiler, you are presented with an application window that is basically empty. To start a new trace, you select the File menu and choose New Trace. In the connection dialog that is displayed, you can enter the connectivity information for the server you want to trace. After the connection is established, the General tab of the Trace Properties window (see Figure 6.2) is displayed.

FIGURE 6.2 General trace properties.

Download from www.wowebook.com

124

CHAPTER 6

SQL Server Profiler

The first place you should look when creating a new trace is at the trace templates. These templates contain predefined trace settings that address some common auditing needs. They have preset events, data columns, and filters targeted at specific profiling scenarios. The available trace templates, found in the template drop-down on the General tab of the Trace Properties window, are listed in Table 6.1.

TABLE 6.1 SQL Profiler Templates Template

Description

SP_Counts

Tracks all the stored procedures as they start. No event except for the stored procedure starting is traced.

Standard

Traces the completion of SQL statements and Remote Procedure Calls (RPCs) as well as key connection information.

TSQL

Traces the start of SQL statements and RPCs. This template is useful for debugging client applications where some of the statements are not completing successfully.

TSQL_Duration Traces the total execution time for each completed SQL statement or RPC.

TSQL_Grouped

Traces the start of SQL statements and RPCs, grouped by Application, NTUser, LoginName, and ClientProcessId.

TSQL_Locks

Traces the completion of SQL statements along with the key lock information that can be used to troubleshoot lock timeouts, deadlocks, and lock escalation issues.

TSQL_Replay

Captures profiling information that is useful for replay. This template contains the same type of information as the standard template, but it adds more detail, including cursor and RPC output details.

TSQL_SPs

Traces stored procedures in detail, including the start and completion of each stored procedure. The SQL statements within each procedure are traced as well.

Tuning

Performs a streamlined trace that tracks only the completion of SQL statements and RPCs. The completion events provide duration details that can be useful for performance tuning.

Download from www.wowebook.com

Creating Traces

125

Keep in mind that the templates that come with SQL Server 2008 are not actual traces. They simply provide a foundation for you in creating your own traces. After you select a template, you can modify the trace setting and customize it for your own needs. You can then save the modified template as its own template file that will appear in the template drop-down list for future trace creation. Trace Name is another property you can modify on the General tab. Trace Name is a rela-

tively unimportant trace property for future traces. When you create a new trace, you can specify a name for the trace; however, this trace name will not be used again. For instance, if you have a trace definition you like, you can save the trace definition as a template file. If you want to run the trace again in the future, you can create a new trace and select the template file that you saved. You will not be selecting the trace to run based on the trace name you entered originally. Trace Name is useful only if you are running multiple traces simultaneously and need to distinguish between them more easily.

TIP

6

Do yourself a favor and save your favorite trace definitions in your own template. The default set of templates that come with SQL Server are good, but you will most likely want to change the position of a column or add an event that you find yourself using all the time. It is not hard to adjust one of the default templates to your needs each time, but if you save your own template with exactly what you need, it makes the task all the more easy. After you save your own template, you can set it as the default template, and it will be used by default every time you start the Profiler.

The Save to File and Save to Table options on the General tab of the Trace Properties page allow you to define where the trace output is stored. You can save the output to a flat file or SQL Server table. These options are discussed in more detail later in the chapter, in the section “Saving and Exporting Traces.” The last option on the General tab of the Trace Properties window is the Enable Trace Stop Time option. This scheduling-oriented feature allows you to specify a date and time at which you want to stop tracing. This capability is handy if you want to start a trace in the evening before you go home. You can set the stop time so that the trace will run for a few hours but won’t affect any nightly processing that might occur later in the evening.

Events The events and data columns that will be captured by your Profiler trace are defined on the Events Selection tab. An example of the Events Selection tab is shown in Figure 6.3. The Events Selection tab consolidates the selection of events, data columns, and filters on one screen. One of the biggest advantages of the SQL Server 2008 Events Selection tab is that you can easily determine which data columns will be populated for each event by looking at the columns that have check boxes available for the event. For example, the Audit Login event has check boxes for Text Data, ApplicationName, and others but does not have a check box available for CPU, Reads, Writes, and other data columns that are not relevant to the event. For those data columns that have check boxes, you have the

Download from www.wowebook.com

126

CHAPTER 6

SQL Server Profiler

FIGURE 6.3 The Events Selection tab. option of unchecking the box so that the data column will not be populated for the event when the trace is run. You may find that adding events in SQL Server 2008 is a bit confusing. When you select a template, the event categories, selected events in those categories, and selected columns are displayed in the Events Selection tab. Now, if you want to add additional events, how do you do it? The answer to this question lies in the Show All Events check box in the lower-right corner of the Events Selection tab. When you click this check box, all the available event categories are listed on the screen. The events and columns that you had previously selected may or may not be visible on the screen. They are not lost, but you may need to scroll down the Events Selection tab to find the event categories that contain the events you had selected prior to selecting the Show All Events check box. You will also notice that all the events in the categories in which you had events selected are displayed. In other words, if you had only 2 events selected in the Security Audit category and then selected the Show All Events check box, you see all 42 events listed. The only 2 events selected are the ones you had selected previously, but you need to wade through many events to see them. One upside to this kind of display is that you can easily view all the events for a category and the columns that relate to the events. One possible downside is that the Events Selection tab can be very busy, and it may take a little extra time to find what you are looking for.

Download from www.wowebook.com

Creating Traces

127

TIP If you capture too many events in one trace, the trace becomes difficult to review. Instead, you can create several traces, one for each type of information that you want to examine, and run them simultaneously. You can also choose to add or remove events after the trace has started. Keep in mind that you can pause a running trace, change the selected events, and restart the trace without losing the output that was there prior to pausing the trace.

Your ability to select and view events is made easier by using the tree control available on each event. The tree control allows you to expand or compress an event category. When you click the + icon next to a category, all the events are displayed. When you click the – icon, the event category is collapsed to a single row on the display. When an event has been selected for use within a category, the category name is shown in bold. If you want to add all the events in a category to your trace, you can simply right-click the category name and choose the Select Event Category option. You can also remove all events in a category by right-clicking the category name and choosing the Deselect Event Category option.

6

Understanding what each of the events captures can be a challenging task. You can refer to “SQL Server Event Class Reference” in Books Online for a detailed description, or you can use the simple Help facility available on the Events Selection tab. The Events Selection tab has a Help facility that describes each of the events and categories. The Help text is displayed on the Events Selection tab below the list of available events. When you mouse over a particular event or event category, a description of that item is shown. This puts the information you need at your fingertips.

NOTE If you are going to use SQL Server Profiler, you should spend some time getting to know the events first and the type of output that Profiler generates. You should do this first in a development environment or standalone environment where the Profiler’s effect on performance does not matter. It’s a good idea to start a trace with a few events at a time and execute some relevant statements to see what is displayed for each event. You will soon realize the strength of the SQL Server Profiler and the type of valuable information it can return.

Data Columns The columns of information captured in a Profiler trace are determined by the Data Columns selected. The Events Selection tab has the functionality you need to add columns, organize the columns, and apply filters on the data returned in these columns. As mentioned earlier, you can select and deselect the available columns for a particular event by using the check boxes displayed for the listed events. To understand what kind of

Download from www.wowebook.com

128

CHAPTER 6

SQL Server Profiler

information a column is going to return, you can simply mouse over the column, and Help for that item is displayed in the second Help box below the event list. Figure 6.4 shows an example of the Help output. In this particular case, the mouse pointer is over the ApplicationName column returned for the SQL:BatchCompleted event. The first Help box displays information about the SQL:BatchCompleted event, and the second Help box shows information about the data column.

FIGURE 6.4 Help for data columns on the Events Selection tab.

Keep in mind that there is a default set of columns displayed for each event. You can view additional columns by selecting the Show All Columns check box. When you choose this option, an additional set of columns is displayed in the Events Selection tab. The additional columns are shown with a dark gray background, and you may need to scroll to the right on the Events Selection tab to be able to see them. Figure 6.5 shows an example of the additional columns displayed for the Performance event when the Show All Columns option is used. Some of the additional columns available for selection in this example are BigintData1 and BigintData2. To organize the columns you have selected, you can choose the Organize Columns selection on the Events Selection tab. This Organize Columns window allows you to change the order of the columns in the trace output as well as group the data by selected columns. Figure 6.6 shows an example of the Organize Columns window with the groups and columns selected by default when you use the TSQL_Grouped template. To change the order of a column, you simply select the column in the list and use the Up or Down buttons to move it. The same movement can be done with columns selected for grouping. You add columns to groups by selecting the column in the data list and clicking the Up button until the column is moved out of the Columns list and into the Groups

Download from www.wowebook.com

Creating Traces

129

FIGURE 6.5 Additional columns displayed with the Show All Columns option.

6

FIGURE 6.6 Organizing columns in the Events Selection tab. list. For example, in Figure 6.6, you can group the SPID column by selecting it and clicking the Up button until it moves into the Groups tree structure instead of the Columns tree structure.

TIP You can select a particular column for all events by right-clicking the column header in the Events Selection tab and choosing the Select Column option. This causes all the check boxes on the grid to be selected. To remove a column from all events, you rightclick the column header and choose Deselect Column.

Download from www.wowebook.com

130

CHAPTER 6

SQL Server Profiler

The number of columns selected for grouping and the order of the columns are both important factors in the way the trace data will be displayed. If you choose only one column for grouping, the trace window displays events grouped by the values in the grouped data column and collapses all events under it. For example, if you group by DatabaseId, the output in the trace window grid displays DatabaseId as the first column, with a + sign next to each DatabaseId that has received events. The number displayed to the right of the event in parentheses shows the number of collapsed events that can be viewed by clicking on the + sign. Figure 6.7 shows an example of the trace output window that has been grouped by DatabaseId only. The database with a DatabaseId equal to 6 is shown at the bottom of the grid in this example. The grid has been expanded, and some of the 20 events that were captured for this DatabaseId are shown.

FIGURE 6.7 Grouping on a single column. If you select multiple columns for grouping, the output in the trace window is ordered based on the columns in the grouping. The events are not rolled up like a single column, but the trace output grid automatically places the incoming events in the proper order in the output display.

TIP The organization of columns in a trace can happen after a trace has been defined and executed. If you save the trace to a file or table, you can open it later and specify whatever ordering or grouping you want to reorganize the output. This flexibility gives you almost endless possibilities for analyzing the trace data.

Filters Filters restrict the event data returned in your trace output. You can filter the events captured by the SQL Profiler via the Column Filters button on the Events Selection tab. An example of the Edit Filter window is shown in Figure 6.8. All the available columns for the

Download from www.wowebook.com

Creating Traces

131

trace are shown on the left side of the Edit Filter window. Those columns that have filters on them have a filter icon displayed next to the column in the column list.

FIGURE 6.8 Editing filter properties. The filtering options in SQL Server 2008 are similar to those available in SQL Server 2005. Which options are available depends on the type of column you are filtering on. The different filtering options are as follows:

6

. Like/Not Like—This option enables you to include or exclude events based on a wildcard. You should use the % character as your wildcard character. When you have completed a filter definition you can press Enter to create an entry space for another filter definition. For example, with the ApplicationName filter, you can specify Like Microsoft%, and you get only those events related to applications that match the wildcard, such as Microsoft SQL Server Management Studio. This filtering option is available for text data columns and data columns that contain name information, such as NTUserName and ApplicationName. . Equals/Not Equal To/Greater Than or Equal/Less Than or Equal—Filters with this option have all four of these conditions available. For the Equals and Not Equal To conditions, you can specify a single value or a series of values. For a series of values, you hit enter after each value is entered and a new entry space is created for you to enter the next value. For the other conditional types, a single value is supplied. For example, you can filter on DataBaseID and input numeric values under the Equals To node of the filtering tree. This filtering option is available for numeric data columns such as Duration, IndexId, and ObjectId. . Greater Than/Less Than—This type of filtering option is available only on timebased data columns. This includes StartTime and EndTime filters. These filters expect date formats of the form YYYY-MM-DD or YYYY-MM-DD HH:MM:SS. Each data column can use one of these three filtering options. When you click the data column available for filtering, you see the filtering options for that column displayed in the right pane of the Edit Filter window. You enter the values on which you want to filter

Download from www.wowebook.com

132

CHAPTER 6

SQL Server Profiler

in the data entry area on the filter tree. This input area is shown when you select a specific filtering option. For multiple filter values, you press the Enter key after you enter each value. This causes a new data entry area to appear below the value you were on.

CAUTION Filters applied to columns that are not available or selected for an event do not prevent the event data from being returned. For example, if you place a filter on the ObjectName column and choose the SQL:StmtStarting event as part of your trace, the event data is not filtered because ObjectName is not a valid column for that event. This behavior may seem relatively intuitive, but it is something to consider when you are receiving output from a trace that you believe should have been filtered out. Also, be careful when specifying multiple filter values and consider the Boolean logic applied to them. When you specify multiple values for the Like filter, the values are evaluated with an OR condition. For example, if you create a filter on ObjectName and have a Like filter with values of A%, B%, and C%, the filter returns object names that start with A or B or C. When you use the Not Like filter, the AND condition is used on multiple values. For example, Not Like filter values for ObjectName of A% and C% result in objects with names that do not start with A and object names that do not start with C.

Executing Traces and Working with Trace Output After you define the events and columns you want to capture in a trace, you can execute the Profiler trace. To do so, you click the Run button on the Trace Properties window, and the Profiler GUI starts capturing the events you have selected. The GUI contains a grid that is centrally located on the Profiler window, and newly captured events are scrolled on the screen as they are received. Figure 6.9 shows a simple example of the Profiler screen with output from an actively running trace. The Profiler GUI provides many different options for dealing with an actively running trace. You can turn off scrolling on the trace, pause the trace, stop the trace, and view the properties of an actively running trace. You can find strings within the trace output, and you can even move the columns around in the display so that they are displayed in a different order. These options provide a great deal of flexibility and allow you to focus on the output that is most important to you.

Saving and Exporting Traces In many cases, you want to save or export the trace output generated by a Profiler trace. The output can be analyzed, replayed, imported, or manipulated at a later time after it has been saved. Trace output can be saved as the trace is running or saved after it has been generated to the Profiler GUI. The Trace Properties window provides options for saving trace output while the trace is running. The options are defined using the Save to File and Save to Table options on the General tab of the Trace Properties window. You can save to a

Download from www.wowebook.com

Saving and Exporting Traces

133

file, a table, or both a table and a file. Figure 6.10 shows an example of a trace that will save to both a file and table while it is executing.

FIGURE 6.9 The Profiler GUI with an active trace.

6

FIGURE 6.10 Saving trace output while a trace is running.

Saving Trace Output to a File When you save a running trace to a file, you have several options for controlling the output. One option you should always consider is the Set Maximum File Size (MB) option. This option prevents a trace output file from exceeding the specified size. Controlling the

Download from www.wowebook.com

134

CHAPTER 6

SQL Server Profiler

size helps make the file more manageable and, more importantly, it can save you from having a trace file gobble up all the disk space on the drive you are writing to. Remember that the amount of trace data written to a file on a busy production system can be extensive. You can also use this file size option in conjunction with the Enable File Rollover option. When the Enable File Rollover option is used, the trace does not stop when the file size maximum is met. Instead, a new trace file is created, and the output is generated to that file until it reaches the file size maximum.

Saving Trace Output to a Table The Save to Table option writes the trace output directly to a SQL Server table as the trace is running. Having the data in a SQL table provides a great deal of flexibility for analyzing the data. You can use the full power of Transact-SQL against the table, including sorting, grouping, and more complex search conditions that are not available through the SQL Profiler filters. You need to consider both the disk space requirements and impact on performance when the Save to Table option is used. The Profiler provides an option, Set Maximum Rows (in Thousands), to limit the amount of output generated from the trace. The performance impact depends on the volume of data being written to the table. Generally, you should avoid writing the trace output to a table when using high-volume SQL servers. The best option for high-volume servers is to first write the trace output to a file and then import the file to a trace table at a later time.

Saving the Profiler GUI Output Another option for saving trace output occurs after trace output has been generated to the Profiler GUI and the trace has been stopped. Similar to the save options for an executing trace, the GUI output can be saved to a file or table. You access the options to save the GUI output by selecting File, Save As. The Trace File and Trace Table options are used to save to a file or table consecutively. With SQL Server 2008, you can also save the output to an XML file. The Trace XML File and Trace XML File for Replay options generate XML output that can be edited or used as input for replay with the SQL Server Profiler.

NOTE Two distinct save operations are available in the SQL Profiler. You can save trace events to a file or table as just described, or you can save a trace definition in a template file. The Save As Trace Table and Save As Trace File options are for saving trace events to a file. The Save As Trace Template option saves the trace definition. Saving a trace template saves you the trouble of having to go through all the properties each time to set up the events, data columns, and filters for your favorite traces.

An alternative to saving all the event data associated with a particular trace is to select specific event rows from the SQL Profiler windows. You can capture all the trace information associated with a trace row by selecting a row in the trace output window of Profiler

Download from www.wowebook.com

Saving and Exporting Traces

135

and choosing Edit, Copy. Or, you can just copy the event text (typically a SQL statement) by selecting the row, highlighting the text in the lower pane, and using the Copy option. You can then paste this data into SSMS or the tool of your choice for further execution and more detailed analysis. This capability can be particularly useful during performance tuning. After you identify the long-running statement or procedure, you can copy the SQL, paste it into SSMS, and display the query plan to determine why the query was running so long.

Importing Trace Files A trace saved to a file or table can be read back into SQL Profiler at a later time for more detailed analysis or to replay the trace on the same SQL Server or another SQL Server instance. You can import data from a trace file or trace table by choosing File, Open and then selecting either a trace file or trace table. If you choose to open a trace file, you are presented with a dialog to locate the trace file on the local machine. If you choose to import a trace table, you are first presented with a connection dialog to specify the SQL Server name, the login ID, and the password to connect to it. When you are successfully connected, you are presented with a dialog to specify the database and name of the trace table you want to import from. After you specify the trace file or trace table to import into Profiler, the entire contents of the file or table are read in and displayed in a Profiler window.

6

You may find that large trace files or trace tables are difficult to analyze, and you may just want to analyze events associated with a specific application or table, or specific types of queries. To limit the amount of information displayed in the Profiler window, you can filter out the data displayed via the Properties dialog. You can choose which events and data columns you want to display and also specify conditions in the Filters tab to limit the rows displayed from the trace file or trace table. These options do not affect the information stored in the trace file or trace table—only what information is displayed in the Profiler window.

Importing a Trace File into a Trace Table Although you can load a trace file directly into Profiler for analysis, very large files can be difficult to analyze. Profiler loads an entire file. For large files, this process can take quite awhile, and the responsiveness of Profiler might not be the best. Multiple trace output files for a given trace can also be cumbersome and difficult to manage when those files are large. You can use the trace filters to limit which rows are displayed but not which rows are imported into Profiler. You often end up with a bunch of rows displayed with no data in the columns you want to analyze. In addition, while the filters allow you to limit which rows are displayed, they don’t really provide a means of running more complex reports on the data, such as generating counts of events or displaying the average query duration. Fortunately, SQL Server 2008 provides a way for you to selectively import a trace file into a trace table. When importing a trace file into a trace table, you can filter the data before it goes into the table as well as combine multiple files into a single trace table. When the

Download from www.wowebook.com

136

CHAPTER 6

SQL Server Profiler

data is in a trace table, you can load the trace table into Profiler or write your own queries and reports against the trace table for more detailed analysis than is possible in Profiler. Microsoft SQL Server also includes some built-in user-defined functions for working with Profiler traces. The fn_trace_gettable function is used to import trace file data into a trace table. Following is the syntax for this function: fn_trace_gettable( [ @filename = ] filename , [ @numfiles = ] number_files )

This function returns the contents of the specified file as a table result set. You can use the result set from this function just as you would any table. By default, the function returns all possible Profiler columns, even if no data was captured for the column in the trace. To limit the columns returned, you specify the list of columns in the query. If you want to limit the rows retrieved from the trace file, you specify your search conditions in the WHERE clause. If your Profiler trace used rollover files to split the trace across multiple files, you can specify the number of files you want it to read in. If the default value of default is used, all rollover files for the trace are loaded. Listing 6.1 provides an example of creating and populating a trace table from a trace file, using SELECT INTO, and then adding rows by using an INSERT statement. Note that this example limits the columns and rows returned by specifying a column list and search conditions in the WHERE clause.

LISTING 6.1 Creating and Inserting Trace Data into a Trace Table from a Trace File /******************************************************************** ** NOTE - you will need to edit the path/filename on your system if ** you use this code to load your own trace files *********************************************************************/ select EventClass, EventSubClass, TextData = convert(varchar(8000), TextData), BinaryData, ApplicationName, Duration, StartTime, EndTime, Reads, Writes, CPU, ObjectID, IndexID, NestLevel into TraceTable FROM ::fn_trace_gettable(‘c:\temp\sampletrace_ 20090510_0622.trc’, default) where TextData is not null or EventClass in (16, — Attention 25, — Lock:Deadlock

Download from www.wowebook.com

Saving and Exporting Traces

27, 33, 58, 59, 79, 80, 92, 93, 94, 95)

— — — — — — — — — —

137

Lock:Timeout Exception Auto Update Stats Lock:Deadlock Chain Missing Column Statistics Missing Join Predicate Data File Auto Grow Log File Auto Grow Data File Auto Shrink Log File Auto Shrink

79, 80, 92, 93, 94, 95)

— — — — — —

6

Insert into TraceTable (EventClass, EventSubClass, TextData, BinaryData, ApplicationName, Duration, StartTime, EndTime, Reads, Writes, CPU, ObjectID, IndexID, nestlevel) select EventClass, EventSubClass, TextData = convert(varchar(7900), TextData), BinaryData, ApplicationName, Duration, StartTime, EndTime, Reads, Writes, CPU, ObjectID, IndexID, nestlevel FROM ::fn_trace_gettable(‘c:\temp\sampletrace_ 20090510_0205.trc’, -1) where TextData is not null or EventClass in (16, — Attention 25, — Lock:Deadlock 27, — Lock:Timeout 33, — Exception 58, — Auto Update Stats 59, — Lock:Deadlock Chain Missing Column Statistics Missing Join Predicate Data File Auto Grow Log File Auto Grow Data File Auto Shrink Log File Auto Shrink

go

After the trace file is imported into a trace table, you can open the trace table in Profiler or run your own queries against the trace table from a query editor window in SSMS. For example, the following query returns the number of lock timeouts encountered for each table during the period the trace was running: select object_name(ObjectId), count(*) from TraceTable where EventClass = 27 — Lock:Timout Event group by object_name(ObjectId) go

Download from www.wowebook.com

138

CHAPTER 6

SQL Server Profiler

Analyzing Trace Output with the Database Engine Tuning Advisor In addition to being able to manually analyze traces in Profiler, you can also use the Database Engine Tuning Advisor to analyze the queries captured in a trace and recommend changes to your indexing scheme. The Database Engine Tuning Advisor is a replacement for the Index Tuning Wizard that was available in SQL Server 2000. You can invoke it from the Tools menu in SQL Profiler. The Database Engine Tuning Advisor can read in a trace that was previously saved to a table or a file. This feature allows you to capture a workload, tune the indexing scheme, and re-run the trace to determine whether the index changes improved performance as expected. Because the Database Engine Tuning Advisor analyzes SQL statements, you need to make sure that the trace includes one or more of the following events: SP:StmtCompleted SP:StmtStarting SQL:BatchCompleted SQL:BatchStarting SQL:StmtCompleted SQL:StmtStarting

One of each class (one SP: and one SQL:) is sufficient to capture dynamic SQL statements and statements embedded in stored procedures. You should also make sure that the trace includes the text data column, which contains the actual queries. The Database Engine Tuning Advisor analyzes the trace and gives you recommendations, along with an estimated improvement-in-execution time. You can choose to create indexes now or at a later time, or you can save the CREATE INDEX commands to a script file.

Replaying Trace Data To replay a trace, you must have a trace saved to a file or a table. The trace must be captured with certain trace events to enable playback. The required events are captured by default if you use the Profiler template TSQL_Replay. You can define a trace to be saved when you create or modify the trace definition. You can also save the current contents of the trace window to a file or table by using the Save As Trace File or Save As Trace Table options in the File menu. To replay a saved trace, you choose File and then Open to open a trace file or trace table. After you select the type of trace to replay, a grid with the trace columns selected in the original trace is displayed. At this point, you can either start the replay of the trace stepby-step or complete execution of the entire trace. The options for replaying the trace are found under the Replay menu. When you start the replay of the trace, the Connect to

Download from www.wowebook.com

Replaying Trace Data

139

Server dialog is displayed, enabling you to choose the server that you want to replay the traces against. When you are connected to a server, a Replay Configuration dialog like the one shown in Figure 6.11 is displayed.

FIGURE 6.11 Basic replay options.

6

The first replay option, which is enabled by default, replays the trace in the same order in which it was captured and allows for debugging. The second option takes advantage of multiple threads; it optimizes performance but disables debugging. A third option involves specifying whether to display the replay results. You would normally want to see the results, but for large trace executions, you might want to forgo displaying the results and send them to an output file instead. If you choose the option that allows for debugging, you can execute the trace in a manner similar to many programming tools. You can set breakpoints, step through statements one at a time, or position the cursor on a statement within the trace and execute the statements from the beginning of the trace to the cursor position.

NOTE Automating testing scripts is another important use of the SQL Profiler Save and Replay options. For instance, a trace of a heavy production load can be saved and rerun against a new release of the database to ensure that the new release has similar or improved performance characteristics and returns the same data results. The saved traces can help make regression testing much easier.

You also have the option of specifying advanced replay options in SQL Server 2008. These options are found on the Advanced Replay Options tab of the Replay Configuration dialog (see Figure 6.12).

Download from www.wowebook.com

140

CHAPTER 6

SQL Server Profiler

FIGURE 6.12 Advanced replay options.

The first two options on the Advanced Replay Options tab relate to the system process IDs (SPIDs) targeted for replay. If the Replay System SPIDs option is selected, the trace events for every SPID in the trace file will be replayed. If you want to target activity for a specific SPID, you should choose the Replay One SPID Only option and select the SPID from the drop-down menu. You can also limit the events that will be replayed based on the timing of the events. If you want to replay a specific time-based section of the trace, you can use the Limit Replay by Date and Time option. Only those trace events that fall between the data range you specify will be replayed. The last set of advanced options is geared toward maintaining the health of the server on which you are replaying the trace. The Health Monitor Wait Interval (sec) option determines the amount of time a thread can run during replay before being terminated. This helps avoid an excessive drain on the server’s resources. The Health Monitor Poll Interval (sec) option determines how often the health monitor will poll for threads that should be terminated. The last advanced option on the screen relates to blocked processes. When it is enabled, the monitor polls for blocked processes according to the interval specified.

Defining Server-Side Traces Much of the SQL Server Profiler functionality can also be initiated through a set of system stored procedures. Through these procedures, you can define a server-side trace that can be run automatically or on a scheduled basis, such as via a scheduled job, instead of through the Profiler GUI. Server-side traces are also useful if you are tracing information over an extended period of time or are planning on capturing a large amount of trace information. The overhead of running a server-side trace is less than that of running a client-side trace with Profiler.

Download from www.wowebook.com

Defining Server-Side Traces

141

To start a server-side trace, you need to define the trace by using the trace-related system procedures. These procedures can be called from within a SQL Server stored procedure or batch. You define a server-side trace by using the following four procedures: . sp_trace_create—This procedure is used to create the trace definition. It sets up the trace and defines the file to store the captured events. sp trace create returns a trace ID number that you need to reference from the other three procedures to further define and manage the trace. . sp_trace_setevent—You need to call this procedure once for each data column of every event that you want to capture. . sp_trace_setfilter—You call this procedure once for each filter you want to define on an event data column. . sp_trace_setstatus—After the trace is defined, you call this procedure to start, stop, or remove the trace. You must stop and remove a trace definition before you can open and view the trace file.

6

You will find that manually creating procedure scripts for tracing can be rather tedious. Much of the tedium is due to the fact that many numeric parameters drive the trace execution. For example, the sp_trace_setevent procedure accepts an eventid and a columnid that determine what event data will be captured. Fortunately, SQL Server 2008 provides a set of catalog views that contain these numeric values and what they represent. The sys.trace_categories catalog view contains the event categories. The sys.trace_events catalog view contains the trace events, and sys.trace_columns contains the trace columns. The following SELECT statement utilizes two of these system views to return the available events and their related categories: select e.trace_event_id, e.name ‘Event Name’, c.name ‘Category Name’ from sys.trace_events e join sys.trace_categories c on e.category_id = c.category_id order by e.trace_event_id

The results of this SELECT statement are shown in Table 6.2.

TABLE 6.2 Trace Events and Their Related Categories trace_event_id Event Name

Category Name

10

RPC:Completed

Stored Procedures

11

RPC:Starting

Stored Procedures

12

SQL:BatchCompleted

T-SQL

13

SQL:BatchStarting

T-SQL

Download from www.wowebook.com

142

CHAPTER 6

SQL Server Profiler

TABLE 6.2 Trace Events and Their Related Categories trace_event_id Event Name

Category Name

14

Audit Login

Security Audit

15

Audit Logout

Security Audit

16

Attention

Errors and Warnings

17

ExistingConnection

Sessions

18

Audit Server Starts And Stops

Security Audit

19

DTCTransaction

Transactions

20

Audit Login Failed

Security Audit

21

EventLog

Errors and Warnings

22

ErrorLog

Errors and Warnings

23

Lock:Released

Locks

24

Lock:Acquired

Locks

25

Lock:Deadlock

Locks

26

Lock:Cancel

Locks

27

Lock:Timeout

Locks

28

Degree of Parallelism

Performance

33

Exception

Errors and Warnings

34

SP:CacheMiss

Stored Procedures

35

SP:CacheInsert

Stored Procedures

36

SP:CacheRemove

Stored Procedures

37

SP:Recompile

Stored Procedures

38

SP:CacheHit

Stored Procedures

40

SQL:StmtStarting

T-SQL

41

SQL:StmtCompleted

T-SQL

42

SP:Starting

Stored Procedures

43

SP:Completed

Stored Procedures

44

SP:StmtStarting

Stored Procedures

45

SP:StmtCompleted

Stored Procedures

Download from www.wowebook.com

Defining Server-Side Traces

143

TABLE 6.2 Trace Events and Their Related Categories Category Name

46

Object:Created

Objects

47

Object:Deleted

Objects

50

SQLTransaction

Transactions

51

Scan:Started

Scans

52

Scan:Stopped

Scans

53

CursorOpen

Cursors

54

TransactionLog

Transactions

55

Hash Warning

Errors and Warnings

58

Auto Stats

Performance

59

Lock:Deadlock Chain

Locks

60

Lock:Escalation

Locks

61

OLEDB Errors

OLEDB

67

Execution Warnings

Errors and Warnings

68

Showplan Text (Unencoded)

Performance

69

Sort Warnings

Errors and Warnings

70

CursorPrepare

Cursors

71

Prepare SQL

T-SQL

72

Exec Prepared SQL

T-SQL

73

Unprepare SQL

T-SQL

74

CursorExecute

Cursors

75

CursorRecompile

Cursors

76

CursorImplicitConversion

Cursors

77

CursorUnprepare

Cursors

78

CursorClose

Cursors

79

Missing Column Statistics

Errors and Warnings

80

Missing Join Predicate

Errors and Warnings

81

Server Memory Change

Server

6

trace_event_id Event Name

Download from www.wowebook.com

144

CHAPTER 6

SQL Server Profiler

TABLE 6.2 Trace Events and Their Related Categories trace_event_id Event Name

Category Name

82

UserConfigurable:0

User configurable

83

UserConfigurable:1

User configurable

84

UserConfigurable:2

User configurable

85

UserConfigurable:3

User configurable

86

UserConfigurable:4

User configurable

87

UserConfigurable:5

User configurable

88

UserConfigurable:6

User configurable

89

UserConfigurable:7

User configurable

90

UserConfigurable:8

User configurable

91

UserConfigurable:9

User configurable

92

Data File Auto Grow

Database

93

Log File Auto Grow

Database

94

Data File Auto Shrink

Database

95

Log File Auto Shrink

Database

96

Showplan Text

Performance

97

Showplan All

Performance

98

Showplan Statistics Profile

Performance

100

RPC Output Parameter

Stored Procedures

102

Audit Database Scope GDR Event

Security Audit

103

Audit Schema Object GDR Event

Security Audit

104

Audit Addlogin Event

Security Audit

105

Audit Login GDR Event

Security Audit

106

Audit Login Change Property Event

Security Audit

107

Audit Login Change Password Event

Security Audit

108

Audit Add Login to Server Role Event

Security Audit

Download from www.wowebook.com

Defining Server-Side Traces

145

TABLE 6.2 Trace Events and Their Related Categories Category Name

109

Audit Add DB User Event

Security Audit

110

Audit Add Member to DB Role Event

Security Audit

111

Audit Add Role Event

Security Audit

112

Audit App Role Change Password Event

Security Audit

113

Audit Statement Permission Event

Security Audit

114

Audit Schema Object Access Event

Security Audit

115

Audit Backup/Restore Event

Security Audit

116

Audit DBCC Event

Security Audit

117

Audit Change Audit Event

Security Audit

118

Audit Object Derived Permission Event

Security Audit

119

OLEDB Call Event

OLEDB

120

OLEDB QueryInterface Event

OLEDB

121

OLEDB DataRead Event

OLEDB

122

Showplan XML

Performance

123

SQL:FullTextQuery

Performance

124

Broker:Conversation

Broker

125

Deprecation Announcement

Deprecation

126

Deprecation Final Support

Deprecation

127

Exchange Spill Event

Errors and Warnings

128

Audit Database Management Event

Security Audit

129

Audit Database Object Management Event

Security Audit

130

Audit Database Principal Management Event

Security Audit

131

Audit Schema Object Management Event

Security Audit

132

Audit Server Principal Impersonation Event

Security Audit

6

trace_event_id Event Name

Download from www.wowebook.com

146

CHAPTER 6

SQL Server Profiler

TABLE 6.2 Trace Events and Their Related Categories trace_event_id Event Name

Category Name

133

Audit Database Principal Impersonation Event

Security Audit

134

Audit Server Object Take Ownership Event

Security Audit

135

Audit Database Object Take Ownership Event

Security Audit

136

Broker:Conversation Group

Broker

137

Blocked process report

Errors and Warnings

138

Broker:Connection

Broker

139

Broker:Forwarded Message Sent

Broker

140

Broker:Forwarded Message Dropped

Broker

141

Broker:Message Classify

Broker

142

Broker:Transmission

Broker

143

Broker:Queue Disabled

Broker

144

Broker:Mirrored Route State Changed

Broker

146

Showplan XML Statistics Profile

Performance

148

Deadlock graph

Locks

149

Broker:Remote Message Acknowledgement

Broker

150

Trace File Close

Server

151

Database Mirroring Connection

Database

152

Audit Change Database Owner

Security Audit

153

Audit Schema Object Take Ownership Event

Security Audit

154

Audit Database Mirroring Login

Security Audit

155

FT:Crawl Started

Full text

156

FT:Crawl Stopped

Full text

157

FT:Crawl Aborted

Full text

158

Audit Broker Conversation

Security Audit

Download from www.wowebook.com

Defining Server-Side Traces

147

TABLE 6.2 Trace Events and Their Related Categories Category Name

186

TM: Commit Tran completed

Transactions

187

TM: Rollback Tran starting

Transactions

188

TM: Rollback Tran completed

Transactions

189

Lock:Timeout (timeout > 0)

Locks

190

Progress Report: Online Index Operation

Progress Report

191

TM: Save Tran starting

Transactions

192

TM: Save Tran completed

Transactions

193

Background Job Error

Errors and Warnings

194

OLEDB Provider Information

OLEDB

195

Mount Tape

Server

196

Assembly Load

CLR

198

XQuery Static Type

T-SQL

199

QN: Subscription

Query Notifications

200

QN: Parameter table

Query Notifications

201

QN: Template

Query Notifications

202

QN: Dynamics

Query Notifications

212

Bitmap Warning

Errors and Warnings

213

Database Suspect Data Page

Errors and Warnings

214

CPU threshold exceeded

Errors and Warnings

215

PreConnect:Starting

Sessions

216

PreConnect:Completed

Sessions

217

Plan Guide Successful

Performance

218

Plan Guide Unsuccessful

Performance

235

Audit Fulltext

Security Audit

6

trace_event_id Event Name

Download from www.wowebook.com

148

CHAPTER 6

SQL Server Profiler

The numeric IDs for the trace columns can be obtained from the sys.trace_columns catalog view, as shown in the following example: select trace_column_id, name ‘Column Name’, type_name ‘Data Type’ from sys.trace_columns order by trace_column_id

Table 6.3 shows the results of this SELECT statement and lists all the available trace columns.

TABLE 6.3 Trace Columns Available for a Server-Side Trace trace_column_id

Column Name

Data Type

1

TextData

text

2

BinaryData

image

3

DatabaseID

int

4

TransactionID

bigint

5

LineNumber

int

6

NTUserName

nvarchar

7

NTDomainName

nvarchar

8

HostName

nvarchar

9

ClientProcessID

int

10

ApplicationName

nvarchar

11

LoginName

nvarchar

12

SPID

int

13

Duration

bigint

14

StartTime

datetime

15

EndTime

datetime

16

Reads

bigint

17

Writes

bigint

18

CPU

int

19

Permissions

bigint

20

Severity

int

21

EventSubClass

int

22

ObjectID

int

23

Success

int

Download from www.wowebook.com

Defining Server-Side Traces

149

TABLE 6.3 Trace Columns Available for a Server-Side Trace Column Name

Data Type

24

IndexID

int

25

IntegerData

int

26

ServerName

nvarchar

27

EventClass

int

28

ObjectType

int

29

NestLevel

int

30

State

int

31

Error

int

32

Mode

int

33

Handle

int

34

ObjectName

nvarchar

35

DatabaseName

nvarchar

36

FileName

nvarchar

37

OwnerName

nvarchar

38

RoleName

nvarchar

39

TargetUserName

nvarchar

40

DBUserName

nvarchar

41

LoginSid

image

42

TargetLoginName

nvarchar

43

TargetLoginSid

image

44

ColumnPermissions

int

45

LinkedServerName

nvarchar

46

ProviderName

nvarchar

47

MethodName

nvarchar

48

RowCounts

bigint

49

RequestID

int

50

XactSequence

bigint

51

EventSequence

bigint

6

trace_column_id

Download from www.wowebook.com

150

CHAPTER 6

SQL Server Profiler

TABLE 6.3 Trace Columns Available for a Server-Side Trace trace_column_id

Column Name

Data Type

52

BigintData1

bigint

53

BigintData2

bigint

54

GUID

uniqueidentifier

55

IntegerData2

int

56

ObjectID2

bigint

57

Type

int

58

OwnerID

int

59

ParentName

nvarchar

60

IsSystem

int

61

Offset

int

62

SourceDatabaseID

int

63

SqlHandle

image

64

SessionLoginName

nvarchar

65

PlanHandle

image

66

GroupID

int

You have to call the sp_trace_setevent procedure once for each data column you want captured for each event in the trace. Based on the number of events and number of columns, you can see that this can result in a lot of executions of the sp_trace_setevent procedure for a larger trace definition. To set up filters, you must pass the column ID, the filter value, and numeric values for the logical operator and column operator to the sp_trace_setfilter procedure. The logical operator can be either 0 or 1. A value of 0 indicates that the specified filter on the column should be ANDed with any other filters on the column, whereas a value of 1 indicates that the OR operator should be applied. Table 6.4 describes the values allowed for the column operators.

Download from www.wowebook.com

Defining Server-Side Traces

151

TABLE 6.4 Column Operator Values for sp_trace_setfilter Value

Comparison Operator

0

= (equal)

1

(not equal)

2

> (greater than)

3

< (less than)

4

>= (greater than or equal)

5

getdate() - 5 and UPPER(h.destination_database_name) = ‘AdventureWorks2008R2’ order by UPPER(h.destination_database_name), h.restore_date desc

One of the challenges with using system tables is determining the relationships between them. Some vendors offer diagrams of these tables, and you can also determine the relationships by reviewing the foreign keys on these tables and by referring to SQL Server 2008 Books Online, which describes the use for each column in the system table.

CAUTION Microsoft does not recommend querying system tables directly. It does not guarantee the consistency of system tables across versions and warns that queries that may have worked against system tables in past versions may no longer work. Catalog views or information schema views should be used instead, especially in production code.

7

Queries against system tables are best used for ad hoc queries. The values in system tables should never be updated, and an object’s structure should not be altered, either. Making changes to the data or structure could cause problems and cause SQL Server or one of its components to fail.

System Views System views are virtual tables that expose metadata that relates to many different aspects of SQL Server. Several different types of views target different data needs. SQL Server 2008 offers an extended number of system views and view types that should meet most, if not all, your metadata needs. The available system views can be shown in the Object Explorer in SSMS. Figure 7.2 shows the Object Explorer with the System Views node highlighted. There are far too many views to cover in detail in this chapter, but we cover each type of view and provide an example of each to give you some insight into their value. Each system view is covered in

Download from www.wowebook.com

172

CHAPTER 7

SQL Server System and Database Administration

detail in SQL Server Books Online, which includes descriptions of each column in the view.

FIGURE 7.2 System views listed in Object Explorer.

Compatibility Views Compatibility views were retained in SQL Server 2008 for backward compatibility. Many of the system tables available in SQL Server 2000 and prior versions of SQL Server are now implemented as compatibility views. These views have the same name as the system tables from prior versions and return the same metadata available in SQL Server 2000. They do not contain information that was added after SQL Server 2000. You can find most of the compatibility views in the Object Explorer by looking for system views that have names starting with sys.sys. For example, sys.syscolumns, sys.syscomments, and sys.sysobjects are all compatibility views. The first part of the name indicates the schema that the object belongs to (in this case, sys). All system objects are part of this sys schema or the INFORMATION_SCHEMA schema. The second part of the name is the view name, which corresponds to the name of a system table in SQL Server 2000.

Download from www.wowebook.com

System Views

173

TIP To see a list of compatibility views, use the index lookup in SQL Server 2008 Books Online and look for sys.sys. The index is placed at the beginning of a list of compatibility views, starting with sys.sysaltfiles. Objects in the list that are compatibility views have the text compatibility view following the object name, so you can easily identify them and get help. You also can use the new IntelliSense feature available with SQL Server 2008 to obtain information about the compatibility views and other system views. Simply open a query window in SSMS and start typing a SELECT statement. When you start typing the name of the view that you want to select from (for example, sys.) the IntelliSense drop-down appears listing the views that start with the letters sys. You can also determine the columns available from the view by referencing the view or alias for the view in the column selection list. When you enter the period following the view or alias, the IntelliSense drop-down shows you the available columns.

You should transition from the use of compatibility views to the use of other system views, such as catalog views. The scripts that were created in SQL Server 2000 and reference SQL Server 2000 system tables should continue to function in SQL Server 2008, but this capability is strictly for backward compatibility. Table 7.2 provides a list of SQL Server 2000 system tables and alternative SQL Server 2008 system views you can use instead.

TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables SQL Server 2008 System View

View Type

sysaltfiles

sys.master_files

Catalog view

syscacheobjects

sys.dm_exec_cached_plans

DMV

sys.dm_exec_plan_attributes

DMV

sys.dm_exec_sql_text

DMV

syscharsets

sys.syscharsets

Compatibility view

syscolumns

sys.columns

Catalog view

syscomments

sys.sql_modules

Catalog view

sysconfigures

sys.configurations

Catalog view

sysconstraints

sys.check_constraints

Catalog view

sys.default_constraints

Catalog view

sys.key_constraints

Catalog view

7

SQL Server 2000 System Table

Download from www.wowebook.com

174

CHAPTER 7

SQL Server System and Database Administration

TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables SQL Server 2000 System Table

SQL Server 2008 System View

View Type

sys.foreign_keys

Catalog view

syscurconfigs

sys.configurations

Catalog view

sysdatabases

sys.databases

Catalog view

sysdepends

sys.sql_dependencies

Catalog view

sysdevices

sys.backup_devices

Catalog view

sysfilegroups

sys.filegroups

Catalog view

sysfiles

sys.database_files

Catalog view

sysforeignkeys

sys.foreign_keys

Catalog view

sysfulltextcatalogs sys.fulltext_catalogs

Catalog view

sysindexes

sys.indexes

Catalog view

sys.partitions

Catalog view

sys.allocation_units

Catalog view

sys.dm_db_partition_stats

DMV

sysindexkeys

sys.index_columns

Catalog view

syslanguages

sys.syslanguages

Compatibility view

syslockinfo

sys.dm_tran_locks

DMV

syslocks

sys.dm_tran_locks

DMV

syslogins

sys.sql_logins (transact-sql)

Catalog view

sysmembers

sys.database_role_members

Catalog view

sysmessages

sys.messages

Catalog view

sysobjects

sys.objects

Catalog view

sysoledbusers

sys.linked_logins

Catalog view

sysopentapes

sys.dm_io_backup_tapes

DMV

sysperfinfo

sys.dm_os_performance_counters DMV

syspermissions

sys.database_permissions

Catalog view

sys.server_permissions

Catalog view

sys.dm_exec_connections

DMV

sysprocesses

Download from www.wowebook.com

System Views

175

TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables SQL Server 2000 System Table

SQL Server 2008 System View

View Type

sys.dm_exec_sessions

DMV

sys.dm_exec_requests

DMV

sys.database_permissions

Catalog view

sys.server_permissions

Catalog view

sysreferences

sys.foreign_keys

Catalog view

sysremotelogins

sys.remote_logins

Catalog view

sysservers

sys.servers

Catalog view

systypes

sys.types

Catalog view

sysusers

sys.database_principals

Catalog view

sysprotects

Catalog Views Using catalog views is the preferred method for returning information used by the Microsoft SQL Server database engine. There is a catalog view to return information about almost every aspect of SQL Server. The number of catalog views is far too large to list here, but you can gain some insight into the range of information available by looking at the following list, which shows the categories of information covered by catalog views:

7

. Change Tracking . Common language runtime (CLR) assembly . Data spaces and full text . Database mirroring . Data spaces . Endpoint . Extended properties . Linked servers . Messages (for errors) . Objects . Partition function . Resource Governor . Scalar types . Schemas

Download from www.wowebook.com

176

CHAPTER 7

SQL Server System and Database Administration

. Security . Server-wide configuration . Service Broker . SQL Server Extended Events . XML schemas (XML type system) Some of the catalog views return information that is new to SQL Server 2008. Examples include the Change Tracking and Resource Governor catalog views. Other catalog views provide information that may have been available in prior versions through system tables, system procedures, and so on, but the new catalog views expand on the information returned and include elements that are new to SQL Server 2008. To demonstrate the use of a catalog view, let’s compare a simple SQL Server 2000 SELECT statement that returns object information to a SELECT statement in SQL Server 2008 that returns similar information. The following example shows a SELECT statement written in SQL Server 2000 to return any stored procedure created after a given date: select o.crdate, o.name from sysobjects o where type = ‘p’ and crdate > ‘1/1/08’ order by crdate, name

Now, compare this SELECT statement to one that uses a SQL Server 2008 catalog view. The sys.objects catalog view is a new alternative to the SQL Server 2000 sysobjects system table. The following SELECT uses the sys.objects catalog view to return the same type of information as the preceding example: select o.create_date, o.modify_date, name from sys.objects o where type = ‘p’ and (create_date > ‘1/1/08’ or o.modify_date >= ‘1/1/08’) order by 1, 2, 3

As you can see, the modify_date column has been added to the SELECT statement. This column did not exist with the sysobjects system table. The addition of this column allows you to identify objects that were created as well as objects that were modified or altered. Let’s look at an example of using a catalog view to return the same kind of information returned in SQL Server 2000 with a system procedure. The handy sp_helpfile system procedure returns information about database files associated with a given database. This SQL Server 2000 procedure is still available in SQL Server 2008. An alternative to this procedure is the new sys.master_files catalog view. This view returns all the information that sp_helpfile returns and more. The following example shows a SELECT statement

Download from www.wowebook.com

System Views

177

using the sys.master_files catalog view to return the database files for the AdventureWorks2008R2 database: select * from sys.master_files where db_name(database_id) = ‘AdventureWorks2008R2’

You have the distinct advantage of being able to select the database files for all the databases on your server by using this catalog view. You can also tailor your SELECT statement to isolate database files based on the size of the database or the location of the physical database files. For example, to return all database files that are found somewhere on your C drive, you could use the following SELECT: select db_name(database_id), physical_name from sys.master_files where physical_name like ‘c:\%’

There are plenty of catalog views that provide information about SQL Server. When you are looking to return information about SQL Server components, you should look to the catalog views first. These views provide a great deal of flexibility and allow you to isolate the specific information you need.

Information Schema Views

7

Information schema views provide another system table–independent option for accessing SQL Server metadata. This type of view was available in prior versions of SQL Server. Using information schema views is a viable alternative for accessing SQL Server metadata from a production application. The information schema views enable an application that uses them to function properly even though the underlying system tables may have changed. Changes to the underlying system tables are most prevalent when a new version of SQL Server is released (such as SQL Server 2008), but changes can also occur as part of service packs to an existing version. The information schema views also have the advantage of being SQL-92 compatible. Compliance with the SQL-92 standard means that SQL statements written against these views work with other DBMSs that also adhere to the SQL-92 standard. The SQL-92 standard supports a three-part naming convention, which SQL Server has implemented as database.schema.object. In SQL Server 2008, all the information schema views are in the same schema, named INFORMATION_SCHEMA. The following information schema views or objects are available: . CHECK_CONSTRAINTS . COLUMN_DOMAIN_USAGE . COLUMN_PRIVILEGES . COLUMNS . CONSTRAINT_COLUMN_USAGE

Download from www.wowebook.com

178

CHAPTER 7

SQL Server System and Database Administration

. CONSTRAINT_TABLE_USAGE . DOMAIN_CONSTRAINTS . DOMAINS . KEY_COLUMN_USAGE . PARAMETERS . REFERENTIAL_CONSTRAINTS . ROUTINES . ROUTINE_COLUMNS . SCHEMATA . TABLE_CONSTRAINTS . TABLE_PRIVILEGES . TABLES . VIEW_COLUMN_USAGE . VIEW_TABLE_USAGE . VIEWS When you refer to information schema views in a SQL statement, you must use a qualified name that includes the schema name. For example, the following statement returns all the tables and columns in a given database, using the tables and columns information schema views: select t.TABLE_NAME, c.COLUMN_NAME from INFORMATION_SCHEMA.TABLES t join INFORMATION_SCHEMA.COLUMNS c on t.TABLE_NAME = c.TABLE_NAME order by t.TABLE_NAME, ORDINAL_POSITION

TIP You can expand the Views node in a given database in the Object Explorer and open the System Views node to see a list of the available information schema views. The information schema views are listed at the top of the System Views node. If you expand the Column node under each information schema view, you see the available columns to select from the view. You can then drag the column into a query window for use in a SELECT statement. You can also use IntelliSense in a query window determine the columns.

Fortunately, the names of the information schema views are fairly intuitive and reflect the kind of information they contain. The relationships between the information schema views can be derived from the column names shared between the tables.

Download from www.wowebook.com

System Views

179

Dynamic Management Views Dynamic management views (DMVs), which were introduced in SQL Server 2005, provide a simple means for assessing the state of a server. These views provide a lightweight means for gathering diagnostic information without the heavy burden associated with the tools available in SQL Server 2000. The SQL Server 2000 diagnostic tools, such as heavy Profiler traces, PerfMon, dbcc executions, and pssdiag, are still available, but oftentimes, the information returned from the DMVs is enough to determine what may be ailing a SQL Server machine. An extensive number of DMVs are available in SQL Server 2008. Some DMVs are scoped at the server level, and others are scoped at the database level. They are all found in the sys schema and have names that start with dm_. Table 7.3 lists the different types of DMVs. The DMVs in this table are categorized based on function as well as the starting characters in the DMV names. The naming convention gives you an easy means for identifying the type of each DMV.

TABLE 7.3 Types of DMVs Name Prefix

Information Captured

Auditing

dm_audit

New Auditing information

Service Broker

dm_broker

Server Broker statistics, including activated tasks and connections

Change Data

dm_cdc

New Change Data Capture information

CLR

dm_clr

CLR information, including the CLR loaded assemblies

Cryptographic dm_cryp

7

Category

Security related data

TDE

dm_database Transparent Data Encryption

Database

dm_db

Databases and database objects

Execution

dm_exec

Execution of user code

Full-Text

dm_fts

Full-Text Search information

I/O

dm_io

Input and output on network disks

Operating system

dm_os

Low-level operating system information, including memory and locking information

Provider

dm_provider Extensible Key Management (EKM)

Query Notification

dm_qn

Active Query Notification subscriptions

Replication

dm_repl

Replication information, including the articles, publications, and transaction involved in replication

Download from www.wowebook.com

180

CHAPTER 7

SQL Server System and Database Administration

TABLE 7.3 Types of DMVs Category

Name Prefix

Information Captured

Server

dm_server

Server Audit status

Transaction

dm_tran

Transactions and isolation-level information

Object

dm_sql

Object References

Extended Events

dm_xe

New event handling infrastructure

TIP You can expand the Views node in a given database in the Object Explorer and open the System Views node to see a list of the available DMVs. The DMVs are all listed together and start with dm_. If you expand the Column node under each DMV, you see the available columns to select from the view. You can then drag the column into a query window to be included in a SELECT statement.

To illustrate the value of the DMVs, let’s look at a performance scenario and compare the SQL Server 2000 approach to a SQL Server 2008 approach using DMVs. A common performancerelated question is “What stored procedures are executing most frequently on my server?” With SQL Server 2000, the most likely way to find out is to run a Profiler trace. You must have a Profiler trace that has already been running to capture the stored procedure executions, or you must create a new trace and run it for a period of time to answer the performance question. The trace takes time to create and can affect server performance while it is running. With SQL Server 2008, you can use one of the DMVs in the execution category to answer the same performance question. The following example uses the sys.dm_exec_query_stats DMV along with a dynamic management function named dm_exec_sql_text. It returns the object IDs of the five most frequently executed stored procedures, along with the actual text associated with the procedure: select top 5 q.execution_count, q.total_worker_time, s.dbid, s.objectid, s.text from sys.dm_exec_query_stats q CROSS APPLY sys.dm_exec_sql_text (q.sql_handle) s ORDER BY q.execution_count desc

The advantage of using a DMV is that it can return past information without having to explicitly create a trace or implement some other performance tool. SQL Server automatically caches the information so that you can query it at any time. The collection of the data starts when the SQL Server instance is started, so you can get a good cross-section of information. Keep in mind that your results can change as the server continues to collect information over time. Many of the performance scenarios such as those that relate to memory, CPU utilization, blocking, and recompilation can be investigated using DMVs. You should consider using

Download from www.wowebook.com

System Views

181

DMVs to address performance problems before using other methods in SQL Server 2008. In many cases, you may be able to avoid costly traces and glean enough information from the DMV to solve your problem.

NOTE Dynamic management functions return the same type of information as DMVs. The dynamic management functions also have names that start with dm_ and reside in the sys schema. You can find the dynamic management functions listed in the Object Explorer within the master database. If you select Function, System Functions, TableValued Functions, you see the dynamic management functions listed at the top.

DMVs are also a great source of information that does not relate directly to performance. For example, you can use the dm_os_sys_info DMV to gather important server information, such as the number of CPUs, the amount of memory, and so on. The following example demonstrates the use of the dm_os_sys_info DMV to return CPU and memory information: select cpu_count, hyperthread_ratio, physical_memory_in_bytes from sys.dm_os_sys_info /* Results from prior select

7

cpu_count hyperthread_ratio physical_memory_in_bytes ----------- ----------------- -----------------------2 2 2146357248 */

The cpu_count column returns the number of logical CPUs, hyperthread_ratio returns the ratio between physical CPUs and logical CPUs, and the last column selected returns the physical memory on the SQL Server machine.

System Stored Procedures System stored procedures have been a favorite of SQL Server DBAs since the inception of SQL Server. They provide a rich set of information that covers many different aspects of SQL Server. They can return some of the same types of information as system views, but they generally return a fixed set of information that cannot be modified as you can when using a SELECT statement against the system views. That is not to say that they are not valuable; they are valuable, and they are particularly useful for people who have been using SQL Server for a long time. System stored procedures such as sp_who, sp_lock, and sp_help are tools for a database professional that are as basic as a hammer is to a carpenter. System stored procedures have names that start with sp_, and they are found in the sys schema. They are global in scope, which allows you to execute them from any database,

Download from www.wowebook.com

182

CHAPTER 7

SQL Server System and Database Administration

without qualifying the stored procedure name. They also run in the context of the database where you are working. In other words, if you execute sp_helpfile in the AdventureWorks2008R2 database, the database files for the AdventureWorks2008R2 database are returned. This same type of behavior exists for any stored procedure that is created in the master database with a name that starts with sp_. For example, if you create a procedure named sp_helpme in the master database and execute that procedure in the AdventureWorks2008R2 database, SQL Server ultimately looks for and finds the procedure in the master database.

NOTE It is often useful to create your own system stored procedures to make it easier to execute complex queries against the system views (or to provide information not provided by the built-in system procedures). For more information and tips on creating your own system stored procedures, refer to Chapter 28, “Creating and Managing Stored Procedures.”

System stored procedures are listed in the Object Explorer, in the Programmability node within Stored Procedures and then System Stored Procedures. There are far too many system stored procedures to list or discuss them all here. A quick check of the master database lists more than 1,000 procedures. SQL Server Books Online provides detailed help on these procedures, which it groups into 18 different categories.

Useful System Stored Procedures You are likely to use only a handful of system stored procedures on a regular basis. What procedures you use depends on the type of work you do with SQL Server and your capacity to remember their names. Table 7.4 contains a sample set of system stored procedures that you may find useful.

TABLE 7.4 Useful System Stored Procedures System Stored Procedure

Description

sp_configure

Displays or changes server-wide configuration settings.

sp_createstats

Creates statistics that are used by the Query Optimizer for all tables in a database.

sp_help

Provides details about the object that is passed to it. If a table name is passed to this procedure, it returns information on the columns, constraints, indexes, and more.

sp_helpdb

If no parameters are supplied, returns relevant database information (including the space used) for all the databases on an instance of SQL Server.

Download from www.wowebook.com

System Stored Procedures

183

TABLE 7.4 Useful System Stored Procedures System Stored Procedure

Description

sp_helpfile

Lists the database files associated with the database you are connected to.

sp_lock

Displays current locking information for the entire SQL Server instance.

sp_spaceused

Provides the number of rows and disk space used by the table, indexed view, or queue passed to it.

sp_who

Lists current processes that are connected to an instance of SQL Server.

Many of the administrative functions performed by SSMS can also be accomplished with system stored procedures. Examples include procedures that start with sp_add and sp_delete, which can be used to add and delete database objects. In addition, more than 90 system stored procedures start with sp_help, which return help information on database objects.

TIP

7

You can use the sys.all_objects catalog view to search for available system stored procedures. This catalog view lists objects that are schema scoped as well as system objects. For example, the query SELECT * FROM sys.all_objects WHERE name LIKE ‘sp_help%’ returns all the system stored procedures that start with sp_help. You can turn to Books Online for detailed help on any of the system stored procedures. Just enter sp_ in the index search, and you see a list of them all.

Becoming familiar with some of the system stored procedures is well worth your while. Using them is a very fast and effective means for gathering information from SQL Server. They do not require the formation of a SELECT statement, and using them is often the easiest way to get information via a query window.

Summary Administering SQL Server can be a complex and time-consuming job. Understanding the SQL Server internals and some of the easy ways to obtain information about a SQL Server instance can make this job a lot easier. Taking the time to learn what makes SQL Server tick expands your knowledge of this comprehensive DBMS and helps you make better decisions when working with it. Now that you know a bit about managing SQL Server, you may need to install an instance of SQL Server to administer. Take a look at Chapter 8, “Installing SQL Server 2008,” which guides you through the installation process.

Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

8

Installing SQL Server 2008

IN THIS CHAPTER . What’s New in Installing SQL Server 2008 . Installation Requirements . Installation Walkthrough . Installing SQL Server Using a Configuration File

Installing SQL Server is the first and one of the easiest tasks you’ll accomplish as an administrator. And even though it may take as little as 15 minutes to get SQL Server 2008 up and running by clicking through the install screens and accepting the defaults (Next, Next, Next...), it is crucial to first understand the meaning of each install option and its ramifications for your environment.

. Installing Service Packs and Cumulative Updates . Slipstream Installations

What’s New in Installing SQL Server 2008 The installation process has been completely revamped for SQL Server 2008, introducing enhancements to simplify the installation compared to SQL Server 2005. The new installation features for SQL Server 2008 include the following: . A new SQL Server 2008 Installation Center landing page, which includes a number of options for planning, installing, and maintaining a SQL Server implementation, as well as links to SQL Server documentation for planning and reviewing before starting the install. . New maintenance tasks available in the installation process, allowing DBAs to either repair a corrupt SQL Server 2008 installation or conduct a feature upgrade. The Feature Upgrade Wizard allows DBAs to upgrade or change their installed edition of SQL Server 2008 (for example, upgrading from Standard Edition to Enterprise Edition without having to perform a complete reinstall).

Download from www.wowebook.com

186

CHAPTER 8

Installing SQL Server 2008

. A discovery report that provides details on all SQL Server components, features, and settings associated with an installation. . The potential to automate SQL Server installations by using an existing configuration file. . An Advanced Cluster Preparation tool, which streamlines and prepares a SQL Server 2008 failover cluster installation. With the release of Service Pack 1, SQL Server 2008 also now supports Slipstream installation. Slipstreaming is a method of integrating a SQL Server 2008 update (such as a service pack or cumulative update) with the original installation media so that the original media and update are installed at the same time. This capability can be a huge timesaver over having to manually apply service packs or cumulative updates after performing a full installation.

Installation Requirements Before you install SQL Server 2008 on your server, it’s a good idea (even if you own the latest-and-greatest system) to review the hardware and software requirements. The next two sections gather all the fine print into a few conveniently organized tables.

NOTE The SQL Server 2008 installer helps determine whether your system meets the minimum requirements by running the new System Configuration Checker (SCC) early in the install. SCC conveniently provides a savable (via a button click) textual report on its results (and displays them onscreen). SCC is covered in detail later in this chapter.

Hardware Requirements To install SQL Server 2008, you must ensure your system possesses a few basic components: . A pointing device . A display device with resolution of at least 1024×768 (required by SQL Server Management Studio [SMSS]) . A DVD-ROM or CD-ROM drive (for installation from disc) Table 8.1 lists server environment hardware requirements, by SQL Server edition, with reference to processor type and/or word length. This table lists the base minimum hardware requirements. In most installations, you want to have at least 2GB of memory and a 2GHz or faster processor. In addition, installation using a redundant array of disks (RAID) on production systems is highly recommended. Of course, faster editions of processors, increased RAM, and more disk space don’t negatively impact any installation either. One final (and perhaps obvious) note: The more SQL Server components you install, the more disk space you need. Analysis Services, for example, requires an additional 90MB of disk space for the install.

Download from www.wowebook.com

Installation Requirements

187

The hard disk space requirements for SQL Server are dependent on which SQL Server components are installed. Table 8.2 breaks down the disk space requirements by feature.

TABLE 8.1 SQL Server 2008 Minimum Hardware Requirements, by Edition SQL Server Editions

Memory (RAM)

Processors (CPU)

Enterprise, Datacenter, Standard, Workgroup, Web, and Developer (32-bit)

1GB

1GHz Pentium III

Enterprise, Datacenter, Standard, Workgroup, Web, and Developer (64-bit)

1GB

1.4GHz AMD Opteron, AMD Athlon 64, Intel Xeon with Intel EM64T support, or Intel Pentium IV with EM64T support

Enterprise, Standard, and Developer (Itanium)

1GB

1GHz Itanium

Express (64-bit)

256MB

1.4GHz AMD Opteron, AMD Athlon 64, Intel Xeon with Intel EM64T support, or Intel Pentium IV with EM64T support

Express (32-bit)

256MB

1GHz Pentium III

Express with Tools and Express with Advanced Services (32-bit)

512MB

1GHz Pentium III

NOTE

8

Licensing for multicore processors is the same as for single-core processors: only a single license is required for each multicore processor. Another way of saying this is licensing is per CPU socket, not per processor core.

TABLE 8.2 SQL Server 2008 Disk Space Requirements, by Feature SQL Server Feature

Disk Space Requirement

Database Engine and data files, Replication, and Full-Text Search

280MB

Analysis Services and data files

90MB

Reporting Services and Report Manager

120MB

Integration Services

120MB

Client Components

850MB

SQL Server Books Online

240MB

Download from www.wowebook.com

188

CHAPTER 8

Installing SQL Server 2008

Software Requirements The following software prerequisites must be installed on any server running any SQL Server edition: . Microsoft Internet Explorer 6.0 Service Pack 1 (SP1) or later (required because it is a dependency of SMSS, Books Online, Business Intelligence Development Studio [for Analysis Services], and the Report Designer) . Windows Installer 4.5 or later (sometimes distributed by Microsoft Windows Update services; also will be installed by the SQL Server Installation Center) . .NET Framework 3.5 SP1, SQL Server Native Client and SQL Server Setup support files (if not installed already, these are also installed by SQL Server Installation Center) Table 8.3 lists the software and operating system requirements for SQL Server 2008, by edition.

TABLE 8.3 SQL Server 2008 R2 Software Requirements, by Edition SQL Server Editionμs

Supported Operating Systems

Enterprise and Datacenter (32-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter Editions with SP2 or later Windows Server 2008 Web, Standard, Enterprise, and Datacenter Editions with SP2 or later Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter Editions

Enterprise and Datacenter (64-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter x64 Editions with SP2 or later Windows Server 2008 Standard, Web, Enterprise, and Datacenter x64 Editions with SP2 or later Windows Server 2008 R2 Standard, Web, Enterprise, and Datacenter x64 Editions

Enterprise (Itanium)

Windows Server 2003 Enterprise and Datacenter 64-bit Itanium Editions SP2 or later Windows Server 2008 64-bit Itanium with SP2 or later Windows Server 2008 R2 64-bit Itanium

Download from www.wowebook.com

Installation Requirements

189

TABLE 8.3 SQL Server 2008 R2 Software Requirements, by Edition Supported Operating Systems

Standard and Developer (32-bit)

Windows XP SP3 or later Windows Vista SP2 Ultimate, Enterprise, Business, and Home Basic/Premium Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium x64 Editions Windows Server 2003 Enterprise, Standard, and Datacenter Editions with SP2 or later Windows Server 2008 R2 Web Standard, Enterprise, and Datacenter Editions Windows Server 2008 Web, Standard, Enterprise, and Datacenter Editions

Standard and Developer (64-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter x64 Editions with SP2 or later Windows XP Professional x64 Edition Windows Vista Ultimate, Enterprise, Business, and Home Basic/Premium x64 Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium x64 Editions Windows Server 2008 Web, Standard, Datacenter, and Enterprise x64 Editions Windows Server 2008 R2 Web, Standard, Datacenter, and Enterprise x64 Editions

Developer (Itanium)

Windows Server 2003 Enterprise and Datacenter Editions for Itaniumbased systems with SP2 or later Windows Server 2008 64-bit Itanium Enterprise and Datacenter Edition SP2 or later Windows Server 2008 R2 64-bit Itanium Enterprise Edition

Workgroup (32-bit)

Windows XP SP3 and later Windows Server 2003 Standard, Enterprise, and Datacenter Editions with SP2 or later Windows Vista SP2 Ultimate, Enterprise, Business, and Home Basic/Premium Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium Editions Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter Editions

8

SQL Server Editionμs

Download from www.wowebook.com

190

CHAPTER 8

Installing SQL Server 2008

TABLE 8.3 SQL Server 2008 R2 Software Requirements, by Edition SQL Server Editionμs

Supported Operating Systems

Workgroup (64-bit)

Windows XP x64 Professional Windows Server 2003 Standard, Enterprise, and Datacenter x64 Editions with SP2 or later Windows Vista Ultimate, Home Premium, Home Basic, Enterprise, and Business x64 Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium x64 Editions Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter x64 Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter x64 Editions

Web (32-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter Editions with SP2 or later Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter Editions

Web (64-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter x64 Editions with SP2 or later Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter x64 Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter x64 Editions

Express (32-bit)

Windows XP (Home, Tablet, Professional, and Media Editions) SP2 or later Windows Server 2003 (Web, Standard, Enterprise, and Datacenter Editions with SP2 or later) Windows Vista SP2 Ultimate, Home Premium, Home Basic, Enterprise, and Business Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium Editions Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter Editions

Download from www.wowebook.com

Installation Requirements

191

TABLE 8.3 SQL Server 2008 R2 Software Requirements, by Edition SQL Server Editionμs

Supported Operating Systems

Express (64-bit)

Windows Server 2003 Standard, Enterprise, and Datacenter x64 Editions with SP2 or later Windows Vista Ultimate, Home Premium, Home Basic, Enterprise, and Business x64 Editions Windows 7 Ultimate, Enterprise, Professional, and Home Basic/Premium x64 Editions Windows Server 2008 SP2 Web, Standard, Enterprise, and Datacenter x64 Editions Windows Server 2008 R2 Web, Standard, Enterprise, and Datacenter x64 Editions

Network Protocol Support The following network protocols are supported for all editions (where applicable): . Shared memory (but not for failover clusters) . Named pipes . TCP/IP (required for SQL Server endpoint communications) . Virtual Interface Adapter (VIA)

8

Running Multiple Simultaneous Editions You can install multiple editions of SQL Server 2008 on the same machine and run them simultaneously. This capability comes in handy when you need to test code or other feature functionality on one edition versus another, such as when your development and deployment environments differ. In fact, you can even install and run SQL Server 2008 Enterprise Evaluation Edition on XP SP2 (not supported for the non–Evaluation Enterprise Edition) if you need to test an Enterprise Edition feature on a non–Windows Server system.

NOTE You can quickly ascertain the SQL Server edition you’re running by executing this T-SQL query: select serverproperty(‘edition’)

Download from www.wowebook.com

192

CHAPTER 8

Installing SQL Server 2008

Installation Walkthrough The following sections walk you through a typical installation scenario step by step. We bring up important points of information along the way, providing a real-world perspective on the process. No past experience with SQL Server is required to understand these sections.

NOTE SQL Server 2008 is actually version 10 of the product, just as SQL Server 2005 is version 9, and SQL Server 2000 was version 8, which succeeded SQL Server 7. SQL Server 2008 R2 is considered version 10.5. Although versioning by year seems straightforward, it may obfuscate the reasoning behind the naming convention used for many installed items, such as shared folder names (for example, Microsoft SQL Server\100), SQL Server instance folder names (for example, \MSSQL10_50.MSSQLSERVER), and so on. In addition, SQL Server 2000 servers appear as version 8 when registered in SSMS (and elsewhere). You can still administer many aspects of SQL Server 2000 instances via the 2008 and 2008 R2 management tools.

Install Screens, Step by Step The first step in installing SQL Server 2008 or 2008 R2 is, of course, to launch the SQL Server Installation Center. You do this by inserting the install DVD in the drive and double-clicking setup.exe in the root folder (if AutoPlay is enabled, setup runs automatically). If you’re installing from a decompressed .iso file or network share, locate the root folder and double-click the setup.exe file in the root folder. If Windows Installer 4.5 or Microsoft .NET Framework 3.5 Service Pack 1 are not installed, the SQL Server Setup program first needs to install them before you can continue. If this is the case, you see a dialog like the one shown in Figure 8.1

FIGURE 8.1 SQL Server 2008 prerequisites warning dialog.

Download from www.wowebook.com

Installation Walkthrough

193

NOTE If the prerequisites for the Installer need to be installed, you likely need to restart the computer for the updates to take effect. After restarting, rerun setup.exe to continue the installation.

When the prerequisites are installed, the Installation Wizard runs the SQL Server Installation Center, as shown in Figure 8.2.

8

FIGURE 8.2 SQL Server 2008 Installation Center window.

NOTE The same installation program is used whether you want to perform a full SQL Server installation or to install just the client tools. You have the option to choose which components to install on the Feature Selection screen, which is displayed after you install the Setup Support Files.

The first thing you’ll notice is that there is a great deal of content immediately available from the SQL Server Installation Center Planning window, including documentation on hardware and software requirements, release notes, security and upgrade documentation,

Download from www.wowebook.com

194

CHAPTER 8

Installing SQL Server 2008

and the System Configuration Checker. You typically first want to run the System Configuration Checker to confirm that your system meets the minimum hardware and software requirements for installing SQL Server 2008. Click on the link for the System Configuration Checker to bring up the screen shown in Figure 8.3. This is essentially the Setup Support Rules screen that also runs during the actual installation. It’s better to find out now if there will be any issues with the installation before you get into the actual installation.

FIGURE 8.3 System Configuration Checker window

When the SCC scan is complete, overall status of the check is detailed at the top of the main window. You can click the Show Details button to view a detailed report of the checks performed. This report notes any issues found. If any checks fail, or a warning is raised, click the hyperlink in the Status column for more detailed report with specifics and suggestions for resolution. Click the View Detailed Report link to see the SCC results in an HTML report format, which is also saved to a file (see Figure 8.4). After you verify that the system configuration is sufficient to support the SQL Server 2008 installation, click OK to go back to the SQL Server Installation Center. Then click on the Installation option in the menu on the left of the SQL Server Installation Center. This brings up the installation options. To install a new instance of SQL Server, select the New Installation or Add Features to an Existing Installation option, as shown in Figure 8.5.

Download from www.wowebook.com

Installation Walkthrough

195

FIGURE 8.4 System Configuration Checker HTML report.

8

FIGURE 8.5 SQL Server Installation menu.

Download from www.wowebook.com

196

CHAPTER 8

Installing SQL Server 2008

NOTE The following installation steps and screenshots are based on the installation of SQL Server 2008 R2. For SQL Server 2008 installations, the order of the install screens and options may be slightly different, but the screen contents and options are similar.

The first step of the installation is to run the Setup Support Rules to identify any potential issues that might occur when the installer installs the SQL Server Setup support files and lists any items that may need to be corrected before Setup can continue. These checks include the following: . Operating system version . Whether there are any reboots pending from other installers . Whether the logged-in user is a system administrator (a must) . Whether there is support for long pathnames where the installation media resides . The consistency of any SQL Server Registry keys After the Setup Support Rules run for the Setup Support Files, you can click on the Show Details button to display a window like that shown in Figure 8.6.

FIGURE 8.6 Setup Support Rules for Setup Support Files Detail. If any tests fail, you can click on the View Detailed Report link to see a more detailed report file. You can also click on the hyperlink in the Status column of the failed rule to

Download from www.wowebook.com

Installation Walkthrough

197

view specifics on the failed rule. If there are no failed Setup Support Rules to hinder installation, click OK to continue to the installation of the Setup Support Files (see Figure 8.7). The Setup Support Files are components that need to be installed so that the actual SQL Server product installation can proceed. Click Install to initiate the installation of the Setup Support Files.

FIGURE 8.7 Setup Support Files installation screen.

8

After the installation of the Setup Support Files has completed successfully, the Installer reruns the Setup Support Rules, this time running additional checks to verify that the system will support the installation of SQL Server and its features. Again, if any of the tests fail or a warning is generated, you typically need to address this situation before continuing to ensure a successful SQL Server installation. For example, Figure 8.8 shows a warning regarding Windows Firewall. Clicking on the Warning hyperlink in the Status column brings up a dialog with more information about the warning. In this case, the warning indicates that if Windows Firewall is enabled, the network ports for SQL Server need to be opened to allow remote clients to access SQL Server on this machine. If no tests have failed and all warnings have been reviewed or resolved, click Next to bring up the Product Key page to enter any necessary product keys if you are installing a version of SQL Server 2008 that is not free (see Figure 8.9). After entering the product key (if needed), click Next to review the License Terms for SQL Server 2008 R2 (see Figure 8.10). Note that you need to accept the license agreement that follows; otherwise, you can’t proceed. Click the check box indicating your acceptance of the license terms and click Next to bring up the Setup Role page, as shown in Figure 8.11.

Download from www.wowebook.com

198

CHAPTER 8

Installing SQL Server 2008

FIGURE 8.8 Setup Support Rules for SQL Server installation detail.

FIGURE 8.9 Product Key entry page.

Download from www.wowebook.com

Installation Walkthrough

199

FIGURE 8.10 License Terms page.

8

FIGURE 8.11 Setup Role page.

Download from www.wowebook.com

200

CHAPTER 8

Installing SQL Server 2008

The Setup Role page is new with SQL Server 2008 R2. This page was not available in SQL Server 2008. The Setup Role page lets you specify whether to use the Feature Selection page to select individual features to be installed or to install using a setup role. A setup role is a fixed selection of all the features and shared components required to implement a predefined SQL Server configuration. For example, in Figure 8.11, you are presented with three options. The SQL Server Feature Installation option lets you select individual features and shared components to be installed, such as Database Engine Services, Analysis Services (native mode), Reporting Services, and Service Broker. The Analysis Services with SharePoint Integration option allows you to install Analysis Services server components in a Microsoft Office SharePoint Server farm. This option enables large-scale query and data processing for published Excel workbooks that contain embedded PowerPivot data. The All Features with Defaults option skips the Feature Selection screen and installs all SQL Server 2008 R2 features available for the current release. All services are installed with the default system accounts, and the current user running the install is provisioned as a member of the SQL Server sysadmin role. In most cases, you choose the SQL Server Feature Installation option. After selecting this option, click Next to display the Feature Selection window (see Figure 8.12). Here, you can select which SQL Server features you want to install. For example, if you want to install only the SQL Server Client Tools, this is the place you specify that choice.

FIGURE 8.12 The Feature Selection page. Following are the most commonly available features (detailed in subsequent chapters of this book):

Download from www.wowebook.com

Installation Walkthrough

201

. Database Engine Services—Includes the core Database Engine services, optional replication (see Chapter 19, “Replication”), and Full-Text Search (see Chapter 50, “SQL Server Full-Text Search”) services. . Analysis Services—Includes the engine used to create business intelligence solutions that rely on OLAP and data mining (see Chapter 51, “SQL Server 2008 Analysis Services”). . Reporting Services—Includes the engine and tools used to generate and deploy data-centric reports (see Chapter 53, “SQL Server 2008 Reporting Services”). . Shared Features—Includes optional features shared among multiple SQL Server instances on the same system, such as Business Intelligence Development Studio, Client Tools Connectivity components, Integration Services, SQL Server Books Online, SQL Server Management Tools, and the Microsoft Sync Framework. If you are uncertain about the need for a specific feature, when you click on it in this window, a description of the feature and what will be installed is displayed in the Description pane on the right. The Feature Selection page is also the place where you can change the installation location for the shared features (if this is the first time any of the shared features are being installed on the system). The default location is C:\Program Files\Microsoft SQL Server. In most production installations, you’ll most likely want the shared features to remain in the Program Files folder. After you finish making your selections, click Next to move on to the Installation Rules page (see Figure 8.13).

NOTE In versions of SQL Server 2008 prior to R2, the installation rules were not run until later in the installation process.

8 The Installation Rules page runs a check to determine whether there are any issues that will block the installation of the selected features. From this page, you can address any issues and rerun the rules until they all pass or only warning messages are displayed. Like the Setup Support Rules page, this page enables you to get detailed information on the rule checks performed by clicking on the Show Details button. You can get more information on a specific rule by clicking the hyperlink in the Status column. A detailed HTML report can be generated as well by clicking on the View Detailed Report hyperlink. When no errors are displayed on the Installation Rules page, click Next to proceed to the Instance Configuration page. You can choose to install SQL Server as the default instance (if a default instance has not already been installed) or as a named instance. SQL Server supports multiple instances of SQL Server on a single server or workstation, but only one instance can be the default instance. The default instance can be an installation of SQL Server 2000, SQL Server 2005, or SQL Server 2008. All other instances must be named instances. The named instances

Download from www.wowebook.com

202

CHAPTER 8

Installing SQL Server 2008

FIGURE 8.13 The Installation Rules page. can be different versions and/or editions of SQL Server. You can run multiple instances of SQL Server concurrently on the same machine with each instance running independently of other instances. You can also install SQL Server as a named instance without installing a default instance first. If any instances are already installed, they are listed in the Installed Instances list. (For example, Figure 8.14 shows that an instance of the Shared Components from SQL Server 2005 is already installed.) Another option you can specify on this screen is the Instance Root Directory. This determines where the data files for the system databases for the SQL Server instance will be installed. The installation path for SQL Server 2008 defaults to the system drive of the machine to which you are installing, followed by the root default folder: [system drive letter]:Program Files\Microsoft SQL Server. From here, two main subfolders branch out: . 100—This is the version-specific parent folder (SQL Server 2008 is version 10.0, hence 100) for shared features such as Integration Services (under DTS), client tools (under Tools), shared tools (under Shared), and COM components (under COM). . MSSQL10_50.InstanceName—This is the parent folder for Database Engine components (under MSSQL/Binn) and data files (under MSSQL/Data). InstanceName is determined by the value specified during the installation process. . MSAS10_50.InstanceName—This is the parent folder for Analysis Services components.

Download from www.wowebook.com

Installation Walkthrough

203

FIGURE 8.14 Instance Configuration page. . MSRS10_50.InstanceName—This is the parent folder for Reporting Services components.

8

After you finish configuring the instance, click Next to bring up the Disk Space Requirements page. This information screen shows only the disk space requirements for the features you’ve chosen to install and the available space in the drives you selected to install to. If you want to change the install locations, click on the Back button to return to the screen where the installation directory you want to change is specified. When you are satisfied with your selections, click Next to move onto the Server Configuration page (see Figure 8.15). On the Server Configuration page, you can specify the specific user accounts and passwords to use for the selected SQL Server services you chose to install. To simplify matters, you can click the Use the Same Account for All SQL Server Services button to specify a single local or domain account dedicated for SQL Server 2008 R2 use and assign it to all services. However, for improved security, it is recommended that you create multiple accounts, one for each service. This helps reinforce the least-privileged user account approach, which states that a user should have only the privileges required to get the job done—and no more. Having multiple accounts also makes it clearer for network administrators to determine which SQL Server services (as opposed to the multitude of other running services) are requesting access to a resource. If you don’t specify a user account, the services are set up to run under the Local System account, which is an account with local admin privileges that does not have access to any network resources. The Installer provides warnings if you specify an account with insufficient privileges or credentials.

Download from www.wowebook.com

204

CHAPTER 8

Installing SQL Server 2008

FIGURE 8.15 Server Configuration page. Also on the Service Accounts tab, you can select the server startup options for the SQL Server services being installed by selecting the startup type in the drop-down selection list to the right of the service. It is highly recommended to autostart the SQL Server service so it’s available when the system is started. (If necessary, you can change the startup options for the SQL Server services later, using the SQL Server Configuration Manager.)

NOTE The SQL Server Browser service is installed only once, no matter how many instances you install.

NOTE If you are not sure what accounts to set up for the various services, don’t worry too much at this point. You can always change the service accounts later using the SQL Server Configuration Manager.

The Server Configuration page also allows you to override the default SQL Server collation settings. You do so by first clicking on the Collation tab (see Figure 8.16). Collations are important because they are used to determine case sensitivity of textual data for comparisons, sort order in indexes, and so on.

Download from www.wowebook.com

Installation Walkthrough

205

FIGURE 8.16 Server Configuration Collation setting.

8

If you’re running Windows in the United States, the collation selection defaults to SQL_Latin1_General_CP1_CI_AS for the Database Engine. The default settings should be changed only if the collation setting for this installation of SQL Server needs to match the collation settings used by another instance of SQL Server, or if it needs to match the Windows system locale of another computer. If you need to change the collation settings, click on the Customize button. This brings up the Database Engine Collation Customization dialog, where you can select from standardized SQL Collations or customize your own by specifying a Windows collation setting and the desired sort options. After making your selections on the Server Configuration page, click Next to move onto the Database Engine Configuration page. On this page, you can specify the authentication mode to use for SQL Server. This is done on the Account Provisioning tab (see Figure 8.17). The default setting is for Windows Authentication only. However, Mixed Mode authentication is required if you plan to have any clients authenticating to SQL Server 2008 R2 but will not be authenticating to a Windows domain. If you do select Mixed Mode authentication, you also have to enter a password to use for the built-in in SQL Server administration account (sa). A strong sa password is recommended. The Account Provisioning page also provides the opportunity to specify local or domain accounts to be mapped to the sysadmin role in SQL Server (you must provide at least one). These accounts have unrestricted access to SQL Server for performing SQL Server administration and maintenance tasks. For more information on user accounts, passwords, and server roles, see Chapter 11, “Security and User Administration.”

Download from www.wowebook.com

206

CHAPTER 8

Installing SQL Server 2008

FIGURE 8.17 The Account Provisioning tab.

On the Data Directories tab (see Figure 8.18), you can configure the data root directory and default directories where the user and tempdb data and log files will be created, as well as the default location for the Backup directory. Note that the System Database Directory cannot be changed here; you need to return to the Instance Configuration page and modify the Instance Root directory. In a production installation, for performance reasons, you should set up multiple drives or drive arrays to store the data and log files. Typically, you do not want the system data files stored on the C: drive, especially buried in the Program Files folder. You likely want to locate the data files on a high-performance drive setup specifically for database files and away from the system swap file and other applications. For recoverability purposes, you also should keep your backup files on a separate drive from your data files. (For more information on database devices and performance, see Chapter 38, “Database Design and Performance.”) As a general rule, you also should place the log files on separate disks from the data files, and placing tempdb on its own disk further helps improve performance

Download from www.wowebook.com

Installation Walkthrough

207

FIGURE 8.18 The Data Directories tab.

NOTE

8

If you are planning on installing multiple SQL Server instances on the same server, consider using separate subdirectories for each instance’s data and log files. This way, you avoid potential conflicts between data and log filenames for databases with the same names created in more than on SQL Server instance. As you notice, by default, the SQL Server Installer creates subdirectories under the specified root directory name using the SQL Server version number and instance name (for example, MSSQL10_50.MSSQLSERVER) and then an additional subdirectory for the services type (MSSQL for SQL Server, MSAS for Analysis Services, and MSRS for Reporting Services).

The final tab on the Database Engine Configuration tab is FILESTREAM (see Figure 8.19). The FILESTREAM data type is a column property available in SQL Server 2008. FILESTREAM storage is implemented as a varbinary(max) column, but the actual data is stored as BLOBs in the file system. Because of security considerations, FILESTREAM, by default, is disabled. If you want to use the FILESTREAM option, click the Enable FILESTREAM for Transact-SQL Access check box to enable FILESTREAM capabilities. This control must be checked before the other control options will be available. The Enable FILESTREAM for File I/O Streaming Access check box enables Win32 streaming access for FILESTREAM. If this option is selected, you can specify the name of the Windows share in which the FILESTREAM data

Download from www.wowebook.com

208

CHAPTER 8

Installing SQL Server 2008

will be stored. The Allow Remote Clients to Have Streaming Access to FILESTREAM Data check box determines whether to allow remote clients to access this FILESTREAM data on this server. For more information on defining and using FILESTREAM data in SQL Server 2008, see Chapters 24, “Creating and Managing Tables,” and 42, “What’s New for TransactSQL in SQL Server 2008.” If you are unsure whether you need or want to use FILESTREAM data, you can leave this option disabled during the install. You can enable FILESTREAM data at any time via the SQL Server Configuration Manager.

FIGURE 8.19 The FILESTREAM tab. Some of the remaining configuration screens depend on which features you selected in the Feature Selection page. For example, if you chose to install Analysis Services or Reporting Services, you have configuration pages to specify the installation options for these features. For more information on configuring Analysis Services and Reporting Services, see Chapters 51, “SQL Server 2008 Analysis Services,” and 53, “SQL Server 2008 Reporting Services.” As with the FILESTREAM option, you do not have to install Analysis Services or Reporting Services during the initial install. You can always run the SQL Server Installation Center later to add these features to an existing SQL Server instance. After you finish making your selections, click Next to move on to the Error Reporting page. On the Error Reporting page, you have the option to indicate whether you want to have error reports sent to Microsoft automatically for any of the SQL Server services that run without user interaction. This option, if enabled, helps Microsoft improve future releases of SQL Server features by sending error reports to Microsoft automatically. This

Download from www.wowebook.com

Installation Walkthrough

209

process is colloquially known as “phoning home,” and you may be inclined to keep this option unchecked. Note that doing so reduces Microsoft’s capability to gather important information that can helpful for identifying possible bugs and developing fixes in future service pack releases. Specify whether you want to participate and click Next to continue to the Installation Configuration Rules page, as shown in Figure 8.20.

FIGURE 8.20 The Installation Configuration Rules page.

8

NOTE In SQL Server 2008, the Error Reporting page was referred to as the Error and Usage Reporting page. In addition to the option to have error reports sent to Microsoft automatically, it also provided the option to participate in the Customer Experience Improvement program.

The Installation Configuration Rules page runs a final set of checks to determine if there are any issues that will prevent a successful installation of SQL Server 2008. If no errors are reported, click Next to continue to the Ready to Install page (see Figure 8.21). This page displays a summary of the installation options chosen as well as the file locations specified. Review this information to ensure the features and file locations match what you

Download from www.wowebook.com

210

CHAPTER 8

Installing SQL Server 2008

specified during the previous screens. This page also displays the location of the Configuration file path where you can find the ConfigurationFile.ini file generated by the installer. This .ini file can be used for unattended installations, which are discussed later in this chapter. The ConfigurationFile.ini file is located in the same place where you can find the installation log files, which you can review if any problems occur during the installation.

FIGURE 8.21 The Ready to Install Page. If everything looks satisfactory on the Ready to Install Page, click the Install button to proceed with the SQL Server installation. This displays the Installation Progress screen, which shows a progress bar and messages to allow you to track the progress of the installation. When the setup process is complete, the Installer displays the Complete page, which contains a hyperlink to the Installer log file and supplemental information about the installation. One of the notes that may be displayed in the Supplemental Information section of the Complete page refers to the installation of the SQL Server sample databases. If you’ve worked with previous versions of SQL Server, you may remember that there was an option to install the sample databases during the SQL Server installation. With SQL Server 2008, the sample databases are not part of the SQL Server Installation Center, nor are they available on the install media. To install the sample databases and sample code for non-Express editions of SQL Server 2008, you need to go to the Microsoft CodePlex website to download the installer for the sample databases. There is a link to the SQL Server samples on the CodePlex website on the Resources page of the SQL Server Installation Center.

Download from www.wowebook.com

Installation Walkthrough

211

FIGURE 8.22 The Complete page. The Supplemental Information section also provides a link to the latest readme file for the release of SQL Server installed and a note regarding how SQL Server updates are now available via Microsoft Update. Before leaving the Installation Center, you might want to click the Search for Product Update link on the Installation page to see whether there are any critical hotfixes or service packs already available for your SQL Server installation.

8

Other Options Available in the SQL Server Installation Center Before leaving the SQL Server Installation Center, let’s explore a few other utilities available from the main menu. The Maintenance menu provides tools to upgrade an installed SQL Server 2008 Edition (for example, from Standard Edition to Enterprise Edition), repair a corrupt installation, or remove a node from a SQL Server 2008 cluster. The Tools menu provides links to the System Configuration Checker, the Installed features discovery report that generates information regarding all SQL Server products and features installed on the local machine, and a utility to upgrade existing SQL Server 2005 Integration Services packages to the SQL Server 2008 Integration Services package format. Finally, on the Advanced menu, there are options to prepare and complete a SQL Server failover cluster and to install in instance of SQL Server 2008 from an existing configuration file. Installing using an existing configuration file allows you to repeat an installation without having to go through all the individual steps and enter/select all the options you normally have to go through with the installation wizard.

Download from www.wowebook.com

212

CHAPTER 8

Installing SQL Server 2008

Installing SQL Server Using a Configuration File If you need to install SQL Server 2008 to multiple machines, you’ll likely want to do so without having to manually select the same options over and over. Running the installer using a configuration file provides this much-needed timesaving feature. With the SQL Server 2008 installer, you have the option of running the installer with a configuration file in a couple of ways: using the Installer Wizard with options prefilled by the configuration file or using a fully automated and unattended installation from the command line. If you use the GUI with the options prefilled by the configuration file, you have the opportunity to review and change options along the way as necessary. The ConfigurationFile.ini file is a text file composed of parameters in name/value pairs along with descriptive comments. Many of the parameter names correspond to the screens and screen options you would see when using the Installer Wizard. Here are some examples: . INSTANCENAME—Specifies a named instance name for the value or specifies the special value MSSQLSERVER to install the default instance. . FEATURES—Specifies which features to install, uninstall, or upgrade. The list of toplevel features include SQL, AS, RS, IS, and Tools. The SQL feature installs the Database Engine, Replication, and Full-Text. The Tools feature installs Management Tools, Books Online, Business Intelligence Development Studio, and other shared components. . INSTALLSHAREDIR—Specifies the root installation directory for native shared components. . INSTANCEDIR—Specifies the installation directory for instance-specific components. . INSTALLSQLDATADIR—Specifies the Database Engine root data directory. . SQLBACKUPDIR—Specifies the default directory for the Database Engine backup files. . SQLUSERDBDIR—Specifies the default directory for the Database Engine user databases. . SQLUSERDBLOGDIR—Specifies the default directory for the Database Engine user database logs. . SQLTEMPDBDIR—Specifies the directory for Database Engine tempdb files. . SQLCOLLATION or ASCOLLATION—Specifies values to set the collation for SQL Server or Analysis Services. . SQLSVCACCOUNT—Specifies the user account for the SQL Server service: domain\user or system account. . TCPENABLED—Specifies whether the TCP/IP protocol is enabled (1) or disabled (0). . NPENABLED—Specifies whether the Named Pipes protocol is enabled (1) or disabled (0).

Download from www.wowebook.com

Installing SQL Server Using a Configuration File

213

. SECURITYMODE—Specifies authentication mode for SQL Server. You can use the special value “SQL” here to override the default of Windows-only authentication. The following example shows the contents of a configuration file for SQL Server 2008 R2: ;SQLSERVER2008 Configuration File [SQLSERVER2008] ; Specify the Instance ID for the SQL Server features you have specified. SQL Server directory structure, registry structure, and service names will reflect the instance ID of the SQL Server instance. INSTANCEID=”MSSQLSERVER” ; Specifies a Setup work flow, like INSTALL, UNINSTALL, or UPGRADE. This is a required parameter. ACTION=”Install” ; Specifies features to install, uninstall, or upgrade. The list of top-level features include SQL, AS, RS, IS, and Tools. The SQL feature will install the database engine, replication, and full-text. The Tools feature will install Management Tools, Books online, Business Intelligence Development Studio, and other shared components. FEATURES=SQLENGINE,REPLICATION,FULLTEXT,CONN,IS,BC,BOL,SSMS,ADV_SSMS ; Displays the command line parameters usage HELP=”False” ; Specifies that the detailed Setup log should be piped to the console. INDICATEPROGRESS=”False”

8

; Setup will not display any user interface. QUIET=”False” ; Setup will display progress only without any user interaction. QUIETSIMPLE=”False” ; Specifies that Setup should install into WOW64. This command line argument is not supported on an IA64 or a 32-bit system. X86=”False” ; Detailed help for command line argument ENU has not been defined yet. ENU=”True” ; Parameter that controls the user interface behavior. Valid values are Normal for the full UI, and AutoAdvance for a simplied UI. UIMODE=”Normal”

Download from www.wowebook.com

214

CHAPTER 8

Installing SQL Server 2008

; Specify if errors can be reported to Microsoft to improve future SQL Server releases. Specify 1 or True to enable and 0 or False to disable this feature. ERRORREPORTING=”True” ; Specify the root installation directory for native shared components. INSTALLSHAREDDIR=”C:\Program Files\Microsoft SQL Server” ; Specify the installation directory. INSTANCEDIR=”C:\SQL2008R2” ; Specify that SQL Server feature usage data can be collected and sent to Microsoft. Specify 1 or True to enable and 0 or False to disable this feature. SQMREPORTING=”True” ; Specify a default or named instance. MSSQLSERVER is the default instance for non-Express editions and SQLExpress for Express editions. This parameter is required when installing the SQL Server Database Engine (SQL), Analysis Services (AS), or Reporting Services (RS). INSTANCENAME=”MSSQLSERVER” ; Agent account name AGTSVCACCOUNT=”SQLADMIN” ; Auto-start service after installation. AGTSVCSTARTUPTYPE=”Automatic” ; Startup type for Integration Services. ISSVCSTARTUPTYPE=”Automatic” ; Account for Integration Services: Domain\User or system account. ISSVCACCOUNT=”SQLADMIN” ; Startup type for the SQL Server service. SQLSVCSTARTUPTYPE=”Automatic” ; Level to enable FILESTREAM feature at (0, 1, 2 or 3). FILESTREAMLEVEL=”1” ; Specifies a Windows collation or an SQL collation to use for the Database Engine. SQLCOLLATION=”SQL_Latin1_General_CP1_CI_AS” ; Account for SQL Server service: Domain\User or system account. SQLSVCACCOUNT=”SQLADMIN”

Download from www.wowebook.com

Installing SQL Server Using a Configuration File

215

; Windows account(s) to provision as SQL Server system administrators. SQLSYSADMINACCOUNTS=”SQLADMIN” ; The default is Windows Authentication. Use “SQL” for Mixed Mode Authentication. SECURITYMODE=”SQL” ; The Database Engine root data directory. INSTALLSQLDATADIR=”C:\SQL2008R2” ; Default directory for the Database Engine backup files. SQLBACKUPDIR=”C:\SQL2008R2\MSSQL10_50.MSSQLSERVER\MSSQL\Backup” ; Default directory for the Database Engine user databases. SQLUSERDBDIR=”C:\SQL2008R2\MSSQL10_50.MSSQLSERVER\MSSQL\Data” ; Default directory for the Database Engine user database logs. SQLUSERDBLOGDIR=”C:\SQL2008R2\MSSQL10_50.MSSQLSERVER\MSSQL\Data” ; Directory for Database Engine TempDB files. SQLTEMPDBDIR=”C:\SQL2008R2\MSSQL10_50.MSSQLSERVER\MSSQL\Data” ; Provision current user as a Database Engine system administrator for SQL Server 2008 R2 Express. ADDCURRENTUSERASSQLADMIN=”False” ; Specify 0 to disable or 1 to enable the TCP/IP protocol. TCPENABLED=”0” ; Specify 0 to disable or 1 to enable the Named Pipes protocol. NPENABLED=”0”

8

; Startup type for Browser Service. BROWSERSVCSTARTUPTYPE=”Disabled” ; Add description of input argument FTSVCACCOUNT FTSVCACCOUNT=”NT AUTHORITY\LOCAL SERVICE”

Depending on which options you chose during an install, other options may be listed in the Configuration.ini file, some of which are designed solely for clustered installs, Analysis Services, Reporting Services, Integration Services, or Tools. To create a configuration file (sorry, no configuration file template is available on the installation media), run the installation program and follow the wizard all the way through to the Ready to Install page where the location of the Configuration.ini file generated is specified (see Figure 8.21). If you do not want to continue with an actual

Download from www.wowebook.com

216

CHAPTER 8

Installing SQL Server 2008

installation at this point, simply click the Cancel button to cancel the setup. At this point, you can copy the Configuration.ini file to another location so you can make edits to it.

NOTE The Installer writes out all the appropriate parameters for the options and values specified, with the exception of sensitive information such as passwords. For an unattended install, these values can be provided at the command prompt when you run setup.exe. In addition, the new SQL Server 2008 R2 /IAcceptSQLServerLicenseTerms parameter is also not written out to the configuration file and requires either you modify the configuration file or supply a value at the command prompt.

The setup.exe command-line program can be found at the root level of the installation media. To use a configuration file to install a standalone SQL Server instance, run the installation through the command-line setup.exe program and supply the ConfigurationFile.ini using the ConfigurationFile parameter, as in the following example: Setup.exe /ConfigurationFile=CustomConfigurationFile.INI

If you want to override any of the values in the configuration file or provide values not specified in the configuration file, you can provide additional command-line parameters to setup.exe. For example, to avoid having to enter the service account passwords during the installation, you can enter them on the command line using the password parameters to config.exe: Setup.exe /SQLSVCPASSWORD=”mypassword” /AGTSVCPASSWORD=”mypassword” /ASSVCPASSWORD=”mypassword” /ISSVCPASSWORD=”mypassword” /RSSVCPASSWORD=”mypassword” /ConfigurationFile=CustomConfigurationFile.INI

NOTE The password parameters are required to run a fully unattended installation. Also, if the SECURITYMODE setting is set to SQL in the configuration file or via the commandline parameter, you need to provide the /SAPWD parameter to provide a password for the sa account.

Most of the other available setup.exe command-line parameters are the same as the parameter names used in the configuration file as listed previously. For full details of the available setup.exe parameters, refer to SQL Server Books Online.

Download from www.wowebook.com

Installing SQL Server Using a Configuration File

217

Running an Automated or Manual Install When installing SQL Server from the command prompt, you can also specify what level of the installer interface you want to run, either silent, basic, or full interaction. SQL Server supports full quiet mode by using the /Q parameter or Quiet Simple mode by using the /QS parameter. The /Q switch is intended for running unattended installations. With this switch provided, Setup runs in quiet mode without any user interface. The /QS switch only shows progress via the GUI; it does not accept any input and displays no error messages if encountered. Regardless of the installation method chosen, you are required to confirm acceptance of the software license terms as an individual or on behalf of an entity, unless your use of the software is governed by a separate agreement such as a Microsoft volume licensing agreement or a third-party agreement with an ISV or OEM. For full unattended installations (using the /Q or /QS parameters) with SQL Server 2008 R2, you must include the /IACCEPTSQLSERVERLICENSETERMS parameter to avoid the display of the License Terms page. Following is a sample command line for running an unattended installation of SQL Server 2008: C:\Documents and Settings\rrankins\My Documents\Downloads\SQL2008\R2 Nov CTP>setup.exe /configurationfile=customconfigurationfile.ini /Q /IACCEPTSQLSERVERLICENSETERMS /SQLSVCPASSWORD=”riddler” /AGTSVCPASSWORD=”riddler” /SAPWD=”riddler”

8

SQL Server 2008 R2 introduces a new option to the setup.exe that allows you to run a somewhat more attended mode of the installation that gives you a bit more control over the install than the /Q and /QS parameters, while streamlining the install somewhat. You can now specify the /UIMODE parameter instead of the /Q or /QS switches. The /UIMODE parameter specifies whether to present the full set of Installer Wizard pages for review and confirmation while running the setup or to present a minimum number of pages during setup. /UIMODE=Normal, the default option, presents all setup dialog boxes for the selected features, allowing you to review the values or manually enter values not provided in the configuration file (such as service account passwords). You can specify the /UIMODE=AutoAdvance option to skip nonessential dialogs and auto advances through a number of pages, including the Ready to Install page.

NOTE Although SQL Server 2008 Configuration.ini files are compatible with the SQL Server 2008 R2 setup.exe program, some of the options generated in a SQL Server 2008 R2 Configuration.ini file are not compatible with the pre-R2 installer, such as the ENU, UIMODE, FARMADMINPORT, and IACCEPTSQLSERVERLICENSETERMS parameters.

Download from www.wowebook.com

218

CHAPTER 8

Installing SQL Server 2008

Installing Service Packs and Cumulative Updates If you are installing SQL Server 2008 instead of SQL Server 2008 R2, it is recommended that you install SQL Server 2008 Service Pack 1. SQL Server 2008 SP1 doesn’t provide any significant new features for SQL Server 2008 but does provide a number of fixes to the GA release version of SQL Server 2008 (Microsoft Knowledge Base article 968369 lists all the fixes). Service Pack 1 does provide a few new features primarily to ease the deployment of service packs and cumulative updates. The first of these is Slipstream installations. Slipstreaming is an installation method that integrates the base installation files for SQL Server with its service packs and cumulative updates and enables you to install them in a single step. You can slipstream SQL Server 2008 SP1 and subsequent cumulative updates with the original installation media so that original media and the updates are installed at the same time. The next section in this chapter describes how to set up a Slipstream installation. SQL Server 2008 SP1 also provides the capability to uninstall SQL Server 2008 cumulative updates or service packs via the Programs and Features Control Panel (or the Add/Remove Programs Control Panel in Windows XP or Windows Server 2003). Before installing SP1, you should make sure to back up all user-created databases, as well as the system databases master, model, msdb, and any replicated databases. If you have installed Analysis Services, back up the entire OLAP directory (as discussed earlier in this chapter, in the “Installation Paths” section) and all its subdirectories. You also should make sure to close all open connections to the instance to which you are applying SP1 (including any connections via the management tools; setup should prompt you to close them) and make sure the various SQL Server services are started in the Services Control Panel. Also, be sure master and msdb each have 500KB free (or that they are autogrow enabled). When you’re ready, log on to the machine as an admin and start the downloaded SP1 executable. After extracting the contents to a temporary folder on the C: drive, the SP1 setup launches, displaying the Welcome screen shown in Figure 8.23. As you can see from this window, the SP1 Welcome screen runs the SP1 setup support rules to verify that the SP1 install can be run. Click Next to display the License Agreement screen. Click the check box to select the license agreement and then click Next again to advance to the Select Features screen to display and select the installed features to be updated (see Figure 8.24). The ensuing Feature Selection window lists (again) the features to be updated, organized in tree fashion, by SQL Server instance name. You can uncheck the features or instances you do not want to upgrade to SP1, except for shared features, which are required to be updated. Click Next to move onto the Check Files in Use screen (see Figure 8.25). This screen identifies any open or running files that the SP1 setup program needs access to during the install. If any files are listed, you have the option to shut down the services or applications associated with the files and run the check again to see whether the all items are cleared from the list. Note that it is not critical for the Files in Use list to be empty, but if

Download from www.wowebook.com

Installing Service Packs and Cumulative Updates

219

FIGURE 8.23 SQL Server 2008 SP1 Welcome screen.

8

FIGURE 8.24 SQL Server 2008 SP1 Feature Selection screen.

Download from www.wowebook.com

220

CHAPTER 8

Installing SQL Server 2008

any files are listed, you need to reboot the system after running the SP1 setup to complete the installation.

FIGURE 8.25 SQL Server 2008 SP1 Check Files in Use screen. Click Next again to proceed to the Ready to Update screen (see Figure 8.26), which displays a summary of the instances and features that will be updated to SP1. Click Update to start the installation and display the Update Progress screen. When the SP1 installation is complete, click Next to proceed to the Complete screen. The Complete screen displays the location of the SP1 summary log file (see Figure 8.27). The default location of the SP1 summary log file is C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\LOG.

Installing SP1 from the Command Line Like the SQL Server 2008 main install, SP1 can also be installed from the command line with no user interaction. This capability is useful if you need to install SP1 to a number of servers and want to avoid having to go through all the SP1 Install Wizard screens each time. To run SP1 from the command line, you must first extract the setup files from the SP1 download file, which is an executable archive file. You can do this by running the SQLServer2008SP1-KB968369-x64-ENU.exe file with the /x option from the command line. This launches the extractor, which prompts you for a location to extract the files to. Alternatively, you can specify a directory on a local drive to have it extract the setup files to automatically: SQLServer2008SP1-KB968369-x64-ENU.exe /x:C:\SP1

Download from www.wowebook.com

Installing Service Packs and Cumulative Updates

221

FIGURE 8.26 SQL Server 2008 SP1 Ready to Update screen.

8

FIGURE 8.27 SQL Server 2008 SP1 Installation Complete screen.

Download from www.wowebook.com

222

CHAPTER 8

Installing SQL Server 2008

After extracting the SP1 setup files to a folder, you can run the setup.exe program from the command line. The SP1 setup program supports options similar to the SQL Server 2008 installer command-line options (although significantly fewer options are available): . /HELP—Displays these command-line parameters. . /ALLINSTANCES—Specifies that all instances are to be included in the setup operation. . /CLUSTERPASSIVE—Specifies that the setup utility should not automatically start and stop the SQL Server services if running in a non-Microsoft cluster environment. . /INDICATEPROGRESS—Specifies that the detailed Setup log messages should be displayed to the console. . /INSTANCENAME—Specifies the default or named instance to be updated . /QUIET—Runs the install in full unattended mode. Setup does not display any user interface. . /QUIETSIMPLE—Runs the install in Quiet Simple mode. Setup displays the wizard screens but without any user interaction. . /X86—Specifies that Setup should install a 32-bit edition into WOW64 on an x64based system. For example, to install SP1 with no user interaction for all instances on a server, you would run the following command: setup.exe /quiet /allinstances

Slipstream Installations With the release of SQL Server 2008 SP1, Microsoft provides the capability to create Slipstream installations of SQL Server 2008. Slipstreaming is a method of integrating a SQL Server 2008 update with the original installation media so that the original media and update are installed at the same time. This capability can be a huge timesaver over having to manually run a service pack and possible cumulative update installations after running a full SQL Server install, especially if you have to repeat the installation in multiple environments. Slipstreaming is supported in the following scenarios: . Installing the original media and a service pack . Installing the original media, a service pack, and a cumulative update to the service pack

Download from www.wowebook.com

Slipstream Installations

223

NOTE Slipstreaming a cumulative update for SQL Server 2008 with the original media but without a service pack is not supported because slipstreaming wasn’t supported until SQL Server 2008 SP1 was released. Also, a Slipstream installation cannot be performed to update a SQL Server 2008 instance to SQL Server 2008 R2.

If you are doing a single install of SQL Server 2008 and at the same time want to apply SP1 and possibly a cumulative update as well, you can run the Slipstream installation by performing the following steps: 1. If they are not installed already on the target machine, install the required prerequisites for the SQL Server 2008 Installer (.NET Framework 3.5 SP1 and Windows Installer 4.5). You can install them manually from the SQL Server install disk (the installers are located in the Drive_Letter:\platform\redist\Windows Installer folder). Alternatively, after you extract the service pack files, run the sqlsupport.msi file from within the folder where the service pack files have been extracted. For example, if you extracted the Service pack to the C:\sql2k8xp1 folder on an X86 platform, this file would be found in the C:\SQL2K8SP1\x86\setup\1033 folder.

NOTE To confirm whether the setup support files are installed, search for the Microsoft SQL Server 2008 Setup Support Files entry in the Programs and Features Control Panel (or the Add or Remove Programs Control Panel in operating systems prior to Windows Vista or Windows Server 2008).

NOTE

8

On the IA-64 platform, the .NET Framework 3.5 is not supported. The .NET Framework 2.0 SP2 is required instead. The .NET Framework 2.0 SP2 is located in the Drive_Letter:\ia64\redist\2.0\NetFx20SP2_ia64.exe folder on the source media.

2. If not done already, download the Service Pack (PCU) package that matches your system architecture and, if desired, the cumulative update (CU) package you want to install. 3. For each package you want to include in the Slipstream installation, extract the contents to a folder on the local drive by running a command similar to the following at the command prompt from within the folder where you downloaded the package(s): Name_of_the_PCU_or_CU_package.exe /x:Root_of_path_to_extract_to\

Download from www.wowebook.com

224

CHAPTER 8

Installing SQL Server 2008

4. Now things get a bit tricky. Because Slipstream support is introduced with SP1, the setup.exe program that shipped with the original SQL Server 2008 installation media doesn’t support the /PCUSource or /CUSource options that allow you to specify the locations of the service pack and cumulative updates to be slipstreamed. Instead, you need to run the SQL Server 2008 Setup program for Service Pack 1 and specify the action as INSTALL, and the file paths for the original media, as well as service pack and cumulative update files. These are specified using the /ACTION, /MEDIASource, /PCUSource, and /CUSource parameters. The following example shows how to run a slipstream install of SQL Server 2008 from the install CD in the D: drive with SP1 extracted to the C:\SQLServer2008SP1 folder: C:\SQLServer2008SP1>setup.exe /PCUSource=C:\SQLServer2008SP1 /ACTION=INSTALL /MEDIASOURCE=D:\

This command runs the SQL Server installation in the normal GUI mode, requiring you to specify and confirm all settings. If you want, you can also choose to run the install in a limited interface or automated mode, as described previously in this chapter in the section describing how to use a configuration file. However, the first time you run a Slipstream installation, you should at least use an interface that allows you to view the Ready to Install page before running the installation so that you can verify whether the desired Slipstream installation is being performed. If the setup utility is running a Slipstream installation, it is indicated in the Action field, as shown in Figure 8.28.

FIGURE 8.28 Verifying a Slipstream installation on the Ready to Install page.

Download from www.wowebook.com

Summary

225

Summary This chapter provides a fairly detailed overview of the SQL Server 2008 install process from start to finish. The chapter shows how the new Installer Wizard makes it easy to install as many instances as you like, with whatever feature sets and in whatever configuration you choose. The chapter also shows how the installer reports progress, failure, and success on an individual task basis rather than with one seemingly endless progress bar, making it a lot easier to rectify problems without calling Microsoft or scouring the newsgroups to figure out what went wrong. Chapter 9, “Upgrading to SQL Server 2008,” takes a similar approach to examining the process of upgrading from SQL Server 2000 or SQL Server 2005 to SQL Server 2008 or SQL Server 2008 R2.

8 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

9

Upgrading to SQL Server 2008

IN THIS CHAPTER . What’s New in Upgrading SQL Server . Using the SQL Server Upgrade Advisor (UA) . Destination: SQL Server 2008 or SQL Server 2008 R2

SQL Server 2008 offers a number of new features and improvements that make upgrading desirable. You can upgrade instances of SQL Server 2000 and SQL Server 2005 to SQL Server 2008 or SQL Server 2008 R2, as well as upgrade SQL Server 2008 to SQL Server 2008 R2. Whether you’re a gung-ho developer or the most conservative of administrators, there’s an upgrade path to suit your comfort level. This chapter provides best practices and recommendations for upgrading to SQL Server 2008 with minimal issues.

. Upgrading Using a Configuration File . Slipstreaming Upgrades74 . Upgrading Other SQL Server Components

What’s New in Upgrading SQL Server SQL Server 2008 provides a new installer program for performing installations and upgrades. The new features of the SQL Server 2008 Installer include . A new SQL Server 2008 Installation Center landing page, which includes a number of options for planning, installing, and maintaining a SQL Server implementation; links to SQL Server documentation for planning and reviewing before starting the upgrade; and a link to install the Upgrade Advisor. . The Feature Upgrade Wizard, which allows DBAs to upgrade or change the installed edition of SQL Server 2008 or SQL Server 2008 R2 (for example, upgrading from Standard Edition to Enterprise Edition without having to perform a complete reinstall).

Download from www.wowebook.com

228

CHAPTER 9

Upgrading to SQL Server 2008

. A discovery report that provides a detailed information regarding all SQL Server components, features, and settings associated with an install or upgrade. . The potential to automate SQL Server upgrades by using a configuration file. . A tool that allows for a smooth transition of SQL Server Integration Services (SSIS) packages by automatically upgrading them from SQL Server 2005 to the SQL Server 2008 Integration Services format. Also new in SQL Server 2008 is a refined Upgrade Advisor. The Upgrade Advisor tool allows a DBA to fully analyze existing SQL Server 2005 and SQL Server 2000 installations for issues that may surface when upgrading to SQL Server 2008 or SQL Server 2008 R2. Addressing these issues before conducting the upgrade should lead to a smoother experience when transitioning to SQL Server 2008. With the release of Service Pack 1, SQL Server 2008 also now supports Slipstream installations. Slipstreaming is a method of integrating a SQL Server 2008 update (such as a service pack or cumulative update) with the original installation media so that the original media and update are installed at the same time. This can be a huge timesaver over having to manually apply service packs or cumulative updates after performing a full installation or upgrade.

NOTE The focus of this chapter is on upgrade options and best practices rather than a screen-by-screen walkthrough of the upgrade process. An upgrade installation is not much different from a new installation. See Chapter 8, “Installing SQL Server 2008,” for a detailed walkthrough and description of the installer screens and options.

Using the SQL Server Upgrade Advisor (UA) It would be a daunting task indeed to try to test every stored procedure and function, every table and view, every online analytical processing (OLAP) cube, every Data Transformation Services (DTS) or SQL Server Integration Services (SSIS) package, and so on that your team has built to make sure they still work after you migrate them to SQL Server 2008. With the availability of the SQL Server Upgrade Advisor (UA), you can relax a bit and let the combined experience and testing of early adopters and the SQL Server development team go to work for you.

NOTE Even though the UA is a great tool, if you have the resources to do so, it is a good idea to set up an additional test environment just for SQL Server 2008. Also, you should thoroughly test your upgraded objects and code after the upgrade on a dry run, just to be sure you don’t miss anything. Remember to make full backups!

Download from www.wowebook.com

Using the SQL Server Upgrade Advisor

229

The UA advises on which aspects of your current setup should or need to be changed to become compatible with SQL Server 2008. Let’s look at how it works.

Getting Started with the UA Before running the Upgrade Advisor, you must first install it. The easiest way to install the Upgrade Advisor is to start the SQL Server 2008 Installer. On the Installer Landing page is an option to install the Upgrade Advisor (see Figure 9.1). Alternatively, the Upgrade Advisor is available in the Servers\redist\Upgrade Advisor folder of the SQL Server installation media, or from the Microsoft Download Center. The Upgrade Advisor has the following system requirements: . Windows XP Service Pack 2 (SP2) or later, Windows Vista, Windows Server 2003 SP2 or later, or Windows Server 2008 SP2, Windows 7, and Windows Server 2008 R2. . Windows Installer beginning with version 4.5 (required by the .NET Framework; you can install Windows Installer from the Windows Installer website) . The .NET Framework

9

FIGURE 9.1 Installing the Upgrade Advisor from the SQL Server 2008 Installer.

NOTE If not installed already, the .NET Framework 2.0 is available on the SQL Server 2008 product media, and from the SDK, redistributable, and service pack download website. To install the .NET Framework 2.0 from the SQL Server 2008 media, locate the root of the disk drive. Then double-click the \redist folder, double-click the \2.0 folder, and run Dotnetfx.exe (for 32-bit) or Dotnetfx64.exe (for 64-bit), depending on your operating system.

Download from www.wowebook.com

230

CHAPTER 9

Upgrading to SQL Server 2008

If you run the SQL Server Installer, it installs the Windows Installer and .NET Framework requirements automatically if they are not detected. If upgrading from SQL Server 2000 Analysis Services, you need to install the SQL Server 2000 Decision Support Objects (DSOs) on the system where UA will be run to scan upgrade issues in Analysis Services. To install DSOs, run the SQL Server 2000 Setup program and click Install SQL Server 2000 Components. Click Analysis Services to start the Analysis Services Setup program. In Select Components, make sure that the Decision Support Objects component is selected. Additionally, if you are upgrading SQL Server 2000 DTS packages, the SQL Server 2000 client components are required to scan SQL Server 2000 DTS packages. The SQL Server 2000 client components can be installed from the SQL Server 2000 installation disk. If you are upgrading from SQL Server 2005 DTS packages that were migrated from SQL Server 2000, you need to install the SQL Server 2005 backward-compatibility components to scan SQL Server 2005 DTS. Use the SQL Server 2005 installation disk to install backward-compatibility components.

NOTE The location where you can install SQL Server Upgrade Advisor depends on what you will be analyzing. Upgrade Advisor supports remote analysis of all supported components except Reporting Services. If you are not scanning instances of Reporting Services, you can install Upgrade Advisor on any computer that can connect to your instance of SQL Server and that meets the Upgrade Advisor prerequisites. If you are scanning instances of Reporting Services, you must install Upgrade Advisor on the Report Server. As described in the following sections, the UA has two main functional areas: the Analysis Wizard and Report Viewer. The first time you use Upgrade Advisor, run the Upgrade Advisor Analysis Wizard to analyze SQL Server components. When the wizard finishes the analysis, you can view the resulting reports in the Upgrade Advisor Report Viewer.

The Analysis Wizard You’ll be glad to know that the analysis process does not modify any code or data; that is left for you to do (or not do) at a later time. As an example, let’s run the UA’s Analysis Wizard against all the SQL Server components of a locally installed SQL Server 2005 instance. The Analysis Wizard examines objects that can be accessed, such as scripts, stored procedures, triggers, and trace files. Upgrade Advisor cannot analyze desktop applications or encrypted stored procedures. To start the process, click the Launch Upgrade Advisor Analysis Wizard hyperlink at the bottom of the Welcome page (see Figure 9.2). When the Analysis Wizard’s Welcome page appears, click Next. When you reach the SQL Server Components screen, choose all the components to be analyzed by checking their corresponding check boxes (see Figure 9.3).

Download from www.wowebook.com

Using the SQL Server Upgrade Advisor

231

FIGURE 9.2 The Upgrade Advisor Welcome page.

9

FIGURE 9.3 Choosing the components to be analyzed by the UA’s Analysis Wizard.

Download from www.wowebook.com

232

CHAPTER 9

Upgrading to SQL Server 2008

NOTE Be sure to select only components that are actually installed on the server being upgraded; otherwise, the Upgrade Advisor stalls at the appropriate feature screen with an error message that the feature could not be found on the specified server.

When the Connection Parameters screen appears, choose the target server, select an authentication method, and if using SQL Server authentication, enter your username and password so that the UA can connect to your instance. Click Next, and the SQL Server Parameters screen, shown in Figure 9.4, appears. Choose which (if any) databases to analyze.

FIGURE 9.4 Choosing the databases and files for the UA to analyze. You can also use this screen to ask the UA to analyze one or more SQL Profiler trace (.trc) files. This feature is useful for analyzing the T-SQL statements submitted from one or more applications for deprecated or discontinued features. You would want to set up and run a trace in SQL Profiler ahead of time to capture a representative sample of the T-SQL executed against the server. You can also scan T-SQL batch files (maintenance scripts, procedures, functions, triggers, and so on) to check for deprecated or discontinued features used in the SQL scripts. For this example, create a SQL batch file that contains the following T-SQL commands, most of which are deprecated in SQL Server 2008, just to test the UA: use bigpubs2008 go EXEC sp_configure ‘set working set size’

Download from www.wowebook.com

Using the SQL Server Upgrade Advisor

233

SELECT * FROM master..syslockinfo DECLARE @ptr varbinary(16) SELECT @ptr = TEXTPTR(pr_info) FROM pub_info WHERE pub_id = ‘6380’ SELECT * FROM Stores s, Stores s2 WHERE s.Stor_Id *= s2.Stor_Id AND s.Stor_name s2.Stor_name READTEXT pub_info.pr_info @ptr 0 25

When you’re ready, click Next, and the Upgrade Advisor presents screens for each of the SQL Server components you selected previously (refer to Figure 9.3) asking for login information or to select packages to analyze. Note that if you selected a component, but that component isn’t installed on the server you are upgrading, the Upgrade Advisor reports that no instances of that component could be found on the server and you cannot proceed until you go back and deselect the component. If you selected to analyze DTS or SSIS packages, the DTS and SSIS Parameters screens (shown in Figure 9.5) give you the option to analyze all the packages stored in the target instance or to specify one or more package files to be analyzed.

9

FIGURE 9.5 Choosing the DTS and SSIS packages to analyze.

Download from www.wowebook.com

234

CHAPTER 9

Upgrading to SQL Server 2008

Note that the DTS Parameters screen advises that you must install the Legacy Components feature when installing SQL Server 2008; otherwise, SQL Server 2008 will not be able to run your DTS packages (unless they are upgraded to the new SSIS format). To upgrade your DTS packages, you need to use the DTS Migration Wizard, which is installed with SSIS and discussed later in this chapter, in the section “Migrating DTS Packages.” When you’re all set with your DTS and SSIS selections, click Next to reach the Confirm Upgrade Advisor Settings screen. Make sure that all the SQL Server services you are analyzing are running and (if you’re happy with your selections) click the Run button to begin the analysis. As you can see from the Upgrade Advisor Progress screen that appears (see Figure 9.6), the wizard performs a task-based study of each component, providing per-step reporting, similar to the installer and the System Configuration Checker (both discussed in Chapter 8).

FIGURE 9.6 The Upgrade Advisor Progress screen.

When the analysis is complete, the UA Progress screen presents a Launch Report button. The output of the UA Analysis Wizard is an XML report that you can view via the second major component of the UA, the Report Viewer, described in the next section.

NOTE You can view your last-generated report by using the Report Viewer; you can find the link to launch it on the main screen. If you run the UA more than once against the same SQL Server instance, however, you must save your previously generated reports to a directory other than the default output directory; otherwise, the previously generated report will be overwritten.

Download from www.wowebook.com

Using the SQL Server Upgrade Advisor

235

UA reports are saved by default to the folder My Documents\SQL Server 2008 R2 Upgrade Advisor Reports\Servername, and then they are broken down into separate XML files by component (for example, AS.xml for Analysis Services, DE.xml for the Database Engine).

You can launch the Report Viewer to figure out what to do about the issues the UA may have uncovered. Click the Launch Report button to proceed.

The Report Viewer The Report Viewer is one of the most important tools in the upgrade process because it provides per-issue messaging, resolution tracking, and (in many cases) hyperlinks to the compiled help documentation distributed with the UA. Issues are organized in the Report Viewer on a per-server and then per-component basis. They can be filtered by type (that is, all issues, all upgrade issues, pre-upgrade issues, all migration issues, and resolved issues), and you can track your resolution progress by checking the This Issue Has Been Resolved check boxes. Figure 9.7 shows the main user interface of the Report Viewer.

9

FIGURE 9.7 SQL Server UA’s Report Viewer.

Download from www.wowebook.com

236

CHAPTER 9

Upgrading to SQL Server 2008

Destination: SQL Server 2008 or SQL Server 2008 R2 Now that you have become familiar with how to use the helpful Upgrade Advisor, you’re ready to begin your extensive pre-upgrade testing phase. After you resolve all the issues you can, it’s time to take the next step: install SQL Server 2008 (in your test and development environments first, of course). Two different paths lead from SQL Server 2000 or 2005 to SQL Server 2008: . You can upgrade your existing SQL Server 2000 SP4 or later and SQL Server 2005 SP2 or later instances in-place, using the SQL Server Installer. . You can install SQL Server 2008 side by side with your current SQL Server instances and then migrate your data and other content to SQL Server 2008. The same upgrade paths exist for upgrading from SQL Server 2008 to SQL Server 2008 R2. The path you choose depends primarily on two factors: your comfort level with the new platform and the scope of feature use in your current environment. When you have become familiar with what it takes to travel either path, you’ll find it much easier to make your decision. The first approach we explore in this chapter is the more conservative sideby-side migration path.

NOTE If the server environment where your current SQL Server installation resides is not a supported platform for performing an in-place upgrade, a side-by-side migration may be your only option. For example, if you are upgrading from SQL Server 7 or running in a Windows 2000 server environment, an in-place upgrade is not supported. For a list of supported in-place upgrade paths, see the “Upgrading In-Place” section, later in this chapter.

Side-by-Side Migration SQL Server 2008 can coexist without a problem on the same servers as any existing SQL Server 2000 or 2005 instances. SQL Server 2008 R2 can coexist on the same servers as any existing SQL Server 2000, 2005, or 2008 instances. This means you can install one or more instances of SQL Server 2008 or 2008 R2 without performing an in-place upgrade of any pre-2008 instances. You don’t have to worry about whether you’re breaking existing functionality. Side-by-side migration is therefore an easy option to investigate.

NOTE If you are doing a side-by-side installation, be sure your server has sufficient resources (CPU, memory, disk space) to support running multiple instances of SQL Server.

Many administrators favor the side-by-side approach to upgrading because it gives everyone on the development team (including eager software folks) a chance to get comfortable

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

237

with the new features in the new SQL Server release before committing to it in production environments. In addition, it is far easier to roll back to your previous-version SQL Server components because installing side by side leaves them intact (unlike upgrading in-place, which replaces them). When you are reasonably comfortable with the new SQL Server release, you can go forward confidently in migrating all your objects (presuming that, if you’re leaving previous versions intact, you’re also ready to perform necessary tasks, such as changing connection strings, server aliases, and so on). Avoiding an Unintentional In-Place Upgrade During Setup If you do intend to go ahead with a side-by-side installation, there’s a small gotcha you need to watch out for when installing a new instance of SQL Server 2008. When you run the Setup program, the Instance Name screen is somewhat lengthy in its header’s verbiage, and if you don’t take the time to read it closely, you might unintentionally upgrade all your components. This is the lowdown: . If you choose the Default Instance radio button and you already have a SQL Server default instance, that default instance is upgraded. . If you the choose the Named Instance radio button, you need to make sure to enter a name that you know is not in use as an instance name; otherwise, the existing named instance is upgraded. Figure 9.8 shows an example of how to make the right choice and use an instance name, SQL2008R2, that makes it abundantly clear you are installing a new instance.

9

FIGURE 9.8 Installing a new named SQL Server 2008 R2 instance.

Download from www.wowebook.com

238

CHAPTER 9

Upgrading to SQL Server 2008

Migrating Databases Now it’s time for the most important task: migrating your databases to SQL Server 2008. One method of migrating to SQL Server 2008 or 2008 R2 is by backing up your SQL Server 2000 and 2005 databases and restoring them to SQL Server 2008. Another method is to attach or restore a database from a prior version of SQL Server to SQL Server 2008. When you migrate using either of these methods, the database is upgraded automatically during the attach/restore process.

NOTE Database backups created by using SQL Server 7.0 or earlier are in an incompatible format and cannot be restored in SQL Server 2008 or 2008 R2. For information on how to migrate a database from SQL Server 6.5 or 7.0 to SQL Server 2008, see the section “Upgrading from SQL Server 7 or SQL Server 6.5,” later in this chapter.

When you use backup and restore to copy a database to another instance of SQL Server, the source and destination computers can be any platform on which SQL Server runs. The general steps to upgrade using backup and restore are as follows: 1. Back up the source database that resides on an instance of SQL Server 2000, SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2. 2. Restore the backup of the source database on the destination SQL Server. Restoring the database automatically creates all the database files and upgrades the database. When restoring the database, you might need to use the MOVE option to relocate the database files because SQL Server 2008 and SQL Server 2008 R2 use a different default path than earlier versions. For more information on using backup and restore, see Chapter 14, “Database Backup and Restore.” In SQL Server 2008 R2, you can also use the detach and attach operations to migrate a user database from SQL Server 2000 or SQL Server 2005. After you attach a SQL Server 2005 or SQL Server 2000 or SQL Server 2008 database to SQL Server 2008 R2, the database is upgraded automatically and becomes available immediately. For more information on the syntax and options for detaching and attaching databases, see Chapter 23, “Creating and Managing Databases.” Another method of migrating an existing database is by using the SQL Server Copy Database Wizard to copy databases between multiple instances of SQL Server.

TIP Before you use any of the methods described here, Microsoft recommends you run the appropriate DBCC consistency checks to make sure there is no data corruption within the databases to be migrated. Using the Copy Database Wizard Using the Copy Database Wizard is probably the easiest approach to use to migrate your databases to SQL Server 2008 or 2008 R2. To run the

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

239

Copy Database Wizard, using SQL Server Management Studio (SSMS), connect the Object Explorer to your previous SQL Server version’s instance. Expand Databases and then select and right-click the database you want to copy (or move) into SQL Server 2008. Then select Tasks, Copy Database. When the wizard’s initial Welcome page is displayed, click Next and then select your source server (the 2000 or 2005 instance). Click Next again and select your destination server (your newly installed SQL Server 2008 or SQL Server 2008 R2 instance). Click Next again to bring up the Select the Transfer Method screen. This screen provides two options for copying or moving your databases to SQL Server 2008: . Detach and Attach—This option is the same as the detach/attach method described previously. It’s fast, but it takes the database offline during the migration process. . Use the SQL Server Management Objects (SMO) to Import the Database—This option is slower, but it keeps the source database online during the process.

NOTE When you use the detach and attach method, SSIS uses the service account of SQL Server Agent that is running on the 2008 (destination) instance. This account must be able to access the file systems of both servers; otherwise, the wizard will fail.

Select the option that works best for you and then click Next. The Select Databases screen appears, and, as Figure 9.9 shows, you should check the Copy (not Move) check boxes for the databases you want to migrate.

9

FIGURE 9.9 Selecting the databases to copy to SQL Server 2009.

Download from www.wowebook.com

240

CHAPTER 9

Upgrading to SQL Server 2008

CAUTION After a pre-2008 database is upgraded (in case you choose the Move Database option or you perform an attach or restore and delete the original), it cannot be downgraded back to its former version—not even if you attempt to detach/attach or restore it to SQL 2000 or 2005. Thus, it is especially important to create full backup copies of all your databases before you upgrade. It’s also a good idea to back up the entire Program Files/Microsoft SQL Server directory tree.

After you make your database selections, click Next, and the Configure Destination Database screen appears for each database you selected in the previous step. This screen allows you to rename the database on the destination server if you so desire (see Figure 9.10). It also provides options to overwrite any existing databases or MDF (data) and LDF (log) files on the destination server or to create new ones in the folders of your choice. Make your selections and click Next.

FIGURE 9.10 Copy Database Wizard Configure Destination Database screen. The Select Database Objects screen that appears next (see Figure 9.11) provides some real power because it allows the server-wide objects (those stored in the system databases and source database) to be imported. These objects include stored procedures residing in master, SQL Server Agent jobs, custom user-defined error messages, SSIS packages, and SQL Server logins. You need to click the ellipsis button to choose the specific ones you want to import (rather than choosing them all, which is the default). When you’re finished selecting the objects you want brought over, click Next again. The Configure the Package screen that appears next provides the opportunity to name and save the SSIS package created for migrating the database, and to specify how you want to log the messages generated during the transfer. Click Next to present the Schedule the

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

241

FIGURE 9.11 Importing server-wide objects, using the Copy Database Wizard. Package screen, which allows you to run the transfer immediately or schedule it to run at a specific time. You are also given an opportunity to specify an SSIS proxy account to use to run the transfer (you should make sure it’s an account that has appropriate permissions on both the source and destination servers to ensure a successful transfer). After you make your scheduling choices, click Next to display the Complete the Wizard screen (see Figure 9.12). Here, you have an opportunity to review the choices you’ve made on the prior screens. If everything looks okay, click Finish to complete the wizard and start or schedule the Copy Database package.

9

FIGURE 9.12 The Copy Database Complete the Wizard screen.

Download from www.wowebook.com

242

CHAPTER 9

Upgrading to SQL Server 2008

Database Compatibility Level Migrating pre-2008 databases into SQL Server 2008 brings up the question of compatibility issues and database compatibility levels. The compatibility level is a per-database setting that controls T-SQL execution behavior with regard to SQL Server’s versioning system. The T-SQL execution engine is flexible insofar as it has the capacity to switch between varying, version-dependent behaviors according to the current compatibility-level setting. When a database is upgraded to SQL Server 2008 from any earlier version of SQL Server, the database retains its existing compatibility level if it is at least 80 (SQL Server 2000). Upgrading a database with a compatibility level below 80 sets the database to compatibility level 80. Compatibility level affects behaviors only for the specified database, not for the entire server. An important point to understand about database compatibility levels, however, is that the database compatibility-level setting is intended to provide only partial backward compatibility with earlier versions of SQL Server. It does not prevent the use of new T-SQL features available in SQL Server 2008 such as new data types and statements. The compatibility-level setting is provided primarily as an interim migration aid to work around version differences in the behaviors that are controlled by the relevant compatibility-level setting. Essentially, it allows T-SQL code that may be using deprecated features or expects pre-100 level behaviors for certain commands to continue operating as it did in the prior version of SQL Server. Using the compatibility-level setting should not be viewed as a permanent solution. It should be used only until the T-SQL code affected by behavioral differences in SQL Server 2008 can be converted to work properly in SQL Server 2008. Then you can use ALTER DATABASE to change the compatibility level to 100. You can find a full list of the behavioral differences between the compatibility-level settings in the Books Online article associated with the “ALTER DATABASE Compatibility Level” topic. This option can be used to set the compatibility level for a particular database. To view the current compatibility level of a database, query the compatibility_level column in the sys.databases catalog view: select compatibility_level from sys.databases where name = db_name() go compatibility_level ------------------90

Upgrading In-Place Now that you’ve seen how to migrate your databases to SQL Server 2008 by following the side-by-side migration path, let’s look at the alternative: upgrading in-place. Unlike a sideby-side install, an in-place upgrade permanently modifies the SQL Server components, data, and metadata objects, and there is no going back. You will likely be more comfortable taking the side-by-side migration path than doing an in-place upgrade, unless a side-

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

243

by-side migration is not possible because of disk space limitations, you have very few SQL Server features in use, or you are fairly confident about the potential success of the upgrade process because you’ve done extensive issue resolution with the assistance of the Upgrade Assistant. If you are performing an in-place upgrade of the Database Engine, it is strongly recommended that you first do the following: . Create full, verified backups of your existing SQL Server databases. . Run the appropriate DBCC consistency checks (for example, DBCC CHECKDB and DBCC CHECKFILEGROUP). . Make sure the system databases on your pre-2008 instances (for example, master, msdb, tempdb, and model) are all set to auto-grow. . Disable any startup stored procedures that get kicked off when the SQL Server service starts. . Disable database replication and empty the replication log. After you perform all these actions, you are ready to begin the upgrade process.

Upgrading the Database Engine You perform an in-place upgrade by running the SQL Server Installation Center. On the Installation page, you can invoke the Upgrade Wizard to upgrade from SQL Server 2000, 2005, or 2008 (see Figure 9.13). After first running the Setup Rules check and installing the Setup Support Files, the Upgrade Wizard essentially runs the installation process. (The installation process and all its screens are described in Chapter 8 under the heading, “Install Screens, Step by Step.”) The key differences between running a new install versus an upgrade is that during the upgrade process, you choose an existing default or named instance on the Select Instance screen (see Figure 9.14). After selecting the instance to upgrade, you see the Feature Selection page. The features to be upgraded are preselected. You cannot change the features to be upgraded, and you cannot add features during an upgrade operation. To add features, you need to run the Installation Center again after the upgrade operation is complete.

9

After making choices on the Features Selection page, step through the Instance Configuration, Disk Space Requirements, and Server Configuration screens, making changes as necessary. For example, authentication and login information are carried forward from the previous instance of SQL Server. You can assign the same login account to all SQL Server services, or you can configure each service account individually. You can also specify whether services start automatically, are started manually, or are disabled. Next, you are presented with options for upgrading your full-text catalogs. In SQL Server 2005 and earlier versions, each full-text index resided in a full-text catalog that belonged to its own filegroup and was treated as a database file. In SQL Server 2008, a full-text catalog is a logical concept that refers to a group of full-text indexes and is no longer treated as a separate database file with a physical path. However, during upgrade of any

Download from www.wowebook.com

244

CHAPTER 9

Upgrading to SQL Server 2008

FIGURE 9.13 Running the Upgrade Wizard from the Installation Center.

FIGURE 9.14 The Select Instance screen in the SQL Server Installation Center.

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

245

full-text catalog, a new filegroup is still created on the same disk to maintain the preupgrade disk I/O behavior. If the old full-text catalog path is invalid, though, the upgrade places the full-text index in the same filegroup as the base table or in the primary filegroup if the table is partitioned. Three options are available for upgrading your existing full-text catalogs: . Import—Typically, import is the fastest method of upgrading, but an imported fulltext catalog does not use the new and enhanced word breakers introduced in SQL Server 2008, so you might want to rebuild your full-text catalogs eventually if not during the upgrade. . Rebuild—This method uses the new SQL Server 2008 word breakers, but rebuilding indexes can take awhile. . Reset—When you use this method, SQL Server 2005 full-text catalog files are removed, but the metadata for full-text catalogs and full-text indexes is retained. The catalog remains empty until you manually issue a full population after the upgrade completes. After choosing your full-text upgrade option, you next choose your Error Reporting options, and then the Upgrade Rules check is run to validate your system configuration with the options and features chosen during the upgrade process. If all the rules pass, you can review the upgrade operation on the Ready to Upgrade page, which also displays the path to the upgrade configuration file (this is useful for setting up and performing unattended upgrades from the command line, as discussed later in this chapter). If everything looks okay, click Upgrade to begin the upgrade process. The upgrade process automatically upgrades all objects that are common to all databases, including the following: . Tables, views, indexes, and constraints . Stored procedures, functions, and triggers . User-defined types, rules, and defaults . Logins, users, and permissions . Database diagrams

9

You can monitor the upgrade progress on the Upgrade Progress screen. Depending on your hardware configuration and the features to be upgraded, the upgrade operation can take from approximately 30 minutes to several hours. The databases on the instance being upgraded remain unavailable until the upgrade is complete. When the upgrade finishes, it displays the upgrade status of each component and also provides the location of the upgrade log. A system restart may be required in some cases if any upgraded components were in use during the upgrade process.

Download from www.wowebook.com

246

CHAPTER 9

Upgrading to SQL Server 2008

When your upgrade of the Database Engine is complete, it is recommended that you perform the following on all databases (also recommended for side-by-side migration): . Repopulate your full-text catalogs if you chose not to rebuild them during the upgrade. . Run the sp_updatestats system stored procedure to update statistics. . Reregister your server in SSMS. The SQL Server 2008 Upgrade Matrix No software upgrade section would be complete without an illustrative table showing the versions and editions of SQL Server for which the upgrade methods described thus far are supported. They are presented in Table 9.1.

TABLE 9.1 Supported Upgrade Paths to SQL Server 2008 and 2008 R2 Previous SQL Server Edition

Supported Upgraded Edition

SQL Server 2000 Enterprise Edition SP4

SQL Server 2008 Enterprise Edition SQL Server 2008 R2 Enterprise Edition SQL Server 2008 R2 Datacenter Edition

SQL Server 2000 IA64 Enterprise Edition SP4

SQL Server 2008 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Datacenter Edition

SQL Server 2000 Developer Edition SP4

SQL Server 2008 Developer Edition SQL Server 2008 R2 Developer Edition

SQL Server 2000 IA64 Developer Edition SP4

SQL Server 2008 IA64 Developer Edition SQL Server 2008 IA64 R2 Developer Edition

SQL Server 2000 Standard Edition SP4

SQL SQL SQL SQL

Server Server Server Server

2008 2008 2008 2008

Standard Edition Enterprise Edition R2 Standard Edition R2 Enterprise Edition

SQL Server 2000 Workgroup Edition SP4

SQL SQL SQL SQL SQL SQL

Server Server Server Server Server Server

2008 2008 2008 2008 2008 2008

Workgroup Edition Standard Edition Enterprise Edition R2 Workgroup Edition R2 Standard Edition R2 Enterprise Edition

SQL Server 2000 Personal Edition SP4

Not supported

SQL Server 2000 Evaluation Edition

Not supported

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

247

TABLE 9.1 Supported Upgrade Paths to SQL Server 2008 and 2008 R2 Previous SQL Server Edition

Supported Upgraded Edition SQL SQL SQL SQL SQL SQL SQL SQL

Server Server Server Server Server Server Server Server

SQL Server 2005 Enterprise Edition SP2

SQL Server 2008 Enterprise Edition SQL Server 2008 R2 Enterprise Edition SQL Server 2008 R2 Datacenter Edition

SQL Server 2005 IA64 Enterprise Edition SP2

SQL Server 2008 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Datacenter Edition

SQL Server 2005 X64 Enterprise Edition SP2

SQL Server 2008 X64 Enterprise Edition SQL Server 2008 R2 X64 Enterprise Edition SQL Server 2008 R2 X64 Datacenter Edition

SQL Server 2005 Developer Edition SP2

SQL Server 2008 Developer Edition SQL Server 2008 R2 Developer Edition

SQL Server 2005 IA64 Developer Edition SP2

SQL Server 2008 IA64 Developer Edition SQL Server 2008 IA64 R2 Developer Edition

SQL Server 2005 X64 Developer Edition SP2

SQL Server 2008 X64 Developer Edition SQL Server 2008 X64 R2 Developer Edition

SQL Server 2005 Standard Edition SP2

SQL SQL SQL SQL

SQL Server 2005 IA64 Standard Edition SP2

SQL Server 2008 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Enterprise Edition

SQL Server 2005 X64 Standard Edition SP2

SQL SQL SQL SQL

Server Server Server Server

Server Server Server Server

2008 2008 2008 2008 2008 2008 2008 2008

2008 2008 2008 2008

2008 2008 2008 2008

Express Express with Tools Express with Advanced Services Workgroup R2 Express R2 Express with Tools R2 Express with Advanced Services R2 Workgroup

Standard Edition Enterprise Edition R2 Standard Edition R2 Enterprise Edition

9

SQL Server 2000 MSDE 2000 SP4

X64 Standard Edition R2 X64Standard Edition X64 Enterprise Edition R2 X64 Enterprise Edition

Download from www.wowebook.com

248

CHAPTER 9

Upgrading to SQL Server 2008

TABLE 9.1 Supported Upgrade Paths to SQL Server 2008 and 2008 R2 Previous SQL Server Edition

Supported Upgraded Edition

SQL Server 2005 Workgroup Edition SP2

SQL SQL SQL SQL SQL SQL

Server Server Server Server Server Server

2008 2008 2008 2008 2008 2008

Workgroup Edition Standard Edition Enterprise Edition R2 Workgroup Edition R2 Standard Edition R2 Enterprise Edition

SQL Server 2005 Personal Edition SP2

Not supported

SQL Server 2005 Evaluation Edition

Not supported

SQL Server 2005 Express SP2

SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL

Server Server Server Server Server Server Server Server Server Server Server Server

2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008

Express Express with Tools Express with Advanced Services Workgroup Standard Edition Enterprise Edition R2 Express R2 Express with Tools R2 Express with Advanced Services R2 Workgroup R2 Standard Edition R2 Enterprise Edition

SQL Server 2005 Express SP2 Advanced

SQL SQL SQL SQL SQL SQL SQL SQL

Server Server Server Server Server Server Server Server

2008 2008 2008 2008 2008 2008 2008 2008

Express with Advanced Services Workgroup Standard Edition Enterprise Edition R2 Express with Advanced Services R2 Workgroup R2 Standard Edition R2 Enterprise Edition

SQL Server 2008 Enterprise Edition

SQL Server 2008 R2 Enterprise Edition SQL Server 2008 R2 Datacenter Edition

SQL Server 2008 IA64 Enterprise Edition

SQL Server 2008 R2 IA64 Enterprise Edition SQL Server 2008 R2 IA64 Datacenter Edition

SQL Server 2008 X64 Enterprise Edition

SQL Server 2008 R2 X64 Enterprise Edition SQL Server 2008 R2 X64 Datacenter Edition

Download from www.wowebook.com

Destination: SQL Server 2008 or SQL Server 2008 R2

249

TABLE 9.1 Supported Upgrade Paths to SQL Server 2008 and 2008 R2 Previous SQL Server Edition

Supported Upgraded Edition

SQL Server 2008 Developer Edition

SQL Server 2008 R2 Developer Edition SQL Server 2008 R2 Datacenter Edition

SQL Server 2008 IA64 Developer Edition

SQL Server 2008 R2 IA64 Developer Edition SQL Server 2008 R2 IA64 Datacenter Edition

SQL Server 2008 X64 Developer Edition

SQL Server 2008 R2 X64 Developer Edition SQL Server 2008 R2 X64 Datacenter Edition

SQL Server 2008 Standard Edition

SQL Server 2008 R2 Standard Edition SQL Server 2008 R2 Enterprise Edition SQL Server 2008 R2 Datacenter Edition

SQL Server 2008 X64 Standard Edition

SQL Server 2008 R2 X64Standard Edition SQL Server 2008 R2 X64 Enterprise Edition SQL Server 2008 R2 X64 Datacenter Edition

SQL Server 2008 Workgroup Edition

SQL SQL SQL SQL

Server Server Server Server

2008 2008 2008 2008

R2 R2 R2 R2

Workgroup Edition Standard Edition Enterprise Edition Datacenter Edition

SQL Server 2008 X64 Workgroup Edition

SQL SQL SQL SQL

Server Server Server Server

2008 2008 2008 2008

R2 R2 R2 R2

X64 X64 X64 X64

SQL Server 2008 Web Edition

SQL Server 2008 R2 Web Edition SQL Server 2008 R2 Standard Edition SQL Server 2008 R2 Enterprise Edition

SQL Server 2008 X64 Web Edition

SQL Server 2008 R2 X64 Web Edition SQL Server 2008 R2 X64 Standard Edition SQL Server 2008 R2 X64 Enterprise Edition

SQL Server 2008 Express

SQL SQL SQL SQL SQL SQL SQL

2008 2008 2008 2008 2008 2008 2008

R2 R2 R2 R2 R2 R2 R2

9

Server Server Server Server Server Server Server

Workgroup Edition Standard Edition Enterprise Edition Datacenter Edition

Express Express with Tools Express with Advanced Services Workgroup Standard Edition Enterprise Edition Datacenter Edition

Download from www.wowebook.com

250

CHAPTER 9

Upgrading to SQL Server 2008

TABLE 9.1 Supported Upgrade Paths to SQL Server 2008 and 2008 R2 Previous SQL Server Edition

Supported Upgraded Edition

SQL Server 2008 Express Advanced

SQL SQL SQL SQL SQL

Server Server Server Server Server

2008 2008 2008 2008 2008

SQL Server 2008 Evaluation Edition

Not supported

R2 R2 R2 R2 R2

Express with Advanced Services Workgroup Standard Edition Enterprise Edition Datacenter Edition

NOTE As you see in Table 9.1, direct upgrades from versions prior to SQL Server 2000 SP4 or SQL Server 2005 versions prior to SP2 are not supported. Options for migrating databases from these versions of SQL Server are presented later in this chapter.

Upgrading Using a Configuration File If you need to upgrade multiple SQL Server 2008 instances, you’ll likely want to do so without having to run the Installation Center utility each time and manually select the same options over and over. Fortunately, you can run an upgrade via the Installation Center using a configuration file. Using a configuration file, you have a couple options for how you run the upgrade: using the Upgrade Wizard with options prefilled by the configuration file or as a fully automated and unattended installation from the command line. If you run using the GUI with the options prefilled by the configuration file, you have the opportunity to review and change options along the way as necessary.

NOTE If you’ve never run a SQL Server installation using the setup feature of SQL Server, you should refer to the “Installing SQL Server Using a Configuration File” section in Chapter 8 for a detailed description of the process and options available.

Download from www.wowebook.com

Slipstreaming Upgrades

251

Following are a few of the parameters relevant to running an upgrade using a configuration file: . /ACTION=UPGRADE—Specifies that you are running an upgrade. . /INSTANCENAME—Specifies the SQL Server instance to be upgraded. For the default instance, you use the special value MSSQLSERVER. . /CONFIGURATIONFILE—Specifies the configuration file to use for the upgrade. . /INSTANCEDIR—Specifies a nondefault installation directory for shared components to be upgraded. . /UIMODE—Specifies whether to present only the minimum number of dialog boxes during setup. Normal presents all setup dialogs; AutoAdvance skips nonessential dialog boxes. . /FTUPGRADEOPTION—Specifies the full-text catalog upgrade option. Valid values are REBUILD, RESET, and IMPORT. To create an upgrade configuration file, run the Upgrade Wizard as described previously and follow it all the way through to the Ready to Install page where the location of the generated Configuration.ini file is specified. At this point, you can click the Cancel button if you don’t want to actually perform the upgrade. Then copy the Configuration.ini file to another location so you can make any necessary edits to it. To run an upgrade using a configuration file, you need to run the setup.exe program, which can be found at the root level of the installation media. If you want to override any of the values in the configuration file or provide values not specified in the configuration file, you can provide additional command-line parameters. For example, to avoid having to enter the service account passwords during the installation, you can enter them on the command line using the password parameters to config.exe. Following is a sample execution to upgrade the default instance and specify the account and password for Reporting Services and the service account for Integration Services: Setup.exe /q /ACTION=upgrade /INSTANCENAME=MSSQLSERVER /RSUPGRADEDATABASEACCOUNT=”myRSaccount” /RSUPGRADEPASSWORD=”myRSpassword” /ISSVCAccount=”NT Authority\Network Service” /IACCEPTSQLSERVERLICENSETERMS

9

Note also that the preceding example specifies the /q parameter, which runs the upgrade in Full Quiet mode, which is intended for running unattended installations. With this switch provided, Setup runs without any user interface. Another option is to run with the /QS switch, which shows progress via the GUI but does not accept any input and displays no error messages if encountered.

Slipstreaming Upgrades If you are upgrading to SQL Server 2008, you’ll likely want to install Service Pack 1 as well and possibly the latest cumulative update. In the past, this meant running the upgrade and then running the Service Pack 1 (SP1) install and cumulative update separately. This

Download from www.wowebook.com

252

CHAPTER 9

Upgrading to SQL Server 2008

process can be tedious and time consuming. Fortunately with the release of SP1, SQL Server 2008 supports Slipstream installations and upgrades. As mentioned previously, slipstreaming is a method of integrating a SQL Server 2008 update with the original installation media so that the original media and the update are installed at the same time. Because slipstreaming was introduced with SQL Server 2008 SP1 and not with the initial release, a slipstream upgrade must be run from the setup.exe program provided with SQL Server 2008 SP1. If you run from the SP1 media folder, you need to specify the location of the SQL Server 2008 installation media using the MEDIASOURCE parameter, as shown in the following example: setup.exe /PCUSource=C:\SQLServer2008SP1 /ACTION=UPGRADE /INSTANCENAME=MSSQLSERVER

/MEDIASOURCE=D:\

The /PCUSource parameter is used to specify the location of the SP1 package. You use the /CUSource parameter to specify the location of a Cumulative Update package you want to apply as well, if any.

NOTE A slipstream install cannot be used to update a SQL Server 2008 instance to SQL Server 2008 R2.

For a full description and more detailed examples on how to set up and run a Slipstream installation, refer to Chapter 8.

Upgrading from SQL Server 7 or SQL Server 6.5 SQL Server supports upgrading from SQL Server 2000 SP4 and later and SQL Server 2005 SP2 and later. Unfortunately, upgrading directly from SQL Server 7.0 or earlier versions is not supported. The supported migration path is to first migrate your SQL Server 7.0 (or earlier) databases to SQL Server 2000 SP4 or 2005 SP2 (upgrades that are supported) and then upgrade from one of these versions to SQL Server 2008 or 2008 R2. If you have a SQL Server 2000 SP2 or SQL Server 2005 SP4 instance available, the easiest way to upgrade your SQL Server 7.0 or earlier databases is to detach them from the source server and then attach the databases to an instance running either SQL Server 2000 SP2 or SQL Server 2005 SP4. When the database is attached, it is upgraded to that version, and then you can upgrade the database to SQL Server 2008 R2. Generally, this is the preferred method. Another option is to use the SQL Server Import and Export Wizard to copy data from a 7.0 or earlier instance of SQL Server. The main disadvantage of this approach is that it brings over only tables and data. You have to manually script your stored procedures, functions, triggers, views, and other database objects and re-create them on the upgraded target database.

Download from www.wowebook.com

Upgrading Other SQL Server Components

253

Upgrading Other SQL Server Components Now that you’ve seen how to migrate databases, jobs, logins, custom error messages, and full-text catalogs, let’s discuss how you can migrate the rest of your SQL Server objects. First, let’s look at Analysis Services.

Upgrading Analysis Services The following sections highlight some important considerations you should be aware of when upgrading Analysis Services. Upgrading from SQL Server 2005 Analysis Services You can upgrade an existing instance of SQL Server 2005 Analysis Services to SQL Server 2008 Analysis Services using the Upgrade Wizard. The wizard automatically migrates existing databases from the old instance to the new instance. The metadata and binary data is compatible between the SQL Server 2005 and SQL Server 2008, so the data is retained after you upgrade. You do not have to manually migrate the data. To upgrade an existing instance of SQL Server 2005 Analysis Services, run the Upgrade Wizard and specify the name of the existing AS instance as the name of the new AS instance. The AS databases are upgraded automatically.

NOTE Users running in a 64-bit environment must upgrade Analysis Services before upgrading the SQL Server Database Engine. You can, of course, run setup more than once, so in this situation it is recommended that you upgrade Analysis Services first (separately) and then upgrade your other components on subsequent runs. Upgrading from SQL Server 2000 Analysis Services Because of changes to the underlying architecture of Analysis Services between SQL Server 2000 and SQL Server 2008, you cannot perform an in-place upgrade. You have to migrate your SQL Server 2000 AS databases to SQL Server 2008.

9

The first task is to install a new named instance of SQL Server 2008 Analysis Services (SSAS) by using the SQL Server 2008 Installation Center program. When this process is complete, you can use the Analysis Services Migration Wizard to import your SQL Server 2000 Analysis Services content into the SQL Server 2008 AS format. This wizard re-creates your existing OLAP structures on the new instance, without altering the original source material. If you remove the prior instance of SQL Server 2000 Analysis Services after you have migrated its databases, you can use the Analysis Services Instance Rename tool to make the named instance of SQL Server 2008 Analysis Services the default instance on the server. To launch the Analysis Services Migration Wizard, open the Object Browser and connect to Analysis Services. Then navigate to the top-level Analysis Services node to find the wizard. You can also simply select Start, Run and then enter the command MigrationWizard.exe. You need to make sure that MSSQLServerOLAPService is running before you begin; you can verify this by using the SQL Server Service Manager.

Download from www.wowebook.com

254

CHAPTER 9

Upgrading to SQL Server 2008

Click Next on the Welcome page, and the Specify Source and Destination screen appears (see Figure 9.15). You need to enter the name of your SQL Server 2000 Analysis Services server as the source. Then you have two options: . Server—You can choose this radio button and enter the name of your new SSAS instance to immediately migrate your OLAP databases. . Script File—If you select this radio button and enter a filename, the wizard can generate an XML for Analysis (XMLA) script, which you can later run to perform the same migration.

FIGURE 9.15 The Analysis Services Migration Wizard’s Specify Source and Destination screen. Click Next, and the Select Databases to Migrate screen appears; this screen is fairly selfexplanatory. Make your selections and then click Next. The Validating Databases screen appears. At this point, the wizard performs the migration and reports on its progress, noting any issues along the way. When the wizard is done, click Next, and the Completing the Wizard screen appears, showing a summary report.

NOTE According to Microsoft, the Analysis Services Migration Wizard is unable to migrate three OLAP constructs: linked cubes, drill-through options, and remote partitions. You need to manually re-create these constructs.

When your migration is complete, you need to remember to reprocess your cubes; otherwise, you are unable to query the new database. In addition, the migrated database doesn’t yet exploit the features of SSAS’s Unified Dimensional Model (UDM) in your exist-

Download from www.wowebook.com

Upgrading Other SQL Server Components

255

ing cubes. To fully explore that topic and learn more about other new features and functionality in Analysis Services, check out Chapter 51, “SQL Server 2008 Analysis Services.”

Upgrading Reporting Services SQL Server 2008 supports upgrading from the following earlier editions of Reporting Services: . SQL Server 2000 Reporting Services with Service Pack 2 (SP2) . SQL Server 2005 Reporting Services You can choose to perform an in-place upgrade or migrate a Reporting Services Installation to SQL Server 2008. You can run the Upgrade Advisor tool on the Report Server computer to determine any issues that might prevent a successful upgrade. Known upgrade issues currently include the following: . There is no upgrade support for a Report Server that uses a remote SQL Server 2000 Database Engine instance to host the Report Server database. . There is no support for the SQL Server 2000 Report Server Web service in SQL Server 2008 because this endpoint is discontinued, and any custom features that point to the ReportServer2000 endpoint no longer run. . There is no support for earlier versions of the Reporting Services WMI provider because the Reporting Services WMI provider is not backward compatible with previous versions. You cannot use the SQL Server 2008 Reporting Services WMI provider with earlier versions of Reporting Services. Performing an In-Place Upgrade of Reporting Services If you’ve run the Upgrade Advisor and it doesn’t report any issues that would prevent a successful upgrade (or you’ve addressed any issues it raises), you can perform an in-place upgrade of any instance of SQL Server 2000 Reporting Services SP2 or SQL Server 2005 Reporting Services. Before upgrading Reporting Services, you should first back up the following: . The symmetric key (by using the RSKEYMGMT tool)

9

. Your Report Server databases . Configuration files: Rsreportserver.config, Rswebapplication.config, Rssvrpolicy.config, Rsmgrpolicy.config, Reportingservicesservice.exe.config, Web.config (for both the Report Server and Report Manager ASP.NET applications), and Machine.config (for ASP.NET if you modified it for Report Server operations) . Any customizations to existing Reporting Services virtual directories in IIS . Your reports Before running the upgrade, you first need to stop IIS and the Report Services Windows service on each machine on which you will be running the in-place upgrade. (For a Web farm [now known as a scale-out implementation] the upgrade must be run on every node.)

Download from www.wowebook.com

256

CHAPTER 9

Upgrading to SQL Server 2008

Then run the Installation Center and select your existing instance for upgrade at the appropriate screen. The Installation Center upgrades the instance in-place, including all its components and any published reports and snapshots. Upgrading Reporting Services also requires updates to your Report Server databases. Because the Report Server database schema can change with each new release of Reporting Services, it is required that the database version match the version of the Report Server instance you are using. In most cases, a Report Server database can be upgraded automatically with no specific action on your part. The following list identifies all the conditions under which a Report Server database is upgraded: . After a Reporting Services instance is upgraded, the database schema is automatically upgraded after service startup and the Report Server determines that the database schema version does not match the server version. . At service startup, the Report Server checks the database schema version to verify that it matches the server version. If the database schema version is an older version, it is automatically upgraded to the schema version that is required by the Report Server. Automatic upgrade is especially useful if you restored or attached an older Report Server database. A message is entered in the Report Server trace log file indicating that the database schema version was upgraded. . The Reporting Services Configuration tool upgrades a local or remote Report Server database when you select an older version to use with a newer Report Server instance. In this case, you must confirm the upgrade action before it happens.

NOTE The Reporting Services Configuration tool no longer provides a separate Upgrade button or upgrade script. Those features are obsolete in SQL Server 2008 due to the automatic upgrade feature of the Report Server service.

After the database schema is updated, you cannot roll back the upgrade to an earlier version. Always back up the Report Server database in case you need to re-create a previous installation. SQL Server 2008 introduces changes to the Report Definition Language (RDL), the report object model, and the rendering object model that affect reports created in earlier versions of the software. When you upgrade a Reporting Services installation from a prior version to a SQL Server 2008 Reporting Services installation, existing reports and snapshots that have been uploaded to a Report Server are automatically upgraded to the new schema the first time they are processed. If a report cannot be automatically upgraded, the report is processed using the backward-compatibility mode. Also, if you open an .rdl file in Report Designer that was created for the SQL Server 2000 or SQL Server 2005 namespace, Report Designer automatically upgrades the report to the current namespace. After you save the report, you cannot open it in earlier versions of Report Designer.

Download from www.wowebook.com

Upgrading Other SQL Server Components

257

If you are unable to perform an in-place upgrade of your existing installation for any reason, your other option is to install a new instance of SQL Server 2008 Reporting Services and then migrate your Report Server database and configuration files to the new instance. Migrating to Reporting Services 2008 The migration process for Reporting Services includes a combination of manual and automated steps. The following tasks are required to perform a Reporting Services migration: . Back up your Report Server databases, applications, and configuration files. . Back up the encryption key. . If it is not installed already, install a new instance of SQL Server 2008 or 2008 R2. . Move your Report Server database(s) from your SQL Server 2000 or 2005 installation to your new installation using the detach/attach or backup/restore method. . Move any custom report items, assemblies, or extensions to the new installation. . Configure the Report Server. . Edit the RSReportServer.config file to include any custom settings from your previous installation. . Optionally, configure custom Access Control Lists (ACLs) for the new Reporting Services Windows service group. . Remove unused applications and tools after you have confirmed that the new instance is fully operational. When you are backing up the Report Server configuration files, the files to back up include . Rsreportserver.config . Rswebapplication.config . Rssvrpolicy.config . Rsmgrpolicy.config . Reportingservicesservice.exe.config

9

. Web.config for both the Report Server and Report Manager ASP.NET applications . Machine.config for ASP.NET if you modified it for Report Server operations During the install of your new instance of Reporting Services, when you reach the Reporting Services screen, you need to be sure to select the Install but Do Not Configure option. After moving your Report Server databases, launch the new Reporting Services Configuration tool and select the Report Server database that you’ve moved from the previous installation to automatically upgrade it. Then restore your backed-up encryption key. Just as with an in-place upgrade, to upgrade the reports themselves, all you need to do is open them in the Report Designer, which automatically converts them to the new Report Definition Language format.

Download from www.wowebook.com

258

CHAPTER 9

Upgrading to SQL Server 2008

After you successfully migrate your Report Server to a SQL Server 2008 Reporting Services instance, you might want to perform the following steps to remove programs and files that are no longer necessary: . Uninstall the previous version of Reporting Services if it’s no longer needed. . Remove IIS if you no longer need it on the computer (it’s no longer needed by Reporting Services 2008). . Delete RSActivate.exe (if you migrated from SQL Server 2000 installations only). Upgrading SSIS Packages When you upgrade an instance of SQL Server 2005 to SQL Server 2008, your existing SQL Server 2005 Integration Services packages are not automatically upgraded to the package format that SQL Server 2008 Integration Services uses. You have to manually upgrade your SQL Server 2005 packages. There are multiple methods to upgrade SQL Server 2005 packages. Some of the methods are only temporary. For others, the upgrade is permanent. Table 9.2 lists each of the upgrade methods and whether the upgrade is temporary or permanent.

TABLE 9.2 SSIS Upgrade Methods Upgrade Method

Type of Upgrade

Using the dtexec utility installed with SQL Server 2008

The package upgrade and script migration are temporary. The changes are not saved.

Adding a SQL Server 2005 package to an existing project or opening a SQL Server 2005 package in SQL Server 2008 Integration Services

The package upgrade is permanent if you save the package. The script migration is permanent if you add the package to an existing project or if you open the package and save the conversion changes.

Using the SSIS Package Upgrade Wizard

The package upgrade and script migration are permanent.

Using the Upgrade method to upgrade one or more Integration Services packages.

The package upgrade and script migration are permanent.

The SSIS Package Upgrade Wizard is the recommended approach for upgrading your SQL Server 2005 SSIS packages. Because you can configure the wizard to back up your original packages, you can continue to use the original packages if you experience upgrade difficulties. You can run the SSIS Package Upgrade Wizard from SQL Server Management Studio, from SQL Server Installation Center, or at the command prompt. To run the wizard from SQL Server Management Studio, connect to Integration Services, expand the Stored Packages node, right-click the File System or MSDB node, and then click Upgrade Packages. To run the wizard from SQL Server Installation Center, click

Download from www.wowebook.com

Upgrading Other SQL Server Components

259

Tools and then click Upgrade Integration Services packages. At the command prompt, run the SSISUpgrade.exe file from the C:\Program Files\Microsoft SQL Server\100\DTS\Binn folder.

Migrating DTS Packages SSIS is a complete rewrite of the DTS runtime, and this is why your DTS packages are not automatically migrated to SQL Server 2008 when running an in-place upgrade. You essentially have two options for how to handle your existing DTS packages: . Install runtime support for DTS packages so you can continue to run your existing DTS packages. . Migrate your DTS packages to SSIS using the DTS Package Migration Wizard. Full DTS support in SQL Server 2008 consists of multiple components. The first component is the Client Tools Backward Compatibility option. During an installation or upgrade, on the Feature Selection page, select Integration Services and choose to install the Client Tools Backward Compatibility option. This option installs the Execute DTS 2000 Package task for SSIS. The next component you need to install is DTS runtime support. To install runtime support for Data Transformation Services packages, go to the Microsoft Download Center and locate the Microsoft SQL Server 2008 Feature Pack page. From there, download the Microsoft SQL Server 2005 Backward Compatibility Components (this component has not been updated for SQL Server 2008). If you also want to use the SQL Server 2008 tools to open and view DTS packages, you have to download and install the design-time support as well. This support can also be found in the Microsoft Download Center on the Feature Pack for Microsoft SQL Server 2005 page. After you install the DTS runtime support, your DTS packages can run as before. You can run your DTS packages one of the following ways: . From the command prompt using the dtsrun.exe utility . Via SQL Server Agent Jobs by setting the job step to Operating system (CmdExec) and use the dtsrun utility (dtsrun.exe) to run the package

9

. Via Integration Services Packages using the Execute DTS 2000 Package task If you also installed the design-time support, you are able to continue to edit and manage your DTS packages. You can manage your DTS packages from SQL Server Management Studio under the Data Transformation Services node, which is available in the Management/Legacy folder. Here, you can open existing DTS packages stored on the file system or in the msdb database, or add additional packages to the server by clicking the Import button. Although DTS packages can be modified and renamed, you cannot create new DTS packages within SSMS. The DTS runtime support is intended to be used only on a temporary basis until you have the opportunity to migrate your DTS packages to SSIS. To migrate your DTS packages to SSIS, you can use the DTS Package Migration Wizard.

Download from www.wowebook.com

260

CHAPTER 9

Upgrading to SQL Server 2008

To run the DTS Package Migration Wizard, you first need to make sure that the SSIS service is in the running state. In SSMS, open the Object Explorer and navigate to the Legacy node, under Management. Then right-click the Data Transformation Services (DTS) node and select the Package Migration Wizard option to migrate one or more packages (those stored on a server or as files) to SSIS.

NOTE The Package Migration Wizard is available only in the Developer, Standard, and Enterprise Editions of SQL Server 2008.

When you run the Package Migration Wizard, you first need to select the source and destination servers (the source must be a SQL Server 7 or 2000 instance, and the destination must be a 2008 instance with SSIS running) on the Choose Source Location and Choose Destination Location screens. Then click Next to reach the List Packages screen (see Figure 9.16), where you check the check boxes for the packages you want to bring over. The name for each imported package is listed in the Destination Package column, and you can click there to edit it.

FIGURE 9.16 The Package Migration Wizard’s List Packages screen. At the next screen, you can specify a log file for the process. You click Next again and then click Finish to complete the migration. As with all the other wizards provided with SQL Server 2008, the Package Migration Wizard reports progress and any issues on a per-package basis, offering an exportable report at the end.

Download from www.wowebook.com

Summary

261

After migration is complete, the original DTS package is still available on the SQL Server 7 or 2000 instance, in unmodified form. You can import packages into SQL Server in SSMS by connecting to SSIS in the Object Explorer and then navigating to the Stored Packages node and then the MSDB node. If you selected a file system folder as the destination, right-click the File System node and then select Import Package to display the migrated packages.

Summary Now that you’ve taken in a great deal of information to help your organization transition to SQL Server 2008, it’s time to put that knowledge to work by actively taking the plunge. If you need even more documentation, you can look to the many other chapters in this book and even more resources on the Web that can assist you. Of course, there’s an abundance of content on Microsoft’s website (after all, it’s in Microsoft’s interests that customers upgrade to SQL Server 2008), including webcasts, TechNet, and online learning courses available to MSDN subscribers. When your new environment is ready to go, you can move on to Chapter 10, “Client Installation and Configuration,” to learn how to get your clients up and running with your new installation of SQL Server 2008.

9 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

10

Client Installation and Configuration

IN THIS CHAPTER . What’s New in Client Installation and Configuration . Client/Server Networking Considerations . Client Installation . Client Configuration

SQL Server 2008 offers a robust client/server architecture

. Client Data Access Technologies

that provides speed and security, simple configuration and maintenance, and enhanced management capabilities. This chapter contains the latest information on how to install, configure, and connect to SQL Server 2008 from the client side, and it offers key server-side insights that will help provide a complete understanding of what you need to do establish a database connection.

What’s New in Client Installation and Configuration Client installation and configuration in SQL Server 2008 is similar to SQL Server 2005 but does have its share of changes. First and foremost is the introduction of a new net-library named SQL Native Client 10.0 (SNAC10). SNAC10 gives applications access to the new features and data types available with SQL Server 2008. It builds on the data access component distribution strategy introduced in SQL Server 2005 that was simply called SQL Native Client (SNAC or SNAC9). The good news is that your applications can continue to access SQL Server 2008 with the older SNAC components. Both SNAC9 and SNAC10 can be used on the same client system. SNAC9 is not able to reference new features in SQL Server 2008, however, so you have to upgrade to SNAC10 to gain access to them. Another big change in SQL Server 2008 is the removal of the Surface Area Configuration (SAC) tool. The SAC tool

Download from www.wowebook.com

264

CHAPTER 10

Client Installation and Configuration

was introduced in SQL Server 2005 and was a key part of client configuration. The functionality made available in this tool has now been replaced with Policy-Based Management features and changes in the SQL Server Configuration Manager (SSCM) tool. For example, the option to allow Remote Connections that was available in SAC is no longer there. You should look to the SSCM tool and enable or disable the protocols for which you want to allow connections. The details of this change are discussed later in this chapter, and a full discussion of Policy-Based Management is provided in Chapter 22, “Administering Policy Based Management.” One last change in SQL Server 2008 Client Installation and Configuration that may rear its head relates to the BUILTIN\Administrator windows group. By default, this group is no longer included in the SQL Server sysadmin fixed server role on new SQL Server 2008 installations. So, by default, network administrators and administrators of the machine where SQL Server is running are not able to log in to SQL Server and administer it. In past versions of SQL Server, the BUILTIN\Administrator windows group was added to the sysadmin role. To grant administrators permission to SQL Server, you can manually add the BUILTIN\Administrator group to the sysadmin SQL Server role, or you can add each individual network administrator that needs to access SQL Server to that role. The change to the BUILTIN\Administrator windows group is in line with Microsoft’s strategy to “secure by design, secure by default, and secure in deployment.” This strategy relates to many aspects of SQL Server, including installation, security, and client installation and configuration. The strategy is a good one but can cause you, as the administrator, some extra grief if you are not aware of the impact that these changes can have on you and your users.

Client/Server Networking Considerations Before we delve into the features on the client side in SQL Server, it’s important to make note of a few server-side features. This information will help you gain an understanding of which networking features are initially configured on the server (after an installation or upgrade) as well as how incoming connections are dealt with. Such knowledge can be invaluable in diagnosing connectivity issues. If you’ve been following along chapter by chapter, you’ve learned how to install or upgrade an instance of SQL Server 2008. To get your clients up and running fast, you must be sure the Database Engine is listening for them. The following sections describe how to set up the server’s basic network configuration, including configuring it to accept remote connections, learning which protocols it supports, and understanding how it listens for and responds to client requests.

Server Network Protocols The first and most basic step after a SQL Server installation or upgrade is to make sure the appropriate network protocols are configured on the server.

Download from www.wowebook.com

Client/Server Networking Considerations

265

NOTE Note that the term server is used here to refer to an instance of the SQL Server 2008 Database Engine. The term client is used generally to mean any program that needs to communicate with a server. The server and client may reside on the same physical machine (especially when using SQL Server Mobile and Express Editions).

First, you should ensure that the protocols your clients once used to connect to SQL Server 7, 2000 or 2005 (or that your clients would like to use) are still supported by SQL Server 2008 and configured. You might be surprised to learn that the following protocols that were supported in SQL Server 2000 are not supported by SQL Server 2005 or SQL Server 2008: . AppleTalk . Banyan VINES . Multiprotocol . NW Link IPX/SPX If you were using these protocols and you’ve upgraded from SQL Server 2000, your clients are no longer able to connect. Following are the only protocols that SQL Server 2008 supports: . Named pipes . Shared memory . TCP/IP . Virtual Interface Adapter (VIA) If you were using any of these protocols and you just upgraded, Setup copies your preupgrade settings over to SQL Server 2008, including the enabled state, IP addresses, TCP ports, pipe names, and so on. Clients can simply test their connections to be sure the upgrade was successful, and in most cases, no changes need to be made.

NOTE

10

The Shared memory protocol works only for connections both to and from the same machine hosting the Database Engine. Shared memory is used by client tools such as SQL Server Management Studio (SSMS) and SQLCMD, and it’s also a good choice for use by locally running custom applications because it is secure by design. (It is the default protocol used by local applications that do not specify otherwise.)

All remote connections to SQL Server are thus disabled by default. Following is an extremely common client-side error message illustrating connection failure due to disabled remote connectivity:

Download from www.wowebook.com

266

CHAPTER 10

Client Installation and Configuration

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.

The exact wording of this message varies slightly, depending on the particular client or connection method used. The same error also occurs when the Database Engine service is stopped. In SQL Server 2008, remote connections must be enabled for each network protocol on which you want the server to communicate. This is easily accomplished using the SQL Server Configuration Manager (SSCM). You launch SSCM from the SQL Server 2008 Configuration Tools menu group. In SSCM, you expand SQL Server Network Configuration and then select the Protocols entry for the SQL Server instance that you want to configure. In the Details pane, right-click on one of the available protocols (for example, Named Pipes) and select Enable to allow connections for this protocol (see Figure 10.1). SSCM serves many purposes and is discussed in detail later in this chapter.

FIGURE 10.1 Enabling remote connections over named pipes using SSCM. When the protocol is enabled, SQL Server is configured to listen for connections from clients using the same protocol. You must restart the SQL Server instance for the changes to take effect and for SQL Server to actually start listening for connections. You can verify that SQL Server is listening on the protocol that you have enabled by looking at the SQL Server error log. Each time the SQL Server instance is restarted, messages are written to the log indicating which protocols it is listening on. The following sample error log messages show what SQL Server is listening for: Server is listening on [ ‘any’ 1719]. Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$INST2008\sql\query ].

Download from www.wowebook.com

Client/Server Networking Considerations

267

SQL Server listens on all configured protocols simultaneously, giving no preference or priority to any. This is in contrast to the explicitly prioritized manner in which clients attempt to connect via all configured protocols. The client configuration is discussed in detail later in this chapter.

NOTE In SQL Server 2005, the Surface Area Configuration (SAC) tool also could be used to allow remote connections and to configure the protocols on which they communicate. The SAC tool has been removed in SQL Server 2008, so you need to look to the SSCM to configure your protocols.

The Server Endpoint Layer A networking feature in SQL Server 2008 adds an additional layer to the client/server network structure: Tabular Data Stream (TDS) endpoints. When you install (or upgrade to) SQL Server 2008, a default system endpoint is created on the server for each available protocol on the server. These endpoints cannot be dropped, and they are created regardless of whether the protocol is disabled or otherwise unavailable.

NOTE The term endpoint in this context refers to the combination of a protocol selection, one or more IP addresses (or pipe names), and any associated port numbers.

These are the default system endpoints: . TSQL Local Machine (for shared memory) . TSQL Named Pipes . TSQL Default TCP . TSQL Default VIA . Dedicated Admin Connection (also known as the DAC) You can view these endpoints and check their status by executing the following T-SQL statement:

10

Use Master GO SELECT * FROM sys.endpoints WHERE principal_id = 1

By default, all users are granted access to these endpoints (except the DAC, which is only for members of the sysadmin role). Administrators can create new endpoints on the server to increase connection security by stopping (or disabling) the default system endpoints and then creating new user-defined endpoints that only specific clients can access.

Download from www.wowebook.com

268

CHAPTER 10

Client Installation and Configuration

(Creating a new system endpoint automatically revokes permission on the default endpoint of the same protocol to the public group.)

NOTE Only one named pipe and one shared memory endpoint can exist per instance, but multiple VIA or TCP endpoints (with different port and address settings) can coexist.

Each endpoint communicates with clients via TDS packets, which are formatted on the server side by SNAC and on the client side by SNAC or another of the net-libraries. Administrators have the option of stopping and starting endpoints while sessions are still active, preventing new connections from being made while still supporting existing ones. An administrator can grant or revoke endpoint access to specific users or groups (for example, preventing backdoor access through client tools). It is therefore important for clients to know that this structure exists and to learn how they receive permission to connect to endpoints through a server-side process known as provisioning. Client Access Provisioning There are three fairly straightforward rules of access provisioning. If any one of these rules is met by an incoming client, that client may access the endpoint. If none are met, the client is denied access. These are the rules: . If the client specifies an IP address and a TCP port that match those of a specific endpoint, the client may connect to it, if the client has permission to do so. . If only the TCP port specified by the client matches that of a specific endpoint, and the endpoint is configured to listen on all IP addresses, the client may connect to it, if the client has permission to do so. . If neither the TCP port nor IP address is specified, but the default endpoint for the protocol is enabled, the client may attempt to connect to the endpoint.

NOTE If the endpoint to which access is successfully provisioned is currently stopped, or if the user does not have permission to connect to it, no further endpoints are tried and the client cannot continue.

For example, let’s say a server has three TCP/IP endpoints defined: . The default (TSQL Default TCP), which listens on all IP addresses and Port 1433 (a default SQL Server 2008 instance) . A user-created endpoint called TCP_UserCreated 101_91, configured to listen on IP address 192.168.1.101 and Port 91

Download from www.wowebook.com

Client/Server Networking Considerations

269

. A second user-created endpoint, called TCP_UserCreated Any_91, which is configured to listen on all IP addresses and Port 91 A client attempts to connect specifically to 192.168.1.101:91. Because this is an exact address and port match, the client can try to connect to TCP_UserCreated 101_91. Having an exact address and port match meets the first provisioning rule. A second client attempts to connect to any IP address on Port 91. Because there is no exact address match, the client cannot attempt to connect to TCP_UserCreated 101_91. However, the client can attempt to connect to TCP_UserCreated Any_91 because it is configured to listen on all IP addresses. This meets the second provisioning rule. A third client attempts to connect on any port and any address. If TSQL Default TCP is started, the client is granted permission to attempt to connect. This meets the third provisioning rule.

NOTE Settings such as IP addresses and TCP ports are used to implicitly connect to specific endpoints. These values are specified by clients in connection strings, data source names (DSNs), and server aliases, all of which are discussed later in this chapter in the “Client Configuration” section.

TIP If, at any time, you want to discover which protocol and endpoint a connected client is currently using, you can run the following T-SQL to list the current connections and related protocols. The session_id identifies the server process ID (SPID), and an additional WHERE clause can be added to the SELECT statement that selects only the SPID you are interested in: SELECT name, net_transport, session_id, e.endpoint_id FROM sys.dm_exec_connections d JOIN sys.endpoints e ON e.endpoint_id = d.endpoint_id go name

Shared memory

session_id 53

endpoint_id 2

10

TSQL Local Machine

net_transport

Following is an example of the client-side error message that results if the TSQL Default TCP endpoint is stopped and you try to connect to it: A connection was successfully established with the server, but then an error occurred during the login process

Download from www.wowebook.com

270

CHAPTER 10

Client Installation and Configuration

Now that you know a bit about endpoints, let’s go a bit deeper and explore how client connections are facilitated on the server.

The Role of SQL Browser You might be surprised to learn that when clients try to connect to SQL Server 2008, their first network access is made over UDP Port 1434 to the SQL Browser service.

NOTE Regardless of the encryption status of the connection itself, login credentials are always encrypted when passed to SQL Server 2008 (to foil any malicious packet sniffing). If a certificate signed by an external authority (such as VeriSign) is not installed on the server, SQL Server automatically generates a self-signed certificate for use in encrypting login credentials.

SQL Browser is the upgrade to the SQL Server Resolution Protocol (SSRP) and its job is to hand out instance names, version numbers, and connection information for each (nonhidden) instance of the Database Engine (and Analysis Services) residing on a server—not only for SQL Server 2008 instances, but for SQL Server 2000 and 2005 instances as well. When clients connect by name, SQL Browser searches for that name in its list and then hands out the connection data for that instance. It can also provide a list of available servers and help make connections to the correct server instance or to make a connection on the dedicated administrator connection (DAC). Ports, Pipes, and Instances Default instances of SQL Server 2008 are automatically configured (just as in previous editions) to listen on all IP addresses and TCP Port 1433. Named instances, on the other hand, are automatically configured to listen on all IP addresses, using dynamic TCP port numbers that change when the Database Engine is restarted. (Most often, these change only when the port number last used by the service is in use by a different application.) If the SQL Browser service is not running, the client might need to provide additional connection information to be able to connect to SQL Server. The additional connection information includes the specific port or pipe that the SQL Server instance may be listening on. The only exception to this is if the server is listening on the default port of 1433. Otherwise, the client must specify the port when connecting with TCP/IP. When dynamic ports are used, the port number can change at any given time and cause your clients to have to change their port to match the new server port. SQL Browser, therefore, is configured to autostart on servers that contain one or more named instances so that clients can connect by simply providing the server name. The complexity associated with providing additional port or pipe information is avoided when

Download from www.wowebook.com

Client Installation

271

the SQL Browser service is running. SQL Browser is also required for enumerating the server lists used to connect with client tools such as SMSS.

NOTE If named instances have fixed port numbers known to clients, or if a pipe name is well known, SQL Browser is not required to connect.

NOTE For named pipes, the default instance’s pipe name is \sql\query; for named instances, the pipe name is MSSQL$instancename\sql\query.

When a link is made, endpoint provisioning kicks in to finalize (or reject) the connection.

Client Installation Now that you have acquired some knowledge about the most important server-side networking considerations, it’s time to learn how to install and configure the client-side half of the equation.

Installation Requirements All SQL Server 2008 installations (including client-tools-only or SNAC-only installations) require Windows Installer 4.5, which is freely downloadable from Microsoft. It can also be installed as part of the SQL Server Installation Wizard or manually installed from the SQL Server media. The location of the installer media varies depending on the media you are using but an example of the location is as follows: D:\English\SQL2008\Enterprise\X86\redist\Windows Installer\x86

The same operating system requirements for server installations apply to client tools and SNAC installations, with one exception: When you install SNAC by itself on top of Windows XP, only SP1 is required, and when you install SNAC on top of Windows Server 2003, SP1 is not required. You can review the complete list of requirements in Chapter 8, “Installing SQL Server 2008,” in the section “Installation Requirements.”

10

Note that SNAC and the client tools both depend on the presence of the .NET Framework 3.5 SP1, and the client tools in turn depend on SNAC. Setup automatically installs both Framework 3.5 SP1 and SNAC, when required, on the target machine. If incompatible or beta versions exist that must be uninstalled first, Setup lets you know to use Installer 4.5.

Installing the Client Tools To install the SQL Server 2008 client tools, you start Setup normally and follow the prompts as described in Chapter 8. When the Feature Selection screen appears, you check only the Client Tools Connectivity check box, as shown in Figure 10.2.

Download from www.wowebook.com

272

CHAPTER 10

Client Installation and Configuration

FIGURE 10.2 Performing a client-tools-only installation. The same kind of install can be done quietly from the command line (Setup doubles as a command-line application), using the following: driveletter:\Servers\Setup> Setup.exe /q /ACTION=Install /FEATURES=CONN /INSTANCENAME=INST2008

That’s all there is to it! You will be happy to learn that the SQL Server 2008 client tools can safely be installed side by side with your SQL Server 2000 or 2005 client tools. You can even access databases and other objects created in either edition (with a few notable exceptions, such as database diagrams) by using either toolset. The sections that follow describe how to install and use a few of the client tools for client configuration and testing.

Installing SNAC This section shows how easy it is to install SNAC, the key net-library for SQL Server 2008 and beyond. As mentioned earlier, both the SQL Server 2008 Database Engine and the client tools depend on SNAC. SNAC is installed when you install the SQL Server connectivity tools, or you can simply launch it on its own from the SQL Server installation medium by running driveletter:\Servers\Setup\sqlncli.msi. Table 10.1 describes the files that the Microsoft Installer (MSI) package installs.

Download from www.wowebook.com

Client Installation

273

TABLE 10.1 Files Installed by the SNAC MSI Package Filename

Purpose

Installed To

Sqlncli.h

C++ header file (replaces sqloledb.h)

Program Files\Microsoft SQL Server\100\SDK

sqlncli10.lib

C++ library file for calling BCP functions (replaces odbcbcp.lib)

Program Files\Microsoft SQL Server\100\SDK

sqlncli10.dll

Main library, containing both the ODBC driver and OLE DB provider (houses all functionality)

WINDIR\system32

sqlnclir10.rll

Resource file

WINDIR\system32

s10ch_sqlncli.chm

Compiled help file for creating data sources using SNAC

WINDIR\system32

TIP For detailed information on how to write C++ code by using the header and library files included in the SNAC software development kit (SDK), see the Books Online topic “Using the SQL Native Client Header and Library Files.”

The SNAC installer has two primary options (shown in Figure 10.3):

10

FIGURE 10.3 SNAC’s installation options.

. Install SNAC by itself . Install the SNAC SDK files along with it

Download from www.wowebook.com

274

CHAPTER 10

Client Installation and Configuration

NOTE By default, all network protocols except for VIA are enabled on the client during installation.

That’s all there is to installing SNAC! Redistributing SNAC with Custom Client Applications If you build an application that relies on SNAC, you need to be aware that it can be redistributed in two ways: . As part of any SQL Server 2008 installation or upgrade . As a custom application installation dependency When you are building MSI files for an application, it is important that you register sqlncli.msi as a package dependency (and, of course, to install it as well, if it is not present on the destination machine). This helps ensure that SNAC will not be accidentally uninstalled from the destination machine without first flashing a warning to users, indicating that any application that relies on it will break. To do this, you execute the following command early in your application’s installation process: msiexec /i sqlncli.msi APPGUID={unique identifier for your product}

NOTE The program name for SNAC found in the Add or Remove Programs Control Panel applet is Microsoft SQL Server 2008 Native Client, not SQL Native Client, as it is commonly known.

Client Configuration Client configuration is a many-leveled beast, consisting of operating system tasks such as installing protocols, application tasks such as choosing or coding to a specific Application Programming Interface (API), provider, or driver, and maintenance tasks such as configuring network settings, building connection strings, and so on. The following sections cover a broad range of these tasks, focusing on the most common. Many examples utilize TCP/IP both because it is the default protocol for remote clients and because it is the most widely used. No chapter can cover all the possible ways of connecting, but this one is designed to give you the tools you need to get set up right from the start and to navigate your way in case specific issues arise. The first client configuration tool we look at is SSCM.

Download from www.wowebook.com

Client Configuration

275

Client Configuration Using SSCM The Client Network Utility available prior to SQL Server 2005 has been decommissioned, and all its functionality is now built into SSCM. This includes the capability to create server aliases, to enable and prioritize network protocols, to control the various SQL Server services, and more.

NOTE One thing Microsoft is keen on including in Books Online is that neither Setup nor sqlncli.msi installs the actual network protocols themselves, nor do they enable them at the operating system level. This means that if you do not have TCP/IP installed and you need to start using it, you have to first set it up by using the Network Connections Control Panel applet (if you’re using Windows, that is).

You can launch SSCM directly from its Start menu icon, or you can access it in the Services and Applications node of the Computer Management console. When you have SSCM up and running, to access its client-side functionality, you expand its top-level node (SQL Server Configuration Manager (servername)) and then you click the SQL Native Client 10.0 Configuration node. Below it, you click the Client Protocols node to reveal the enabled state and priority order of each protocol, in grid format, in the right pane (see Figure 10.4).

FIGURE 10.4 SSCM’s Client Protocols screen.

10 From this screen, you can right-click any of the protocols to change their enabled state, view Properties pages, or change the default connection order (except that of shared memory, which is always tried first and whose order cannot be changed). The following is the default connection order for clients connecting without the benefit of a server alias, connection string, or other means:

Download from www.wowebook.com

276

CHAPTER 10

Client Installation and Configuration

. Shared memory . TCP/IP . Named pipes (As the grid shows, VIA is disabled by default.) When you are connecting remotely, TCP/IP is the first protocol attempted because shared memory is local only.

NOTE When a client does not specify a connection protocol, SNAC automatically tries each protocol in the list in sequence, according to the Order column. The first protocol to connect successfully wins. If the winning connection is subsequently rejected by the server for any reason, no other protocols are tried. Note also that local clients using MDAC 2.8 or lower cannot connect using shared memory, and they are automatically switched to named pipes if they attempt to do so.

Let’s examine one of the protocols. To start, you need to double-click TCP/IP under the Name column to open the TCP/IP Properties screen (see Figure 10.5).

FIGURE 10.5 The TCP/IP Properties screen. The values stored here are used by TCP/IP clients as default connection values, and they are applied only when a specific server alias or other configuration mechanism is not in use. They are also used by the SQL Server 2008 client tools when shared memory is not available.

Download from www.wowebook.com

Client Configuration

277

As you can see, the default port, 1433, is set up to connect to the more commonly configured default instances of SQL Server. By editing the values on this page, you can change the default port number, enabled state, keep-alive values, and other settings (when editing other protocols). You should edit and enable the protocols according to your specific needs.

Server Aliases A server alias is a name that is used like a server name that represents a group of server settings for use by connecting clients. Server aliases are very handy because of the way they simplify connection parameters: clients need only specify the alias name, and SNAC pulls the rest of the information (such as the IP address, TCP port number, and pipe name) from SSCM at connection time. To create a server alias, you right-click the Aliases node under SQL Native Client Configuration and choose New Alias. On the Alias - New screen that appears (see Figure 10.6), you specify the alias name, protocol (except shared memory, for which you cannot create an alias), and server name. (local, ., and localhost also work for local connections over TCP/IP or named pipes.)

10

FIGURE 10.6 Alias properties for a new named pipe server alias.

When you make your protocol selection, the grid rows change to dynamically reveal the settings particular to that protocol. When you are finished, you click OK, and your alias is ready for use.

Download from www.wowebook.com

278

CHAPTER 10

Client Installation and Configuration

Connection Encryption With SQL Server 2008, it is easy to set up Secure Sockets Layer (SSL) encrypted client/server communication over all protocols. The SNAC net-library handles the tasks of encryption and decryption on both the server and client ends. (Note that this process does cause a slight decrease in performance.) Setting it up requires both server-side and client-side configuration changes; this section covers only the client-side changes in detail. SQL Server 2008 enables encryption using two types of certificates: . Certificates generated by and obtained from an external certification authority such as VeriSign . Certificates generated by SQL Server 2008 (known as self-signed certificates) The bit strength of the encryption (40-bit or 128-bit) depends on the bit strength of the operating systems of the computers involved in the connection. To set up the server for encryption, your administrator registers a certificate on the server operating system (using the Certificates Management console) and then installs it in the Database Engine. If an externally signed certificate is not installed on the server, SQL Server uses its built-in self-signed certificate. (A server administrator may also create and save a self-signed certificate by using SQL Server 2008 via the new CREATE CERTIFICATE and BACKUP CERTIFICATE T-SQL syntax.) It is also up to the server to decide whether encryption is required or optional for connecting clients. The client’s half of the job is to have installed what is known as a root-level certificate that is issued by the same certification authority as the server’s certificate. To install a root-level certificate, you right-click the certificate itself (a .cer or .crt file) and select Install Certificate to launch the Certificate Import Wizard. You click Next on the welcome screen to reach the Certificate Store screen (see Figure 10.7). Then you select the first radio button (Automatically Select the Certificate Store) and then click Next. Finally, you click Finish.

FIGURE 10.7 Importing a certificate on the client computer using the Certificate Import Wizard.

Download from www.wowebook.com

Client Data Access Technologies

279

Next, you launch SSCM, right-click the SQL Native Client 10.0 Configuration node, and then select Properties. The Flags tab appears (see Figure 10.8) in the Properties window.

FIGURE 10.8 Forcing clients to request an encrypted connection using SSCM. You set the Force Protocol Encryption property value to Yes. This causes clients to request an SSL-encrypted connection when communicating with the Database Engine. If the server does not respond in kind, the connection is killed. The Trust Server Certificate property gives clients a choice in how they deal with server certificates: . To use a self-signed certificate, you set the property value to Yes. This option prevents SNAC from validating the server’s certificate. . To use an externally signed certificate, you set the property value to No, which causes SNAC to validate the server’s certificate.

10

SSMS can also connect over an encrypted connection. When connecting using the Connect to Server dialog, you click the Options button and then click the Connection Properties tab. Then you choose your database and protocol and, at the bottom left, check the Encrypt Connection check box.

Client Data Access Technologies The question of which data access technology to use with SQL Server 2008 is a common one, with a seemingly easy answer: you use SNAC because it has all the latest and greatest functionality, all rolled into one. (You learn how to use SNAC in the sections that follow.)

Download from www.wowebook.com

280

CHAPTER 10

Client Installation and Configuration

A more correct answer is that your choice depends on which software technologies your clients currently use and what their specific needs are. Your data access options consist of providers and drivers, whose functionality is often encapsulated inside code libraries known as net-libraries (such as SNAC’s sqlncli10.dll). In addition to these net-libraries, supporting services such as MDAC’s OLE DB Core Services are also available, providing useful functionality not found in the net-libraries, such as connection pooling. (ADO.NET also functions as a service, to a certain degree.)

NOTE The Microsoft Data Access Components (MDAC) has a new name that started with the Vista operating system. The data access components are now called Windows Data Access Components or Windows DAC or WDAC. References to MDAC in this chapter also apply to the Windows DAC.

Provider Choices A provider is software used for accessing various data stores in a consistent manner conforming to a specification, such as OLE DB. A provider may contain an API. Clients that use providers are known as consumers. SMSS and SQLCMD, for example, are consumers of the SNAC OLE DB provider. You can choose from the following providers: . SQL Native Client OLE DB provider—This is the latest OLE DB provider, and it is built into SNAC; it is also known as SQLNCLI. COM applications might want to switch to this provider to access the latest functionality; doing so also provides access to SQL Server 7 and 2000 databases. . .NET Framework data provider for SQL Server—This data provider is built in to the System.Data.SqlClient namespace in the .NET Framework. Managed code applications should use it to access the latest SQL Server 2008 functionality from .NET 3.5 applications. .NET 1.0, 1.1, and 2.0 applications do not have access to all the latest SQL Server 2008 functionality through this provider. . Microsoft OLE DB provider for SQL Server—This OLE DB provider, known as SQLOLEDB, is specialized for accessing SQL Server data and is distributed with MDAC. COM applications may continue to use it to access SQL Server 2008, or they can switch to SQLNCLI for the latest functionality. . Microsoft OLE DB provider for ODBC—This deprecated OLE DB provider, known as MSDASQL, is distributed with MDAC. ADO applications can continue to use it to access SQL Server 2008, but SQL Server does not support the latest SNAC-specific OLE DB functionality. Microsoft has also made available a few implementation-specific OLE DB providers, such as the OLE DB provider for DB2, a COM component for integrating IBM DB2 and SQL Server 2008 data.

Download from www.wowebook.com

Client Data Access Technologies

281

Driver Choices A driver in this context can be defined as software that conforms to a standard such as Open Database Connectivity (ODBC) and provides an API for accessing a specific type of data store. osql.exe is a good example of an application that uses an ODBC driver (the SNAC driver). These are the available drivers: . SQL Native Client ODBC driver—This is the latest ODBC driver, and it is built into SNAC. COM applications might want to switch to this driver to access the latest functionality. . Microsoft ODBC driver for SQL Server—This is the ODBC driver distributed with MDAC for accessing SQL Server databases. COM applications can continue to use it to access SQL Server 2008, or they can switch to the SNAC ODBC driver for the latest functionality. This driver also provides access to SQL Server 7, 2000, and 2005 databases. . Java Database Connectivity (JDBC) driver—The JDBC driver was built specifically for accessing SQL Server data from Java code.

CAUTION Although it is still possible to connect to SQL Server 2008 by using DB-library and Embedded SQL, Microsoft has deprecated them both, and they will not be supported in future editions.

Connecting Using the Various Providers and Drivers Now that you know what your options are in terms of providers and drivers, the following sections detail them one by one, with a special focus on putting the features in SQL Server 2008 to work.

The code for SNAC is contained in the single dynamic link library sqlncli10.dll, and it serves as provider, driver, and API for applications that call its underlying COM functions from unmanaged code (that is, from C or C++).

10

Using SNAC SNAC is a net-library that contains both the latest OLE DB provider and ODBC driver for using the rich features in SQL Server 2008 databases. It is compatible for accessing SQL Server 7, 2000, and 2005 databases as well.

The bottom line with SNAC is that if you’re building applications that need to exploit the latest features of SQL Server 2008, you need to use its APIs. If you don’t, your application will continue to work without SNAC, but those new features will not be available.

Download from www.wowebook.com

282

CHAPTER 10

Client Installation and Configuration

NOTE A large number of connection keywords are available for use with SNAC connections. A few of them are illustrated in the examples that follow, but for a complete reference, see the Books Online topic “Using Connection String Keywords with SQL Native Client.” Using OLE DB with SNAC Applications that call the COM APIs for OLE DB need to have the connection provider value changed from SQLOLEDB to SQLNCLI10. You also need to use the SNAC header file, as in the following example: include “sqlncli.h”; sqlncli.h contains the latest function prototypes and other definitions for use with

SNAC. This file is named the same as it was in SQL Server 2005, but it is installed in a different location.

NOTE The SNAC OLE DB provider is OLE DB version 2.0 compliant. Using ODBC with SNAC To connect to SQL Server 2008 using ODBC, you use a connection string or a DSN that is accessible to the client application at runtime. The ODBC driver used with SQL Server 2000 (simply called SQL Server) can still be used but is not the best option for SQL Server 2005 or 2008. To get the latest SNAC functionality, you must use the driver called SQL Native Client 10.0 (for example, DRIVER={SQL Native Client 10.0}). To create a SNAC ODBC DSN, you run the Data Sources (ODBC) applet found in your operating system’s administrative tools. You create a system, file, or user DSN, and you need to be sure to select the SQL Server Native Client 10.0 driver on the Create New Data Source screen that appears. On this screen, you click the Advanced button to enter any SNAC-specific connection string keyword-value pairs, as shown in Figure 10.9.

FIGURE 10.9 Using the Data Sources (ODBC) tool to configure MARS with a SNAC ODBC DSN.

Download from www.wowebook.com

Client Data Access Technologies

283

You finish the wizard by entering the configuration data as you normally would, and you can use you new DSN just as you would any other. For more information on building COM applications that utilize SNAC, see the Books Online topic “Creating a SQL Native Client ODBC Driver Application.” Using ADO with SNAC Of course, the first recommendation is that if you’re still using ADO, you should switch to ADO.NET if you can. If that isn’t feasible, you can still access SQL Server 2008 from your ADO applications. But you should do so only if you need the new features; in this case, you need to start using the SNAC OLE DB provider in your code. To do so, you first install SNAC, and then you update your connection strings (or DSNs) to use the new SQLNCLI value for the Provider connection string keyword. Then you set the DataTypeCompatibility keyword to 80. Here’s an example (in Visual Basic 6 code): Dim Dim Dim Dim Dim

MyConnection As New ADODB.Connection MyFirstOpenRecordset As New ADODB.Recordset MySecondOpenRecordset As New ADODB.Recordset ConnString As String SelectResultsCount As Integer

Connstring = “Provider=SQLNCLI; DataTypeCompatibility=80; Database=MyAppsDB;” & _ “Server=.\SQLEXPRESS; AttachDBFileName=c:\MyDBs\MyAppsDB.mdf;” & _ “MARS Connection=true; Integrated Security=SSPI;” MyConnection.ConnectionString = ConnString MyConnection.Open ‘ Using 2 open recordsets on one connection puts MARS to work: Set MyFirstOpenRecordset = MyConnection.Execute( “SELECT TOP 10 * FROM MyTable”, SelectResultsCount, adCmdText ) Set MySecondOpenRecordset = MyConnection.Execute(“SELECT TOP 10 * FROM MySecondTable”, _ SelectResultsCount, adCmdText) ‘ and so on...

10

Note the use of the AttachDBFileName connection string keyword, which instructs SQL Server 2008 to attach the specified Microsoft data file (MyAppsDB.mdf). Using the .NET Framework Data Provider for SQL Server .NET applications that use the System.Data.SqlClient namespace rely on the .NET Framework data provider and ADO.NET. To use this provider, you simply add the following statement to your C# code file: using System.Data.SqlClient;

Download from www.wowebook.com

284

CHAPTER 10

Client Installation and Configuration

For VB .NET, you use this: Imports System.Data.SqlClient

And for JScript .NET, you use this: import System.Data.SqlClient;

Note that the .NET provider supports a variety of connection string styles, including ODBC, OLE DB, and OLE DB/SNAC, and you can mix and match some of their respective connection string keywords. For example, Database and Initial Catalog mean the same thing to ADO.NET, and so do Server and Data Source. But don’t let this fool you: Under the covers, only the .NET provider is always in use. (This is probably why changing the value passed to the Provider keyword seems to have no noticeable effect.) Applications built on .NET Framework 1.0 and 1.1 can access SQL Server 2008 databases without issue. The only caveat is that those earlier versions of ADO.NET can’t make use of certain SQL Server 2008 features, such as asynchronous command execution, cache synchronization, bulk copy, and the new data types. (However, implicit conversions such as from varchar to xml and from UDTs to varbinary allow their use as T-SQL input from .NET Framework 1.1 applications.) ADO.NET 2.0 applications, however, have access to the full gamut of new functionality in SQL Server 2008. The following is an example of two connection strings (in different styles) that both turn on the MARS feature for ADO.NET 2.0 applications: The following is in ODBC style: Driver={SQL Native Client 10.0}; Database=AdventureWorks2008; Server=MyServer/SQL08; Encrypt=yes; Trusted_Connection=yes; MARS_Connection=yes

The following is in OLE DB style: Provider=SQLNCLI10; Database=AdventureWorks2008; Server=MyServer/SQL08; Encrypt=yes; Trusted_Connection=yes; MultipleActiveResultSets=true

Notice the use of the keywords MARS_Connection (MultipleActiveResultSets also works) and Encrypt (which requests connection encryption from the server). The SQLCLR Context Connection When you need to connect to SQL Server 2008 from within a managed stored procedure, function, or trigger (known as SQLCLR code), which is possible only with .NET 2.0 or greater, you use a special type of connection, known as a context connection. This feature prevents you from having to open a new connection because the code itself is already running within the context of an open connection. The connection string for context connections is extremely easy to use (”context connection=true”), as the C# example in Listing 10.1 illustrates.

Download from www.wowebook.com

Client Data Access Technologies

285

LISTING 10.1 Using the Context Connection from a Managed Stored Procedure using using using using

System; System.Data; System.Data.SqlClient; System.Data.SqlTypes;

using Microsoft.SqlServer.Server; public partial class StoredProcedures { [Microsoft.SqlServer.Server.SqlProcedure] public static void ContextConnectionTest() { using (SqlConnection Context = new SqlConnection(“context connection=true”)) { using (SqlCommand TestCommand = new SqlCommand(“SELECT TOP 10 * FROM Person.Person”, Context)) { using (SqlDataAdapter Adapter = new SqlDataAdapter(TestCommand)) { using (DataSet MyData = new DataSet()) { Adapter.Fill(MyData); } } } } } }

For more information on building SQLCLR client libraries, see Chapter 43, “SQLCLR: Developing SQL Server Objects in .NET”

10

Using MDAC MDAC contains the OLE DB provider for SQL Server (SQLOLEDB) and the ODBC driver for SQL Server. MDAC is officially part of the operating system, and, as mentioned earlier, MDAC and SNAC are distributed and developed on separate tracks: MDAC with the operating system and SNAC with SQL Server. They do interrelate, however, in that applications that use SNAC can make use of the core services provided by MDAC, including support for connection pooling, client-side cursors, ADO support, and memory management. As mentioned earlier, to make use of the latest SQL Server 2008 functionality, you need to use SNAC.

Download from www.wowebook.com

286

CHAPTER 10

Client Installation and Configuration

TIP If, at any time, you want to discover which version of MDAC is installed on a machine, you can simply check the value of the following Registry key (using regedit.exe or from code): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess\Version

Note also that the planned MDAC version 10.0 release has been killed and superseded by SNAC.

If you choose to upgrade from MDAC to SNAC, it’s important to note some key differences between the two that could affect your applications: . Return values from SQL Server 2008 to MDAC applications are implicitly type converted, as shown in Table 10.2.

TABLE 10.2 Implicit Type Conversions for SQL Server 2008 Data Types SQL Server 2008 Data Type

Converted to Data Type

varbinary(MAX)

Image

xml

ntext

nvarchar(MAX)

ntext

varchar(MAX)

text

UDTs

varbinary

. Warning and error messages and message handling differ between MDAC and SNAC. . SNAC requires that T-SQL parameters begin with the @ character; MDAC does not. . SNAC, unlike MDAC, is not compatible with Visual Studio Analyzer or PerfMon. For further details, see the Books Online topic “Updating an Application to SQL Native Client from MDAC.” Using ODBC with MDAC You can configure an ODBC connection by using a connection string or DSN that specifies the Microsoft ODBC driver for SQL Server. For connection strings, you use the keyword-value pair Provider={SQL Server}. To use a DSN, you run the Data Sources (ODBC) applet, as mentioned earlier. When choosing a driver, you select the one simply named SQL Server. Using OLE DB with MDAC You can access SQL Server 2008 databases by using the Microsoft OLE DB provider for SQL Server (SQLOLEDB). In connection strings or property values, you use the Provider keyword and the value SQLOLEDB.

Download from www.wowebook.com

Client Data Access Technologies

287

NOTE Unlike with SNAC’s OLE DB provider, with SQLOLEDB you can access both SQL Server data and data from non–SQL Server data sources. Also, SNAC is not dependent on any particular version of MDAC because it expects that a compatible MDAC version will be present on the operating system, as enforced by its own installation requirements. Using JDBC Microsoft released a freely downloadable, JDBC 4.0-compliant, Type 4 driver for use with SQL Server 2008. It can be used from all types of Java programs and servers via the J2EE connection API. The following is the basic syntax for a JDBC connection string: jdbc:sqlserver://ServerName\InstanceName:port;property=value[;property=value]

For complete details on using JDBC, check out Microsoft’s JDBC product documentation at http://msdn.microsoft.com/en-us/library/ee229547(v=SQL.10).aspx. You might also find the newsgroup microsoft.public.sqlserver.jdbcdriver helpful.

General Networking Considerations and Troubleshooting This section provides guidelines for solving some common connectivity issues. You can perform the following steps as a first line of defense when your connections fail: 1. Check whether the server is configured (via SSCM, as detailed earlier in this chapter, in the section “Server Network Protocols”) to accept remote connections. 2. Ensure that the SQL Browser service is started. 3. Determine whether clients are specifying the correct port (for using fixed ports with named instances) in the server alias or connection string. 4. Check whether the client’s network protocols are enabled and configured to correctly handshake with those of the server. They should use SSCM on both sides, as explained earlier in this chapter, in the section “Client Configuration Using SSCM.” 5. Be sure you have permission to connect on the server’s endpoints. 6. When using encryption, be sure the server and client certificates match (that is, check their Common Name (CN) and any other relevant attributes) and are installed and configured correctly on both sides. (See the section “Connection Encryption,” earlier in this chapter.)

10

7. Make certain that your firewalls are configured to permit the required network traffic. (See the following section, “Firewall Considerations.”) 8. Check to see whether your users have permission to log in to the server and access the specified database. 9. Make sure that your clients’ choices of providers support the SQL Server 2008 features they are trying to use. 10. Make sure the provider, driver, DSN, server alias, or other connection mechanism is still valid and hasn’t been altered or removed from the system.

Download from www.wowebook.com

288

CHAPTER 10

Client Installation and Configuration

11. Network administrators are no longer added to the SQL Server sysadmin role by default. If the user trying to connect is a network administrator, he or she must be granted explicit permission with SQL Server 2008. See the topic named “Database Engine Configuration - Account Provisioning” in Books Online for more information. Firewall Considerations For clients to successfully connect through a firewall, it must be configured to allow the following: . Bidirectional traffic on UDP Port 1434—This is required only for communications to and from the SQL Browser service; when SQL Browser is not in use, you can close this port. . Bidirectional traffic on any TCP port used by SQL Server—Be sure to open port 1433 for default instances and also open any fixed ports assigned to your named or default instances. (TCP high port numbers must be opened only when dynamic ports are used by named instances. Using dynamic port numbers for named instances is not recommended.) You can determine the ports currently in use via SSCM. When using Windows Firewall, you can easily open these ports. To do this, you run Windows Firewall from the Control Panel, and on the main screen that appears, you click the Exceptions tab. Then you click the Add Port button and enter the required names (either SQL Server or SQL Browser, for example) and port numbers, one at a time, on the Add a Port screen that appears (see Figure 10.10).

FIGURE 10.10 Creating port exceptions for SQL Server 2008, using Windows Firewall. Tools for Testing Connections It’s always helpful to have a few tools on your belt for testing client connectivity. SSCM is a tool that is usually easily accessible, and you can use its Connect to Server dialog to select a protocol to test (as described earlier in this chapter, in the section “Client Data Access Technologies”). You can also use SQLCMD with the -S parameter to connect to a particular server. This is the syntax: SQLCMD -Sprotocol_prefix:ServerName,PortNumber -E

Download from www.wowebook.com

Summary

289

In this syntax, protocol_prefix takes one of the following values: . np (for named pipes) . tcp (for TCP/IP) . lpc (for shared memory) . via (for VIA) In the following example, -E indicates the use of a trusted connection: SQLCMD –Stcp:.\SQL08,1435 -E

When all else fails, you can use telnet to test the openness of a port on the firewall. Here’s an example: telnet IP_Address Port_Number

Summary This chapter covers a lot of ground regarding client-side (and even a bit of server-side) communication with SQL Server 2008. Some of the sections are admittedly dense enough to bear rereading, and you probably have questions about your specific setup. You can always refer to the sections presented in this chapter to pick up tips on how to best configure and troubleshoot the varying environments you may encounter. And you can (and should) use the extremely helpful Usenet groups that are devoted to the subject (for example, microsoft.public.sqlserver.clients or microsoft.public.sqlserver.programming). Now that your client configuration is complete, you can move on to Chapter 11, “Security and User Administration,” to learn how to securely administer the Database Engine.

10 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

11

Security and User Administration

IN THIS CHAPTER . What’s New in Security and User Administration . An Overview of SQL Server Security . Authentication Methods . Managing Principals

Securing your database environment and providing the right type of access to your users are critical administrative tasks. This chapter examines the security features in SQL Server 2008 that relate to user administration and the objects that users can access.

. Managing Securables . Managing Permissions . Managing SQL Server Logins . Managing SQL Server Users . Managing Database Roles

What’s New in Security and User Administration

. Managing SQL Server Permissions . The Execution Context

Several new security enhancements have been added to SQL Server 2008 to help make it more secure than any prior version. These enhancements build upon the myriad of security-related changes made in SQL Server 2005 and follow the policy of “least privileges” that Microsoft has been pushing. Several of these new changes follow: . BUILTIN\Administrators—This local Windows group is no longer included in the SQL Server sysadmin fixed server role. In prior versions, the BUILTIN\Administrators account was part of this role, which meant that network administrators could access the SQL Server instance even though they were not given explicit permission. You still have the option of manually adding this group to the sysadmin role, but it is not installed this way by default. . Surface Area Configuration (SAC)—This GUI tool, which was introduced in SQL Server 2005, has been removed in SQL Server 2008. It was used to enable or disable SQL Server features and options, but it has been replaced in part by the new Policy-Based

Download from www.wowebook.com

292

CHAPTER 11

Security and User Administration

Management feature and in part by an enhanced SQL Server Configuration Manager. Right-click on the server instance in Object Explorer and choose Facets. You get a quick look at the number of settings available via facets that are part of Policy-Based Management. If you select Server Configuration from the drop-down, you see features such as CLR Integration (that is, CLRIntegrationEnabled) that you could have set in the past with the Surface Area Configuration tool. . Local Groups Removed from sysadmin—Several local network groups that were added to the sysadmin server role in past versions are no longer added to this role. These accounts include SQLServerMSSQLUser$ COMPUTERNAME $ INSTANCENAME and SQLServerSQLAgentUser$ COMPUTERNAME $ INSTANCENAME. Only the SQL Server Service and SQL Server Agent Service accounts are added to the sysadmin role.

An Overview of SQL Server Security The SQL Server 2008 security model is the best place to start to understand SQL Server security. The model is based on three categories that separate the basic elements of security: . Principals—Principals are the entities that request security to SQL Server resources. They include Windows users, SQL Server users, and database users. . Securables—Securables are the SQL Server resources to which permissions can be granted. . Permissions—Permissions link principals with securables. Table 11.1 shows the security components contained in each tier of the SQL Server 2008 security model. The columns are ordered from left to right, based on the way security is established.

TABLE 11.1 SQL Server 2008 Security Components Principals

Permissions

Securables

Windows:

GRANT/REVOKE/DENY

Server Scope

Groups

CREATE

Login

Domain Login

ALTER

Endpoint

Local Login

DROP

Database

SQL Server:

CONTROL

Database Scope

SQL Login

CONNECT

User

Server Role

SELECT

Role

Download from www.wowebook.com

An Overview of SQL Server Security

293

TABLE 11.1 SQL Server 2008 Security Components

Database:

Permissions

Securables

11

Principals

EXECUTE

Application role

User

UPDATE

Assembly

Database Role

DELETE

Message Type

Application Role

INSERT

Route

REFERENCES

Service

RECEIVE

Remote Service Binding

VIEW DEFINITION

Fulltext Catalog

TAKE OWNERSHIP

Certificate

CONTROL

Asymmetric Key

VIEW CHANGE TRACKING

Symmetric Key Contract Schema Schema Scope Table View Function Procedure Queue Type Synonym Aggregate XML Schema Collection

The implementation of the security model is relatively straightforward: you choose the principal from Column 1, the desired permission from Column 2, and the securable to assign the permission from Column 3. For example, a SQL LOGIN (the principal) needs to CREATE (the permission) databases (the securable). Together, these three elements represent a complete security assignment.

Download from www.wowebook.com

294

CHAPTER 11

Security and User Administration

Some complexity has been introduced, based on the hierarchical nature of some of the security components. Security can be established on these hierarchical components, which in turn cascades the security to the underlying components. In addition, not all the permission components apply to every securable. Many of the securables have a select number of permissions that apply to them; conversely, many permissions apply only to a select number of securables. For example, SELECT permission is applicable to securables such as tables and views but would not be appropriate for stored procedures. The following sections discuss the tiers of the security model and their underlying components.

Authentication Methods The first level of security encountered when accessing SQL Server is known as authentication. The authentication process performs the validation needed to allow a user or client machine to connect to SQL Server. This connection can be granted via a Windows login or SQL Server login.

Windows Authentication Mode Windows Authentication mode validates the account name and password, using information stored in the Windows operating system. A Windows account or group must be established first, and then security can be established for that account in SQL Server. This mode has the advantage of providing a single login account and the capability to leverage domain security features, such as password length and expiration, account locking, encryption, and auditing. Microsoft recommends this approach.

Mixed Authentication Mode Mixed authentication allows for both Windows authentication and SQL Server authentication. SQL Server authentication is based on a login that is created in SQL Server and lives in SQL Server only. No Windows account is involved with SQL Server authentication. The account and password are established and maintained in SQL Server. SQL Server logins can be created with stronger password enforcement that help better protect the login. This topic is discussed in more detail in the section “Managing SQL Server Logins,” later in this chapter. SQL Server authentication is useful in environments in which a Windows domain controller does not control network access. It can also be useful for Web applications or legacy applications, where it may be cumbersome to establish a Windows user account for every connection to the database server.

Download from www.wowebook.com

Managing Principals

295

Setting the Authentication Mode 11

You can select the authentication mode when you install SQL Server, and you can change it after the installation. To change the authentication mode after installation, you rightclick the server node in the Object Explorer and choose the Properties option. When the Server Properties dialog appears, you select the Security page (see Figure 11.1). The Security page allows you to specify Windows Authentication mode or SQL Server and Windows Authentication mode (that is, mixed authentication). Any changes to the authentication mode require a restart of SQL Server to make the change effective.

FIGURE 11.1 Changing the authentication mode.

Managing Principals Principals are the entities that can request permission to SQL Server resources. They are made up of groups, individuals, or processes. Each principal has its own unique identifier on the server and is scoped at the Windows, server, or database level. The principals at the Windows level are Windows users or groups. The principals at the SQL Server level include SQL Server logins and server roles. The principals scoped at the database level include database users, data roles, and application roles.

Download from www.wowebook.com

296

CHAPTER 11

Security and User Administration

Logins Every principal granted security to SQL Server must have an associated login. The login provides access to SQL Server and can be associated with principals scoped at the Windows and server levels. These logins can be associated with Windows accounts, Windows groups, or SQL Server logins. Logins are stored in the master database and can be granted permission to resources scoped at the server level. Logins provide the initial permission needed to access a SQL Server instance and allow you to grant access to the related databases. Permissions to specific database resources must be granted via a database user. The important point to remember is that logins and users are directly related to each other but are different entities. It is possible to create a new login without creating an associated database user, but a new database user must have an associated login. To better understand logins, you can look at the sys.server_principals catalog view. This view contains a row for every server-level principal, including each server login. The following example selects from this view and displays the results: select left(name,25) name, type, type_desc from sys.server_principals AS log WHERE (log.type in (‘U’, ‘G’, ‘S’, ‘R’)) order by 3,1 /*Results from previous query name type ------------------------- ---bulkadmin R dbcreator R diskadmin R processadmin R public R securityadmin R serveradmin R setupadmin R sysadmin R sa S DBSVRXP\LocalUser1 U HOME\Administrator U NT AUTHORITY\SYSTEM U */

type_desc -----------SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SERVER_ROLE SQL_LOGIN WINDOWS_LOGIN WINDOWS_LOGIN WINDOWS_LOGIN

The results from the sys.server_principals selection include the name of the server principal as well as the type of principal. The rows that have a type_desc value of SQL_LOGIN, WINDOWS_GROUP, or WINDOWS_LOGIN are all logins established on the SQL Server instance. A login with a type_desc of SQL_LOGIN represents a login created with SQL Server authentication. Logins with a type_desc of WINDOWS_GROUP or WINDOWS_LOGIN are

Download from www.wowebook.com

Managing Principals

297

Windows groups or individual Windows users granted logins to SQL Server. The other entries with type_desc of SERVER_ROLE are fixed server roles discussed later in this chapter.

11

The logins established for Windows logins or groups can be part of the local domain of the SQL Server machine, or they can be part of another domain. In the previous example, DBSVRXP\LocalUser1 is a login established for a local user on a database server named DBSVRXP. The HOME\Administrator login is also a Windows login, but it is part of a network domain named HOME. Both logins are preceded by the domain that they are part of and are displayed this way in SQL Server.

NOTE In SQL Server 2000, logins were stored in the syslogins system table in the master database. The syslogins table is still available for selection as a view, but it is available only for backward compatibility. The catalog views (including sys.server_principals) are recommended for use instead.

You might have noticed in the earlier sys.server_principals output that two other logins are listed that we have not discussed yet. These logins (SA and NT AUTHORITY\SYSTEM) are system accounts installed by default at installation time. Each of these accounts serves a special purpose in SQL Server. The SA account is a SQL_LOGIN assigned to the sysadmin fixed server role. The SA account and members of the sysadmin fixed server role have permission to perform any activity within SQL Server. The SA account cannot be removed, and it can always be used to gain access to SQL Server. The SA account should always have a strong password to prevent malicious attacks, and it should be used only by database administrators. Users or logins requiring full administrative privileges can be assigned a separate SQL Server login that is assigned to the sysadmin fixed server role. This improves the audit trail and limits the amount of use on the SA account. The NT AUTHORITY\SYSTEM login is an account related to the local system account under which SQL Server services can run. It is also added as a member of the sysadmin fixed server role and has full administrative privileges in SQL Server. This account can also be removed if the SQL Server services are not running with the local system account. This should be done with caution, however, because it can affect applications such as Reporting Services. One other special account was not listed, but it would have been in SQL Server 2005. The BUILTIN\Administrators login is a Windows group that corresponds to the local administrators group for the machine that SQL Server is running on. The BUILTIN\Administrators group is no longer added by default as a SQL Server login during installation. In SQL Server 2005, it was also added as a member of the sysadmin fixed server role, but this is no longer the case. This change improves the security of SQL Server out of the box by limiting the number of people that have access (by default) to the SQL Server instance.

Download from www.wowebook.com

298

CHAPTER 11

Security and User Administration

NOTE The BUILTIN\Administrators group can be manually added in SQL Server 2008 if desired. This allows domain administrators and anyone else who has been added to the local administrators group to have sysadmin privileges. Adding this group is not recommended but can be done if you want to set network privileges that are similar to past versions of SQL Server.

SQL Server Security: Users Database users are principals scoped at the database level. Database users establish a link between logins (which are stored at the server level) and users (which are stored at the database level). Database users are required to use the database and are also required to access any object stored in the database. Generally, the login name and database username are the same, but this is not a requirement. If desired, you could add a login named Chris and assign it to a user named Kayla. This type of naming convention would obviously cause some confusion and is not recommended, but SQL Server has the flexibility to allow you to do it. In addition, a user can be associated with a single person or a group of people. This capability is tied to the fact that a login can be related to a single account or group. For example, a login named training could be created and tied to a Windows group (that is, domain\training) that contains all the training personnel. This login could then be tied to a single database user. That single database user would control database access for all the users in the Windows group.

TIP The relationship between logins and users can be broken when databases are moved or copied between servers. The reason is that a database user contains a reference to the associated login. Logins are referenced based on a unique identifier called a security identifier (SID). When a database is copied from one server to another, the users in that database contain references to logins that may not exist on the destination server or that may have different SIDs. You can use the sp_change_users_login system stored procedure to identify and fix these situations. You can run the following command against a newly restored or attached database to check for orphaned users: EXEC sp_change_users_login ‘Report’

If orphaned users are shown in the results, you can rerun the procedure and fix the problems. For example, if the results indicate that a user named Chris is orphaned, you can run the following command to add a new login named Chris and tie the orphaned database user to this newly created login: EXEC sp_change_users_login ‘Auto_Fix’, ‘Chris’, NULL, ‘pw’

Refer to SQL Server Books Online for full documentation on the sp_change_users_login system stored procedure.

Download from www.wowebook.com

Managing Principals

299

11

You can use the sys.database_principals catalog view to list all the users in a given database. The following example shows a SELECT statement using this view and the results from the SELECT: SELECT left(u.name,25) AS [Name], type, left(type_desc,15) as type_desc FROM sys.database_principals AS u WHERE (u.type in (‘U’, ‘S’, ‘G’)) ORDER BY 1 /*Results from previous query Name type ------------------------- ---dbo S DBSVRXP\LocalUser1 U guest S INFORMATION_SCHEMA S sys S */

type_desc --------------SQL_USER WINDOWS_USER SQL_USER SQL_USER SQL_USER

The SELECT statement in this example returns five rows (that is, five users). This SELECT was run against the AdventureWorks2008 database, and the only user explicitly added to the database was the Windows user DBSVRXP\LocalUser1. The other users are special users who are added by default to each database. These users do not have corresponding server logins named the same. These users are discussed in the following sections. The dbo User The dbo user is the database owner and cannot be deleted from the database. Members of the sysadmin server role are mapped to the dbo user in each database, which allows them to administer all databases. Objects owned by dbo that are part of the dbo schema can be referenced by the object name alone. When an object is referenced without a schema name, SQL Server first looks for the object in the default schema for the user that is connected. If the object is not in the user’s default schema, the object is retrieved from the dbo schema. Users can have a default schema that is set to dbo. Schemas and their relationship to users are discussed in more detail in the section “User/Schema Separation,” later in this chapter. The guest User The guest user is created by default in each database when the database is created. This account allows users that do not have a user account in the database to access the database. By default, the guest user does not have permission to connect to the database. To allow logins without a specific user account to connect to the database, you need to grant

Download from www.wowebook.com

300

CHAPTER 11

Security and User Administration

CONNECT permission to the guest account. You can run the following command in the target database to grant the CONNECT permission: GRANT CONNECT TO GUEST

When the guest account is granted CONNECT permission, any login can use the database. This opens a possible security hole. The default permissions for the guest account are limited by design. You can change the permissions for the guest account, and all logins that use it will be granted those permissions. Generally, you should create new database users and grant permissions to these users instead of using the guest account. If you want to lock down the guest account, you can. You cannot drop the guest user, but you can disable it by revoking its CONNECT permission. The following example demonstrates how to revoke the CONNECT permission for the guest user: REVOKE CONNECT FROM guest

If you decide to grant additional access to the guest account, you should do so with caution. The guest account can be used as a means for attacking your database. The INFORMATION_SCHEMA User The INFORMATION_SCHEMA user owns all the information schema views installed in each database. These views provide an internal view of the SQL Server metadata that is independent of the underlying system tables. Some examples of these views include INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.CHECK_CONSTRAINTS. The INFORMATION_SCHEMA user cannot be dropped from the database. The sys User The sys account gives users access to system objects such as system tables, system views, extended stored procedures, and other objects that are part of the system catalog. The sys user owns these objects. Like the INFORMATION_SCHEMA user, it cannot be dropped from the database.

TIP If you are interested in viewing the specific objects owned by any of the special users discussed in these sections, you can use a SELECT statement like the following: --Find all objects owned by a given user SELECT name, object_id, schema_id, type_desc FROM sys.all_objects WHERE OBJECTPROPERTYEX(object_id, N’OwnerId’) = USER_ID(N’sys’) ORDER BY 1

The SELECT in this example shows all the objects owned by the sys user. To change the user, you simply change the parameter of the USER_ID function in the SELECT statement from ’sys’ to whatever user you want.

Download from www.wowebook.com

Managing Principals

301

User/Schema Separation 11

The changes to schema security introduced in SQL Server 2005 have been carried forward to SQL Server 2008. Versions of SQL Server before SQL Server 2005 had schemas, but they did not conform to the American National Standards Institute (ANSI) definition of schemas. ANSI defines a schema as a collection of database objects that one user owns and that forms a single namespace. A single namespace is one in which each object name is unique and there are no duplicates. So, for example, if you have two tables named customer, they cannot exist in the same namespace. To fully understand the user/schema changes in SQL Server 2008, you need to understand how schemas were used in prior versions of SQL Server. In SQL Server 7.0 and 2000, a default schema was created for each user, and it had the same name as the user. For example, if you created a new user named Rachael, a corresponding schema named Rachael would be created as well. There was no option in those releases to change the default schema for a user, and each user was forever bound to a schema with the same name. When the user created new objects, the objects were created by default in that user’s schema, which is always the name of the user. So, if Rachael created an object named customer, it was placed in the Rachael schema, and the object was owned by Rachael. When Rachael wanted to reference the object, she could use a three-part name with the format database.owner.object. If a linked server was used, according to the SQL Server 2000 documentation, the object in the linked server could be referenced with the four-part name linked_server.catalog.schema.object. (for example myserver.AdventureWorks2008.Rachael.Customer). You can see that the schema name is used prior to the object name when the object is outside the local server. The bottom line is that the schema and owner were basically the same thing in SQL Server 7.0 and 2000. With SQL Server 2005 and SQL Server 2008, the owner and schema have been separated. This is made possible in part by allowing a database user to have a default schema different from the name of the user. For example, our sample user Rachael could be assigned the default schema Sales. When Rachael creates objects in the database, her objects are created, by default, in the Sales schema. If Rachael wants to reference an object that she created, she can reference the table in a number of different ways. She can use the full four-part name (server.database.schema.object) that includes the Sales schema name to reference the object via a linked server. She can simply refer to the object with the object name alone, and the Sales schema will be searched first for the object. She can also use a three-part name or a two part name. If the object name is not found in the Sales schema,

Download from www.wowebook.com

302

CHAPTER 11

Security and User Administration

the dbo schema will be searched. This concept is illustrated in the following sample SELECT statements that all retrieve the same rows from the Region table that was created by Rachael in the Adventureworks2008 database. select * from region select * from sales.region select * from AdventureWorks2008.Sales.Region

The important point to remember is that owners and schemas are different from one another in SQL Server 2008. For example, you can have a customer table created in the Sales schema, and that table can be owned by a user named Chris. The object should be referenced with the schema name qualifier, such as Sales.Customer, not Chris.Customer. This has the distinct advantage of allowing object ownership to change without affecting the code that references the object. The reason is that database code that references an object uses the schema name instead of the object owner. The schema enhancements in SQL Server 2008 go well beyond the user/schema separation. Schemas are an integral part of all the database objects that exist in SQL Server. As we delve into more details about SQL Server security and the assignment of permissions, you will see that schemas play a very important part.

Roles Roles provide a consistent yet flexible model for security administration. Roles are similar to the groups used in administering networks. Permissions are applied to a role, and then members are added to the role. Any member of the role has all the permissions that the role has. The use of roles simplifies the administrative work related to security. Roles can be created based on job function, application, or any other logical group of users. With roles, you do not have to apply security to each individual user. Any required changes to permissions for the role can be made to the role security, and the members of the role receive those changes. SQL Server has the following three types of roles: . Fixed server and fixed database roles—These roles are installed by default and have a predefined set of permissions. . User-defined roles—These roles are created in each database, with a custom set of permissions for each set of users assigned to it. . Application roles—These special roles can be used to manage database access for an application. These roles are discussed in the following sections.

Download from www.wowebook.com

Managing Principals

303

11

Fixed Server Roles Fixed server roles are scoped at the server level, which means that the permissions for these roles are oriented toward server-level securables. These roles contain a variety of fixed permissions geared toward common administrative tasks. Logins (not users) are assigned to these roles. The same fixed server roles available in SQL Server 2000 and SQL Server 2005 are also available in SQL Server 2008. There is, however, one new role named public that has been added. Server principals, by default, are granted the permissions that have been granted to the public role. There are a limited number of permissions that are initially granted to the public role, but you can change the permissions if you like. A complete list of all the fixed server roles and their related permissions is shown in Table 11.2.

TABLE 11.2 Fixed Server Roles Role

Permission

bulkadmin

Allowed to run the BULK INSERT statement.

dbcreator

Allowed to use CREATE, ALTER, DROP, and RESTORE on any database.

diskadmin

Allowed to manage disk files that are used by SQL Server.

processadmin

Allowed to terminate SQL Server processes.

public

Assigned to all logins. Permissions granted to this role are assigned to every login by default.

securityadmin

Allowed to use GRANT, DENY, and REVOKE permissions for logins at the server and database levels. Members of this role can reset passwords for SQL Server logins.

serveradmin

Allowed to change server-wide configuration properties and shut down the server, if needed.

setupadmin

Allowed to add and remove linked servers and execute some system stored procedures.

sysadmin

Allowed to perform any activity in the server.

A single login can be assigned to one or more of these fixed server roles. When multiple roles are assigned, the combination of all the permissions is allocated to the login.

Download from www.wowebook.com

304

CHAPTER 11

Security and User Administration

NOTE Keep in mind that when a login is assigned to certain fixed server roles, they have implied permissions that cascade to the database level. For example, if a login is assigned to the sysadmin role, that login can perform any activity on the server, and it can also perform any action on any database on that server. Similarly, if a login is added to the securityadmin role, the login can change permissions at the database level as well as the server level.

All the fixed server roles are listed in the SQL Server Management Studio (SSMS) Object Explorer. Figure 11.2 shows the Object Explorer with the Server Roles node expanded. You can right-click any of the roles and select Properties to display the logins that are currently members of the role.

FIGURE 11.2 Fixed server roles in Object Explorer.

Fixed Database Roles SQL Server provides fixed roles that define a common set of permissions at the database level. These fixed database roles are assigned to database users. The permissions defined for the fixed database roles cannot be changed. Table 11.3 shows the fixed database roles and their permissions.

Download from www.wowebook.com

Managing Principals

305

TABLE 11.3 Fixed Database Roles Permission

db_accessadmin

Allowed to add or remove database access for logins.

11

Role

db_backupoperator Allowed to back up the database. db_datareader

Allowed to read all user table data.

db_datawriter

Allowed to change the data in all user tables.

db_ddladmin

Allowed to run any Data Definition Language (DDL) command against the database. This includes commands to create, alter, and drop database objects.

db_denydatareader Denied the right to read all user table data. db_denydatawriter Denied the right to change the data in any of the user tables. db_owner

Allowed to perform any action on the database. Members of the sysadmin fixed server role are mapped to this database role.

db_securityadmin

Allowed to manage permissions for database users, including membership in roles.

dbm_monitor

Allowed to view the most recent status in the Database Mirroring Monitor.

NOTE You can find a more granular breakdown of permissions associated with fixed database roles in the SQL Server Books Online documentation. Look for the subject “Permissions of Fixed Database Roles.” The extensive table in this documentation defines the specific permissions for each role. For example, the table shows that the db_backupoperator role is granted the BACKUP DATABASE, BACKUP LOG, and CHECKPOINT permissions. This gives you more insight into what the members of this role can do. Some fixed database roles have a large number of permission defined for them, such as db_ddladmin, which has more than 30 individual permissions. The types of permissions and improved granularity available with SQL Server 2008 are discussed in the “Managing Permissions” section, later in this chapter.

You can also find a list of fixed database roles in the Object Explorer. Figure 11.3 shows the fixed database roles for the AdventureWorks2008 database. The roles are found under the Security node within each database. You can right-click a fixed database role and select Properties to view the member users.

Download from www.wowebook.com

306

CHAPTER 11

Security and User Administration

FIGURE 11.3 The fixed database roles in Object Explorer. Fixed database roles and schemas are related. Figure 11.3 shows the expanded Schemas node for the AdventureWorks2008 database. You can see that there is a corresponding schema for each of the fixed database roles. These schemas are automatically created, and each is owned by the related database role. The public Role The public role is a special database role that is like a fixed database role except that its permissions are not fixed. The permissions for this role can be altered. Every user in a database is automatically made a member of the public role and in turn receives any permissions that have been granted to the public role. Database users cannot be removed from the public role. The public role is similar in function to the guest user that is installed by default in each database. The difference is that the permissions granted to the guest user are used by any login that does not have a user account in the database. In this case, the login is allowed to enter the database via the guest account. In the case of the public role, the login has been added as a user of the database and in turn picks up any permissions that have been granted to the public role. To view the permissions associated with the public role, you can use a SELECT statement like the following: SELECT top 5 g.name, object_name(major_id) as ‘Object’,

Download from www.wowebook.com

Managing Principals

307

11

permission_name from sys.database_permissions p join sys.database_principals g on p.grantee_principal_id = g.principal_id and g.name = ‘public’ order by 1,2 /*Results from the previous select name Object permission_name ------ -------------- --------------public all_columns SELECT public all_objects SELECT public all_parameters SELECT public all_sql_modules SELECT public all_views SELECT */

This SELECT utilizes two catalog views that contain security information. The SELECT returns only the first five permissions for the public role, but the TOP clause can be removed to return all the permissions. User-Defined Roles SQL Server enables you to create your own custom database roles. Like the fixed roles, user-defined roles can be used to provide a common set of permissions to a group of users. The key benefit behind using user-defined roles is that you can define your own set of custom permissions that fit your needs. User-defined roles can have a broad range of permissions, including the more granular set of permissions made available with SQL Server 2008. To demonstrate the power of a user-defined database role, let’s look at a simple example. Let’s say that you have a group of users who need to read all the tables in a database but should be granted access to update only one table. If you look to the fixed database roles, you have the db_datareader and db_datawriter roles, which give you a partial solution. You can use the db_datareader role to allow the read capability you need, but the db_datawriter role gives write permission to all the tables—not just one. One possible solution would be to give every user in the group membership to the db_datareader group and assign the specific UPDATE permission to each user as well. If the group contains hundreds of users, you can see that this would be rather tedious. Another solution might be to create a Windows group that contains every user who needs the permissions. You can then assign a login and database user to this group and grant the appropriate permissions. The Windows group is a viable solution but can sometimes be difficult to implement in a complex Windows domain. Another approach to this challenge is to use a user-defined database role. You can create the role in the database that contains the tables in question. After you create the role, you can include it in the db_datareader role, and you can establish the UPDATE permission to the single table. Finally, you can assign the individual users or group of users to

Download from www.wowebook.com

308

CHAPTER 11

Security and User Administration

the role. Any future permission changes for this set of users can be administered through the user-defined database role. The script in Listing 11.1 steps through a process that demonstrates and tests the addition of a database role. This is similar to the example we just walked through. Parts of the script need to be run by an administrator, and other parts should be run in a query editor window that is connected to the database with the newly created testuser.

LISTING 11.1 An Example of User-Defined Database Roles --The following statements must be run by an administrator to add --a login and database user with no explicit permissions granted CREATE LOGIN [TestUser] WITH PASSWORD=N’pw’, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF GO GO USE [AdventureWorks2008] GO CREATE USER [TestUser] FOR LOGIN [TestUser] go --the following statement fails when executed by the TestUser --which has no explicit permissions defined in the AdventureWorks2008 database select top 5 * from person.person UPDATE person.person SET suffix = ‘Jr.’ WHERE FirstName = ‘Ken’ --The following statement is run by an administrator to: --1)add a new TestDbRole with permission to UPDATE --2)grant UPDATE permission on the Person.person table --3)add the TestUser to the TestDbRole database role USE [AdventureWorks2008] GO --1) CREATE ROLE [TestDbRole] AUTHORIZATION [dbo] --2) GRANT UPDATE ON [Person].[Person] TO [TestDbRole] GRANT SELECT ON [Person].[Person] TO [TestDbRole] --3) EXEC sp_addrolemember N’TestDbRole’, N’TestUser’ --the following statements now succeed when executed --by the TestUser because the role that it --was added to has SELECT and UPDATE permission --on that table select top 5 * from person.person UPDATE person.person SET suffix = ‘Jr.’ WHERE ContactID = 1

Download from www.wowebook.com

Managing Securables

309

11

--the following select fails because ‘testdbrole’ --does not permit SELECT on any table but person.person select * from person.ContactType --The following statement is run by an administrator --to add the TestDbRole database role to the db_datareader --fixed-database role EXEC sp_addrolemember N’db_datareader’, N’TestDbRole’ GO --Finally, the testuser can update the Person.person table -- and select from any other table in the database select * from person.ContactType

Database roles and permissions are discussed in more detail later in this chapter, in the sections “Managing Database Roles” and “Managing Permissions.” Application Roles Unlike other roles, application roles contain no database users. When an application role is created (see the section “Managing Database Roles,” later in this chapter), rather than add a list of users who belong to the role, you specify a password. To obtain the permissions associated with the role, the connection must set the role and supply the password. This is done using the stored procedure sp_setapprole. You set the role to the sales application role (with the password PassW0rd) as follows: EXEC sp_setapprole ‘sales’, ‘PassW0rd’

You can also encrypt the password: EXEC sp_setapprole ‘sales’, {ENCRYPT N ‘ PassW0rd’}, ‘odbc’

When an application role is set, all permissions from that role apply, and all permissions inherited from roles other than public are suspended until the session is ended. So why is it called an application role? The answer is in how it is used. An application role is used to provide permissions on objects through an application, and only through the application. Remember that you must use sp_setapprole and provide a password to activate the role; this statement and password are not given to the users; rather, they are embedded in the application’s CONNECT string. This means that the user can get the permissions associated with the role only when running the application. The application can have checks and balances written into it to ensure that the permissions are being used for the forces of good and not evil.

Managing Securables Securables are the entities in SQL Server on which permissions can be granted. In other words, principals (for example, users or logins) obtain permission to securables. This chapter describes many examples of securables, including tables, databases, and many

Download from www.wowebook.com

310

CHAPTER 11

Security and User Administration

entities that have been part of the SQL Server security model in past versions. SQL Server 2008’s security model contains a granular set of securables for applying permissions. Securables are hierarchical in nature and are broken down into nested hierarchies of named scopes. Three scopes are defined: at the server, database, and schema levels. Table 11.4 list the securables for each scope.

TABLE 11.4 SQL Server 2008 Securables Server

Database

Schema

Logins

User

Table

Endpoints

Role

View

Databases

Application role

Function

Assembly

Procedure

Message Type

Queue

Route

Type

Service

Synonym

Remote Service Binding

Aggregate

Fulltext Catalog

XML Schema Collection Certificate

Asymmetric Key Symmetric Key Contract Schema

As mentioned earlier, a hierarchy exists within each scope; in addition, relationships cross scope boundaries. Servers contain databases, databases contain schemas, and schemas contain a myriad of objects that are also hierarchical. When certain permissions are granted on a securable at the server level the permissions cascade; meaning permission is granted at the database and schema levels. For example, if a login is granted control permission at the server level, control is implicitly granted at the database and schema levels. The relationships between securables and permissions can be complicated. The next section details the different types of permissions and sheds some light on how these permissions affect securables.

Download from www.wowebook.com

Managing Permissions

311

Managing Permissions 11

Database security is mainly about managing permissions. Permissions are the security mechanisms that tie principals (for example, logins) to securables (for example, tables). With SQL Server 2008, permissions can be applied at a granular level that provides a great deal of flexibility and control. Permissions in SQL Server 2008 revolve around three commands: GRANT, REVOKE, and DENY. These three commands were also used in SQL Server 2005 and SQL Server 2000. When permission is granted, the user or role is given permission to perform an action, such as creating a table. The DENY statement denies permission on an object and prevents the principal from gaining GRANT permission based on membership in a group or role. The REVOKE statement removes a permission that was previously granted or denied. When specifying permissions, you need to carefully consider the hierarchy that exists between GRANT, REVOKE, and DENY. This is particularly important when the principal (for example, user or login) is part of a group or role and permissions have been granted on securables at different scopes of the security model. Following are some examples of the precedence that exists between these statements: . A GRANT of a permission removes any REVOKE or DENY on a securable. For example, if a table has SELECT permission denied on it and then the SELECT permission is granted, the DENY permission is then removed on that table. . DENY and REVOKE remove any GRANT permission on a securable. . REVOKE removes any GRANT or DENY permission on a securable. . Permissions denied at a higher scope in the security model override grants on that permission at a lower scope. Keep in mind that the security model has the server scope at the highest level, followed by database and schema. So, if INSERT permission is denied on tables at the database level, and INSERT on a specific table in that database is granted at the schema level, the result is that INSERT is denied on all tables. In this example, a database-level DENY overrides any GRANT at the lower schema level. . Permissions granted at a higher scope in the security model are overridden by a DENY permission at a lower level. For example, if INSERT permission is granted on all tables at the database scope, and INSERT is denied on a specific table in the database (schema scope), INSERT is then denied on that specific table. The assignment of a permission includes the GRANT, DENY, or REVOKE statements plus the permission that these statements affect. The number of available permissions increased in SQL Server 2005 and has been carried forward to SQL Server 2008. Familiar permissions such as EXECUTE, INSERT, and SELECT that were available in SQL Server 2000 are still around, plus the new permissions that were added in SQL Server 2005. Following are some of the new types that were added in SQL Server 2005:

Download from www.wowebook.com

312

CHAPTER 11

Security and User Administration

. CONTROL—This type confers all defined permissions on the securable. This ownership-like capability also cascades to any lower-level objects in the security hierarchy. . ALTER—This type confers the capability to change the securable’s properties but does not include the capability to make ownership changes. If ALTER is applied on a scope such as a database or a schema, the capability to use ALTER, CREATE, or DROP on any object in the scope is allocated as well. . IMPERSONATE—This type allows the principal to impersonate another user or login. . VIEW DEFINITION—This type allows access to SQL Server metadata. This type of data is not granted by default in SQL Server 2008; therefore, the VIEW DEFINITION permission was added to manage access. The combination of available permissions and the securables that they can be applied to is extensive. The permissions that are applicable depend on the particular securable. SQL Server Books Online lists the permissions for specific securables. You can use the index feature at Books Online to look for “permissions [SQL Server].” There, you will find a section named “Permissions Applicable to Specific Securables” as well as a section named “SQL Server Permissions” that lists each securable and its related permissions. You can also view the available permissions by using system functions and catalog views. The following example uses the sys.fn_builtin_permissions function to retrieve a partial listing of all the available permissions: SELECT top 5 class_desc, permission_name, parent_class_desc FROM sys.fn_builtin_permissions(default) order by 1,2 /* Results from previous query class_desc permission_name parent_class_desc ------------------------------ ----------------APPLICATION ROLE ALTER DATABASE APPLICATION ROLE CONTROL DATABASE APPLICATION ROLE VIEW DEFINITION DATABASE ASSEMBLY ALTER DATABASE ASSEMBLY CONTROL DATABASE */

The granularity with which permissions can be applied with SQL Server 2008 is impressive and, to some degree, challenging. When you look at all the available permissions, you will see that some planning is needed to manage them. In the past, fixed database roles were simple to use but in many cases provided permissions that went beyond what the user needed. Microsoft has supplied the tools to facilitate the concept of “least privileges,” which means providing only the privileges that are needed and nothing more. The tools to help you manage permissions are discussed later in this chapter, in the section “Managing SQL Server Permissions.”

Download from www.wowebook.com

Managing SQL Server Logins

313

Managing SQL Server Logins 11

You can create and administer logins easily using SSMS. You can use T-SQL as well, but the GUI screens are often the best choice. The GUI screens present the configurable properties for a login, including the available options, databases, and securables that can be assigned to a login. The number of configurable options is extensive and can be difficult to manage with T-SQL.

Using SSMS to Manage Logins The visual tools for managing logins in SSMS are accessible via the Object Explorer. You need to expand the Security node in Object Explorer and right-click the Logins node. Then you select the New Login option, and the new login screen, shown in Figure 11.4, appears.

FIGURE 11.4 Creating a login in SSMS with Windows Authentication. The default authentication mode for a new login is Windows Authentication. If you want to add a login with Windows Authentication, you need to type the name of your Windows user or group in the Login Name text box. You can also click the Search button to search for Windows logins. In either case, the login entered for Windows Authentication should be in the form \ (for example, mydomain\Chris) or in the form [email protected].

Download from www.wowebook.com

314

CHAPTER 11

Security and User Administration

With Windows Authentication, you have an option to restrict access to the server for the new login when it is created. If you select Deny Server Access, a command to deny access to SQL Server is issued immediately after the login is created (for example, DENY CONNECT SQL TO [DBSVRXP\Chris]). This option can be useful for staging new logins and waiting until all the appropriate security has been applied prior to allowing the login to access your SQL Server instance. After you completing the security setup for the login, you can select the login properties and choose the GRANT SERVER ACCESS option. You can use the same new login screen shown in Figure 11.4 to add a login with SQL Server Authentication. Again, you need to provide a login name, but with the standard SQL Server login, there is no domain associated with the user. The login is independent of any Windows login and can be named as desired. The login and password for SQL Server Authentication are stored and maintained in SQL Server. When SQL Server Authentication is selected, several options related to passwords are enabled. These options, as shown in Figure 11.5, include Enforce Password Expiration, Enforce Password Policy, and User Must Change Password at Next Login. These options are all associated with a more rigid password policy. They are similar to options available with Windows accounts and provide a more robust security solution for SQL Server logins. The catch is that the new password options are enforced only on the Windows 2003 Server operating system and versions above. You can select these options when running SQL Server on a machine that has an operating system that is lower than Windows 2003 Server, but the hooks between SQL Server and the operating system are not in place to enforce the password policy.

FIGURE 11.5 Creating a login in SSMS with SQL Server Authentication.

Download from www.wowebook.com

Managing SQL Server Logins

315

11

The next set of options on the General page of the new login allows you to map the login to a certificate, asymmetric key, or credential. The certificate and asymmetric key selections allow you to create a certificate-mapped login or an asymmetric key-mapped login. A certificate-mapped login and an asymmetric key-mapped login are used only for code signing and cannot be used to connect to SQL Server. If these options are used, the certificate or asymmetric key must exist on the server before you map the logins to them. The capability to map the login to a credential on the General page is new to SQL Server 2008. This option simply links the login to an existing credential, but its capabilities may be expanded. The default database and default language are the final options located on the General page of the new login screen. These options are available regardless of the authentication method selected. The default database is the database that the login will connect to by default. The master database is selected, but it is generally not the best database to select for your default. You should choose the default database that your login will use most often and avoid using any of the system databases as your default. This helps prevent database users from executing statements against the wrong database, and it also removes the step of having to change the database every time the user connects. You should make sure that the login is given access to whatever database you select as the default. (The Database Access page is discussed later in this chapter.) The default language determines the default language used by the login. If no default language is specified and the entry is left in the Language drop-down, the server’s default language is used. The default language for the server can be retrieved or set by using the sp_configure system stored procedure. The language selection affects many things, including date formats, month names, and names of days. To see a list of languages available on the server and the related options, you use the sys.syslanguages catalog view. The new login screen has four other pages available for selection when creating your new login: Server Roles, User Mapping, Securables, and Status. The Server Roles page allows you to select one or more fixed server roles for the login to participate in. Figure 11.6 shows the new login screen with the Server Roles page selected. For a more detailed review of the permissions related to each server role, refer to the section “Fixed Server Roles,” earlier in this chapter. The User Mapping page allows you to select the databases that the login will have access to. When the Map check box is selected for a database, the Default Schema and User cells are enabled. The default schema is the schema that will contain the database objects created by the login. The login can create objects in schemas other than the default if the login has permission to use the other schemas. If no schema is specified, the default schema is used. The default schema also comes into play when you’re retrieving database objects. If no schema is specified on database retrievals, the default schema is searched first for the database object. If no Default Schema is specified on the Database Access screen, the default schema is set to dbo. The User data entry area allows you to enter a database username that is different from the login name. By default, the database username is the same as the login name, but you can change it.

Download from www.wowebook.com

316

CHAPTER 11

Security and User Administration

FIGURE 11.6 Choosing a server role. The other thing that happens when you select the Map check box on the database is that the list of database roles is enabled in the bottom portion of the screen. You can select one or more database roles for the login. Both fixed and user-defined database roles are available for selection. The public database role is selected by default and cannot be deselected. The Securables page allows you to select server objects for login permissions. The server objects are limited to object types scoped at the server level. They include Servers, Endpoints, Logins, and Server Roles object types. The management of all permissions, including those for Logins, is discussed in detail in the “Managing Permissions” section, earlier in the chapter. The last page listed for selection is the Status page, which allows you to configure some authorization and authentication options. You can grant or deny access to the database engine on this page, and you can enable or disable the login. You also might need to visit this page if the login gets locked out. If this happens, you have an option on this page to reenable the login so that it is not longer locked out. To modify a login, you right-click the login in the Security node and select Properties. The same set of property pages available when you create a new login are displayed. You cannot change the authentication mode after the login has been created, but you can change all the other settings, if desired.

Download from www.wowebook.com

Managing SQL Server Logins

317

11

To delete a login, you right-click the login and select Delete. The Delete Object screen appears, and you can click OK to delete the login. A warning message appears, stating “Deleting server logins does not delete the database users associated with the logins.” If the login has associated database users, and the login deletion is performed, database users are orphaned, and you have to manually delete the users associated with the login in each database.

Using T-SQL to Manage Logins You can manage logins by using T-SQL statements. This approach is generally not as easy as using the user-friendly GUI screens that come with SSMS, but sometimes using T-SQL is better. For example, with installations and upgrades that involve changes to logins, you can use T-SQL to script the changes and produce a repeatable process. SQL Server 2008 includes system stored procedures and an ALTER LOGIN statement that you can use to manage logins. The same system stored procedures available in prior versions are still available in SQL Server 2008, but they have been deprecated and will not be available in a future version. Table 11.5 lists the available system stored procedures and the basic function and current state of each one. The state indicates whether the procedure has been deprecated and whether an alternative exists in SQL Server 2008.

TABLE 11.5 System Stored Procedures for Managing Logins Store Procedure

Function

Status

sp_addlogin

Add a SQL Server login.

Deprecated; use CREATE LOGIN

sp_defaultdb

Change the default database.

Deprecated; use ALTER LOGIN instead.

sp_defaultlanguage

Change the default language.

Deprecated; use ALTER LOGIN instead.

sp_denylogin

Deny server access to a Windows login.

Deprecated.

sp_droplogin

Drop a SQL Server login.

Deprecated; use DROP LOGIN instead.

sp_grantlogin

Add a Windows login.

Deprecated.

sp_password

Change a login’s password.

Deprecated; use ALTER LOGIN instead.

sp_revokelogin

Drop a Windows login.

Deprecated; use DROP LOGIN instead.

Download from www.wowebook.com

318

CHAPTER 11

Security and User Administration

The system stored procedures have a variety of parameters, which are documented in Books Online. Because they have been deprecated, they are not the focus of this section. Instead, this section focuses on a number of examples that utilize the CREATE, ALTER, and DROP statements. The following example creates a SQL Server login with a password that must be changed the first time the login connects: CREATE LOGIN Laura WITH PASSWORD=N’mypassw0rd$’ MUST_CHANGE, CHECK_EXPIRATION=ON

You can then use the following ALTER LOGIN statement to change the default database, language, and password for the new Laura login: ALTER LOGIN [Laura] WITH DEFAULT_DATABASE=[AdventureWorks2008], DEFAULT_LANGUAGE=[British], PASSWORD=N’myStr0ngPW’

Finally, you can drop the Laura login by using the following: DROP LOGIN [Laura]

As you can see, the T-SQL statements for Logins are relatively easy to use. To simplify matters, you can generate T-SQL statements from SSMS. To do so, you click the Script button available on the screen that appears after you specify a login action. For example, if you right-click a login and select Delete, the Delete Object screen appears. At the top of this screen is a Script button. When you click this button, SSMS scripts the related T-SQL statements into a query editor window for you to review and execute.

Managing SQL Server Users The SSMS has a set of friendly user interfaces to manage SQL Server users as well. The screens are similar to the screens for logins and are also launched from the Object Explorer. You can also use a set of T-SQL statements to manage users.

Using SSMS to Manage Users To manage users via SSMS, you open the Object Explorer and expand the Security node followed by the Users node. The Users node contains a list of the current database users. To add a new database user, you can right-click the Users node and select New User. Figure 11.7 shows the Object Explorer window with the option to create a new user selected for the AdventureWorks2008 database. Figure 11.8 shows the new database user screen displayed after you select the New User option. In this figure, a login named Chris is used, and the database user name is Chris as well. These two names do not need to match but are often the same for consistency. The login must exist before you can create the user. You can click the ellipsis button next to the login name to view a list of available logins. After you click the ellipsis, you can click the Browse button to see the logins that have already been added to SQL Server.

Download from www.wowebook.com

Managing SQL Server Users

319

11

FIGURE 11.7 The New User option in Object Explorer.

FIGURE 11.8 Using SSMS to create a new user.

Download from www.wowebook.com

320

CHAPTER 11

Security and User Administration

The default schema must be a valid schema created in the database. If the default schema is left blank, it defaults to dbo. After the default schema has been set, it is used as the default location for storing and retrieving database objects. You can select one or more schemas to be owned by the user, but a given schema can be owned by only one user in the database. When a schema is selected for ownership for a user, the previous owner loses ownership, and the new user gains ownership. The following example shows the type of T-SQL statement that you can run to accomplish the ownership change. This example changes the ownership on the Person schema to the user Laura: ALTER AUTHORIZATION ON SCHEMA::[Person] TO [Laura]

When you select the Permissions page, you can assign permissions to securables scoped at the database and schema levels. The management of all permissions, including those for users, is discussed in detail in the “Managing Permissions” section, earlier in the chapter. To modify or delete an existing database user, you can right-click the user in the Object Explorer and choose the related option. To modify the user, you select Properties, and a screen similar to the one you use to add the user is displayed. To delete the user, you select the Delete option.

Using T-SQL to Manage Users CREATE USER, ALTER USER, and DROP USER are the T-SQL commands you use most often to

manage database users. These commands are replacements for the system stored procedures used in prior versions. The system stored procedures, such as sp_adduser, sp_dropuser, sp_grantdbaccess, and sp_revokedbaccess, have been deprecated and will be removed in a future version. They are still available for use now, but you should avoid them when possible. The following example demonstrates the use of the CREATE USER statement to create a new database user named Laura, with a default schema Sales: CREATE USER Laura FOR LOGIN Laura WITH DEFAULT_SCHEMA = Sales

You can use the ALTER USE statement to change the default schema or the username. The following example uses the ALTER USER statement to change the name of the database user currently named Laura to LauraG: ALTER USER Laura WITH NAME = LauraG

If you want to delete a database user, you use the DROP USER command. The following example demonstrates how to delete the LauraG from the previous example: DROP USER [LauraG]

Download from www.wowebook.com

Managing Database Roles

321

11

When dropping database users, you must keep in mind that you cannot drop them if they are the owners of database objects. An object’s ownership must be transferred to another database user before that object can be deleted. This applies to schemas that can be owned by the user as well.

Managing Database Roles Database roles are custom roles that you can define to group your users and simplify the administration of permissions. Generally, custom database roles (non-fixed) are created if the fixed database roles do not meet the security needs of the administrator. (The assignment of logins and users to fixed server and fixed database roles is covered earlier in this chapter.)

Using SSMS to Manage Database Roles You can find database roles in the Object Explorer for each database, under the Security node, which contains a Roles node. The Roles node contains a Database Roles node, which lists both fixed and nonfixed database roles. To add a new custom database role (nonfixed), you right-click the Database Roles node and select New Database Role. A new database role dialog box appears, as shown in Figure 11.9.

FIGURE 11.9 The new database role dialog box.

Download from www.wowebook.com

322

CHAPTER 11

Security and User Administration

You need to enter a name for the role and name for the owner of the role. Like a database user, a database role can also own schemas. If you click the Add button, you can add database users from the current database to the role. If you select the Permissions page, you can define the permission for the database role. This definition includes the selection of database objects scoped at the database and schema levels. These permissions are discussed in detail in the “Managing Permissions” section, earlier in this chapter.

Using T-SQL to Manage Database Roles Some of the T-SQL system stored procedures used in prior versions to manage roles have been deprecated, including sp_addrole and sp_droprole. The sp_addrolemember and sp_droprolemember procedures have not been deprecated and are still good choices for adding members to a role. The CREATE ROLE and DROP ROLE statements are the new replacements for sp_addrole and sp_droprole. The following example uses the CREATE ROLE statement to create a new database role named DevDbRole: CREATE ROLE [DevDbRole]

To assign a user named Chris to the new DevDbRole role, you can use the following: EXEC sp_addrolemember N’DevDbRole’, N’chris’

Role membership is not limited to database users. It is possible to assign database roles as members of another role. The following adds the TestDbRole database role to the DevDbRole role created in the previous example: EXEC sp_addrolemember N’DevDbRole’, N’TestDbRole’

You cannot use sp_addrolemember to add a fixed database role, a fixed server role, or dbo to a role. You can, however, add a nonfixed database role as a member of a fixed database role. If, for example, you want to add the DevDbRole database role as a member of the fixed database role db_dataread, you use the following command: EXEC sp_addrolemember N’db_datareader’, N’DevDbRole’

The ALTER ROLE statement exists but is limited to changing the name of a role. To drop a database role, you use the DROP ROLE statement. Keep in mind that all role members must be dropped before a role can be dropped.

Managing SQL Server Permissions You can use T-SQL or the visual tools available in SSMS to manage permissions. Based on the number of available permissions and their complexity, it is recommended that you use the SSMS tools. The following sections cover these tools from several different angles and

Download from www.wowebook.com

Managing SQL Server Permissions

323

look at the management of permissions at different levels of the security model. You learn how to use T-SQL to manage the permissions as well.

11

Using SSMS to Manage Permissions The Object Explorer in SSMS enables you to manage permissions at many different levels of the permission hierarchy. You can manage permissions at a high level, such as the entire server, or you can manage permissions at the very lowest level, including a specific object, such as a table or stored procedure. The degree of granularity you use for permissions depends on your security needs. To demonstrate the scope of permissions, let’s look at managing permissions at several different levels, starting at a high level and working down to the object level.

NOTE There are many different ways to achieve a security goal in SSMS. For example, you can manage permissions for a database user from the database or from the user. You can apply permissions on schema objects for the entire schema or to individual objects. You should always try to choose the permission solution that allows you to achieve your security goals with the least amount of administrative overhead. Using SSMS to Manage Permissions at the Server Level Logins can be granted explicit permissions at the server level. Earlier we looked at fixed server roles as one means for assigning permissions, but you can manage individual server-level securables as well. Figure 11.10 shows the Login Properties window for a login named Chris. You launch this window by right-clicking the login and selecting Properties. Figure 11.10 shows the Securables page, which allows you to add specific securables to the grid.

NOTE You can open a Permissions page like the one shown in Figure 11.10 from many different places in the Object Explorer. The title of the dialog box and the content of the grid vary, depending on the object selected, but the screen is generally the same, no matter where it is launched. This provides consistency and simplifies the overall management of permissions.

You can click the Search button shown toward the top of Figure 11.10 to add objects to the securables grid. When you click this button, the Add Objects window shown in Figure 11.11 is displayed. This window allows you to choose the types of objects you want to add. If you select Specific Objects, you are taken directly to the Select Objects window. If you choose All Objects of the Types, you are taken to an intermediate screen that allows you to select the type of objects you want to assign permissions to. Again, the Add button and the means for adding objects are fairly consistent for all permissions. What varies is the object types available for selection. For example, at the server level, the types of objects available to assign permissions are scoped at the server level. Figure 11.12 shows the Select Object Types window displayed when you choose the

Download from www.wowebook.com

324

CHAPTER 11

Security and User Administration

FIGURE 11.10 Server-level permissions.

FIGURE 11.11 The Add Objects window. All Objects of the Types option at the server level. You can see that the available objects are all scoped at the server level. If the endpoints objects are selected, the securables grid is populated with all the available endpoints that have permissions to manage. Figure 11.13 shows the Login Properties window with the endpoints securables populated. The TSQL Named Pipes securable is selected, which allows you to specify the explicit permissions for the securable in the bottom grid. In this example, the Grant and With Grant check boxes have been selected for the control permission. This gives the login named Chris the right to control the Named Pipes endpoint and also allows him to grant this control right (because With Grant is selected) to other logins. The examples we just walked through are related to the assignment of explicit permission on a specific instance of a securable. You can also apply server permissions at a higher

Download from www.wowebook.com

Managing SQL Server Permissions

325

11

FIGURE 11.12 Server-level object types.

FIGURE 11.13 Server-level securables. level. For example, you might want to specify permissions for a login to allow that login to control all server endpoints instead of specific endpoints. You can accomplish this in several ways. One way to do it is to select the Server object from the list of object types when adding permissions for a specific login. Another way is to right-click the server name in the Object Explorer and select Properties. The Server Properties window that appears has a Permissions page that lists all the logins for the server, along with the macro-level permissions scoped for the server. Figure 11.14 shows the Server Properties window with the login Chris selected. The explicit permissions listed in this case are at a higher level and are not just for one instance. The example shown in Figure 11.14 allows

Download from www.wowebook.com

326

CHAPTER 11

Security and User Administration

the login Chris to alter any database or any endpoint on the server. This is based on the Grant check boxes selected.

FIGURE 11.14 The Server Properties window’s Permissions page.

Using SSMS to Manage Permissions at the Database Level The same type of hierarchy exists with permissions at the database level as at the server level. You can apply permissions at a high level to affect many objects of a particular type, or you can apply them on a specific object. You can also manage the permissions at the database level on a specific database user, or you can manage them on the database across many users. To demonstrate the differences between object types available at the database level, let’s first look at managing permissions for a specific database user. As with logins, you can right-click a database user and select Properties. On the Properties window that appears, you select the Securables page, and you get a screen to assign permissions that is very similar to the login permissions screen. The difference at the database level is in the object types available for selection. Figure 11.15 shows the object types available when you choose the All Objects of Types choice during the addition of securables for a database user. When a low-level object type such as a table or stored procedure is selected, you are able to apply explicit permissions to a specific object instance. Figure 11.16 shows an example of low-level securables available when the Table object type is selected.

Download from www.wowebook.com

Managing SQL Server Permissions

327

11

FIGURE 11.15 Database-level object types.

FIGURE 11.16 Low-level database securables.

Download from www.wowebook.com

328

CHAPTER 11

Security and User Administration

To apply permissions at a higher level in the database, you choose the object type Databases. With this securable added to the permissions grid, you can apply permissions to a group of objects by selecting a single permission. Figure 11.17 shows the AdventureWorks2008 database selected as the securable and the related permissions available. In this example, the login Chris has been granted INSERT, SELECT, and UPDATE permissions to all the tables in the AdventureWorks2008 database.

FIGURE 11.17 High-level database securables. Using SSMS to Manage Permissions at the Object Level The last permission assignment we look at is the object level. SSMS enables you to select a specific object instance in the Object Explorer and assign permissions to it. This method allows you to navigate to the object you want via the Object Explorer tree and assign permissions accordingly. Figure 11.18 shows the Object Explorer tree expanded to the Stored Procedures node. A specific stored procedure has been right-clicked, and the Properties option has been selected. The Properties window has a page dedicated to permissions. You can select the Permissions page and then select the users or roles you want to add for the specific object, such as a stored procedure. Figure 11.19 shows the Permissions page with a user named Chris added to the Users or Roles window at the top of the page. The bottom portion of the page shows explicit permissions for the user Chris, which includes a DENY permission on the stored procedure selected.

Download from www.wowebook.com

Managing SQL Server Permissions

329

11

FIGURE 11.18 Object-level permissions selected via Object Explorer.

FIGURE 11.19 Object-level permissions.

Download from www.wowebook.com

330

CHAPTER 11

Security and User Administration

NOTE The methods described here for managing permissions in SSMS are by no means the only ways you can manage permissions in SSMS. You will find that the assignment of permissions pervades SSMS and that SSMS allows you to assign permissions in many different ways. The point to keep in mind is that database roles, application roles, schemas, and other objects in the security model all have similar methods for assigning permissions.

Using T-SQL to Manage Permissions As you saw in the SSMS Permissions pages, three options exist for assigning every permission: GRANT, DENY, and REVOKE. Each option has its own T-SQL statements that can be used to manage permissions as well. The simplified syntax for the GRANT command is as follows: GRANT { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n ] [ ON [ class :: ] securable ] TO principal [ ,...n ] [ WITH GRANT OPTION ] [ AS principal ]

This basic GRANT syntax is similar to that in SQL Server 2000, but the addition of many permissions and securables in SQL Server 2005 and SQL Server 2008 has expanded the scope of the command. SQL Server 2005 also introduced the WITH GRANT option which allows a permission to be granted to a principal and allows the principal to grant that permission to another principal. The WITH GRANT option has been carried forward to SQL Server 2008 and is a good way to delegate administrative functions to others. The simplified syntax for the DENY and REVOKE commands is as follows: DENY { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n ] [ ON [ class :: ] securable ] TO principal [ ,...n ] [ CASCADE] [ AS principal ] REVOKE [ GRANT OPTION FOR ] { [ ALL [ PRIVILEGES ] ] | permission [ ( column [ ,...n ] ) ] [ ,...n ] } [ ON [ class :: ] securable ] { TO | FROM } principal [ ,...n ] [ CASCADE] [ AS principal ]

You can see that the simplified syntax for DENY and REVOKE is similar in structure to the GRANT statement. All the statements must identify the permission, securable, and principal that will receive the permission.

Download from www.wowebook.com

The Execution Context

331

11

The ALL clause has been deprecated in SQL Server 2008. If ALL is specified, it does not affect all permissions on the object; it affects only a subset of the permissions related to the securable. The subset of permissions is dependent on the securable. The following examples demonstrate several different types of permissions you can manage by using T-SQL commands: --Grant permissions to create a table -- to a user named Chris GRANT CREATE TABLE TO Chris --Grant ALL permissions on a stored procedure -- to a database role named TestDBRole GRANT ALL ON dbo.uspGetBillOfMaterials TO TestDBRole --DENY UPDATE permission on the Customer table -- to user named Laura DENY UPDATE ON OBJECT::sales.customer TO Laura --REVOKE UPDATE permissions on the Customer table -- to user named Laura. REVOKE UPDATE ON OBJECT::sales.customer TO Laura

There are many different flavors of the GRANT, DENY, and REVOKE statements, depending on the securable they are affecting. Books Online outlines the syntax for each securable and the permissions that can be applied. Remember that you can use the Script option to generate the T-SQL from SSMS. The Script button is available when you’re managing permissions, and using it is a great way to familiarize yourself with the T-SQL that is used to effect changes. You can select the permissions you want to apply via the GUI screen and then click the Script button to generate the T-SQL.

The Execution Context The execution context determines what permissions are checked when statements are executed or actions are performed on the database server. By default, the execution context is set to the principal connected to the server or database. If a user named Chris connects to the AdventureWorks2008 database, the permissions assigned to Chris are checked. In SQL Server 2008, you can change the execution context so that permissions are checked for a principal other than that to which you are connected. You can make this change in execution context (called context switching) explicitly or implicitly.

Download from www.wowebook.com

332

CHAPTER 11

Security and User Administration

Explicit Context Switching With explicit context switching, you can use the EXECUTE AS statement to change the user or login used to check permissions. This is similar to the SET USER statement available in SQL Server 2000 and SQL Server 2005. It is extremely useful for administrators who are testing the permissions they have set for users or logins. The following example demonstrates the use of the explicit EXECUTE AS statement: --Assume that you are connected as an administrator (DBO) --and want to prevent members of the Public role from --selecting from the Sales.Customer table DENY SELECT ON sales.customer TO Public --We can check that user Laura cannot select from the -- Sales.Customer table using the EXECUTE AS statement EXECUTE AS USER = ‘laura’ SELECT TOP 1 * FROM sales.customer -- Revert to the previous execution context. REVERT

You can also do explicit context switching at the login level. You can use the EXECUTE AS statement to switch the execution context to another login instead of a user. Context switching is linked to the IMPERSONATE permission. As an administrator, you can grant IMPERSONATE to a login or user to enable that user to execute as that user. For example, an administrator can temporarily enable another login to run in the same execution context by using the IMPERSONATE permission and EXECUTE AS statement. The following example demonstrates the assignment of the IMPERSONATE permission to a login named Laura: --Chris grants the right to Laura to impersonate him GRANT IMPERSONATE ON LOGIN::[chris] TO [laura] GO --Laura can then connect with her login and use -- the EXECUTE AS command to run commands that -- normally only Chris has permission to run EXECUTE AS Login = ‘Chris’ DBCC CHECKDB (AdventureWorks2008) SELECT USER_NAME() --Revert back to Laura’s execution context REVERT SELECT USER_NAME() Laura can now use EXECUTE as Chris, who is an administrator. This capability can be

particularly useful when a user or login has many custom permissions that would take a lot of time to establish for another user or login.

Download from www.wowebook.com

The Execution Context

333

Implicit Context Switching 11

With implicit context switching, the execution context is set within a module such as a stored procedure, trigger, or user-defined function. The EXECUTE AS clause is placed in the module and is set to the user that the module will be run as. The context switch is implicit because the user who runs the module does not have to explicitly specify the context before running the module. The context is set within the module. The EXECUTE AS clause has several different options to establish the execution context. All modules are able to set the context to a specific user or login. Functions, stored procedures, and Data Manipulation Language (DML) triggers can also execute as CALLER, SELF, or OWNER. DDL triggers can run as CALLER or SELF. Queues can run as SELF or OWNER. The CALLER option is the default, and it runs the module in the context of the user who called the module. The SELF option causes the module to run in the context of the user or login that created the procedure. The OWNER option causes the module to run in the context of the current owner of the module. The following example demonstrates the creation and execution of a stored procedure with the EXECUTE AS clause on a specific user named Chris: CREATE PROCEDURE dbo.usp_TestExecutionContext WITH EXECUTE AS ‘chris’ AS SELECT USER_NAME() as ‘User’ --Set the user to someone other than chris to test the -- implicit EXECUTE AS SETUSER ‘DBO’ EXEC usp_TestExecutionContext /*Results of the prior execution User -----chris */

This example shows that the USER_NAME retrieved in the stored procedure is Chris, regardless of who executed the procedure. Implicit execution context can be particularly useful in situations in which permissions cannot be granted to a user directly. For example, TRUNCATE TABLE permissions cannot be granted explicitly to a user, but a database owner can run this command. Instead of granting dbo rights to a user needing TRUNCATE permissions, you can create a stored procedure that does the truncation. You can create the stored procedure with the execution context of dbo, and you can grant the user rights to execute the stored procedure that does the truncation. When you use this method, the user can perform the truncation but does not have any of the other permissions related to a database owner.

Download from www.wowebook.com

334

CHAPTER 11

Security and User Administration

Summary SQL Server 2008 continues the trend of providing more security and more flexible security to the SQL Server database environment. Several new enhancements have been added to SQL Server 2008 that add to the slew of security changes added to SQL Server 2005. The granularity of the permissions and the other security-related features covered in this chapter allow you to keep your SQL Server environment safe. Chapter 12, “Data Encryption,” looks at another aspect of SQL Server that helps secure your database environment. It covers encryption methods that can be implemented to further protect your data from unauthorized access.

Download from www.wowebook.com

CHAPTER

12

Data Encryption

IN THIS CHAPTER . What’s New in Data Encryption . An Overview of Data Security . An Overview of Data Encryption . SQL Server Key Management . Column-Level Encryption

With all the concern about identity theft these days, there has been increasingly more attention paid to how all the Personally Identifiable Information (PII) and other sensitive information stored in databases is being protected. It is necessary to secure and protect this data to avoid any potential liability should the PII or sensitive data fall into the wrong hands, and in some cases, doing so may even be required by law (for example, Health Insurance Portability and Accountability Act, or HIPAA, requirements).

. Transparent Data Encryption . Column-Level Encryption Versus Transparent Data Encryption

Chapter 11, “Security and User Administration,” discusses methods to secure and control the access to your SQL Server data via login and user security. This type of security is usually sufficient to prevent access to the data by anyone other than properly authorized users. But what if you need to prevent authorized users, such as your database or server administrators, from viewing sensitive data? How can you protect sensitive data from hackers or in the event that a database backup is stolen? One method is to encrypt the data. This chapter looks at two methods provided in SQL Server 2008 for encrypting data: column-level encryption and transparent data encryption (TDE). In addition to describing how to implement both methods, the chapter presents the features and limitations of each of these methods to help you decide which data encryption method may help you meet your data security needs.

Download from www.wowebook.com

336

CHAPTER 12

Data Encryption

What’s New in Data Encryption In SQL Server 2000 and earlier, if you wanted to encrypt data in your databases, you usually needed to implement some form of client-side encryption. SQL Server itself did not provide any means of encrypting data at the database level, so all the encryption and decryption occurred in the application itself. This required custom-written applications to encrypt and decrypt the data, and only those applications would be able to view the encrypted data. SQL Server 2005 introduced the capability to perform column-level (sometimes called celllevel) encryption. This provided the capability to encrypt data within the database itself at the column level. However, this method is still not transparent to the applications and requires changes to the database schema as well as changes to your applications and T-SQL code to include the proper function calls to encrypt and decrypt the data as it is stored and retrieved. SQL Server 2008 introduces a new form of database encryption: transparent data encryption. TDE allows you to encrypt an entire database without affecting client applications. The purpose of TDE is to prevent scenarios in which the physical media (such as database files or backups) containing sensitive data are stolen and then read by attaching the database files or restoring the backups.

NOTE Both column-level and transparent data encryption are available only in the Enterprise and Developer Editions of SQL Server 2008 and SQL Server 2008 R2.

Another new feature in SQL Server 2008 is Extensible Key Management (EKM). EKM enables parts of the cryptographic key hierarchy to be managed by an external source such as Hardware Security Module (HSM), referred to as a cryptographic provider. Encryption and decryption operations using these keys are handled by the cryptographic provider. This allows for flexibility and choice in cryptographic providers as well as common key management.

An Overview of Data Security Security is important for every product and every business. By following some simple security best practices, you can avoid many security vulnerabilities. This section discusses some security recommendations that you should consider for your SQL Server implementations. Securing SQL Server can be viewed as a series of steps, involving four areas: the platform, authentication, objects (including data), and applications that access the system.

Download from www.wowebook.com

An Overview of Data Security

337

12

The platform for SQL Server includes the physical hardware and networking systems connecting clients to the database servers. The first step in securing your SQL Server environment is to provide sufficient physical security by limiting access to the physical server and hardware components. To enhance the physical security of the SQL Server installation, you should consider placing the server in a room accessible only by authorized personnel, ideally a locked computer room with monitored flood detection and fire detection or suppression systems. In addition, you should physically secure your backup media by storing it at a secure offsite location. Next, you need to ensure your system provides sufficient physical network security by keeping unauthorized users off the network by limiting access to the network to authorized users only. Make sure your database servers are installed in a secure zone of your company’s intranet behind a firewall. Do not connect your SQL Servers directly to the Internet. Always make sure there is a firewall between your servers and the Internet and set it up to block all traffic except for that which is required. Next, you need to ensure that you have secured your operating system and files. SQL Server uses operating system files for operation and data storage. Be sure to restrict access to these files to system administrators only. Use the NTFS file system because it is more stable and recoverable than FAT file systems. NTFS also enables security options such as file and directory Access Control Lists (ACLs) and Encrypting File System (EFS) file encryption. For your installed SQL Server instances, you can enhance the security of the SQL Server installation by running your SQL Server services under service accounts granted the minimal permissions necessary for operation (do not run under the Windows Administrator account!). These accounts should be low-privileged Windows local user or domain user accounts. Surface area reduction is also an important security measure. Surface area reduction helps improve security by providing fewer avenues for potential attacks on a system. In addition to running services under “least privilege” accounts, this measure also involves stopping or disabling unused components. You should also enhance the security of the SQL Server instances through limiting the individuals, groups, and processes granted access to SQL Server and appropriately limiting access to the databases and objects the database contains. One way is to require Windows authentication for connections to SQL Server. If you are using SQL Server authentication as well, you should be sure to enforce password policies that require strong passwords and password expiration for all SQL Server logins. For more information on setting up SQL Server logins and managing database users and object permissions, see Chapter 11. Even if you follow the recommendations presented here for securing your environment, you still can be vulnerable to access control problems. Encryption provides another way to enhance security by limiting data loss even in the rare occurrence that access controls are bypassed. For example, if a malicious user hacks into the database host computer and obtains sensitive data, such as credit card numbers, that stolen information might be useless if it is encrypted.

Download from www.wowebook.com

338

CHAPTER 12

Data Encryption

An Overview of Data Encryption Encryption is the process of obfuscating data by the use of a key or password. This can make the data useless without the corresponding decryption key or password. Encryption does not solve access control problems. However, it enhances security by limiting data loss even if access controls are bypassed. Encryption is actually the conversion of readable plaintext into ciphertext, which cannot be easily understood by unauthorized people. The concrete procedure of carrying out the encryption is called an algorithm. Decryption is the process of converting ciphertext back into its original form so it can be understood. Both encryption and decryption require a key, which must be kept secret because it enables the holder to carry out the decryption. There are two primary methods of encryption: symmetric key encryption and asymmetric key encryption. Symmetric key encryption uses the same key for both encryption and decryption. Asymmetric key encryption, also called public-key encryption, uses two different keys for encryption and decryption, which together form a key pair. The key used for encryption is called a public key. The key used for decryption is referred to as a private key. Symmetric key encryption is inherently less secure because it uses the same key for both encryption and decryption operations, and the exchange of data requires transfer of the key, which introduces a potential for its compromise. This can be avoided with an asymmetric key because individuals encrypting and decrypting data have their own, separate keys. However, asymmetric encryption is based on algorithms that are more complex, and its impact on performance is more significant, making it often unsuitable in scenarios involving larger amounts of data. However, it is possible to take advantage of the strengths of both methods by encrypting data with a symmetric key and then protecting the symmetric key with asymmetric encryption. One solution to the dilemma of key distribution is to use digital certificates. A certificate is a digitally signed piece of software that associates a public key with the identity of the private key owner, assuring its authenticity. There is an inherent problem with this approach—namely, how to assure the identity of the certificate issuer. To resolve this issue, Microsoft provides a number of trusted certificate authorities (known as Trusted Root Certification Authorities) with the operating system. These certificate authorities are responsible for verifying that organizations requesting certificates are really what they claim to be. Typically, the algorithms used for encryption are industry standard, such as the Advanced Encryption Standard (AES). The fact that the algorithms are published doesn’t make them weaker, but rather helps ensure they are strong and robust. Because these algorithms have been reviewed by thousands of experts around the globe, they have stood the test of time. SQL Server 2008 allows administrators and developers to choose from among several algorithms, including DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128bit AES, 192-bit AES, and 256-bit AES. No one algorithm is ideal for all situations, and a discussion on the merits of each is beyond the scope of this chapter. However, the following general principles apply:

Download from www.wowebook.com

SQL Server Key Management

339

. Strong encryption generally consumes more CPU resources than weak encryption. . Long keys generally yield stronger encryption than short keys. . Asymmetric encryption is stronger than symmetric encryption using the same key length, but it is slower.

. If you are encrypting lots of data, you should encrypt the data using a symmetric key and encrypt the symmetric key with an asymmetric key.

12

. Long, complex passwords are stronger than short passwords.

However, what really protects your data from third parties is not so much the algorithm but the encryption key, which you must keep secure. Keys must be stored securely and made available only on a need-to-know basis. Ideally, authorized people or systems should be able to use but not necessarily have a copy of the key. It’s also a security best practice to implement key rotation, changing keys periodically in case a key has been compromised. For greater key security, you can also make use of Extensible Key Management, allowing keys to be managed by an external source such as Hardware Security Module. SQL Server 2008 provides support for not only encryption of data, but also encryption of user network connections and stored procedures. The remainder of this chapter discusses the two methods of data encryption, column-level encryption and transparent data encryption. Client network encryption is covered in Chapter 10, “Client Installation and Configuration.” Encryption of stored procedure code is discussed in Chapter 28, “Creating and Managing Stored Procedures.”

NOTE Although encryption is a valuable tool to help ensure security, it does incur overhead and can affect performance, and any use of encryption requires a maintenance strategy for your passwords, keys, and certificates. Therefore, encryption should not be automatically considered for all data or connections. When you are deciding whether to implement encryption, consider how users access the data. If access is over a public network, data encryption may be required to increase data security. However, if all access is via a secure intranet configuration, encryption may not be required. This chapter describes the encryption methods available in SQL Server 2008 and SQL Server 2008 R2 along with the pros and cons of implementing these encryption methods. This information should help you to determine whether using encryption is appropriate for implementing your data security solutions.

SQL Server Key Management SQL Server 2008 provides rich support for various types of data encryption using symmetric and asymmetric keys and digital certificates. As an administrator, you probably need to manage at least the upper level of keys in the hierarchy shown in Figure 12.1. Each key

Download from www.wowebook.com

340

CHAPTER 12

Data Encryption

protects its child keys, which in turn protect their child keys, down through the tree. The one exception is when a password is used to protect a symmetric key or certificate. This is how SQL Server lets users manage their own keys and take responsibility for keeping the key secret.

Service Master Key (Protected by DPAPI) Server Level Database Level Database Master Key

Pwd

Certificates

Symmetric Keys

Data

Pwd

Asymmetric Keys

Symmetric Keys

Symmetric Keys

Pwd

Data

Data

FIGURE 12.1 Key hierarchy in SQL Server 2008.

Each SQL Server instance has its service master key. The service master key is the one key that rules them all. It is a symmetric key created automatically during SQL Server installation and is encrypted and protected by the Data Protection API (DPAPI), which is provided by the underlying Windows OS, using the credentials of the SQL Server service account. Protection of this key is critical because if it is compromised, an attacker can eventually decipher every key in the server managed by SQL Server. SQL Server manages the service master key for you, although you can perform maintenance tasks on it to dump it to a file, regenerate it, and restore it from a file. However, most of the time you will not need or want to make any of these changes to the key, although administrators are advised to back up their service master keys in the event of key corruption. The main purpose of the server master key is to secure system data, such as passwords used in instance-level settings such as linked servers or connection strings. The service master key is also used to secure each of the database master keys. Within each database, the database master key serves as the basis for creating certificates or asymmetric keys, which subsequently can be applied to protect data directly or to further extend the encryption hierarchy (for example, by creating symmetric keys). Creation, storage, and other certificate and key management tasks can be handled internally, without resorting to features of the operating system or third-party products.

Download from www.wowebook.com

SQL Server Key Management

341

Each database can have a single master key. You must create a database master key before using it by using the CREATE MASTER KEY Transact-SQL statement with a usersupplied password: CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘R@nD0m!T3%t’

12

SQL Server encrypts the database master key using a triple DES key derived from the password as well as the service master key. The first copy is stored in the database, and the second is stored in the master database. Having the database master key protected by the server master key makes it possible for SQL Server to decrypt the database master key automatically when required. The application or user does not need to open the master key explicitly using the password. This is a major benefit of having the keys protected in the hierarchy.

NOTE Detaching a database with an existing master key and moving it to another server can be an issue. The problem is that the new server’s database master key is different from that of the old server. As a result, the server cannot automatically decrypt the database master key. This situation can be circumvented by opening the database master key with the password with which it is encrypted and using the ALTER MASTER KEY statement to encrypt it with the new database master key.

When the database master key exists, developers can use it to create any of three types of keys, depending on the type of encryption required: . Asymmetric keys . Symmetric keys . Certificates

TIP Microsoft recommends against using certificates or asymmetric keys for encrypting data directly. Asymmetric key encryption is many times slower, and the amount of data that you can protect using this mechanism is limited, depending on the key modulus. It is recommended that you protect certificates and asymmetric keys using a password instead of by the database master key.

Extensible Key Management Another new feature in SQL Server 2008 that provides greater key security is Extensible Key Management. EKM enables you to manage your encryption keys via an external provider. This allows for flexibility and choice in encryption providers as well as common key management across your enterprise.

Download from www.wowebook.com

342

CHAPTER 12

Data Encryption

With the growing demand for regulatory compliance and concern for data privacy, organizations are taking advantage of encryption as a way to provide a “defense in depth” solution. As organizations increasingly use encryption and keys to secure their data, key management becomes more complex. Some high security databases use thousands of keys, and you must employ a system to store, retire, and regenerate these keys. This approach is often impractical using only database encryption management tools. As a solution, various hardware vendors provide products to store encryption keys on hardware or software modules. These products also provide a more secure key management solution because the encryption keys do not reside with encryption data. They also move the key management workload from SQL Server to a dedicated key management system. Extensible key management in SQL Server 2008 also supports the use of Hardware Security Module, which enables the encryption keys used to protect your data to be stored in an off-box device such as a smartcard, USB device, or EKM/HSM module, providing a physical separation of keys from data. SQL Server 2008 Extensible Key Management enables thirdparty EKM/HSM vendors to register their modules in SQL Server. When registered, SQL Server users can use the encryption keys stored on EKM modules. This enables SQL Server to access the advanced encryption features these modules support such as bulk encryption and decryption, and key management functions such as key aging and key rotation. SQL Server 2008 Extensible Key Management also provides data protection from database administrators. Data can be encrypted by using encryption keys that only the database user has access to on the external EKM/HSM module. To summarize, SQL Server 2008 Extensible Key Management provides the following benefits: . An additional authorization check that enables separation of duties between database administration and key management . Improved performance through hardware-based encryption/decryption rather than software-based encryption/decryption . External encryption key generation . Physical separation of data and keys . Encryption key retrieval . External encryption key retention and encryption key rotation . Easier encryption key recovery . Manageable encryption key distribution . Secure encryption key disposal When possible, it is highly recommended that you use EKM with both database- and column-level encryption for more comprehensive key management and hardware-based cryptography.

Download from www.wowebook.com

Column-Level Encryption

343

Column-Level Encryption

Column-level encryption is implemented as a series of built-in functions and a key management hierarchy. Implementing column-level encryption is a manual process that requires a re-architecture of the application to call the encryption and decryption functions explicitly when storing or retrieving data. In addition, the tables must be modified to store the encrypted data as varbinary. The data is then recast back to the appropriate data type when it is read.

12

Column-level encryption (sometimes referred to as cell-level encryption) was introduced in Microsoft SQL Server 2005 and is still fully supported in SQL Server 2008 R2. Columnlevel encryption offers a more granular level of encryption than TDE, allowing you to encrypt specific data columns in the context of specific users.

Column-level encryption and decryption are provided by pairs of functions that complement each other: . EncryptByCert() and DecryptByCert()—Encrypts and decrypts data using the public key of a certificate to generate a private asymmetric key . EncryptByAsymKey() and DecryptByAsymKey()—Encrypts and decrypts data using an asymmetric key . EncryptByKey() and DecryptByKey()—Encrypts and decrypts data by using a symmetric key . EncryptByPassphrase() and DecryptByPassphrase()—Encrypts and decrypts data by using a passphrase to generate a symmetric key Before you can begin generating keys to encrypt columns, you must first make sure a database master key has been created: USE AdventureWorks2008R2; GO --If there is no master key, create one now. IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101) CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘Th15i$aS7riN&ofR@nD0m!T3%t’ GO

NOTE The examples in this chapter make use of the AdventureWorks2008R2 database but can be run in the AdventureWorks2008 database as well; however, there may be differences in the data values returned. For more information on downloading and installing the AdventureWorks databases, see the Introduction.

Download from www.wowebook.com

344

CHAPTER 12

Data Encryption

Encrypting Columns Using a Passphrase As our first example, let’s keep things simple and look at how to encrypt a column using a passphrase. To do so, let’s look at the Sales.CreditCard table, which currently stores card numbers in cleartext: select top 5 * from Sales.CreditCard go CreditCardID -----------1 2 3 4 5

CardType -------------SuperiorCard Distinguish ColonialVoice ColonialVoice Vista

CardNumber -------------33332664695310 55552127249722 77778344838353 77774915718248 11114404600042

ExpMonth -------11 8 7 7 4

ExpYear ------2006 2005 2005 2006 2005

ModifiedDate ----------2007-08-30 2008-01-06 2008-02-15 2007-06-21 2007-03-05

Credit card numbers really should not be stored in their cleartext form in the database, so to fix this, first create a copy of the Sales.CreditCard table and define the CardNumber_encrypt column as a varbinary(256) so you can store the encrypted credit card numbers in the column (encrypted columns in SQL Server 2008 can be stored only as varbinary values): USE AdventureWorks2008R2; GO select CreditCardID, CardType, CardNumber_encrypt = CONVERT(varbinary(256), CardNumber), ExpMonth, ExpYear, ModifiedDate into Sales.CreditCard_encrypt from Sales.CreditCard where 1 = 2

Now, you can populate the CreditCard_encrypt table with rows from the original CreditCard table using the EncryptByPassPhrase function to encrypt the credit card numbers as the rows are copied over: declare @passphrase varchar(128) set @passphrase = ‘unencrypted credit card numbers are bad, um-kay’ insert Sales.CreditCard_encrypt ( CardType, CardNumber_encrypt, ExpMonth, ExpYear,

Download from www.wowebook.com

Column-Level Encryption

345

12

ModifiedDate ) select top 5 CardType, CardNumber_encrypt = EncryptByPassPhrase(@passphrase, CardNumber), ExpMonth, ExpYear, ModifiedDate from Sales.CreditCard

Now, try a query against the CreditCard_encrypt table without decrypting the data and see what it returns (note, for display purposes, the values in the CardNumber_encrypt column have been truncated): select * from Sales.CreditCard_encrypt go CreditCardID -----------1 2 3 4 5

CardType ------------SuperiorCard Distinguish ColonialVoice ColonialVoice Vista

CardNumber_encrypt --------------------0x010000007C65089E... 0x010000000C624987... 0x01000000AA8761A0... 0x010000002C2857CC... 0x0100000095F6730D...

ExpMonth -------11 8 7 7 4

ExpYear ------2006 2005 2005 2006 2005

ModifiedDate ----------2007-08-30 2008-01-06 2008-02-15 2007-06-21 2007-03-05

In the preceding results, you can see that the credit card numbers have been encrypted as a varbinary value, and no meaningful information can be obtained from this. To view the data in its unencrypted form, you need to use the DecryptByPassPhrase function and convert the value back to an nvarchar(25): declare @passphrase varchar(128) set @passphrase = ‘unencrypted credit card numbers are bad, um-kay’ select CreditCardID, CardType, CardNumber = convert(nvarchar(25), DecryptByPassPhrase(@passphrase, CardNumber_encrypt)), ExpMonth, ExpYear, ModifiedDate from Sales.CreditCard_encrypt GO

Download from www.wowebook.com

346

CHAPTER 12

Data Encryption

CreditCardID CardType CardNumber ExpMonth ExpYear ModifiedDate ------------ -------------- -------------- -------- --------------------1 SuperiorCard 33332664695310 11 2006 2007-08-30 2 Distinguish 55552127249722 8 2005 2008-01-06 3 ColonialVoice 77778344838353 7 2005 2008-02-15 4 ColonialVoice 77774915718248 7 2006 2007-06-21 5 Vista 11114404600042 4 2005 2007-03-05

So that’s a simple example showing how to encrypt a column. You may be thinking, however, using a passphrase like this probably isn’t very secure. The passphrase used to encrypt the column would have to be shared with all users and applications that need to store or retrieve data in the CreditCard_encrypt table. A shared passphrase like this can be easily compromised, and then the data is visible to anyone who can gain access to the database. It is usually more secure to encrypt data using a symmetric key or certificate.

Encrypting Columns Using a Certificate One solution to the problem of encrypting using a shared passphrase is to encrypt the data using a certificate. A primary benefit of certificates is that they relieve hosts of the need to maintain a set of passwords for individual subjects. Instead, the host merely establishes trust in a certificate issuer, which may then sign an unlimited number of certificates. Certificates can be created within SQL Server 2008 using the CREATE CERTIFICATE command. The certificate created is a database-level securable that follows the X.509 standard and supports X.509 V1 fields. The CREATE CERTIFICATE command can load a certificate from a file or assembly, or it can also generate a key pair and create a self-signed certificate. The ENCRYPTION BY PASSWORD option is not required; the private key of the certificate is encrypted using the database master key. When the private key is encrypted using the database master key, you do not have to specify a decryption password when retrieving the data using the certificate. The first step is to create the certificate with the CREATE CERTIFICATE command: USE AdventureWorks2008R2; CREATE CERTIFICATE BillingDept01 WITH SUBJECT = ‘Credit Card Billing’ GO

After you create the certificate, the next step is to create a symmetric key that will be encrypted by the certificate. You can use many different algorithms for encrypting keys. The supported encryption algorithms for the symmetric key are DES, TRIPLE_DES, RC2, RC4, RC4_128, DESX, AES_128, AES_192, and AES_256. The following code creates a symmetric key using the AES_256 encryption algorithm and encrypts it using the BillingDept01 certificate: USE AdventureWorks2008R2; CREATE SYMMETRIC KEY BillingKey2010 WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE BillingDept01; GO

Download from www.wowebook.com

Column-Level Encryption

347

Now you empty out the rows inserted previously in the CreditCard_encrypt table using the PassPhrase encryption method by truncating it: USE AdventureWorks2008R2; Truncate table Sales.CreditCard_encrypt

12

Next reinsert rows from the CreditCard table, this time using the symmetric key associated with the certificate to encrypt the data using the EncryptByKey function. The EncryptByKey function requires the GUID of the symmetric key as the first parameter. You can look up this identifier by running a query against the sys.symmetric_keys table or simply use the KEY_GUID() function, as in this example: USE AdventureWorks2008R2; -- First, decrypt the key using the BillingDept01 certificate OPEN SYMMETRIC KEY BillingKey2010 DECRYPTION BY CERTIFICATE BillingDept01 -- Now, insert the rows using the symmetric key -- encrypted by the certificate insert Sales.CreditCard_encrypt ( CardType, CardNumber_encrypt, ExpMonth, ExpYear, ModifiedDate ) select top 5 CardType, CardNumber_encrypt = EncryptByKey(KEY_GUID(‘BillingKey2010’), CardNumber), ExpMonth, ExpYear, ModifiedDate from Sales.CreditCard

If you examine the contents of the CreditCard_encrypt table, you can see that they have been encrypted: select * from Sales.CreditCard_encrypt go CreditCardID -----------1 2

CardType ------------SuperiorCard Distinguish

CardNumber_encrypt --------------------0x0046C380E7A27749... 0x0046C380E7A27749...

ExpMonth -------11 8

ExpYear ------2006 2005

ModifiedDate ----------2007-08-30 2008-01-06

Download from www.wowebook.com

348

CHAPTER 12

3 4 5

Data Encryption

ColonialVoice 0x0046C380E7A27749... 7 ColonialVoice 0x0046C380E7A27749... 7 Vista 0x0046C380E7A27749... 4

2005 2006 2005

2008-02-15 2007-06-21 2007-03-05

Now, an authorized user that specifies the appropriate certificate can retrieve the data by using DecryptByKey function: USE AdventureWorks2008R2; OPEN SYMMETRIC KEY BillingKey2010 DECRYPTION BY CERTIFICATE BillingDept01 select CardType, CardNumber = convert(nvarchar(25), DecryptByKey(CardNumber_encrypt)), ExpMonth, ExpYear, ModifiedDate from Sales.CreditCard_encrypt go CreditCardID -----------1 2 3 4 5

CardType -------------SuperiorCard Distinguish ColonialVoice ColonialVoice Vista

CardNumber -------------33332664695310 55552127249722 77778344838353 77774915718248 11114404600042

ExpMonth -------11 8 7 7 4

ExpYear ------2006 2005 2005 2006 2005

ModifiedDate ----------2007-08-30 2008-01-06 2008-02-15 2007-06-21 2007-03-05

When you are done using a key, it is good practice to close the key using the CLOSE SYMMETRIC KEY statement: CLOSE SYMMETRIC KEY BillingKey2010

The keys defined in a database can be viewed through the system catalog table, sys.symmetric_keys: select name, pvt_key_encryption_type, issuer_name, subject, expiry_date = CAST(expiry_date as DATE), start_date = CAST(start_date as DATE) from sys.certificates go name pvt_key_encryption_type issuer_name subject expiry_date start_date ------------- --------------------- ------------------------------------- ----------- ----------

Download from www.wowebook.com

Column-Level Encryption

BillingDept01 MK Credit Card Billing 2011-05-01

349

Credit Card Billing 2010-05-01

The certificates defined in a database can be viewed through the system catalog tables, sys.certificates:

12

select name, key_length, key_algorithm, algorithm_desc, create_date = CAST(create_date as DATE), modify_date = CAST(create_date as DATE), key_guid from sys.symmetric_keys go name key_length key_algorithm algorithm_desc create_date modify_date key_guid ------------------------ ----------- ------------- ------------------------ ----------- -----------------------------------##MS_DatabaseMasterKey## 128 D3 TRIPLE_DES 2010-04-30 2010-04-30 A3550B00-6BAE-41E2-A1BC-D784DC35779E BillingKey2010 256 A3 AES_256 2010-04-30 2010-04-30 10C5C800-0B4C-44C2-9F71-5415007C2E81

If the usage of the key and certificate are no longer needed, they should be dropped from the database: DROP SYMMETRIC KEY BillingKey2010 DROP CERTIFICATE BillingDept01

NOTE There is a lot more information about column-level encryption and key management that could be discussed at this point, but such discussion would be beyond the scope of this chapter; our intent here is to merely introduce the concepts of data encryption. For more information on column-level encryption, refer to SQL Server 2008 Books Online.

Download from www.wowebook.com

350

CHAPTER 12

Data Encryption

Transparent Data Encryption As mentioned previously, transparent data encryption (TDE) is a new feature introduced in SQL Server 2008 that allows an entire database to be encrypted. Unlike column-level encryption, in TDE the encryption and decryption of data is performed automatically by the Database Engine, and this is fully transparent to the end user and applications. No changes to the database or applications are needed. Consequently, TDE is the simpler choice when bulk encryption of data is required to meet regulatory compliance or corporate data security standards. The encryption of a database using TDE helps prevent the unauthorized access of data in the scenario in which physical media or backups have been lost or stolen. Transparent data encryption uses a database encryption key (DEK) for encrypting the database. The DEK is stored in the database boot record and is secured by a certificate stored in the master database. The database master key is protected by the service master key, which is in turn protected by the Data Protection API. When TDE is enabled on a database, attaching data files to another SQL Server instance or the restoring of a backup to another SQL Server instance is not permitted until the certificate that was used to secure the DEK is available.

NOTE Optionally, the DEK can be secured by an asymmetric key that resides in a Hardware Security Module with the support of Extensible Key Management. The private key of the certificate is encrypted with the database master key that is a symmetric key, which is usually protected with a strong password.

For example, if a hard drive that contains database files is stolen, without TDE, those database files can be attached in another SQL Server instance, thus allowing access to the nonencrypted data in those files. With TDE, the data and log files are automatically encrypted, and the data within these files cannot be accessed without an encryption key. Additionally, backups of databases that have TDE enabled are also encrypted automatically. We’re all familiar with stories about how backup tapes containing sensitive information have been lost or stolen. With TDE, the data in the backup files is completely useless without also having access to the key used to encrypt that data. The encryption and decryption of data with TDE are performed at the page level as data moves between the buffer pool and disk. Data residing in the buffer pools is not encrypted. TDE’s specific purpose is to protect data at rest by encrypting the physical files of the database, rather than the data itself. These physical files include the database file (.mdf), transaction log file (.ldf), and backup files (.bak). Data pages are encrypted as they are written from the buffer pool to the database files on disk. Conversely, the data is decrypted at the page level when the data is read in from the files on disk into the buffer pool. The encryption and decryption are done using a background process transparent to the database user. Although additional CPU resources are required to implement TDE, overall, this approach offers much better performance than column-level encryption. According to Microsoft, the performance hit averages only about 3–5%.

Download from www.wowebook.com

Transparent Data Encryption

351

TDE supports several different encryption options, such as AES with 128-bit, 192-bit, or 256-bit keys or 3 Key Triple DES. You make your choice when implementing TDE.

Implementing Transparent Data Encryption 12

Like many encryption scenarios, TDE is dependent on an encryption key. The TDE database encryption key is a symmetric key that secures the encrypted database. The DEK is protected using a certificate stored in the master database of the SQL Server instance where the encrypted database is installed. Implementing TDE for a specific database is accomplished by following these steps: . Create a master key. . Create or obtain a certificate protected by the master key. . Create a database encryption key and protect it by the certificate. . Configure the database to use encryption. Listing 12.1 demonstrates the commands needed to encrypt the AdventureWorks2008R2 database, including the creation of a master key, certificate, and DEK protected by the certificate.

LISTING 12.1 Encrypting the AdventureWorks2008R2 Database USE master; GO --Create the master key which is stored in the master database CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘mystrongpassword$$’; GO -- Create a certificate that is also stored in the master -- database. This certificate will be used to encrypt a user database CREATE CERTIFICATE MyCertificate with SUBJECT = ‘Certificate stored in Master Db’ GO -- Create a Database Encryption Key (DEK) that is based -- on the previously created certificate -- The DEK is stored in the user database USE AdventureWorks2008R2 GO CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE MyCertificate GO

Download from www.wowebook.com

352

CHAPTER 12

Data Encryption

-- Turn the encryption on for the AdventureWorks2008R2 ALTER DATABASE AdventureWorks2008R2 SET ENCRYPTION ON GO

After you enable TDE, you might want to monitor the progress of the encryption. This can be done by running the following query: SELECT DBName = DB_NAME(database_id), encryption_state FROM sys.dm_database_encryption_keys ; GO DBName -------------------tempdb AdventureWorks2008R2

encryption_state ---------------3 3

This query returns the database encryption state. A database encryption state of 2 means that encryption has begun, and an encryption state of 3 indicates that encryption has completed. When the tempdb database and user database you are encrypting reach a state of 3, the entire user database and tempdb database are encrypted. When TDE is enabled for a given database, encryption is applied to a variety of files related to the database, including the following: . Database Data Files—All data files that contain the database data are encrypted. These files typically have the extension .mdf or .ndf. . Database Log Files—The transaction log files are encrypted so that no clear text is visible in the files. These files typically have the extension .ldf. . Database Backups—All database backups, including full, differential, and log, are encrypted. . Tempdb—If any databases on a server are encrypted with TDE, the tempdb database is also encrypted. In addition to these files, you can also manually enable TDE on the distribution and subscriber database involved in replication. This encrypts a portion of data involved in replication, but there are still some unencrypted files. Snapshots from snapshot replication as well as the initial distribution of data for transactional and merge replication are not encrypted.

Managing TDE in SSMS You can also view and manage transparent data encryption in SQL Server Management Studio. To do so, right-click on the database in the Object Explorer for which you want to configure TDE and select Tasks; then select Manage Database Encryption. If you are setting up the initial configuration for TDE in a database, you see a dialog like that shown in Figure 12.2.

Download from www.wowebook.com

Transparent Data Encryption

353

12

FIGURE 12.2 Enabling TDE in SSMS. The options available in this dialog correspond to commands shown in Listing 12.1. You specify the encryption algorithm to be used and the server certificate used to protect the database encryption key. When you are ready to enable TDE for the database, put a check mark in the Set Database Encryption On check box. If TDE is already enabled for a database, the dialog changes to provide you with options to re-encrypt the database encryption key and to regenerate the DEK using a different encryption algorithm. You can also enable/disable database encryption (see Figure 12.3). A second page displays the current TDE properties and encryption state of the database (see Figure 12.4).

Backing Up TDE Certificates and Keys The most important issue to consider when using TDE is that you must back up and retain the certificate and private key associated with the encryption. If these things are lost or unavailable, you are not able to restore or attach the encrypted database files on another server. The following warning message displayed after creating a certificate drives home this point: Warning: The certificate used for encrypting the database encryption key has not been backed up. You should immediately back up the certificate and the private key associated with the certificate. If the certificate ever becomes unavailable or if you must restore or attach the database on another server, you must have backups of both the certificate and the private key or you will not be able to open the database. Backup up the certificate and private key

Download from www.wowebook.com

354

CHAPTER 12

Data Encryption

FIGURE 12.3 Modifying TDE properties in SSMS.

FIGURE 12.4 Viewing TDE properties in SSMS. Backing up the certificate, private key, and master key for the server is relatively straightforward. An example of backing up the master key is shown in the following SQL statement: BACKUP MASTER KEY TO FILE = ‘c:\mssql2008\backup\masterkey’ ENCRYPTION BY PASSWORD = ‘somekeybackuppassword$$’

Download from www.wowebook.com

Transparent Data Encryption

355

Backing up the certificate and associated private key also uses the BACKUP command. The following example backs up the certificate created in Listing 12.1: BACKUP CERTIFICATE MyCertificate TO FILE = ‘c:\mssql2008\backup\MyCertificate’ WITH PRIVATE KEY ( FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’ , ENCRYPTION BY PASSWORD = ‘somecertbackuppassword$$’ )

12

If you want to restore a database backup on another server instance, a master key for the server must exist. If one does not exist, you can create one by using the CREATE MASTER KEY ENCRYPTION syntax. After creating the master key, you are able to create the TDE certificate from a backup of the certificate from the original SQL Server instance, as shown in the following example: CREATE CERTIFICATE MyCertificate FROM FILE = ‘c:\mssql2008\backup\MyCertificate’ WITH PRIVATE KEY (FILE = ‘c:\mssql2008\backup\MyCertificatePrivateKey’, DECRYPTION BY PASSWORD = ‘somecertbackuppassword$$’)

After the certificate is restored on the other server instance, you can restore the encrypted database backup. At this point, the restore can be performed just as you would restore any unencrypted database backup. The restored database is also encrypted and behaves like the original TDE database. TDE is a relatively simple and effective way to encrypt and protect your data. Other encryption methods that exist with SQL Server can protect different elements of your database. Encryption can be applied to columns of data, an entire table, as well as the communication that occurs between databases and the clients that access them. The level of encryption and need to use it depend on the type of data you are securing.

Limitations of TDE Although TDE offers many benefits over column-level encryption, it has some of its own limitations, which are important to consider. They include . TDE is not granular like column-level encryption. The entire database is encrypted, but only on disk. Sensitive data such as Social Security numbers or credit card numbers can be seen by anyone who has permission to access those columns. TDE also does not prevent DBAs from viewing any data in the database. . TDE does not protect communications between client applications and SQL Server. Network encryption methods should be used to protect sensitive data flowing over the network. . FILESTREAM data is not encrypted. . When any one database on a SQL Server instance has TDE enabled, the tempdb database is also automatically encrypted. This can affect performance for both encrypted and nonencrypted databases running on the same instance.

Download from www.wowebook.com

356

CHAPTER 12

Data Encryption

. Databases encrypted with TDE can’t take advantage of SQL Server 2008’s new backup compression. If you want to take advantage of both backup compression and encryption, you have to use a third-party application, such as Idera's SQL Safe Backup or Redgate's SQL Backup, which both have the capability to both compress and encrypt backups.

Column-Level Encryption Versus Transparent Data Encryption So is column-level encryption or transparent data encryption the right solution for your systems? Both column-level encryption and transparent data encryption provide a means of obfuscating sensitive data to protect it from unauthorized access. However, they do so in different ways. TDE prevents the unauthorized access of the contents of the database files and backups, but does not protect sensitive data within the database from being viewed by authorized users or database administrators. Column-level encryption provides more granular control over the data being encrypted but is not transparent to your applications. Table 12.1 lists the similarities and differences between column-level encryption and TDE.

TABLE 12.1 Comparison of Column-Level Encryption and Transparent Data Encryption Features/Limitations Column-Level Encryption

Transparent Data Encryption

Data is encrypted on disk and backups

Yes

Yes

Supports HSMs

Yes

Yes

Data level of encryption

Granular, at the column level

Encrypts the entire database only

User level of encryption

Encrypted data can be restricted at the user level on a need-to-know basis

Any user with sufficient database permissions can view encrypted data

Impact on applications

Database applications need to be modified

Completely transparent to applications and end users

Indexing of encrypted data

Encrypted columns cannot be indexed

No restrictions on indexes

Performance impact

May be significant depending on the type of encryption key used

Small impact on performance (3–5%)

For some organizations, you might want to consider implementing both column-level encryption along with TDE for a database. Although this combination is more complex to set up and administer, it offers greater security and encryption granularity than does either method used alone. TDE protects the database files and backups from unauthorized

Download from www.wowebook.com

Summary

357

access, whereas column-level encryption protects sensitive data within the database from being accessed by authorized users, including DBAs. Implementing TDE in conjunction with cell-level encryption provides a layered approach to data security, which enhances its effectiveness.

12

The main disadvantage to implementing column-level encryption is that it isn’t transparent to the end-user applications. In addition to requiring changes to the database schema, it also requires changes in the applications to include the proper function calls to encrypt and decrypt the data as it is stored and retrieved. Another issue with column-level encryption is that you cannot index encrypted columns, nor can you generate statistics on the encrypted columns. This can affect query performance because search arguments that reference encrypted columns cannot be optimized. For this reason, typically only the most sensitive columns of a table that do not need to be indexed are encrypted.

Summary Chapter 11, “Security and User Administration,” discusses methods to secure and control the access to your SQL Server data via login and user security to prevent unauthorized users from accessing your SQL Server instances and databases. Column-level encryption, as discussed here, takes these protections a step further by preventing authorized users, such as your database or server administrators, from viewing sensitive data within a database. Transparent data encryption protects all your data from being accessed by unauthorized users in the event that your database files or backups are lost or stolen. Chapter 13, “Security and Compliance,” discusses security methods available in SQL Server and how they can be implemented to meet your security compliance requirements. It also covers the new data auditing methods you can use to track changes to your data and database objects.

Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

13

Security and Compliance

IN THIS CHAPTER . Exposure and Risk . Across the Life Cycle . The Security Big Picture . Identity Access Management Components . Compliance and SQL Server

As you complete what you think is your best database

. SQL Server Auditing

design and application on the planet, you stop yourself dead in your tracks and say, with hesitation, “What about the security and compliance implications?” Now is not the time to start thinking about these aspects. In fact, as we show you in this chapter, you should start considering these issues from the beginning of the development life cycle.

. Setting Up Auditing via T-SQL . SQL Injection Is Easy to Do

With the growth of software and database development in the world, there is a rise in the demand for security best practices to achieve the goals of creating secure software. Best practices must start from the glass and reach through the application, to the database layer, and even to the operating system and the physical file levels. Best practices are also meant to be scrutinized for overall results on the basis of the level of security, efficiency, and complexity they provide. How much and which best practice to use can also be considered on the basis of confidentiality, integrity, and availability (which is known as CIA). Software security must be considered at many layers and is additive in nature— each layer providing the necessary security and compliance of one part of the bigger puzzle. To get it right, you must “design in” security from the beginning. In this chapter we discuss security aspects in conjunction with a traditional development life cycle; this includes aspects such as vulnerability assessments, threat modeling, and identity management. You can take many steps to prevent SQL injection, for example, and other vulnerabilities. We also talk about compliance aspects in regards to global and regional regulations such as the Health Insurance Portability and Accountability Act (also known as HIPAA),

Download from www.wowebook.com

360

CHAPTER 13

Security and Compliance

the Payment Card Industry (PCI) standards, and data privacy regulations such as Personally Identifiable Information (PII). We also provide a simple example of using the SQL Server Auditing feature that can be extremely useful in identifying and monitoring compliance of access and usage at the SQL Server database or object levels. And lastly, we show you how to do some malicious damage with SQL injection. We show you how to do this so that you can learn how to prevent it. But first, let’s try to better understand what exposure and risk are all about.

Exposure and Risk You must understand that security is really “risk management” or “risk mitigation.” It can be very difficult to completely secure an application or environment. However, you are able to control or limit damage by following certain practices. Your data and applications have different levels of security requirements depending on the exposure endpoints (an exposure endpoint is defined by who is using the application and data). Figure 13.1 shows a simple matrix of data and application sensitivity versus the exposure endpoints of that application. By definition, the more external facing your application is (such as to the Internet) and the higher the sensitivity of the data involved, the higher risk precautions you have to take.

Data/Application

Exposure End Points Limited Exposure (Internal/Intranet Only)

Exposable (External Internet)

Low Sensitivity (Public)

Low Risk

Medium Risk

Medium Sensitivity (Confidential)

Medium Risk

High Risk

High Sensitivity (Highly Confidential)

High Risk

High Risk

FIGURE 13.1 The exposure endpoints “risk” by category of data/application sensitivity. Let’s say you have an internal company SQL Server–based application that has only very low sensitivity data (public-facing data such as benefits data). You freely share this type of data with whoever wants to see it. The types of controls or rigor are likely very small for this type of application—perhaps as simple as an integrated Active Directory with your SQL Server and read-only access for all user roles. On the other side of the spectrum, you may have applications generating financial transactions with credit card data that must have zero vulnerabilities, encrypt data across the network, encrypt data at rest within SQL Server, and use the new SQL auditing feature for database-level monitoring of all data accesses.

Download from www.wowebook.com

Across the Life Cycle

361

A big part of the risk management aspect is understanding what the impact of this risk would be if your system is compromised. It is always best to identify this aspect up front in some type of risk “cost” or “impact.” Many financially strong companies have gone out of business as a result of security breaches they had not anticipated or considered. It is better to plan for such risk from the beginning.

13

Another aspect to consider is staying compliant with data you use in nonproduction environments. Often, companies needlessly put their entire livelihood at risk by using live data values in nonproduction environments. If PII or other company-sensitive data is available in your nonproduction environments (such as in Development, Test, and Quality Assurance platforms), you are violating laws and regulations around the globe and putting your company and your customers at risk. You can easily employ data subsetting and masking to your nonproduction data. Putting this practice in place is a great idea.

Across the Life Cycle We introduce formal development life-cycle concepts in other chapters. In those chapters, such as Chapter 41, “A Performance and Tuning Methodology,” the emphasis is on designing in performance from the beginning. A part of good design is how you have complied with laws and regulations, how you have protected the data you access or store, how you have secured your application and data, and how you have verified all this. For these reasons, we provide some details and describe what must be done across the development life cycle to properly address security and compliance. We term this process the “risk mitigation” of what you build. Figure 13.2 shows a formal waterfall development life cycle with key security and compliance items identified at each relevant phase. Getting into the risk mitigation business starts by giving security and compliance the full commitment and recognition they deserve. This step starts with a clear statement of security and compliance objectives as you are sizing up your application in the assessment phase. These objectives often take the form of stating how you will address the rules, laws, data sensitivities, access considerations, and eventual end users (and the countries they reside in). Next, you focus on the clear identification and specification of all security and scope of compliance. You look at the details of exactly where the compliance or security lines need to be, determine how you must fully address them, and clearly identify which must be adhered to for your application. Often, organizations have security information analysts and data privacy groups that contribute to this part of your development efforts. They, in turn, bring others to the table, such as legal, auditing, and even corporate communications folks. As you go into the design phase, you must complete the full analysis and design of every security and compliance element for your application. As part of this analysis and design phase, you should start enumeration test plans that must be completely verified before your application can be delivered to its users.

Download from www.wowebook.com

CHAPTER 13

362

Development Life Cycle Phases

Security and Compliance

Security & Compliance Statement of Security & Compliance Objective

Assessment Initiate

Identify & Design

Design

Security & Compliance Scope Identified

Ri

sk

Prototype

Security & Compliance Analysis & Design

M

itig

Security & Compliance Test Plans

at

ion

Security & Compliance Prototyping

/C

om

Code & Test

pli

Security & Compliance Code/Test

an

Construct

ce

System Test & Acceptance Deploy

Security & Compliance Acceptance

Implementation

FIGURE 13.2 Security and compliance across the development life cycle. In the prototyping phase, you have a chance to start demonstrating how security, access, privacy, and compliance will be addressed. This phase is very important because of all the complications, rules, laws, and issues that are at stake and must be verified. We have not run a development effort without extensive prototyping of as many security and compliance tests as are humanly possible. It is this risk that must be fully addressed early and never as an afterthought! As you fully code and test your database and application, you must never skip the security testing and validation. It is best to put these tests first in your overall test plans. As your application completely takes shape, a complete application scan for vulnerabilities can be performed. Popular tools such as AppScan are essential tools of the trade for performing this task. Finally, as you near deployment, you should make sure all the security and compliance acceptance tests are met. You need to capture these results fully because the successful completion of this part of acceptance testing can be shown in SOX compliance auditing.

The Security Big Picture Now, let’s turn to the bigger security and compliance picture that shows many of the layers involved in a broader security enforcement approach. Figure 13.3 shows many of these layers, starting at the top with solid guidelines, policies, and compliance-reporting capabilities. You must start with these components to guarantee that you are aware of what must be done and have a way to show you are doing what the policies outline. Next, you must define and create other aspects of security and compliance, such as security event management, alerting and monitoring, complete threat models, and vulnerability

Download from www.wowebook.com

The Security Big Picture

Security Standards & Guidelines

Business Continuity/Disaster Recovery Vulnerability Assessment

Database Security

Security Compliance Reporting

Security Event Management

Threat Modeling

Auditing

Alerts and Monitoring

Identity Management/SSO

Distributed Denial of Service (DDoS)

Access Control Lists (ACLs)

File Integrity Checking (MD5, SH1, ..)

Policy Compliance

Autonomous System

Network Access Control

13

Intrusion Detection/Intrusion Prevention

Internet Protocol

363

Disk Encryption (host)

FIGURE 13.3 Security enforcement layers and components. assessment objectives. These types of components must also reach into and be enforceable across major events such as disaster recovery (to ensure business continuity) and continue to support what you have deployed around identity management and single sign-on. The next inner layer is where your database security is defined, along with any databaselevel or database instance–level auditing you put into place. It is also this layer where messy things such as SQL injection can occur and Denial of Service often surfaces. Getting some type of intrusion detection and prevention scheme into place is essential. Clear access controls are also essential. Later in this chapter, we describe some basic SQL Server–based auditing at the database level. Chapters 11, “Security and User Administration,” and 12, “Data Security,” also describe much of what you must do around overall security administration and database-level security. Figure 13.3 highlights these two critical areas. Moving further down the layers of security, you find file integrity checking, secure Internet protocols, disk-level encryption, and other security-enhancing items. They all work together to bring you what should be a more secure (and compliant) place to deploy your applications within. With SQL Server 2008 R2, you are essentially out-of-the-box ready to do absolutely nothing. In other words, Microsoft has taken the policy to “allow nothing,” and any access, execution, or other action must be explicitly granted. Believe it or not, this is the right thing to do. This approach ensures that all objects and accesses are explicitly declared and, by definition, are fulfilling security and many compliance regulations.

Download from www.wowebook.com

364

CHAPTER 13

Security and Compliance

The Open Web Application Security Project (OWASP; www.owasp.org) lists its recent top 10 application vulnerabilities as follows: . SQL Injection . Cross-Site Scripting . Broken Authentication and Session Management . Insecure Direct Object References . Cross-Site Request Forgery . Security Misconfiguration . Failure to Restrict URLs . Unvalidated Redirects and Forwards . Insecure Cryptographic Storage . Insufficient Transport Layer Protection

Identity Access Management Components One of the key areas identified in the security big picture (as you can see looking back at Figure 13.3) is identity management. It is key in the sense that well-managed identities are essential to well-managed security. There is a quite a bit to consider when talking about identities. Figure 13.4 shows a common “identity universe” for a company that has both internal- and external-facing applications. In other words, identities are both customers that interact with the business and internal identities such as employees and other workforce identities (contractors, temps, partners, and so on). Both sets of identities must be managed well, and often there are overlapping identities that require accesses (and identity management) in both areas (internal and external). Often, companies use one internal-facing LDAP directory such as Microsoft’s Active Directory for managing their internal identities and then another LDAP directory such as Sun One LDAP for managing all external-facing identities (for forums, eStore, and so on). Then they create triggers or synchronization jobs that do a “search before create” type of processing when new identities are created within either LDAP directory. Because overlap is rare, not much extra “create” overhead occurs, but when they do overlap, only one identity (such as a partner identity that might be in that company’s internal and external LDAP directories) gets created. This is effectively “mastering” the user identities. It is recommended that you consider both sources of identities at all times. You should also establish strict access roles for all identities with the least rights going to anonymous identities. More and more companies are also now moving to concepts such as Open ID, where a company can utilize the authentication and identification established by third-party Open ID providers and grant trust to these identities with very high confidence. The industry is moving this way fast. Figure 13.5 shows the logical components of identity access management.

Download from www.wowebook.com

Identity Access Management Components

365

Identity Universe Company Identities Internally-Facing Identities

Externally-Facing Identities

Partners (and their Contacts)

Employees App Store…

Customers Temps

(Registered/Subscription/Anonymous)

13

Opportunities Others

Social Networking Forums

Leads Prospects Mergers and Acquisitions

Mergers and Acquisitions

Touch/Use Internal Applications/Data

Mergers and Acquisitions

Sell/Service/Buy/Use Products, Services, Data

FIGURE 13.4 Identity universes (internal and external-facing applications).

Logical Components of Identity Access Management Applications/Access Points Identity Life-Cycle Management - User Management - Credential Management - Entitlement Management - Identity Integration - Provisioning/De-provisioning

Access Management - Authentication & SSO - Trust & Federation - Entitlements & Authorization - Security Auditing/Compliance - Identity Propagation - Impersonation & Delegation

Directory Services - Users - Groups - Credentials

- Attributes - Roles - Policies

Applications/Access Points FIGURE 13.5 Logical components of identity access management.

Download from www.wowebook.com

366

CHAPTER 13

Security and Compliance

This figure shows that you must carefully address full identity life-cycle management, which includes user ID management, credential management, entitlement management, identity integration (between multiple LDAPs), and provisioning and deprovisioning identities. Access management is all about authentication, single sign-on, authorization, and impersonation and delegation rules. And, the directory services themselves define the users, groups, all attributes (or elements) of a user or group, roles, policies to enforce, and credentials to be used. All applications and access points must be plugged in to this identity access management framework. All risk is minimized by a sound identity access management foundation.

Compliance and SQL Server On the global level, hundreds of compliance laws are in place that affect almost every aspect of data access, data protection, data movement, and even data storage. Countries such as Germany now have some of the most severe data compliance rules on the planet, such as strict control of how certain personal data is stored and what personal data can be stored; these rules even prohibit personal data from being transmitted (or moved) across German borders. If you are planning to create applications and databases that will span countries or contain sensitive or private data, you must “design in” the rules and enforcements from the beginning (as we have been stressing throughout this chapter). Let’s address the most common “sensitive” data: Personal Identifiable Information (or PII for short). PII data is at the center of most global data privacy laws and regulations. As you can see from a subset of the PII data model in Figure 13.6, PII data is any personal information that identifies an individual, such as name; address; driver’s license number; other government-issued identification (such as passport number); and even gender, ethnicity, and age. If you have any databases or applications that have this type of data in it, you are bound by local and/or regional laws and regulations whether you like it or not. It is the law. You must then protect this data in accordance with those regulations and laws; otherwise, you become liable for fines, lawsuits, or worse (risk exposure of that data could put you out of business). As you can also see in Figure 13.6, there are different sensitivity levels around PII data. Something like a person’s name is considered low sensitivity, whereas an employee ID is considered medium sensitivity. And marital status, gender, Social Security number, bank account number, driver’s license number, and passport number are considered high sensitivity and often must be treated with special care and feeding with capabilities such as encryption in transit and at rest (while stored in a table). Following is a list of some of the many laws and regulations that have been put into effect and that you will likely have to address in your application: . The Health Insurance Portability and Accountability Act (also known as HIPAA) was introduced in 1996 to protect critical health and patient information. HIPAA forces companies to strictly control data identified under its jurisdiction.

Download from www.wowebook.com

Compliance and SQL Server

367

High Sensitivity Sales Entity

Medium Sensitivity Low Sensitivity

Enterprise/SMB Customer Specifies Consumer Customer Name e on-K N "First Name" "Last Name"

Known by Consumer Customer

Installed Installed Made

Personnel Name on-K N "First Name" "Middle Name" "Last Name"

Purchases on-K N

Provided

Government Identification e on-K N "Social Security Number" "Passport Number" "Drivers License Number" "Other Government ID"

Made

Product "Purchase Date" "Purchase Amount" "Renewal Date"

Made

13

Known by

Identified via

has provided

Specifies

Personnel on-K N "Employee ID"

Referenced by

characterized by

Internal Contact Information on-K N "Office Phone Number" "Job Title" "Site Location"

Personnel Demographic on-K N BirthDate Gender "Marital Status" Children

Customer Contact Points provided

Billing Profile on-K N Customer Physical Address on-K N "Street Address" City State "Postal Code"

Customer Electronic Address

"Card Number" "Card Type" PIN "Security Code" Bank "Bank Account Number" "Bank Routing Number"

FIGURE 13.6 Personally Identifiable Information (PII). . The Sarbanes-Oxley Act (known as SOX), put into place in 2002, requires auditors to assess and report on the effectiveness of a company’s internal controls on information and extend into the authorization of access and updates to data. . The Gramm-Leach-Bliley Act (GLBA) of 1999 further defines steps that must be taken by financial institutions to protect, secure, and prevent access of core financial data. . California’s Information Practices Act of 2005 details strict controls around PII data, what needs to be encrypted, and laws surrounding breaches of controlled data. . The Children’s Online Privacy Protection Act, passed in 1998, focuses on the procedures to protect the confidentiality, security, and integrity of personal information collected from children. Other industry-oriented laws and regulations have emerged, such as the Payment Card Industry data security standard (PCI standard). It is focused on what must be done to ensure credit card information is secure from the moment a customer makes a purchase until the merchant disposes of the credit card transactions. Two great books on security and compliance are Cryptography in the Database by Kevin Kenan (2006, Addison-Wesley) and The Executive Guide to Information Security by Mark Egan (2005, Addison-Wesley). These books will make great focused additions to your technology library.

Download from www.wowebook.com

368

CHAPTER 13

Security and Compliance

SQL Server Auditing Introduced with SQL Server 2008 is the SQL Server Audit feature. This long-overdue feature now adds a great native auditing functionality into the SQL Server Database Engine.

NOTE The SQL Server Audit feature is available only in the SQL Server 2008 Enterprise and Developer Editions.

An audit is the combination of several elements into a single package for a specific group of server actions or database actions. The components of SQL Server Audit combine to produce an output that is called an audit. The SQL Server Audit feature in SQL Server 2008 is intended to replace SQL Trace as the preferred auditing solution. SQL Server Audit is meant to provide full auditing capabilities, and only auditing capabilities, unlike SQL Trace, which also serves for performance debugging. The SQL Server Audit feature is built on top of Extended Events, a new high-performance eventing infrastructure introduced in SQL Server 2008. SQL Server Audit leverages the performance benefits of Extended Events, which provides both asynchronous and synchronous write capabilities (by default, SQL Server Audit uses the asynchronous eventing model).

NOTE By default, the audit events are written to the audit target in an asynchronous fashion for performance reasons. When tighter guarantees of audit records being written to the audit log are required, you can select synchronous write, with the understanding that some amount of performance degradation should be expected. The choice of asynchronous or synchronous is controlled by the QUEUE_DELAY option of the CREATE AUDIT DDL.

SQL Server Audit is also tightly integrated with the Windows operating systems and can push (write) its audits to the Windows Application or Security Event Log. With SQL Server Auditing, you can set up auditing of just about any event or execution within SQL Server, and it can be as granular as you need (right down to a table and operation level). This capability is important because not only can you track all these events, but you can use this auditing capability to fulfill application and database audit compliance and look for patterns of misuse, or even specific “hot” objects that contain the most sensitive data in your database. As you can see in Figure 13.7, a branch under each database called Security contains several of the common security-related nodes that you’ve seen before (Users, Roles, Schemas, and so on). But now, there is a Database Audit Specifications branch from which you can set up and view the database audit specifications you have defined. You

Download from www.wowebook.com

SQL Server Auditing

369

can have as many specifications as you want, and again, they can be at varying levels of granularity.

13

FIGURE 13.7 The new Database Audit Specifications item in the SQL Server Management Studio (SSMS) Object Explorer.

Before you can set up a Database Audit Specification, however, you must first set up a SQL Server Audit object. To do this, you must use a couple of new entries in the Object Explorer under the Security folder at the SQL Server instance level: Audits and Server Audit Specifications. Essentially, three main objects describe audits in SQL Server 2008: . The Server Audit object—Used to describe the target for audit data, plus some toplevel configuration settings. This destination can be a file, the Windows Application log, or the Windows Security log. The Server Audit object contains no information about what is being audited—just where the audit data is going. Multiple Server Audit objects can be defined with each object independent from one another (that is, they can each specify a different destination). . The Server Audit Specification object—Used to describe what to audit at a server instance-wide level. A server audit specification must be associated with a Server Audit object to define where the audit data is written. There is a one-to-one relationship between the Server Audit Specification object and the Server Audit object. . The Database Audit Specification—Used to describe what to audit at a specific database level. Where the audit data is written is determined by the Server Audit object it is associated with. Each database audit specification can be associated with

Download from www.wowebook.com

370

CHAPTER 13

Security and Compliance

only one server audit. A server audit can be associated with audit specifications for multiple databases, but only one database audit specification per database. To create a new Server Audit object, right-click on the Audits item in Object Explorer and select New Audit (see Figure 13.8).

FIGURE 13.8 Creating a new Server Audit object in Object Explorer at the Server instance level. When you set up a Server Audit object, you specify where the audit information will be written to. In Figure 13.9, you can see that we are creating a server audit named NEW_SQL_Server_Audit and are defining it to use the Application log at the Windows operating system level as the audit destination. You can also choose to write to the Windows Security log or to a text file. Events written to the Application or Security Event log can be accessed with Event Viewer or with specialized Event log management software, such as Microsoft Systems Center Operations Manager.

NOTE Depending on the volume of audit targets being monitored, better performance may be achieved by using a file as the audit target rather than the Windows Event log. Also, when written to a file, the audit data is accessible through a built-in table-valued function (fn_get_audit_file), which allows the use of regular SELECT syntax to query the audit trail.

NOTE You can also configure the Audit object to shut down the SQL Server instance if, for whatever reason, SQL Server Audit is unable to write its audit events to the audit target. Although shutting down the server instance may seem drastic, doing so may be necessary for certain scenarios, to ensure that the server cannot operate without its activity being audited.

Download from www.wowebook.com

SQL Server Auditing

371

13

FIGURE 13.9 The Create Audit dialog. After you set up the Server Audit object, the next step is to go to the Database Audit Specifications folder, as shown in Figure 13.7, in the database for which you want to set up auditing. Right-click this folder and select New Database Audit Specification to bring up the dialog shown in Figure 13.10. This is where you define your database-level audits.

FIGURE 13.10 The Create Database Audit Specification dialog. In the Create Database Audit Specification dialog, you specify the name of the Database Audit object and the Server Audit object it will be running under. In this example, the Database Audit name is NEW_Database_Audit_Specification, and it will be running under

Download from www.wowebook.com

372

CHAPTER 13

Security and Compliance

the NEW_SQL_Server_Audit Audit object defined in Figure 13.9. In this example, the database audit is being set up to audit any SELECT statements (reads) run against the Employee table (which, of course, contains company-sensitive employee data) by any user (public). At this point you have created a Server Audit object and database audit specification associated with the server audit. However, neither of these audits is enabled. You can enable them by right-clicking on each and selecting Enable. As soon as the Server Audit object is enabled, it begins auditing and writing audit records to the specified destination (in this example, the Windows Application log).

NOTE If your SQL Server login is configured for a default database other than master, enabling the SQL Server Audit object via SSMS fails with the following message: Cannot alter a server audit from a user database. This operation must be performed in the master database.

If you receive this error, you need to enable/disable the server audit via T-SQL, as shown in Listing 13.1.

You can review the details by right-clicking on the Server Audit and selecting View Audit Logs or, if you are auditing to the Windows Application or Security Event Log, by opening the Windows Event Viewer directly. One of the advantages of opening the Audit log from within SSMS is that it automatically filters the log to show only SQL Server Audit events. In Figure 13.11, you can see that we’ve opened the Log File Viewer and selected to view the Application log (where we directed our SQL Server Audit to go). A few SELECT statements were run against the Employee table and, sure enough, the audit information of the SELECT statements shows up in the Application log. Within the Log File Viewer, you can filter your audit results or search them to look for patterns, specific violations, and so on. From the Log File Viewer, you also have the option of exporting the audit logs to a text file or to a comma-separated values (CSV) file. With a CSV file, you could import the audit logs into a database for further analysis and correlation. It’s up to your security and audit team to decide how these audits are to be used. In addition to database-level auditing of actions at the database level, you can also set up auditing of server-level events, such as management changes and logon and logoff operations. These are set up in the SSMS Object Explorer through the Server Audit Specifications item in the Security folder for the SQL Server instance (refer to Figure 13.8).

Setting Up Auditing via T-SQL Alternatively, you can set up auditing with T-SQL statements and also switch the audit off and on using the ALTER SERVER AUDIT command by using WITH (STATE=ON) or WITH (STATE=OFF), as shown in Listing 13.1.

Download from www.wowebook.com

Setting Up Auditing via T-SQL

373

13

FIGURE 13.11 Log File Viewer showing the audit events of a SQL Server Audit object. LISTING 13.1 Setting Up Auditing with T-SQL /* Create the SQL Server Audit object, and send the results to the Windows Application event log. */ USE master; go CREATE SERVER AUDIT NEW_SQL_Server_Audit TO APPLICATION_LOG WITH ( QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE); GO /* Create the Database Audit Specification object using an Audit event */ USE AdventureWorks2008R2; GO CREATE DATABASE AUDIT SPECIFICATION NEW_Database_Audit_Specification FOR SERVER AUDIT NEW_SQL_Server_Audit ADD (SELECT ON OBJECT::[HumanResources].[Employee] BY [public]) WITH (STATE = ON); GO

Download from www.wowebook.com

374

CHAPTER 13

Security and Compliance

/* Enable the audit. */ USE master; go ALTER SERVER AUDIT NEW_SQL_Server_Audit WITH (STATE = ON); /* Test the audit is working */ USE AdventureWorks2008R2; GO SELECT * from HumanResources.Employee; GO /* Disable the audit. */ USE master; GO ALTER SERVER AUDIT NEW_SQL_Server_Audit WITH (STATE = OFF); GO

It is recommended that you create your audit specifications with scripts so that you can easily manage them and not have to re-create them via SSMS dialogs.

SQL Injection Is Easy to Do As we previously stated, SQL injection is the number-one security vulnerability globally as reported and tracked by the Open Web Application Security Project (OWASP; www.owasp. org). Because of this continued vulnerability, we decided to show you how to do SQL injection. However, keep in mind that we are showing you how to do it so that you can prevent this situation from happening to you. You need to make sure you include the vulnerability checks as a part of your coding and design reviews. Then this will never happen to you. If you have a typical .NET forms application that prompts users to provide filter criteria to locate information, this is often a perfect place for hackers to add their own malicious code to do damage. Even your own employees might be hackers or want to cause harm. We call these folks “Evil SQL’ers.” The most common way SQL injection occurs is with the direct insertion of code into a variable that is part of a SQL statement. In other words, a user-defined variable is concatenated with a partially defined SQL statement and then subsequently executed as part of the application. The hacker adds a terminating character to the first part of the input and then follows it up with his or her own destructive SQL statement. Let’s consider the following simple Contact Name search application as an example. A .NET forms application might define a variable called ContactFirstName and then prompt the end user for a value to search for any contact’s first name that begins with a set of

Download from www.wowebook.com

SQL Injection Is Easy to Do

375

characters such as “Don.” Such an operation might result in finding “Don,” “Donald,” and “Donny” matching rows. The code might look like this: var ContactFirstName; ContactFirstName = Request.form (“ContactFirstName”); var sql = “SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] like ‘“ + ContactFirstName + “%’”;

The subsequent SQL code that would be submitted to SQL Server for execution would be as follows:

13

SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] Like ‘Don%’;

This code works perfectly. To test this code as if you are an “Evil SQL’er,” create a table named XtraContactsTable that you can pretend is your primary contacts table where all your company’s contacts are stored. Go ahead and create this empty table for this evil test. The simple CREATE statement could be CREATE TABLE [dbo].[XtraContactsTable] ([ContactFirstName] [nchar](10) NULL) ON [PRIMARY];

To be really evil, attempt to drop this table and cause severe damage to this company using the SQL injection method. Now, at the applications prompt for a contact first name, you, acting as the evil SQL’er, can instead type the following: Don’; drop table [dbo].[XtraContactsTable] --

The subsequent SQL code that is sent to SQL Server for execution is SELECT * FROM [AdventureWorks].[Person].[Contact] WHERE [FirstName] Like ‘Don%’; drop table [dbo].[XtraContactsTable] --

The first part of the query is executed, followed by the DROP TABLE statement. Try this with the table you just created. After you execute the entire “valid” SQL statement, you see rows returned from the first part of the query, and the drop of the XtraContactsTable is also executed. If the evil code had simply used the Employee table name or the Contact table name, all your company’s most sacred data would be gone in a flash. That is SQL injection! It is easier to do than you think. And now you know how to do it, which means you must also prevent this and other SQL injection vulnerabilities from the beginning. In this case, you should write code to reject quotation marks, specific delimiters (such as ;), and comment characters such as - - and /*...*/. We have included this SQL code example on the CD with this book as well. Another popular method by Evil SQL’ers is to put a nasty piece of code into text or char data that will be stored as data in a table. When (or if) the data is ever used as part of a

Download from www.wowebook.com

376

CHAPTER 13

Security and Compliance

SQL statement (and concatenated to SQL code as just demonstrated), the code in the data is executed. Pretty tricky! Sort of like a time bomb waiting to explode.

FIGURE 13.12 Reprinted with permission from xkcd.com.

NOTE For additional examples of SQL injection and SQL coding tips to help prevent SQL injection attacks, see Chapter 43, “Transact-SQL Programming Guidelines, Tips, and Tricks.”

Summary As stated earlier, best practices for security and compliance must start from the glass and reach through the application, to the database layer, and even to the operating system and the physical file levels. This chapter describes an orderly process to follow as you develop applications that include security and compliance reviews and add testing all along the way. You should never wait until your application is done to start checking for security vulnerabilities; verify adherence to compliance rules or regulations; or determine what data needs to be protected, encrypted, or perhaps not even stored. Taking advantage of the new SQL Server Auditing feature can be extremely useful in identifying and monitoring compliance of access and usage at the SQL Server database or object levels. Now you know how to do a little damage via SQL injection. You should also know how to prevent this type of damage. Remember, software security is really risk management. It is this risk that must be analyzed thoroughly. After you analyze it, responding in a known situation is always easier. Risks can appear due to architectural problems or with holes in applications (such as with SQL injection). The main aim of software security is to just fall safely and carefully and to limit the damage. We don’t want to read about your failing in the newspaper or on Twitter. In the next chapter, you learn about database backup and restores. To fix damage caused by security issues like those described in this chapter, you may have to restore your database to its state before the attack occurred. We hope that this never happens to you.

Download from www.wowebook.com

CHAPTER

14

Database Backup and Restore

IN THIS CHAPTER . What’s New in Database Backup and Restore . Developing a Backup and Restore Plan . Types of Backups . Recovery Models

You need to perform database backups to protect your investment in data. Making backups may seem mundane, but consider Murphy’s Law (“If anything can go wrong, it will”) when you are considering your backup plan. For example, if you forget to add a new database to your backup plan, that database will crash. If you neglect to run a test restore of your backups, those backups will not restore properly. This type of thinking may seem a bit defeatist, but it can help you create a robust backup solution that allows you to sleep comfortably knowing you have a good plan.

. Backup Devices . Backing Up a Database . Backing Up the Transaction Log . Backup Scenarios . Restoring Databases and Transaction Logs . Restore Scenarios . Additional Backup Considerations

Fortunately, SQL Server comes with many different backup and restore options you can use to develop a robust backup plan and avoid those worst-case scenarios. This chapter covers the key considerations in developing a backup and restore plan and then covers the options available with SQL Server to implement that plan.

What’s New in Database Backup and Restore The majority of the backup and restore features that existed in SQL Server 2005 still exist in SQL Server 2008. A few options, however, have been eliminated or deprecated. For example, the backup options used to truncate the transaction log in prior versions are no longer supported. Specifically, the NO_LOG and TRUNCATE_ONLY options have been eliminated. The alternative for performing this kind of operation is to set the database recovery model to simple. Several other deprecated features are still available in SQL Server 2008 but will be removed in a future version of SQL

Download from www.wowebook.com

378

CHAPTER 14

Database Backup and Restore

Server. The Tape backup option is one example. The option to set a password on a backup or media-set will be removed in the next version of SQL Server. The protection provided by these passwords is weak, which is the reason they are being removed. The biggest enhancement in backup and restore is the ability to create a compressed backup. Compressed backups use less space and can be created in less time than conventional backups. The creation of compressed backups can be established server-wide or can be enabled on a single backup using the COMPRESSION option. This feature is available only in SQL Server 2008 Enterprise and Developer Editions.

Developing a Backup and Restore Plan Developing a solid backup and restore plan for SQL Server is one of the most critical tasks an administrator performs. Simply put, if you are a database administrator (DBA) and have a significant loss of data in a database you are responsible for, your job may be on the line. You need to carefully examine the backup needs of your organization, document those needs, and deliver a plan that defines how your backup and restore plan will meet those needs. The best place to start in identifying the backup requirements is to ask the right questions. The following questions can help drive out the answers you need: . How much data loss is acceptable? For example, if you choose to do only full database backups each night, would it be acceptable to lose all the data added to the database during the next day? This could happen if you had a failure and had to restore to the last full backup. . What is the nature of the database? For example, is the database used for a data warehouse, or is it used for a high-volume transaction processing system? . How often does the data in the database change? Some databases may change very little or not at all during the day but sustain heavy batch updates during the evening. . What is the acceptable recovery time in the event a database must be restored from previous backups? This question is directly related to the amount of downtime acceptable for the applications using the database. . Is there a maintenance window for the application/database? The maintenance window is typically a period of time when the database or server can be taken offline. What are the exact times of the maintenance windows? . What is the size of the database(s) you need to back up? . What media is available for backup, and where is the media located? . What is the budget for database backup and recovery? If no budget has been established, the answers to some of the preceding questions drive the cost of the solution. Some of the questions that need to be asked to come up with a good backup and restore plan may raise some eyebrows. For example, you may find that the answer you get for the question “How much data loss is acceptable?” is “None!” Don’t panic. There are sensible

Download from www.wowebook.com

Types of Backups

379

responses for these types of answers. The reality is that you can deliver a solution that virtually eliminates the possibility of data loss—but that comes at a cost. The cost may come in the form of real dollars as well as other costs, such as performance or disk space. As with many other technical solutions, you need to consider trade-offs to come up with the right plan.

NOTE

14

Many of the questions that relate to database backup and restore are related to system backups as well. System-wide backups, which happen independently of SQL Server backups, capture all or most of the files on a server and write them to appropriate media. These server backups are often performed by DBAs, system administrators, and the like. You should consider having the person or persons responsible for the system backups present when asking the database backup and restore questions. This will help with the coordination and timing of the backups.

When you have the answers to these questions, you need to document them, along with your recommended solution. You should identify any assumptions and make sure to outline any portion of the plan that has not met the requirements. The good news is that the implementation of the plan is often less difficult than coming up with the plan itself. Microsoft provides a myriad of tools to create database backups that can meet the needs of your organization. The remainder of this chapter focuses on the details required to finalize a solid backup and recovery plan.

Types of Backups SQL Server offers several different types of backups you can use to restore a database to a former state. Each of these backups uses a file or set of files to capture the database state. The files are found outside the SQL Server database and can be stored on media such as tape or hard disk. As described in the following sections, these backup types are available with SQL Server 2008: . Full database backups . Differential database backups . Partial backups . Differential partial backups . File and filegroup backups . Copy-only backups . Transaction log backups

Download from www.wowebook.com

380

CHAPTER 14

Database Backup and Restore

Full Database Backups A full database backup is an all-inclusive backup that captures an entire database in one operation. This full backup can be used to restore a database to the state it was in when the database backup completed. The backup is transactionally consistent, contains the entire database structure, and contains the related data stored in these structures. As with many other backups, SQL Server allows for updates to the database while a full backup is running. It keeps track of the changes occurring during the backup by capturing a portion of the transaction log in the database backup. The backup also records the log sequence number (LSN) when the database backup is started, as well as the LSN when the database backup completes. The LSN is a unique sequential number you can use to determine the order in which updates occur in the database. The LSNs recorded in the backup are used in the restore process to recover the database to a point in time that has transactional consistency. A full database backup is often used in conjunction with other backup types; it establishes a base for these other types if a restore operation is needed. The other backup types are discussed in the following sections, but it is important not to forget about the full backup that must be restored first in order to utilize other backup types. For example, let’s say you are making hourly transaction log backups. If the database is to be recovered using those transaction log backups, the last full database backup must be restored first, and then the subsequent log backups can be applied.

Differential Database Backups Differential database backups capture changes to any data extent that happened since the last full database backup. The last full database backup is referred to as the differential base and is required to make the differential backup useful. Each data extent that is monitored consists of eight physically contiguous data pages. As changes are made to the pages in an extent, a flag is set to indicate that a change has been made to the extent. When the differential database backup is executed, only those extents that have had pages modified are written to the backup. Differential database backups can save backup space and improve the overall speed of recovery. The savings in space and time are directly related to the amount of change that occurs in the database. The amount of change in the database depends on the amount of time between differential backups. When the number of database changes since the last backup is relatively small, you achieve the best results. If, however, a significant number of changes occur to the data between differential backups, the value of this type of backup is diminished. Ultimately the number of data pages that are affected by the changes determine the number of pages that must be included in the differencial backup. The number of pages is affected by the indexing structure as well as the nature of the updates. If for example,

Download from www.wowebook.com

Types of Backups

381

there are many rows that are changed but those rows are all clustered on a limited number of data pages then the differencial backup will not be that large.

Partial Backups Partial backups provide a means for eliminating read-only data from a backup. In some implementations, a portion of the data in a database may not change and is strictly used for inquiry. If this data is placed on a read-only filegroup, you can use partial backups to back up everything except the read-only data. This technique reduces the size of your backup and reduces the time it takes to complete the backup. The read-only filegroups should still be backed up, but this needs to occur only after the read-only data is loaded.

Differential Partial Backups 14

Differential partial backups work like differential database backups but are focused on the same type of data as partial backups. The extents that have changed in filegroups that are not read-only are captured in this type of backup. This includes the primary filegroup and any read/write filegroups defined at the time of the backup. Like differential database backups, these backups also require a differential base, but it must be a single differential base. In other words, multiple base backups that have been taken at different times for different database files will not work. You must use a single base backup that encompasses all of the database files.

File and Filegroup Backups File and filegroup backups are targeted at databases that contain more than one filegroup. In these situations, the filegroup or files in the filegroups can be backed up independently. If a filegroup is backed up, all the files defined in the filegroup are backed up. File and filegroup backups are often used for larger databases where the creation time for a full database backup takes too long or the resulting backup is too large. In these situations, you can stagger the backups of the files or filegroups and write them to different locations. The main disadvantage of this type of backup is the increase in administrative overhead. Each of the files in the database must be backed up, and a complete set of these files must be retained to restore the database. For a full recovery model, the transaction log backups must also be retained.

NOTE SQL Server 2008 supports file and filegroup backups for all recovery models, including simple recovery. The catch with simple recovery is that the files and filegroups are limited to read-only secondary filegroups. SQL Server 2000 did not allow these types of backups with simple recovery.

Download from www.wowebook.com

382

CHAPTER 14

Database Backup and Restore

Copy-Only Backups Copy-only backups allow a backup of any type to be taken without affecting any other backups. Normally, a database backup is recorded in the database itself and is identified as part of a chain that can be used for restore. For example, if a full database backup is taken, any subsequent differential database backups use this full database backup as their base. A restore process utilizing the differential database backups would have a reference to the full database backup, and that backup would have to be available. Copy-only backups do not affect the restore chain. They are useful in situations in which you simply want to get a copy of the database for testing purposes or things of this nature. Microsoft has made it easier to make this kind of backup by adding the Copy Only Backup check box when performing a backup using SQL Server Management Studio (SSMS). In SQL Server 2005, the Copy Only Backup had to be performed via the TransactSQL (T-SQL) BACKUP command. An example of the copy-only backup is provided later in this chapter, in the section “Backing Up a Database.”

Transaction Log Backups Transaction log backups capture records written to the transaction log file(s) defined for a database. The full and bulk-logged recovery models are the only models that support transaction log backups. These models cause transaction events to be retained in the transaction log so that they can be backed up. Simple recovery mode causes the transaction log to be truncated periodically and thus invalidates the usefulness of the transaction log backups. The transaction log backups and their strong ties to the recovery model are discussed in more detail in the next section.

Recovery Models Each database has a recovery model that determines how transactions will be written to the transaction log. The recovery model you choose has a direct impact on your ability to recover from a media failure. These following three recovery models are available with SQL Server 2008: . Full recovery . Bulk-logged . Simple You set the recovery model via T-SQL or the Database Properties window in SSMS. The following example shows the T-SQL command you can use to change the AdventureWorks2008 database to the bulk-logged model: ALTER DATABASE [AdventureWorks2008] SET RECOVERY BULK_LOGGED WITH NO_WAIT

Download from www.wowebook.com

Recovery Models

383

Figure 14.1 shows the Options page on the Database Properties window, which also allows you to select a recovery model.

14

FIGURE 14.1 Setting the recovery model in SSMS.

Full Recovery The full recovery model gives you the most protection against data loss. A database set to full recovery will have all database operations written to the transactions log. These operations include insertions, updates, and deletions, as well as any other statements that change the database. In addition, the full recovery model captures any database inserts that are the result of a BCP command or BULK INSERT statement. In the event of a media failure, a database that is in full recovery can be restored to the point in time at which the failure occurred. Your ability to restore to a point in time is dependent on your database backup plan. If a full database backup is available, along with the transaction log backups that occurred after the full database backup, you can recover to the point of the last transaction log backup. In addition, if your current transaction log is available, you can restore up to the point of the last committed transaction in the transaction log. This recovery model is the most comprehensive, but in some respects, it is the most expensive. It is expensive in terms of the transaction log space needed to capture all the database operations. The space can be significant with databases that have a lot of update activity or with databases that have large bulk load operations. It is also expensive in

Download from www.wowebook.com

384

CHAPTER 14

Database Backup and Restore

terms of server overhead because every transaction is captured and retained in the transaction log so that they can be recovered in the event of a failure.

TIP A common problem in SQL Server environments involves a database that is set to full recovery but whose transaction log is never backed up. In this scenario, the transaction log can grow to the point that it fills up the drive on which the transaction log is located. You need to ensure that you have regularly scheduled backups of the transaction log if you have set your database to full recovery. The transaction log backups allow you to recover from a media failure and also remove the inactive portion of the transaction log so that it does not need to grow.

Bulk-Logged Recovery The bulk-logged recovery model is similar to full recovery, but it differs in the way that bulk operations are captured in the transaction log. With full recovery mode, SQL Server writes every row to the transaction log that is inserted with BCP or BULK INSERT. Bulklogged recovery keeps track of the extents that have been modified by a bulk load operation but does not write each row to the transaction log. This reduces the overall size of the transaction log during bulk load operations and still allows the database to recover after a bulk load operation has occurred. The biggest downside to setting a database to bulk-logged recovery is that the log backups for the databases can be large. The log backups are large because SQL Server copies all the data extents that have been affected by bulk load operations since the last backup of the transaction log. Remember that data extents consist of eight data pages each, and each page is 8KB in size. This may not seem like much by today’s standards, but it can be significant when you’re bulk loading a large table. For example, consider a table occupying 1GB of space that is truncated each week and reloaded with a bulk insert. The bulk insert operation goes relatively fast because the rows are not being written to the transaction log, but the backup of the transaction log is much larger.

NOTE In testing we did on a table with approximately 2.4 million rows (that occupied 500MB of space), the log file grew over 2GB during a bulk insert operation that reloaded all rows in a full recovery mode database. In contrast, the same bulk insert operation on the database with bulk-logged recovery grew the log by only 9MB. However, the backup of the 9MB transaction log was approximately 500MB. This is much larger than the actual log itself because the bulk operation caused all the modified extents from the bulk insert operation to be stored in the log backup as well.

The other downside to bulk-logged recovery is that with it, you may sacrifice the ability to restore to the most recent point in time. This situation occurs if a bulk insert operation

Download from www.wowebook.com

Backup Devices

385

has occurred since the last database backup and a media failure occurs. In this case, the restores can occur for any backups that were taken that do not contain a bulk insert operation, but any outstanding changes that were retained in the transaction log cannot be applied. The reason is that bulk operations are not written to the log directly in this model and cannot be recovered. Only bulk operations captured in a backup can be restored. If transactions have occurred in a database since the last backup, and no bulk insert operations have occurred, you can recover those pending transactions as long as the media containing the transaction log is still available. The tail of the transaction log can be backed up and applied during a restore operation. The tail of the log and other restore scenarios are discussed in the “Restore Scenarios” section, later in this chapter.

Simple Recovery 14

The simple recovery model is the easiest to administer, but it is the option that has the greatest possibility for data loss. In this mode, your transactions log is truncated automatically based on a checkpoint in the database. These checkpoints happen often, and they cause the data in the transaction log to be truncated frequently.

NOTE Prior to SQL Server 2000, the trunc. log on checkpoint database option was used to truncate the log on a checkpoint and produce the same type of behavior as simple recovery. This database option and the equivalent backup options NO_LOG and TRUNCATE_ONLY are no longer supported. The only supported method for truncating the transaction log in SQL Server 2008 is to switch the database to use the simple recovery model.

The most important point to remember about the simple recovery model is that with it, you cannot back up the transaction log that captures changes to your database. If a media failure occurs, you are not able to recover the database activity that has occurred since the last database backup. This is a major exposure, so simple recovery is not recommended for production databases. However, it can be a good option for development databases where the loss of some transactions is acceptable. In these types of environments, simple recovery can equate to saved disk space because the transaction log is constantly truncated. The administration in these environments is reduced as well because the transaction log backups are not an option and thus do not need to be managed. For a more detailed discussion of the transaction log, see Chapter 31, “Transaction Management and the Transaction Log.”

Backup Devices A backup device is used to provide a storage destination for the database backups created with SQL Server. Backups can be written to logical or physical devices. A logical device is essentially an alias to the physical device and makes it easier to refer to the device when

Download from www.wowebook.com

386

CHAPTER 14

Database Backup and Restore

performing database backups. The physical backup devices that SQL Server can write to include files on local disks, tape, and network shares.

Disk Devices A disk device is generally stored in a folder on a local hard drive. This should not be the same hard drive where your data is stored! Disk devices have several advantages, including speed and reliability. If you have ever had a backup fail because you forgot to load a tape, you can appreciate the advantage of disk backups. On the other hand, if backups are stored on a local disk and the server is destroyed, you lose your backups as well.

NOTE Disks have become increasingly popular media as the prices have fallen. Storage area networks (SANs) and other large-scale disk solutions have entered mainstream usage and offer a large amount of storage at a relatively inexpensive price. They also offer redundancy and provide fault tolerance to mitigate the chance of losing data on a disk. Finally, increased network bandwidth across LANs and WANs has allowed for the movement of backups created on disk to alternate locations. This is a simple way to achieve additional fault tolerance.

Tape Devices Tape devices are used to back up to tape. Tape devices must be directly connected to the server, and parallel backups to multiple drives are supported to increase throughput. Tape backups have the advantage of being scalable, portable, and secure. Scalability is important as a database grows; available disk space often precludes the use of disk backups for large databases. Because tapes are removable media, they can easily be transported offsite, where they can be secured against theft and damage. SQL Server supports the Microsoft Tape Format (MTF) for backup devices, which means that SQL Server backups and operating system backups can share the same tape. This capability is convenient for small sites with shared use servers and only one tape drive. You can schedule your SQL Server backups and file backups without having to be onsite to change the tape.

Network Shares SQL Server 2008 allows the use of both mapped network drives and Universal Naming Convention (UNC) paths in the backup device filename. A mapped network drive must be mapped as a network drive in the session in which SQL Server is running. This is prone to error and generally not recommended. UNC paths are much simpler to administer. With UNC backup devices, the SQL Server service account must be able to see the UNC path on the network. This is accomplished by granting the service account full control permission on the share or by making the service account a member of the Administrators group on the remote computer. Keep in mind that backups performed on a network share should be done on a dedicated or high-speed network connection, and the backup should be verified to avoid potential

Download from www.wowebook.com

Backup Devices

387

corruption introduced by network error. The time it takes a backup to complete over the network depends on network traffic, so you need to take this factor into consideration when planning your backups.

Media Sets and Families When you’re backing up to multiple devices, the terms media set and media family are used to describe the components of the backup. A media set is the target destination of the database backup and comprises several individual media. All media in a media set must be of the same type (for example, all tape or all disk). A media family is the collection of media associated with an individual backup device. For example, a media family could be a collection of five tapes contained in a single tape device.

14

The first tape in the media family is referred to as the initial media, and the subsequent tapes are referred to as continuation media. All the media families combined are referred to as the media set. If, for example, a backup is written to 3 backup devices (each with 4 tapes), the media set would contain 3 media families and consist of a total of 12 tapes. It is recommended to use the MEDIANAME parameter of the BACKUP command to specify a name for the media set. This parameter associates the multiple devices as members of the media set. The MEDIANAME parameter can then be referenced in future backup operations.

Creating Backup Devices You can create logical backup devices by using T-SQL or SSMS. The T-SQL command for creating these logical backup devices is sp_addumpdevice, which has the following syntax: sp_addumpdevice [ @devtype = ] ‘device_type’ , [ @logicalname = ] ‘logical_name’ , [ @physicalname = ] ‘physical_name’ [ , { [ @cntrltype = ] controller_type | [ @devstatus = ] ‘device_status’ } ]

The following sample script demonstrates the creation of the different types of backup devices: -- Local Disk EXEC sp_addumpdevice ‘disk’, ‘diskdev1’, ‘c:\mssql2008\backup\AdventureWorks2008.bak’ -- Network Disk EXEC sp_addumpdevice ‘disk’, ‘networkdev1’, ‘\\myserver\myshare\AdventureWorks2008.bak’ -- Tape EXEC sp_addumpdevice ‘tape’, ‘tapedev1’, ‘\\.\tape0’

To create backup devices with SSMS, you navigate to the Server Objects node in the Object Explorer and right-click Backup Devices and then New Backup Device; the Backup

Download from www.wowebook.com

388

CHAPTER 14

Database Backup and Restore

Device screen appears. This screen includes a text box for the device name, along with a section to select the destination for the device. This is the physical location, and you can select either Tape or File.

Backing Up a Database Now that you know the types of backups, the recovery models they relate to, and the devices you can write to, you are ready to back up your database. You can create backups with SQL Server 2008 by using either the SSMS or T-SQL. Some backups are supported only through T-SQL, but the vast majority can be accomplished with either tool.

Creating Database Backups with SSMS The backup options in SSMS are accessible through the Object Explorer. For example, you can right-click the AdventureWorks2008 database in the SSMS Object Explorer, select Tasks and Backup, and a backup window like the one shown in Figure 14.2 appears.

FIGURE 14.2 The Back Up Database window in SSMS. The Source section on the Back Up Database window contains information relative to the database that will be backed up. The target database is displayed in the first drop-down, along with the recovery model set for the database. The backup types available in the drop-down are dependent on the recovery model. For simple recovery, only full and differ-

Download from www.wowebook.com

Backing Up a Database

389

ential backup types are available. For full recovery and bulk-logged recovery models, all backup types are available in the drop-down. The Backup Set section allows you to give the backup a meaningful name and specify when the backup set will expire. When the backup set expires, the backup can be overwritten and is no longer retained. If the backup is set to expire after 0 days, it will never expire. The Destination section identifies the disk or tape media that will contain the backup. You can specify multiple destinations in this section by clicking the Add button. For disk media, you can specify a maximum of 64 disk devices. The same limit applies to tape media. If multiple devices are specified, the backup information is spread across those devices. All the devices must be present for you to be able to restore the database. If no tape devices are attached to the database server, the Tape option is disabled.

14

You can select several different types of options for a database backup. Figure 14.3 shows the options page available when you back up a database by using SSMS.

FIGURE 14.3 The Back Up Database Options page in SSMS. The Overwrite Media section allows you to specify options relative to the destination media for the backup. Keep in mind that a given media set can contain more than one backup. This can occur if the Append to the Existing Backup Set options is selected. With this option, any prior backups contained on the media set are preserved, and the new backup is added to it. With the Overwrite All Existing Backup Sets option, the media set contains only the latest backup, and no prior backups are retained.

Download from www.wowebook.com

390

CHAPTER 14

Database Backup and Restore

You can use the options in the Reliability section to ensure that the backup that has been created can be used reliably in a restore situation. Verifying the backup when finished is highly recommended, but doing so causes the backup time to be extended during the verification. Similarly, the Perform Checksum Before Writing to Media option helps ensure that you have a sound backup, but again, it causes the database backup to run longer. The options in the Transaction Log section are available for databases in the full recovery or bulk-logged model. These options are disabled in the simple recovery model. The Truncate the Transaction Log option causes any inactive portion of the transaction log to be removed after the database backup is complete. The inactive portion of the log and other detail of the transaction log are discussed in more detail in Chapter 30 “Transaction Management and the transaction log”. This option, the default, helps keep the size of the transaction log manageable. The Back Up the Tail of the Log option is related to point-intime restores and is discussed in more detail in the “Restore Scenarios” section later in this chapter. The set of options in the Tape Drive section are enabled only when tape has been selected for the destination media. Selecting the Unload the Tape After Backup option causes the media tape to be ejected when the backup completes. This option can help identify the end of a backup and prevent the tape from being overwritten the next time the backup runs. The Rewind the Tape Before Unloading option is self-explanatory; it causes the tape to be released and rewound before you unload the tape. The last set of options relate to compressed database backups. The options for compressed backups are discussed in detail in the Compressed Backup secion later in this chapter.

NOTE Keep in mind that all backups can be performed while the database is in use. SQL Server is able to keep track of the changes occurring during the backup and can maintain transactional consistency as of the end of the backup. You need to consider some performance overhead during the actual backup, but the backup can occur during active database hours. However, it is still a good idea to schedule your database backups during off-hours, when database activity is at a minimum.

Creating Database Backups with T-SQL The T-SQL BACKUP command offers a myriad of options to perform all the backup operations available in SSMS. However, SSMS does not support some backup operations that can be performed only with T-SQL. The BACKUP command comes in three different flavors. The first flavor involves the backup of a database. The command syntax starts with BACKUP DATABASE, followed by the relevant parameters and options. The second flavor involves the backup of a file or filegroup that is part of the database. The command syntax for this type of backup also utilizes the BACKUP

Download from www.wowebook.com

Backing Up a Database

391

DATABASE command, but a file or filegroup is specified after the database name to identify

which parts of the database should be backed up. The last flavor involves the backup of the database’s transaction log. The syntax for backing up the transaction log starts with BACKUP LOG. Each flavor shares many of the same options. The basic syntax for backing up a database follows:

14

BACKUP DATABASE { database_name | @database_name_var } TO < backup_device > [ ,...n ] [ [ MIRROR TO < backup_device > [ ,...n ] ] [ ...next-mirror ] ] [ WITH [ BLOCKSIZE = { blocksize | @blocksize_variable } ] [ [ , ] { CHECKSUM | NO_CHECKSUM } ] [ [ , ] COMPRESSION | NO_COMPRESSION] [ [ , ] COPY_ONLY ] [ [ , ] { STOP_ON_ERROR | CONTINUE_AFTER_ERROR } ] [ [ , ] DESCRIPTION = { ‘text’ | @text_variable } ] [ [ , ] DIFFERENTIAL ] [ [ , ] EXPIREDATE = { date | @date_var } | RETAINDAYS = { days | @days_var } ] [ [ , ] PASSWORD = { password | @password_variable } ] [ [ , ] { FORMAT | NOFORMAT } ] [ [ , ] { INIT | NOINIT } ] [ [ , ] { NOSKIP | SKIP } ] [ [ , ] MEDIADESCRIPTION = { ‘text’ | @text_variable } ] [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] [ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ] [ [ , ] NAME = { backup_set_name | @backup_set_name_var } ] [ [ , ] { NOREWIND | REWIND } ] [ [ , ] { NOUNLOAD | UNLOAD } ] [ [ , ] RESTART ] [ [ , ] STATS [ = percentage ] ] ]

The number of options is extensive, but many of them are optional. A BACKUP DATABASE command can be as simple as the following example: BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_COPY.bak’

The first part of the BACKUP command is related to the database you want to back up (database_name), followed by the location to which you want to write the backup (backup_device). The remainder of the syntax relates to the options that can be specified following the WITH clause. These options determine how your backup will be created and the properties of the resulting backup. Table 14.1 outlines these options.

Download from www.wowebook.com

392

CHAPTER 14

Database Backup and Restore

TABLE 14.1 BACKUP DATABASE Options Option

Description

BLOCKSIZE

The physical block size that will be used to create the backup. The default is 64KB.

CHECKSUM | NO_CHECKSUM

When CHECKSUM is specified, a checksum is calculated before the backup is written to validate that the backup is not corrupt. The default is NO_CHECKSUM.

COMPRESSION | NO_COMPRESSION

This new option in SQL Server 2008, available only with the Enterprise or Developer Edition, causes the backup file to be compressed. The default is NO_COMPRESSION.

STOP_ON_ERROR | CONTINUE_AFTER_ERROR

This option is used in conjunction with the CHECKSUM option. The STOP_ON_ERROR option, which is the default, causes the backup to fail if the checksum cannot be validated.

DESCRIPTION

This is a 255-character description of the backup set.

DIFFERENTIAL

This option causes a differential backup to occur, which captures changes only since the last backup.

EXPIREDATE

This option specifies the date on which the backup set will expire and be overwritten.

RETAINDAYS

This option specifies the number of elapsed days before the backup set can be overwritten.

PASSWORD

This is a password that must be specified when restoring the backup set.

FORMAT | NOFORMAT

FORMAT causes the existing media header and backup set to be overwritten. The default is NOFORMAT.

INIT | NOINIT

The INIT option causes a backup set to be overwritten. The backup set is not overwritten if the backup set has not expired or if it does not match the media name specified with the NAME option. NOINIT, which is the default, causes the backup set to be appended to the existing media.

NOSKIP | SKIP

NOSKIP, which is the default, allows backup sets to be overwritten if they have expired. The SKIP option skips expiration and media name checks and is used to prevent the overwriting of backup sets.

MEDIADESCRIPTION

This is a 255-character description for the entire backup media containing the backup sets.

Download from www.wowebook.com

Backing Up the Transaction Log

393

TABLE 14.1 BACKUP DATABASE Options Description

MEDIANAME

This is a 128-character name for the backup media. If it is specified, the target media must match this name.

MEDIAPASSWORD

This is a password for the media set. When media is created with this password, the password must be supplied to be able to create a backup set on that media or to restore from that media.

NAME

This is a 128-character name for the backup set.

NOREWIND | REWIND

This option is used for tape operations. REWIND, which is the default, causes the tape to be released and rewound after it fills.

NOUNLOAD | UNLOAD

This option is used for tape operations. NOUNLOAD, which is the default, causes the tape to remain in the tape drive after a backup completes. UNLOAD causes the tape to be rewound and unloaded when the backup completes.

RESTART

This option has no effect and is in place only for backward compatibility.

STATS

This option causes completion statistics to be displayed at the specified interval to assess progress.

COPY_ONLY

This option allows a backup to be made without affecting the normal sequence of backups.

14

Option

The “Backup Scenarios” section, later in this chapter, provides some examples of how to use these options.

Backing Up the Transaction Log As discussed, the full and bulk-logged recovery models cause transactions to be written to the database’s transaction log. These transactions should be backed up periodically for two main reasons. First, the transaction log backups can be used in case of a media failure to restore work completed in the database. These backups limit your exposure to data loss and enable you to reapply changes that have occurred. The second reason for backing up the transaction log is to keep the size of the log manageable. Keep in mind that SQL Server is a write-ahead database management system (DBMS) and thus writes most changes to the transaction log first, before it updates the actual data files. This type of DBMS is great for recovery purposes, but it can be a real headache if you do not periodically clear those transactions from the log. Without a

Download from www.wowebook.com

394

CHAPTER 14

Database Backup and Restore

backup or manual truncation, the log can fill to a point where it will use up all the space on your disk.

Creating Transaction Log Backups with SSMS The same backup screen utilized for database backups in SSMS can also be used for transaction log backups. Figure 14.4 shows the Back Up Database window with Transaction Log selected as the backup type. A device must be selected to write the backup to, and some additional options on the Options page that relate to the transaction log are enabled.

FIGURE 14.4 Backing up the transaction log in SSMS.

Creating Transaction Log Backups with T-SQL When you back up a transaction log by using T-SQL, you use the BACKUP LOG command, which includes all the previously listed options except the DIFFERENTIAL option. (Differential backups do not apply to transaction logs.) Several additional options are available for transaction log backups. The following abbreviated syntax for the BACKUP LOG command shows the options used exclusively for backing up transaction logs: BACKUP LOG { database_name | @database_name_var } TO < backup_device > [ ,...n ] [ [ MIRROR TO < backup_device > [ ,...n ] ] [ ...next-mirror ] ] [ WITH

Download from www.wowebook.com

Backing Up the Transaction Log

395

.... [ [ , ] NO_TRUNCATE ] [ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]

The options specific to BACKUP LOG are discussed in detail in the following sections.

14

The NO_TRUNCATE Option You use the NO_TRUNCATE option when the log is available, but the database is not. This option prevents the truncation of the transaction log after a backup occurs. Under normal circumstances, the BACKUP LOG command not only writes to the transaction log, but also signals a checkpoint for the database to flush any dirty buffers from memory to the database files. This behavior becomes a problem when the media containing the database is unavailable and you must capture the current contents of a log to a backup file for recovery. If you last did a log backup four hours ago, this would mean the loss of all the input since then. If your log is on a separate disk that is not damaged, you have those four hours of transactions available to you, but BACKUP LOG fails because it can’t run a checkpoint on the data files. You run BACKUP LOG with the NO_TRUNCATE option, and the log is backed up, but the checkpoint is not run because the log is not actually cleared. You now have this new log backup to restore as well, enabling recovery to the time of failure. The only transactions lost are those that were not yet committed. The NORECOVERY | STANDBY= undo_file_name Options The NORECOVERY option causes the tail of the log to be backed up and leaves the database in a RESTORING state, which allows additional transaction logs to be applied, if necessary. The tail of the log is the active portion of the log that contains transactions not yet backed up. This “tail” is critical in restore situations in which all committed transactions are reapplied. Typically, the NORECOVERY option is used with the NO_TRUNCATE option to retain the contents of the log. The STANDBY option also backs up the tail of the log, but it leaves the database in a readonly/standby state. The read-only state allows inquiry on the database and allows additional transaction logs to be applied to the database as well. undo_file_name must be supplied with the STANDBY command so that transactions not committed and rolled back at the time of the backup can be reapplied if additional transaction logs are applied to the database. This STANDBY option produces the same results as executing BACKUP LOG WITH NORECOVERY followed by a RESTORE WITH STANDBY command.

NOTE As mentioned earlier, Microsoft has removed the NO_LOG and TRUNCATE_ONLY options available with earlier versions of SQL Server, including SQL Server 2005. Setting a database to use the simple recovery model is the alternative to these options.

Download from www.wowebook.com

396

CHAPTER 14

Database Backup and Restore

Backup Scenarios Typically, several different types of backups are used in a comprehensive backup plan. These backups are often combined to produce maximum recoverability while balancing the load on the system and amount of time to recover the database. The following backup scenarios outline some of the ways SQL Server backups are used.

NOTE Many of the examples that follow utilize a backup directory named c:\mssql2008\backup. If you are interested in running some of these examples on your own system, you need to create this directory on the database server first before running the scripts that reference this directory. You can use backup and data directories different from the default directory to simplify the directory structure for the SQL Server files. Typically, these directories should not be on the C: drive, but the C: drive is used here for simplicity.

Full Database Backups Only A full database backup, without the use of other database backups, is often found in nonproduction environments where the loss of transactional data is relatively unimportant. Some development environments are good examples of this. In these environments, a nightly full backup is sufficient to ensure that recent Data Definition Language (DDL) changes and the related development data for the day are captured. If a catastrophic failure occurs during the day and causes a restore to occur, the database can be restored from the prior night’s backup. The following example shows a full backup of the AdventureWorks2008 database: --Full Database Backup to a single disk device BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\AdventureWorks2008.bak’ WITH NOFORMAT, INIT, NAME = N’AdventureWorks2008-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10

The sole use of daily full database backups needs to be carefully considered. The benefits of limited administration and limited backup space requirements have to be weighed against the costs of losing an entire day’s transactions.

Full Database Backups with Transaction Log Backups Compared to making a full database backup only, a more comprehensive approach to database backups includes the use of transaction log backups to augment the recoverability of full database backups. Transaction log backups that are taken periodically capture incremental database activity that can be applied to a full database backup during database restore. You need to measure the frequency of the transaction log backup against the tolerance for data loss. For example, if the requirement is to prevent no more than one hour’s worth of

Download from www.wowebook.com

Backup Scenarios

397

work, the transaction log backups should be taken hourly. If the media on which the backup is stored is accessible, you should lose no more than one hour’s worth of data. As mentioned earlier, the database must be placed in full or bulk-logged recovery mode to capture transaction log backups. Listing 14.1 shows the commands necessary to place the AdventureWorks2008 database in full recovery mode, the required backup to establish a base, followed by the command to perform the actual transaction log backup.

LISTING 14.1 Full Backups with Transaction Logs --First need to change the recovery model from simple to full --so that the tlogs are available for backup ALTER DATABASE [AdventureWorks2008] SET RECOVERY FULL WITH NO_WAIT

14

--*** A Full database backup must be taken after the --*** recovery mode has been changed --*** in order to set a base for future tlog backups. --*** If the full backup is not taken --*** then tlog backups will fail. --The Following full backup utilizes two devices on the same drive. --Often times multiple devices are backed up to different drives. --Backing up to different drives -- can speed up the overall backup time and help when you are running low on space on a drive -- where your backups are written. BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_Full_Dev1.bak’, DISK = N’C:\mssql2008\backup\AdventureWorks2008_Full_Dev2.bak’ WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10 --Transaction log backups can be taken now that a base has been established --The following tlog backup is written to a single file BACKUP LOG [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\log\AdventureWorks2008_FirstAfterFull.trn’ WITH NOFORMAT, INIT, NAME = N’AdventureWorks2008-Transaction Log Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM

Differential Backups Differential backups can be used to reduce the amount of time required to restore a database and can be particularly useful in environments where the amount of data that changes is limited. Differential backups capture only the database extents that have changed since the last database backup—typically, a full database backup.

Download from www.wowebook.com

398

CHAPTER 14

Database Backup and Restore

The addition of differential backups to a plan that includes full database backups and transaction log backups can significantly improve the overall recovery time. The differential database backup eliminates the need to apply any transaction log backups that have occurred from the time of the last full backup up until the completion of the differential backup. Figure 14.5 depicts a backup plan that includes full database backups, transaction log backups, and differential backups. The differential backups are executed on a daily basis between the full backups.

FIGURE 14.5 A backup plan that includes differential backup. It is important to remember that differential backups are cumulative and contain all changes since the last differential base. There is no need to apply previous differential backups if the new differential base has not been established. For example, in the backup plan shown in Figure 14.5, if a media failure occurred in the middle of the day on January 3, the differential backup that would be used is the one taken at the beginning of the day on January 3; the differential backup that occurred on January 2 would not be needed. The full backup from January 1, the differential from January 3, and any transaction log backups that had occurred since the differential on January 3 would be used to restore the database. You can create differential backups by using SSMS or T-SQL. The following example demonstrates the creation of a differential backup for the AdventureWorks2008 database using T-SQL: BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_Diff2.bak’ WITH DIFFERENTIAL , NOFORMAT, INIT, NAME = N’AdventureWorks2008-Differential Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10

Partial Backups Partial backups are useful when read-only files or filegroups are part of a database. Listing 14.2 contains the commands necessary to add a read-only filegroup to the AdventureWorks2008 database. The commands in Listing 14.2 do not perform a partial

Download from www.wowebook.com

Backup Scenarios

399

backup, but they do modify a sample database so that a partial database would make sense.

LISTING 14.2 Adding a Read-Only Filegroup to a Database

14

--Need to add a read only filegroup first to demonstrate ALTER DATABASE AdventureWorks2008 ADD FILEGROUP ReadOnlyFG1 GO -- Add a file to the Filegroup ALTER DATABASE AdventureWorks2008 ADD FILE ( NAME = AdventureWorks2008_ReadOnlyData, FILENAME = ‘C:\mssql2008\data\AdventureWorks2008_ReadOnlyData.ndf’, SIZE = 5MB, MAXSIZE = 100MB, FILEGROWTH = 5MB) TO FILEGROUP ReadOnlyFG1 go --Create a table on the ReadOnly filegroup CREATE TABLE AdventureWorks2008.dbo.MyReadOnlyTable ( FirstName varchar(50), LastName varchar(50), EMailAddress char(1000) ) ON ReadOnlyFG1 --Insert some data into the new read only Filegroup insert AdventureWorks2008.dbo.MyReadOnlyTable select LastName, FirstName, ‘xxx’ from AdventureWorks2008.person. person --Make the filegroup readonly ALTER DATABASE [AdventureWorks2008] MODIFY FILEGROUP [ReadOnlyFG1] READONLY

When you have a filegroup that contains read-only data, a partial backup can be valuable. The partial backup by default excludes any read-only filegroups and backs up only the read/write data that could have changed. Listing 14.3 contains three separate backup commands that relate to the partial backup. The first backup command is not a partial backup but instead backs up the read-only filegroup. If the read-only filegroup is not backed up prior to the partial backup, the readonly filegroup is backed up, as is part of the partial backup. The second backup command creates the actual partial backup. The key parameter in this backup is READ_WRITE_FILEGROUPS, which causes the backup to skip the read-only data. The third backup command in Listing 14.3 shows that it is possible to perform a partial backup that includes the read-only data as well. This command includes a specific reference to the read-only filegroup, which causes it to be backed up as well.

Download from www.wowebook.com

400

CHAPTER 14

Database Backup and Restore

LISTING 14.3 Making a Partial Backup --Need to backup the readonly filegroup that was created -- or it will be included in the partial backup BACKUP DATABASE [AdventureWorks2008] FILEGROUP = N’ReadOnlyFG1’ TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_ReadOnlyFG.bak’ WITH NOFORMAT, NOINIT, NAME = N’AdventureWorks2008-Full Filegroup Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10 --Create the Partial Database Backup --It will not contain the data from readonly filegroup --The partial database backup can be restored without affecting -- the data in the readonly filegroup BACKUP DATABASE [AdventureWorks2008] READ_WRITE_FILEGROUPS TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_Partial.bak’ WITH NOFORMAT, INIT, NAME = N’AdventureWorks2008-Partial Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10 --It is possible to backup the readonly filegroup(s) as well --by listing the readonly filegroups in the backup command as shown in the --following backup command BACKUP DATABASE [AdventureWorks2008] FILEGROUP = ‘ReadOnlyFG1’, READ_WRITE_FILEGROUPS TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_Partial_WithReadOnly.bak’ WITH NOFORMAT, INIT, NAME = N’AdventureWorks2008-Partial Database Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10

File/Filegroup Backups Much of our discussion thus far has focused on backing up an entire database, but it is possible to back up only particular files or a group of files in a filegroup. A SQL Server database, by default, has only two files: the data file (with the file extension .mdf) and the log file (with the extension .ldf). You can add additional files and filegroups that contain these files to extend the database beyond the original two files. These additional files are often data files added to larger databases that require additional space. With very large databases, performing a full backup that contains all the database files can take too much time. In such a case, the individual files or filegroups can be backed up separately, enabling you to spread out the backup. Listing 14.4 shows the T-SQL command that can be used to back up the read-only file you added to the AdventureWorks2008 database in Listing 14.3.

Download from www.wowebook.com

Backup Scenarios

401

LISTING 14.4 Creating a File Backup BACKUP DATABASE [AdventureWorks2008] FILE = ‘AdventureWorks2008_ReadOnlyData’ TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_ReadOnlyData.bak’ WITH NOFORMAT, INIT, NAME = N’AdventureWorks2008-Readonly File Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10

There is some additional administrative overhead associated with file and filegroup backups. Unlike a full database backup that produces one file that contains the entire database, the file backups do not stand by themselves and require other backups to be able to create the entire database. You need to keep the following points in mind when performing file and filegroup backups:

14

. A file or filegroup backup does not back up any portion of the transaction log. To restore a file or filegroup backup, you must have the transaction log backups since the last file or filegroup backup, including the tail of the log, for the database system to ensure transactional consistency. This also implies that the database must be in full or bulk-logged recovery because these are the only models that support transaction log backups. . Individual file or filegroup backups can be restored from a full database backup. . Point-in-time recovery is not permitted with file or filegroup backups. . Differential backups can be combined with file or filegroup backups. These differential backups capture only those extents that have changed since the file or filegroup backup was made. File and filegroup backups can be very powerful options for very large databases, but you need to ensure that the relevant backups can be accounted for. In all backup situations, the key to a successful plan is testing your backup strategy; this is particularly true with file and filegroup backups.

Mirrored Backups The use of mirrored backups can help diminish the possibility of losing a database backup. Database backups can be your lifeline to recovery, and you do not want to lose them. Mirrored backups simultaneously write the backup information to more than one media set. You can mirror the backup to two, three, or four different media sets. Listing 14.5 gives an example of a mirrored backup that writes two different media sets.

LISTING 14.5 Creating a Mirrored Backup BACKUP DATABASE AdventureWorks2008 TO disk = ‘C:\mssql2008\backup\AdventureWorks2008_Mirror1a.bak’,

Download from www.wowebook.com

402

CHAPTER 14

Database Backup and Restore

disk = ‘C:\mssql2008\backup\AdventureWorks2008_Mirror1b.bak’ MIRROR TO disk = ‘c:\mssql2008\backup\AdventureWorks2008_Mirror2a.bak’, disk = ‘C:\mssql2008\backup\AdventureWorks2008_Mirror2b.bak’ WITH FORMAT, MEDIANAME = ‘AdventureWorks2008MirrorSet’

The example in Listing 14.5 is simplistic and demonstrates only the backup’s capability to write to two different locations. At the end of the backup example, four files will exist. Each pair of files can be used to restore the database. In the real world, a backup like that in Listing 14.5 would write to two different disk or tape drives. Storing the media on the same drive is very risky and does not give you all the advantages a mirror can afford.

Copy-Only Backups If you want a backup that will not affect future or past backups, copy-only backups are for you. The copy-only backup allows you to make a database or log backup without identifying the backup as one that should be included in a restore sequence. Contrast this with a full database backup: If a full database backup is taken, the information related to this backup is captured in the system tables. This backup can form the base for other backups, such as transaction log backups or differential backups, and must be retained to be able to restore the backups that depend on the base. The following example shows a copy-only backup; the COPY_ONLY parameter is the key to creating this kind of backup: BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\AdventureWorks2008_COPY.bak’ WITH COPY_ONLY

Compressed Backups How would you like to create a backup file that is smaller and takes less time to create? Sign me up. This has got to be an option that the average database user would love to use. Compressed backups are smaller in size than uncompressed backups. The reduced size of a compressed backup typically requires less device I/O and can therefore reduce backup times significantly. You must be aware that there are some trade-offs, however. First, this feature is available only with Enterprise Edition or Developer Edition. Second, the creation of a compressed backup can impact on the performance of concurrent operations on your database server while the backup is being created. Specifically, CPU usage increases during the backup. This may or may not be an issue for you. Consider that many full database backups are taken during off-hours, so there are more CPU cycles available during this time. Either way, you should monitor the CPU usage using compression versus not using compression to evaluate the impact. Another option is to create low-priority compressed backups in a

Download from www.wowebook.com

Restoring Databases and Transaction Logs

403

session whose CPU usage is limited by the Resource Governor. (For more information on using the Resource Governor, see Chapter 40, “Managing Workloads with the Resource Governor.”) When you get past these hurdles, the creation of a compressed backup is straightforward. One option is to set a server option so that all backups are created as compressed files by default. You can use the sp_configure stored procedure to set the backup compression default. If this is set to true, future backups will be created in a compressed format unless the backup is specifically created with the NO_COMPRESS option. You also have the option of creating a compressed backup regardless of the server option. This is done using the new COMPRESSION option available with the T-SQL BACKUP command. The following example shows how to create an AdventureWorks2008 backup in the compressed format:

14

BACKUP DATABASE [AdventureWorks2008] TO DISK = N’C:\MSSQL2008\Backup\AdventureWorks2008_compressed.bak’ WITH NOFORMAT, NOINIT, NAME = N’AdventureWorks2008-Full Database Backup’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10

The compression is quite impressive. In some simple tests performed on the AdventureWorks2008 database, the compressed backup was one fourth the size of a noncompressed backup. The compression ratio varies depending on the type of data in the database that you are backing up but can be as good as or better than 4:1.

System Database Backups The system databases are the master, model, msdb, resource, tempdb, and distribution databases. SQL Server uses these databases as part of its internal workings. All these databases should be part of your backup plan, except for resource and tempdb. You can find detailed descriptions of these databases in Chapter 7, “SQL Server System and Database Administration.” The important point to remember about all these databases is that they contain key information about your SQL Server environment. The msdb database contains information about backups and scheduled jobs. The master database contains information about all the user databases stored on the server. This information can change over time. To ensure that you do not lose the information the system databases contain, you should back up these databases as well. Typically, nightly full database backups of these databases suffice. You can use the same backup T-SQL syntax or SSMS screens that you use for a user databases to accomplish this task.

Restoring Databases and Transaction Logs A database restore allows a database or part of a database to be recovered to a state that it was in previously. This state includes the physical structure of the database, configuration options, and data contained in the database. The options you have for recovery are heavily dependent on the backup plan you have in place and way you have configured

Download from www.wowebook.com

404

CHAPTER 14

Database Backup and Restore

your database. Databases that are set to simple recovery mode have limited options for database restore. Databases that are in full recovery mode and have frequent backups have many more restore options. Following are the basic options for restore: . Restore an entire database. . Perform a partial restore. . Restore a file or page from a backup. . Restore a transaction log. . Restore a database to a point in time by using a database snapshot. The following sections delve further into the restore options listed here. They focus on the means for accomplishing these restores and some of the common restore scenarios you might encounter.

Restores with T-SQL The command to restore a database in SQL Server is aptly named RESTORE. The RESTORE command is similar to the BACKUP command in that it can be used to restore a database, part of a database, or a transaction log. You restore an entire database or part of a database by using the RESTORE DATABASE syntax. You do transaction log restores by using the RESTORE TRANSACTION syntax. Database Restores with T-SQL Listing 14.6 shows the full syntax for RESTORE DATABASE.

LISTING 14.6 RESTORE DATABASE Syntax --To Restore an Entire Database from a Full database backup (a Complete Restore): RESTORE DATABASE { database_name | @database_name_var } [ FROM [ ,...n ] ] [ WITH [ { CHECKSUM | NO_CHECKSUM } ] [ [ , ] { CONTINUE_AFTER_ERROR | STOP_ON_ERROR } ] [ [ , ] ENABLE_BROKER ] [ [ , ] ERROR_BROKER_CONVERSATIONS ] [ [ , ] FILE = { file_number | @file_number } ] [ [ , ] KEEP_REPLICATION ] [ [ , ] MEDIANAME = { media_name | @media_name_variable } ] [ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ] [ [ , ] MOVE ‘logical_file_name’ TO ‘operating_system_file_name’ ] [ ,...n ] [ [ , ] NEW_BROKER ] [ [ , ] PARTIAL ] [ [ , ] PASSWORD = { password | @password_variable } ] [ [ , ] { RECOVERY | NORECOVERY | STANDBY =

Download from www.wowebook.com

Restoring Databases and Transaction Logs

405

{standby_file_name | @standby_file_name_var } } [ [ [ [ [ [ |

] [ [ [ [ [ [

|

, ] REPLACE ] , ] RESTART ] , ] RESTRICTED_USER ] , ] { REWIND | NOREWIND } ] , ] STATS [ = percentage ] ] , ] { STOPAT = { date_time | @date_time_var } STOPATMARK = { ‘mark_name’ | ‘lsn:lsn_number’ } [ AFTER datetime ] STOPBEFOREMARK = { ‘mark_name’ | ‘lsn:lsn_number’ } [ AFTER datetime ]

} ] [ [ , ] { UNLOAD | NOUNLOAD } ]

14

]

Once again, there are many available options for restoring a database, but a simple restore is fairly straightforward. The following example demonstrates a full restore of the AdventureWorks2008 database: RESTORE DATABASE [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008_FullRecovery.bak’ WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10

For more sophisticated restores, you can specify options following the WITH clause. Table 14.2 briefly describes these options. Many of the options are the same as for the BACKUP command and provide similar functionality.

TABLE 14.2 RESTORE DATABASE Options Option

Description

CHECKSUM | NO_CHECKSUM

When CHECKSUM is specified, a checksum is calculated before the backup is restored. If the checksum validation fails, the restore fails as well. The default is NO_CHECKSUM.

STOP_ON_ERROR | CONTINUE_AFTER_ERROR

The STOP_ON_ERROR option, which is the default, causes the backup to fail if an error is encountered. CONTINUE_AFTER_ERROR allows the restore to continue if an error is encountered.

ENABLE_BROKER

This option starts the Service Broker so that messages can be received.

Download from www.wowebook.com

406

CHAPTER 14

Database Backup and Restore

TABLE 14.2 RESTORE DATABASE Options Option

Description

ERROR_BROKER_CONVERSATIONS

Service Broker conversations with the database being restored are ended, with an error stating that the database is attached or restored.

FILE = { file_number | @file_number }

This option identifies the backup set number to be restored from the backup media. The default is 1, which indicates the latest backup set.

KEEP_REPLICATION

This option prevents replication settings from being removed during a restore operation. This is important when setting up replication to work with log shipping.

MEDIANAME

This is a 128-character name for the backup media. If it is specified, the target media must match this name.

MEDIAPASSWORD

This is a password for the media set. If the media was created with a password, the password must be supplied to restore from that media.

MOVE

This option causes the specified logical_file_name to be moved from its original file location to another location.

NEW_BROKER

This option creates a new service_broker_guid.

PARTIAL

This option causes a partial restore to occur that includes the primary filegroup and any specified secondary filegroup(s).

PASSWORD

This password is specific to the backup set. If a password was used when creating the backup set, a password must be used to restore from the media set.

RECOVERY | NORECOVERY | STANDBY

The RECOVERY option, which is the default, restores the database so that it is ready for use. NORECOVERY renders the database inaccessible but able to restore additional transaction logs. The STANDBY option allows additional transaction logs to be applied but the database to be read. These options are discussed in more detail later in this section.

Download from www.wowebook.com

Restoring Databases and Transaction Logs

407

TABLE 14.2 RESTORE DATABASE Options Description

REPLACE

This option causes the database to be created with the restore, even if the database already exists.

RESTART

This option allows a previously interrupted restore to restart where it was stopped.

RESTRICTED_USER

This option restricts access to the database after it has been restored. Only members of the db_owner, dbcreator, or sysadmin role can access it.

REWIND | NOREWIND

This option is used for tape operations. REWIND, which is the default, causes the tape to be released and rewound.

STATS

This option causes completion statistics to be displayed at the specified interval to assess progress.

STOPAT | STOPATMARK | STOPBEFOREMARK

This option causes a restore to recover to a specified date/time or to recover to a point defined by a specific transaction. The STOPAT option restores the database to the state it was in at the date and time. The STOPATMARK and STOPBEFOREMARK options restore based on the specified marked transaction or LSN.

UNLOAD | NOUNLOAD

This option is used for tape operations. NOUNLOAD cause the tape to remain in the tape drive after a restore completes. UNLOAD, which is the default, causes the tape to be rewound and unloaded when the restore completes.

14

Option

Various options are utilized in the “Restore Scenarios” section, later in this chapter. Those restore scenarios provide a frame of reference for the options and further meaning about what they can accomplish. Transaction Log Restores with T-SQL The syntax details and options for restoring a transaction log backup are similar to those for RESTORE BACKUP. The options not available with RESTORE LOG include ENABLE_BROKER, ERROR_BROKER_CONVERSATIONS, NEW_BROKER, and PARTIAL. The RECOVERY | NORECOVERY | STANDBY options are particularly important when performing transaction log restores and also when restoring a database that will have transaction

Download from www.wowebook.com

408

CHAPTER 14

Database Backup and Restore

logs applied. If these options are used incorrectly, you can render your database inaccessible or unable to restore subsequent transaction log backups. With the RECOVERY option, any uncommitted transactions are rolled back, and the database is made available for use. When a restore (of either a database or transaction log) is run with this option, no further transaction logs can be applied. The NORECOVERY and STANDBY options do allow subsequent transaction logs to be applied. When the NORECOVERY option is specified, the database is completely unavailable after the restore and is left in a restoring state. In this state, you cannot read the database, update the database, or obtain information about the database, but you can restore transaction logs. With the STANDBY option, the database is left in a read-only state that allows some database access. standby_file_name must be specified with the STANDBY option. The standby file contains uncommitted transactions rolled back to place the database in a consistent state for read operations. If subsequent transaction log backups are applied to the STANDBY database, the uncommitted transactions in the standby file are reapplied to the database.

CAUTION Take note of the standby_file_name name used when restoring with the STANDBY option and make sure the file is secure. If another restore operation is performed and the same standby_file_name is used, the previous standby file is overwritten. The database cannot be fully recovered without the standby file, so you have to perform all the restore operations again. We speak from personal experience on this one. During a data recovery drill, for a large database (approximately 1TB), we spent hours restoring the transaction logs on a set of log-shipped databases. We manually restored the last log to be applied to place the database in STANDBY mode. Another database also in the data recovery drill was also placed in STANDBY, and unfortunately, the same standby file was used on this database. This caused more than one person a very long night. Be careful!

Some of the other options of the RESTORE DATABASE command are covered in the “Restore Scenarios” section, later in this chapter. Once again, many of these options are not required for most types of restores. For example, the following command uses basic options to restore a transaction log backup to the AdventureWorks2008 database: RESTORE LOG [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008\AdventureWorks2008_backup_200906091215.trn’ WITH FILE = 1, NOUNLOAD, STATS = 10, NORECOVERY

Typically, the individual restore commands you will use are along the lines of the preceding example. The restores become more complicated when many restores of different types are involved in a recovery option. Fortunately, SSMS can help ease this pain.

Download from www.wowebook.com

Restoring Databases and Transaction Logs

409

Restoring by Using SSMS The restore capabilities in SSMS are comprehensive and can reduce the amount of time needed to perform a restore and limit the number of errors. This is partly due to the fact that SSMS keeps track of the backups that have occurred on a server. When a restore operation is requested for a database, SQL Server reads from its own system tables and presents a list of backups that it knows about that can be restored. In situations in which many files need to be restored, SSMS can be an invaluable tool.

14

You access the restore functions in SSMS by right-clicking the database in the Object Explorer and selecting Tasks and then Restore. The options available for restore include Database, File and Filegroups, and Transaction Log. Which restore options are enabled depends on the state of the database being restored. The Transaction Log option is disabled for databases that were restored with the RECOVERY option or are set to simple recovery mode. Figure 14.6 shows an example of the restore screen that is displayed when you select a database restore for the AdventureWorks2008 database.

FIGURE 14.6 A database restore with SSMS.

The Restore Database window can show more than one type of backup, depending on what is available. The first backup shown in Figure 14.6 is a full backup, followed by a series of transaction log backups. The beauty of this screen is that the backups are shown in the order in which they should be applied. This order is very important with restores

Download from www.wowebook.com

410

CHAPTER 14

Database Backup and Restore

because they must be applied in the order in which they occurred. You can choose to apply all the backups or selectively choose the backups you want to apply. If you uncheck the first full database backup, all subsequent log backups are unchecked as well. If you recheck the full database backup and click one of the transaction log backups toward the bottom of the list, all the required backups that happened prior to the selected backups are also selected. Figure 14.7 shows an example or the Options page of the Restore Database window for the AdventureWorks2008 database. The Options page allows you to specify many of the T-SQL RESTORE options reviewed previously. The Overwrite the Existing Database option is equivalent to the REPLACE parameter and forces a replacement of the restored database if it exists already. The Preserve the Replication Settings option is equivalent to KEEP_REPLICATION. The Restrict Access to the Restored Database option is the same as using the RESTRICTED_USER option with the T-SQL RESTORE command. The Prompt Before Restoring Each Backup option does not have a T-SQL equivalent; it displays a prompt before restoring each backup set to ask whether you want to restore it.

FIGURE 14.7 Restore options with SSMS. The last three options on the Options page relate the recovery state of the last backup set restored. The first option is synonymous with the RECOVERY option, the second option is the same as NORECOVERY, and the last option is equivalent to the STANDBY option. The standby filename must be supplied with the STANDBY option and defaults to the default backup directory for the server. By default, the name of the file contains the name of the database being restored.

Download from www.wowebook.com

Restoring Databases and Transaction Logs

411

TIP You should click the Script button available on the Restore Database window if you want to see what is going on under the hood of the SSMS restores or want to run a restore later. You can learn a lot about the T-SQL options and how they work by scripting out the commands.

Restore Information

14

Backup files and system tables contain a wealth of information about what can be restored or already has been restored. You can retrieve information from the backup files by using variations of the RESTORE command. These variations do not actually perform the restore operation but provide information about the backups that can be restored. The RESTORE commands and some useful system tables are detailed in the following sections. The RESTORE FILELISTONLY Command The RESTORE FILELISTONLY command returns a result set that contains a list of the database and log files contained in the backup. An example of this command follows: RESTORE FILELISTONLY FROM DISK = ‘C:\mssql2008\backup\AdventureWorks2008_Partial.bak’

The results from this type of restore include the logical and physical filenames, the type of each file, and the size of each file. The RESTORE HEADERONLY Command The RESTORE HEADERONLY command returns a result set that contains the backup header data for all backup sets on the specified backup device. This command is useful when multiple backup sets are written to the same device. An example of this command follows: RESTORE HEADERONLY FROM DISK = ‘C:\mssql2008\backup\AdventureWorks2008_Partial.bak’

More than 50 columns are returned in the result set. Some particularly useful pieces of information include the start and finish time for the backup, recovery mode when the backup was taken, type of backup, and name of the computer from which the backup was performed. The RESTORE VERIFYONLY Command The RESTORE VERIFYONLY command verifies that a backup set is complete and readable. The restore does not attempt to verify the structure of the data in the backups, but it has been enhanced to run additional checks on the data. The checks are designed to increase the probability of detecting errors. An example of this command follows:

Download from www.wowebook.com

412

CHAPTER 14

Database Backup and Restore

RESTORE VERIFYONLY FROM DISK = ‘C:\mssql2008\backup\AdventureWorks2008_Partial.bak’ /*Result from the prior RESTORE VERIFYONLY command The backup set on file 1 is valid. */

The results from the prior example show that the RESTORE VERIFYONLY command does not contain much output, but the value of this command is in helping ensure that the backups are sound. Backup and Restore System Tables The system tables for backups and restores are found in the msdb system database. These system tables are used to keep historical information about the backups and restores that have occurred on the server. These system tables are listed in Table 14.3.

TABLE 14.3 Backing Up and Restoring System Tables

msdb System Table

Description

backupfile

Contains one row for each data or log file of a database.

backupfilegroup

Contains one row for each filegroup in a database at the time of backup.

backupmediafamily Contains a row for each media family. backupmediaset

Contains one row for each backup media set.

backupset

Contains a row for each backup set.

logmarkhistory

Contains one row for each marked transaction that has been committed.

restorefile

Contains one row for each restored file. These include files restored indirectly, by filegroup name.

restorefilegroup

Contains one row for each restored filegroup.

restorehistory

Contains one row for each restore operation.

suspect_pages

Contains one row per page that failed with an 824 error (with a limit of 1,000 rows).

sysopentapes

Contains one row for each currently open tape device.

Refer to “Backup and Restore Tables” in the “System Tables” section of SQL Server Books Online for a detailed description of each table, including each column that can be retrieved.

Download from www.wowebook.com

Restoring Databases and Transaction Logs

413

You are able to query these tables to obtain a variety of information related to backups and restores. You can tailor these queries to look at a specific database or a specific time frame. The following example retrieves restore information for the AdventureWorks2008 database:

14

select destination_database_name ‘database’, h.restore_date, restore_type, cast((backup_size/1024)/1024 as numeric(8,0)) ‘backup_size MB’, f.physical_device_name from msdb..restorehistory h (NOLOCK) LEFT JOIN msdb..backupset b (NOLOCK) ON h.backup_set_id = b.backup_set_id LEFT JOIN msdb..backupmediafamily f (NOLOCK) ON b.media_set_id = f.media_set_id where h.restore_date > getdate() - 5 and UPPER(h.destination_database_name) = ‘AdventureWorks2008’ order by UPPER(h.destination_database_name), h.restore_date desc

This example displays information related to restores that have been executed in the past five days for the AdventureWorks2008 database. The restore date, type of restore, size of the backup, and physical location of the file used for the restore are displayed when you run this query.

CAUTION Queries against system tables are acceptable and can provide a wealth of information, but you need to exercise caution whenever you are dealing with a system table. SQL Server uses these tables, and problems can occur if the values in them are changed or their physical structure is altered.

Backup and Restore Report A set of standard reports that come with SQL Server 2008 provide a variety of information about your databases, including recent restores and backups. You can access these reports by right-clicking on a database in the SSMS Object Explorer, then Reports, and then Standard Reports. You see over a dozen reports ready for you to run. A report particularly useful for obtaining restore and backup information is named Backup and Restore Events. This report details the latest backup and restore events that have occurred on a particular database. An example of this report is shown in Figure 14.8. The interactive report allows you to drill down into each backup or restore event to obtain more information. For example, the restore information shown in Figure 14.8 was obtained by clicking on the plus button next to the Successful Restore Operations label. You can then drill down into an individual restore to obtain more information, including the physical files involved in the operation.

Download from www.wowebook.com

414

CHAPTER 14

Database Backup and Restore

FIGURE 14.8 Backup and Restore Events report.

Restore Scenarios Restore scenarios are as varied as the backup scenarios that drive them. The number of scenarios is directly related to the types of backups taken and frequency of those backups. If a database is in simple recovery mode and full database backups are taken each night, your restore options are limited. Conversely, full recovery databases that have multiple filegroups and take a variety of different types of backups have a greater number of options that can be used to restore the database. The following sections describe a number of restore scenarios to give you a taste of the types of restores you may encounter. The scenarios include some restores performed with T-SQL and others performed with SSMS.

Restoring to a Different Database You can restore a database backup to a different database. The database you’re restoring to can be on the same server or a different server, and the database can be restored to a different name, if needed. These types of restores are common in development environments where a production backup is recovered on a development server or multiple copies of the same development database are restored to different database names for use by different groups. Listing 14.7 shows the T-SQL RESTORE command you can use to create a new database named AdventureWorks2008_COPY from the backup of the AdventureWorks2008 database. Take note of the MOVE options that specify where the database files for the new

Download from www.wowebook.com

Restore Scenarios

415

AdventureWorks2008_COPY database will exist. Each MOVE option must refer to the logical

name for the file and include a physical file location that is a valid location on the server. In addition, the referenced file cannot be used by another database. The only exception is when you are restoring to the database that is using the files and the REPLACE option is used.

LISTING 14.7 Restore to a Different Database

14

RESTORE DATABASE [AdventureWorks2008_COPY] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008.bak’ WITH FILE = 1, MOVE N’AdventureWorks2008_Data’ TO N’C:\mssql2008\data\AdventureWorks2008_Copy.mdf’, MOVE N’AdventureWorks2008_Log’ TO N’C:\mssql2008\data\AdventureWorks2008_Copy_log.ldf’, NOUNLOAD, STATS = 10

TIP A restore of a database backup taken from another server can cause problems after the restore completes. The problems are caused by broken relationships between the database users captured in the backup file and the associated logins on the server to which the backup is restored. The relationships are broken because each login receives a unique ID assigned to it when it is added. These unique IDs can and will be different across servers, even though the logins may have the same name. The unique ID from the login is stored with each database user in order to identify the login that the user is associated with. When the unique ID for the login is different or not found, you get spurious errors when trying to connect to the database with these users or when trying to administer these users in SSMS. The sp_change_users_login system stored procedure is designed to correct these broken relationships. You can run this procedure with the ”report” option in the database in question to help identify any problems (that is, sp_change_users_login “report”). The stored procedure also has options to fix the broken relationships. For example, sp_change_users_login “autofix”, “myuser” fixes the relationship for the ”myuser” database user. You should check SQL Server Books Online for further options and details on this stored procedure. Another quick-and-dirty means for fixing orphaned database users is to delete the users from the database and then re-create them. Of course, the login must exist on the server, and all the permissions associated with the database user must be reestablished. Permissions can be overlooked or missed with this method, so it is safer to stick with the sp_change_users_login procedure.

Download from www.wowebook.com

416

CHAPTER 14

Database Backup and Restore

Restoring a Snapshot Database snapshots, which were introduced in SQL Server 2005, provide a fast method for capturing a transactionally consistent view of a database. The snapshot is created as another read-only database linked to the original database from which the snapshot was taken. As changes are made to the original database, the database engine uses a copy-onwrite method to keep the snapshot consistent. After a snapshot is taken, you can revert back to the snapshot at a later time and restore the original database to the state it was in when the snapshot was taken. You do not create the snapshot by backing up a database, but you can restore it using methods similar to restoring a backup. The following examples shows the syntax to revert a database back to a database snapshot: RESTORE DATABASE { database_name | @database_name_var } FROM DATABASE_SNAPSHOT database_snapshot_name

Database snapshots are available only with the Enterprise or Development Editions of SQL Server. They are discussed in more detail in Chapter 32, “Database Snapshots.”

Restoring a Transaction Log Transaction log restores deserve special attention because of their dependency on other backup types. Typical transaction log restores occur after a full or differential database restore has occurred. After this base is established, the transaction log restores must be done in the same sequential order as the backups that were taken. Fortunately, SSMS does a good job of presenting the available backups in the order in which they must be applied. You can do the entire restore sequence with SSMS, including a full restore followed by a restore of any other backups, including transaction log backups. To restore transaction log backups (independent of other backups), you can select the Transaction Log option. Figure 14.9 shows a sample screen for restoring transaction logs in the AdventureWorks2008 database. The transaction logs shown in Figure 14.9 are listed in the order in which they were taken and the order in which they need to be applied. You can uncheck some of the available backups, but you are not allowed to select backups that are not in the correct sequence. In other words, you can uncheck backups from the bottom of the list, but if you uncheck backups toward the top of the list, all backups found below that item are unchecked as well. It is important to remember that you can restore transaction log backups only to a database that is in the NORECOVERY or STANDBY state. Make sure that every restore prior to the last one uses one of these options. When you restore the last transaction log, you should use the RECOVERY option so that the database is available for use.

Download from www.wowebook.com

Restore Scenarios

417

14

FIGURE 14.9 Transaction Log Restore.

Restoring to the Point of Failure A disk failure on a drive that houses database files is a reality that some database administrators must deal with. This situation can give pause to the most seasoned administrators, but it is a situation that can be addressed with little or no data loss. Don’t panic! You need to first identify the available backups.

NOTE It is hoped the disk that experienced a failure is not the same disk that houses your backups. Database backups should always be stored on separate media. One of the best approaches is to write the backups to a drive that does not contain any other SQL Server files and write the contents of that drive to tape. This minimizes the possibility of losing one of those all-important backups.

The backup components that you need to restore to the point of failure include the following: . A backup of the tail of the transaction log . A full database backup or file/filegroup backup to establish a base

Download from www.wowebook.com

418

CHAPTER 14

Database Backup and Restore

. The full sequence of transaction log backups created since the full database backup The following sections describe the detailed steps for recovery that relate to these backup components.

NOTE The restore steps outlined in the following sections do not address the recovery of the actual disk that failed. The recovery of hardware, such as a disk, is beyond the scope of this book, but it needs to be addressed to get your environment back to the state it was in prior to the failure.

Backing Up the Tail of the Transaction Log The first thing you should do in the event of a damaged database is to back up the tail of the transaction log. The tail of the transaction log is found in the active SQL Server transaction log file(s). This tail is available only for databases that are in full or bulk-logged recovery mode. This tail contains transactions not backed up yet. The following example shows how to back up the tail of the log for the AdventureWorks2008 database using TSQL: BACKUP LOG [AdventureWorks2008] TO DISK = N’C:\mssql2008\backup\log\AdventureWorks2008_Tail.trn’ WITH NO_TRUNCATE NO_TRUNCATE prevents the transactions in the log from being removed and allows the

transaction log to be backed up, even if the database is inaccessible. This type of backup is possible only if the transaction log file is accessible and was not on the disk that had the failure.

Recovering the Full Database Recovery After you back up the tail of the transaction log, you are ready to perform a full database restore. This restore, which is based on a full database backup or a file/filegroup backup, overwrites the existing database. It is imperative that the full database restore be done with the NORECOVERY option so that the transaction log backups and tail of the log can be applied to the database as well. The following example restores a full backup of the AdventureWorks2008 database, using the T-SQL RESTORE command: RESTORE DATABASE [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10

Upon completion of this type of restore, the database appears in the SSMS Object Explorer with ”(Restoring...)” appended to the end of the database name. The database is now ready for transaction log backups to be applied.

Download from www.wowebook.com

Restore Scenarios

419

Restoring the Transaction Log Backup The final step in recovery is to apply the transaction log backups. These backups include all the transaction log backups since the last full backup plus the tail of the log you backed up after the media failure. If differential backups were taken since the last full backup, you can apply the last differential backup and apply only those transaction log backups that have occurred since the last differential backup. You can restore transaction log backups by using T-SQL or SSMS. To restore with SSMS, you can right-click the database in the restoring state and select the Transaction Log Restore option. The Restore Transaction Log screen lists the available transaction log backups, including the backup of the transaction log tail. You need to select all the transaction logs, including the tail. You should make sure to go to the Options tab and select the Recovery option so that your database is available after the restore completes.

14

Alternatively, you can use T-SQL to perform the transaction log backup restores. The following example shows a series of transaction log restores. The first two restores are done with the NORECOVERY option. The last command restores the tail of the log and uses the RECOVERY option to make the database available for use: RESTORE LOG [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008_backup_200906180922.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008_backup_200906180923.trn’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [AdventureWorks2008] FROM DISK = N’C:\mssql2008\backup\log\AdventureWorks2008_Tail.trn’ WITH FILE = 3, NOUNLOAD, STATS = 10 GO

When many transaction log backups are involved, using T-SQL to perform the restores can be challenging. The restores must occur in the proper order and refer to the proper location of the backup file(s). Restores done with SSMS are typically less prone to error.

Restoring to a Point in Time Databases in the full or bulk-logged recovery models can be restored to a point in time. This type of restore is similar to the point-of-failure scenario covered previously, but it allows for a more precise restore operation. These restores allow the database to be recovered to a time prior to a particular event. Malicious attacks or erroneous updates are some examples of events that would justify a point-in-time restore.

Download from www.wowebook.com

420

CHAPTER 14

Database Backup and Restore

NOTE There are some limitations on point-in-time restores of databases set to the bulklogged recovery model. Point-in-time restores are not possible on transaction log backups that contain bulk load operations. Point-in-time restores can occur using transaction log backups that occurred prior to the bulk load operation, as long as a bulk load did not occur during the time of these backups.

A point-in-time restore can be done using one of the following: . A specific date/time within the transaction log backup . A specific transaction name inserted in the log . An LSN Point-in-time restores can be done with T-SQL or SSMS. Figure 14.10 shows the General page that allows you to specify the Point in Time option. The default is to restore to the most recent time possible, but you can click on the ellipsis to display the Point in Time Restore dialog box, which is shown in the middle of Figure 14.10. You can select the date to restore to by using the date drop-down and enter the time to restore to as well.

FIGURE 14.10 A point-in-time restore.

Download from www.wowebook.com

Restore Scenarios

421

Online Restores Online restores were new to SQL Server 2005 and continue to be supported in SQL Server 2008. They allow a filegroup, file, or specific page within a file to be restored while the rest of the database is online. The file or filegroup that is being restored to must be offline during the duration of the online restore.

TIP You should take a full backup of a database immediately before taking a read-only file offline. This simplifies the online restore process and eliminates the need to apply a bunch of transaction log backups prior to the online restore. This applies only to databases in full or bulk-logged recovery.

14

The following example demonstrates how to take a read-only file offline: ALTER DATABASE AdventureWorks2008 MODIFY FILE (NAME = ‘AdventureWorks2008_ReadOnlyData’, OFFLINE)

When the file is offline, you can perform a restore to that file without affecting the rest of the database. The following example shows an example of an online restore of a read-only file to the AdventureWorks2008 database: RESTORE DATABASE [AdventureWorks2008] FILE = N’AdventureWorks2008_ReadOnlyData’ FROM DISK = N’C:\mssql2008\backup\AdventureWorks2008_ReadOnlyData.bak’ WITH FILE = 1, NOUNLOAD, STATS = 10, RECOVERY

Restoring the System Databases The SQL Server 2008 system databases that can be restored are the master, msdb, model, and distribution databases. Each of these databases performs an essential role in the operation of SQL Server. If these databases are damaged or lost, they can be restored from database backup files in a similar fashion to user databases. The master database, which contains information about other databases and is required to start SQL Server, has some special restore considerations. It must be operational before restores of other system databases can be considered. When you are restoring the master database, there are two basic scenarios. The first scenario involves a restore of the master database when the master database currently used by SQL Server is operational. In the second scenario, the master database is unavailable, and SQL Server is unable to start. The first master database restore scenario is less involved and typically less stressful than the second. In the first scenario, your SQL Server can be up and running until the time you want to do the restore. When you are ready to do the restore, the SQL Server instance must be running in single-user mode. The server can be started in single-user mode via a

Download from www.wowebook.com

422

CHAPTER 14

Database Backup and Restore

command prompt window. You stop the currently running SQL Server service, open a command prompt window, navigate to the directory where the sqlservr.exe file exists (typically C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\), and run the following command: sqlservr.exe –m

When this command is executed, the SQL Server instance is running in the command prompt window. This window must be kept open for the SQL Server instance to keep running. The service for SQL Server appears as stopped, but the database engine is truly running. The –m parameter places the server in single-user mode and allows a single administrator connection to the server. You can use that one connection to connect to the server to use the Object Explorer, a database query window in SSMS, SQLCMD, or any other tool that allows you to establish a connection and run commands against the database server. If you use the SSMS Object Explorer connection, you can right-click on the master database and select the Restore option. You need to enter master for the database to restore and select the overwrite option. You can instead run a T-SQL RESTORE command to achieve the same result. When the restore of the master database is complete, SQL Server is automatically shut down. If you performed the restore using Object Explorer, you can expect to get an error message at the end of the restore process because SQL Server was shut down. You can simply close the command prompt window you used earlier and establish a new connection to the database server. All the databases, logins, and so on that were present prior to the backup are reestablished. In the second scenario, the master database is damaged or unavailable, and SQL Server cannot start. If SQL Server is unable to start, you must reestablish a base environment like that which existed when SQL Server was initially installed. Using the REBUILDDATABASE option in setup.exe is one way to re-create all the system databases and reestablish this base environment. The REBUILDDATABASE parameter is part of a SQL Server installation that is done from the command prompt. You need the installation media for the edition of SQL Server installed on the machine. After you insert the disk and when you have access to the installation files, you can use the following syntax to launch the Setup program from a command prompt window: start /wait \setup.exe /qn INSTANCENAME= REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD= InstanceName should be set to MSSQLSERVER for a default instance of SQL Server or the name of the instance, if it is not the default. In addition, a new SA password needs to be supplied for the SAPWD parameter. The /qn parameter suppresses all the setup dialog boxes

and error messages and causes the installation to run silently. If you want to receive more information during the installation, you can specify the /qb parameter.

Download from www.wowebook.com

Additional Backup Considerations

423

NOTE If you get a message about a missing Windows Installer, you can find that software on the SQL Server media in the Redist folder. You may also find that the setup.exe file is not found on the root of your installation media. If this is the case, you need to change the directory in the command prompt window to the location of the setup.exe file on the installation media prior to executing the command to launch the setup program. Finally, remember to reinstall any service packs or patches you may have installed. The execution of the command prompt setup reverts the server back to the original software release.

14

At the end of the installation, all the system database files are installed to their original locations. This includes the original master.mdf, mastlog.ldf, msdbdata.mdf, and msdblog.ldf files, as well as the related database files for the other system databases. Any of the user databases you may have added to the server are no longer known by the master database and in turn are not available in the Object Explorer or other database tools. If you have a backup of the master database, you can restore it after the command prompt installation is complete. You follow the procedures outlined in the first scenario, earlier in this section, to restore the master database from a backup. At the completion of the restore, any user databases present at the time of the master database backup are now available. You can also run restores for other system databases at this time, including the msdb database, which contains all your scheduled jobs and history. If you do not have a backup of the master database, this is not the end of the world. You still have the option of manually attaching your user databases or restoring them from backup files. Attaching the database is typically much faster than restores from backup files and is the preferred method. You must also reestablish logins, backup devices, server triggers, and any other server-level objects stored in the master database. Depending on your environment, this can be a lengthy operation, but you can easily avoid it by making those all-important system database backups.

Additional Backup Considerations A sound backup plan goes beyond the commands and tools described thus far in this chapter. There are several other considerations, detailed in the following sections, that should be considered as well.

Frequency of Backups How often you back up your databases depends on many factors, including the following: . The size of your databases and your backup window (that is, the time allocated to complete the task of backing up the database)

Download from www.wowebook.com

424

CHAPTER 14

Database Backup and Restore

. The frequency of changes to the data and method by which it is changed . The acceptable amount of data loss in the event of a failure . The acceptable recovery time in the event of a failure First, you must establish what your backup window will be. Because SQL Server allows dynamic backups, users can still access the database during backups; however, this affects performance. This means you should still schedule backups for low-activity periods and have them complete in the shortest possible time. After you establish your backup window, you can determine your backup method and schedule. For example, if it takes 4 hours for a full backup to complete, and the database is quiescent between midnight and 6:00 a.m., you have time to perform a full backup each night. On the other hand, if a full backup takes 10 hours, and you have a 2-hour window, you should consider monthly or weekly backups, perhaps in conjunction with filegroup, differential, and transaction log backups. In many decision-support databases populated with periodic data loads, it might suffice to back up once after each data load. Backup frequency is also directly tied to acceptable data loss. In the event of catastrophic failure, such as a fire in the server room, you can recover data only up to the point of the last backup moved offsite. If it is acceptable to lose a day’s worth of data entry, nightly backups might suffice. If your acceptable loss is an hour’s worth of data, hourly transaction log backups would have to be added to the schedule. Your backup frequency affects your recovery time. In some environments, a weekly full backup plus transaction log backups taken every 10 minutes provide an acceptable data loss factor. A failure a few days after backup would require a full database restore and the application of hundreds of transaction logs. Adding a daily differential backup in this case would vastly improve restore time. The full and differential backups would be restored, and then six logs would be applied for each hour between the differential backup and the time of failure.

Using a Standby Server If the ability to quickly recover from failure is crucial to your operation, you might consider implementing a standby server. Implementing a standby server involves backing up the production server and then restoring it to the standby server, leaving it in recovery mode. As transaction logs are backed up on the production server, they are applied to the standby server. If a failure occurs on the production server, the standby server can be recovered and used in place of the production server. If the production server is still running, you should not forget to back up the current log with the NO_TRUNCATE option and restore it to the standby server as well before bringing it online.

NOTE Another advantage of restoring backups to a standby server is that it immediately validates your backups so you can be assured of whether they are valid. There is nothing worse than finding out during a recovery process that one of the backup files is damaged or missing.

Download from www.wowebook.com

Additional Backup Considerations

425

The STANDBY =undo_file_name option plays a key role in the application of transaction logs to the standby server. When the database and subsequent log backups are restored to the standby server with this option, the database is left in recovery mode but is available as a read-only database. Now that the standby database is available for queries, it can actually reduce load on the production database by acting as a decision support system (DSS). Database Consistency Checks (DBCC) can be run on it as well, further reducing the load on the production system.

14

For the database to be available for reads, the data must be in a consistent state. This means that all uncommitted transactions must be rolled back. This rollback is usually handled by the RECOVERY option during a restore. In the case of a standby server, this would cause a problem because you would intend to apply more logs, which could, in fact, commit those transactions. This situation is handled by the undo_file_name clause of the STANDBY option. The file specified here holds a copy of all uncommitted transactions rolled back to bring the standby server to a consistent, read-only state. If those transactions subsequently commit a log restore, this undo information can be used to complete the transaction. The application of hundreds or thousands of transaction logs to the standby server can be challenging. Fortunately, SQL Server 2008 includes log shipping, which automates the transfer of logs to the standby server. Log shipping, which can be configured in SSMS, uses SQL Server Agent jobs on the primary server to back up the transaction log and copy it to a folder on the standby server. SQL Server Agent on the standby server then executes a load job to restore the log. Automating your standby server with log shipping reduces administration and helps to ensure that the standby database is up-to-date. For further details on log shipping, see Chapter 19, “Replication.” Log shipping isn’t a form of replication but is covered in Chapter 19 as an alternative to replication.

Snapshot Backups Snapshot backups are developed in conjunction with independent hardware and software vendors. These backups are not related to SQL Server database snapshots and are not accessible from any of the SQL Server tools. They utilize backup and restore technology and can provide relatively fast backup and restore operations. Snapshot backups are typically utilized on very large databases that are unable to perform database backups and restores in a timely fashion using SQL Server’s conventional backup and restore resources.

Considerations for Very Large Databases When it comes to backup and recovery, special consideration must be given to very large databases, which are known as VLDBs. A VLDB has the following special requirements: . Storage—Size might dictate the use of tape backups over the network or a disk. . Time—As your time to backup increases, the frequency of backups might have to be adjusted. . Method—How you back up your database is affected by its size. Differential or file and filegroup backups might have to be implemented.

Download from www.wowebook.com

426

CHAPTER 14

Database Backup and Restore

. Recovery—Partial database recovery, such as restoring a file or filegroup, might be required due to the prohibitive time required to restore the entire database. When designing a VLDB, you must integrate your backup plan with storage, performance, and availability requirements. Larger databases take longer to back up because the backup sizes are larger, and restores on this type of database can take much longer to complete than with a smaller database.

Maintenance Plans SQL Server includes maintenance plans that provide database maintenance tasks, including optimization, integrity checks, and backups. The backup options available in the maintenance plans are comprehensive and include the capability to regularly schedule full, differential, and transaction log backups. This type of automation is essential to ensure that your backups are taken with a reliable tool at regular intervals. You can create maintenance plans from within SSMS. If you open the Management node in the Object Explorer, you see a node named Maintenance Plans. If you right-click this node, you can select New Maintenance Plan to create a plan from scratch, or you can select Maintenance Plan Wizard to have a wizard guide you through the creation of a new maintenance plan. The following options that relate to backups are available as part of a maintenance plan: . Back Up Database (Full) . Back Up Database (Differential) . Back Up Database (Transaction Log) Using these tasks in a maintenance plan is a great start to a solid backup and recovery plan. Refer to Chapter 33, “Database Maintenance,” for further details about creating a maintenance plan.

Summary Having a database environment without a solid backup and recovery plan is like owning a home without an insurance policy to protect it. If you develop a plan to minimize the possibility of losing a database, you have essentially bought an insurance policy for your data. In the event of a problem, you can call on the backups that you have invested in and recover the loss with a minimal amount of cost. Chapter 15, “Database Mail,” explores a comprehensive mail feature offered with SQL Server 2008. Database Mail allows you to send email notifications from SQL Server. These notifications can be tied to scheduled jobs and alerts within SQL Server, including jobs that can execute those all-important database backups.

Download from www.wowebook.com

CHAPTER

15

Database Mail

IN THIS CHAPTER . What’s New in Database Mail . Setting Up Database Mail . Sending and Receiving with Database Mail . Using SQL Server Agent Mail . Related Views and Procedures

Database Mail is SQL Server 2008’s emailing component, built as the replacement for SQL Mail. Although SQL Mail can still be enabled in SQL Server 2008 (for backward compatibility, although it is deprecated), it’s a simple task to convert all your existing SQL Mail code and SQL Agent Mail notifications to Database Mail. And you’ll surely want to.

What’s New in Database Mail Database Mail is an enterprise-class implementation designed with all the features you’d expect from this nextgeneration database server, most of which are not available in SQL Mail. These features include support for multiple email profiles and accounts, asynchronous (queued) message delivery via a dedicated process in conjunction with Service Broker, cluster-awareness, 64-bit compatibility, greater security options (such as governing of mail attachment size and prohibition of file extensions), and simplified mail auditing. Database Mail also utilizes the industry-standard Simple Mail Transfer Protocol (SMTP), signaling the end of reliance on Extended Messaging Application Programming Interface (Extended MAPI). Database Mail has more capabilities and is more scalable and reliable than SQL Mail, especially when stressed with the heavier usage scenarios common today. And, thankfully, it’s a good deal easier to successfully configure than its predecessor.

Download from www.wowebook.com

428

CHAPTER 15

Database Mail

Setting Up Database Mail Unlike with SQL Mail, setting up profiles and accounts for use with Database Mail is easy to accomplish, thanks mainly to the Database Mail Configuration Wizard, found in the SQL Server Management Studio (SSMS) Object Browser. You can use this wizard both to set up and manage Database Mail. Before using it, you need to switch on the Database Mail feature, which is off by default, in keeping with Microsoft’s secure-by-default approach. Follow these steps to do so. Configure the Database Mail XPs configuration option by running the following T-SQL code in a new query window (while logged in as sysadmin, of course): use Master GO sp_configure ‘show advanced options’, 1; GO RECONFIGURE; GO sp_configure ‘Database Mail XPs’, 1; GO RECONFIGURE GO Configuration option ‘show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install. Configuration option ‘Database Mail XPs’ changed from 0 to 1. Run the RECONFIGURE statement to install.

If you ever want to disable Database Mail, you can run this: sp_configure ‘Database Mail XPs’, 0;

This statement prevents Database Mail from starting in response to a call to sysmail_start_sp (discussed later in this chapter). If Database Mail is running when you make this call, it sends unsent queued mail until the mail sending process (DatabaseMail.exe) has been idle for the duration of the DatabaseMailExeMinimumLifeTime configuration setting (discussed later in this chapter); then it stops. You also need to enable Service Broker in msdb (if not done already) because Database Mail relies on it as part of its implementation. To do this, you stop the SQL Server Agent service and then execute the following script: USE master GO ALTER DATABASE msdb SET ENABLE_BROKER

Download from www.wowebook.com

Setting Up Database Mail

429

You can check the status of Service Broker on msdb by using the following code: Use Master GO SELECT is_broker_enabled FROM sys.databases WHERE name = ‘msdb’ GO is_broker_enabled ————————1 (1 row(s) affected)

To receive message send requests from outside the SQL Server instance, you need to create an endpoint (preferably a certificate-secured one) associated with Service Broker. To accomplish this, refer to the “Service Broker Routing and Security” section in Chapter 49, “SQL Server Service Broker” (on the CD), or consult the “Create Endpoint” topic in Books Online.

15

To complete this configuration, you need to return to SSMS and establish a connection to the same SQL Server instance for which you just enabled Database Mail. You connect the Object Browser to that instance and expand the Management folder to reveal the Database Mail node. Then you right-click the Database Mail node and select the Configure Database Mail menu option to launch the Database Mail Configuration Wizard.

Creating Mail Profiles and Accounts After you pass the Database Mail Configuration Wizard’s welcome screen, you are presented with the opportunity to set up Database Mail (“for the first time”). You can achieve this by creating the required profiles, profile security settings, SMTP accounts, and system-wide mail settings. You should leave the first radio button (Set Up Database Mail by Performing the Following Tasks) selected and then click Next.

NOTE In Database Mail, you use mail profiles. A mail profile is simply a securable container for a group of SMTP accounts that is used when sending mail. In contrast to SQL Mail, with Database Mail, you can set up multiple profiles containing multiple accounts, allowing for finer-grained administrative control. You can create one profile for admintrators and another for regular users, for example, or create distinct profiles dedicated to various software applications. Note also that to use Database Mail, you no longer need to run the SQL Server or SQL Server Agent Windows services under user accounts (rather than using the default, LocalSystem), nor do you need to install Microsoft Outlook (or any other Extended MAPI client) on the machine hosting SQL Server 2008.

In the New Database Mail Account screen that appears (see Figure 15.1), you name (using a valid sysname) and describe your first profile in the provided text boxes, and then you

Download from www.wowebook.com

430

CHAPTER 15

Database Mail

click Add to add your first SMTP account. This process is much like the process of setting up the SMTP (or sending) portion of your email accounts with your regular email client software. To create the SMTP account, you specify a name, an optional description, a user display name, an email address, an optional reply address, a server name, a port, and an authentication mode, which is used to authenticate to the specified SMTP server (as required by your SMTP provider). For many non-Windows SMTP providers, anonymous (no authentication) or basic (simple user name/password) authentication is usually required. If your provider requires Windows Authentication, the credentials under which the SQL Server Windows service runs are supplied to the SMTP server at runtime.

FIGURE 15.1 Using the Database Mail Configuration Wizard to set up SMTP accounts. Instead of using the wizard, you can add a new profile via T-SQL. For example, the following three examples introduce the Database Mail stored procedures sysmail_add_profile_sp, sysmail_add_account_sp, and sysmail_add_profileaccount_sp. The first script creates the new profile: EXEC msdb.dbo.sysmail_add_profile_sp @profile_name = ‘Default SQL 2008 Profile’, @description = ‘Used for general-purpose emailing.’

The second script creates the new SMTP account: EXEC msdb.dbo.sysmail_add_account_sp @account_name = ‘UnleashedMailAcct1’,

Download from www.wowebook.com

Setting Up Database Mail

431

@description = ‘The first SMTP Account.’, @email_address = ‘[email protected]’, @display_name = ‘SQL 2008 Mail Account 1’, @mailserver_name = ‘smtp.samspublishing.com’ ;

The third script associates this new account with the new profile: EXEC msdb.dbo.sysmail_add_profileaccount_sp @profile_name = ‘Default SQL 2008 Profile’, @account_name = ‘UnleashedMailAcct1’, @sequence_number =1;

15

The great thing you’ll find when adding SMTP accounts is that Database Mail allows you to provide more than one SMTP account for the same profile. You can order the SMTP accounts by priority (using the Move Up/Move Down buttons) so that if a mail send via the top-level (or first) account fails, the second account will be used to retry sending, and so on. This is called SMTP failover priority, and there are two mail settings that control how it works. These settings, found on the Configure System Parameters screen of the wizard, are AccountRetryAttempts and AccountRetryDelay. AccountRetryAttempts specifies how many mail send retries Database Mail will make before failing over to the SMTP account of next-highest priority. AccountRetryDelay specifies (in seconds) how long to wait between mail send retries. These features represent a big improvement in reliability over SQL Mail, which had no such retry capabilities. After adding the new account to the profile, click Next to set up the profile security settings on the Manage Profile Security screen. Database Mail profiles have two levels of security (with two corresponding tabs on the wizard screen): . Public—The profile can be used by all msdb users. . Private—The profile can be used only by specific users or members of a specific role. (Note that to send mail, users must have DatabaseMailUserRole membership in msdb. Use sp_addrolemember to accomplish this.) Specify these users on the Private Profiles tab of the Manage Profile Security screen. In this case, check the check box under the Public column of the data grid on the Public tab; then click the word No under the Default Profile column. A drop-down list appears, allowing you to make the profile the default (by changing the selection to Yes). The default profile on the server is used when you invoke sp_send_dbmail (the successor to xp_sendmail) without specifying any profile name for the @profile_name parameter. It’s a good idea to have a default profile set up for general mailing purposes, especially when testing. To set profile security using T-SQL, run the following call to the stored procedure sysmail_add_principalprofile_sp: exec msdb.dbo.sysmail_add_principalprofile_sp @profile_name = ‘Default SQL 2008 Profile’, @principal_name = ‘public’, @is_default = 1 ;

Download from www.wowebook.com

432

CHAPTER 15

Database Mail

A third way to configure all the previously mentioned mail objects (in the form of a T-SQL script) is to use an SMSS Database Mail query template. To do this, you open the Template Explorer via the View menu (or by pressing Ctrl+Alt+T), and then you expand to the Database Mail folder and double-click Simple Mail Database Configuration. Then you connect to your SQL Server instance and, from the Query menu, select the Specify Values for Template Parameters option (or press Ctrl+Shift+M) to fill in the desired parameter values, which correspond to the parameters of the stored procedures mentioned previously.

Using T-SQL to Update and Delete Mail Objects To delete or update profiles, accounts, profile-account associations, and profile security settings (note: do so in reverse order), you use the stored procedures shown in Table 15.1.

TABLE 15.1 T-SQL Stored Procedures Stored Procedure Name

Purpose

sysmail_delete_profile_sp

Delete a profile

sysmail_delete_account_sp

Delete an account

sysmail_delete_principalprofile_sp

Delete the association between a profile and a user or role (revokes permission for the principal on use of the profile)

sysmail_delete_profileaccount_sp

Delete the association between a profile and an account

sysmail_update_profile_sp

Update a profile

sysmail_update_account_sp

Update an account

sysmail_update_principalprofile_sp

Update the association between a profile and a user or role

sysmail_update_profileaccount_sp

Update the association between a profile and an account

For example, to delete a profile, you execute this: exec msdb.dbo.sysmail_delete_profile_sp @profile_name=’Undesireable Profile Name’

To update a profile’s security, changing it from the default to the nondefault profile, you execute the following: exec msdb.dbo.sysmail_update_principalprofile_sp @profile_name = ‘Default SQL 2008 Profile’,

Download from www.wowebook.com

Setting Up Database Mail

433

@principal_name = ‘public’, @is_default = 0;

Alternatively, you can simply return to the wizard and select one of the Manage options to alter or drop any of the settings or objects. (Of course, under the covers, the wizard probably uses all these stored procedures.)

Setting System-wide Mail Settings You use the Configure System Parameters screen in the Database Mail Configuration Wizard to configure the system-wide Database Mail settings. (Click Next on the Select Configuration Task screen to reach this screen, if you haven’t already.) You’ve seen the first two settings that appear in the grid (AccountRetryAttempts and AccountRetryDelay) in an earlier section (“Creating Mail Profiles and Accounts”) as they relate to SMTP failover priority. These are the other four: . Maximum File Size (Bytes)—This setting specifies the maximum size of any one email attachment.

15

. Prohibited Attachment File Extensions—This setting specifies which potentially dangerous or undesirable attachment types to ban from exchanged emails. . Database Mail Executable Minimum Lifetime (seconds)—This setting specifies how long (minimally) the database mail process (that is, DatabaseMail.exe, which is activated by Service Broker) should run idly before closing after it finishes emptying the mail send queue. . Logging Level—This setting specifies the quality of email auditing to use, and it can be set to Normal (errors only), Extended (errors, warnings, and informational messages; this is the default), or Verbose (the same as Extended, plus success messages and other messages that are useful when you debug problems with DatabaseMail.exe). To view Database Mail’s primary log, right-click the Database Mail folder in the Object Browser and then click the View Database Mail Log menu option. Examine and maintain the log by using the Log File Viewer that is launched. You can also use the built-in stored procedure sysmail_delete_log_sp to clear the log, or query the msdb sysmail_event_log view to see its contents in tabular format. To change any of these configuration settings via T-SQL script, use the sysmail_configure_sp stored procedure. sysmail_configure_sp takes two parameters: the name of the setting (minus any spaces) and its new value. The following example uses the sysmail_configure_sp procedure to change AccountRetryDelay to two minutes: exec msdb.dbo.sysmail_configure_sp ‘AccountRetryDelay’, 1200

Testing Your Setup The final step in setting up Database Mail is to ask SQL Server to send a test email. To do this, right-click the Database Mail folder in the Object Browser and then click the Send Test E-mail menu option.

Download from www.wowebook.com

434

CHAPTER 15

Database Mail

If the test fails, click Troubleshoot, and SMSS opens the “Troubleshooting Database Mail” Books Online topic, which provides a solid set of troubleshooting steps to get you started. If the mail is sent by SQL Server and successfully received in your client software’s inbox, you can proceed to the next section to learn how to use the sp_send_dbmail stored procedure to send email from T-SQL. Otherwise, look for more troubleshooting help in the “Related Views and Procedures” section of this chapter.

Sending and Receiving with Database Mail If you’re building client applications that rely heavily on Database Mail, it’s crucial to gain an in-depth understanding of its underlying architecture. The following sections provide detailed information on its inner workings.

The Service Broker Architecture As noted earlier, SQL Server relies on Service Broker (SSB) to activate the Database Mail process (DatabaseMail.exe) used to send mail. DatabaseMail.exe uses ADO.NET to connect to SQL Server and to read from and write to SSB queues (found in msdb) that hold send requests and send statuses in the form of typed SSB messages. You can view these queues (InternalMailQueue and ExternalMailQueue) in the Object Browser by selecting Service Broker and then the Queues folder. If you look a bit further in the Object Browser, you see how the mail transmission architecture is implemented (in part) as an SSB application, as you find the corresponding internal and external Database Mail SSB services (InternalMailService and ExternalMailService), SSB message types (SendMail and SendMailStatus), and a single SSB contract (SendMail/v1.0). SSB’s involvement with Database Mail works like this: 1. sp_send_dbmail (as the SSB initiator) is invoked and returns immediately. Under the covers, this adds an SSB message of type SendMail to the SSB mail queue, activating the undocumented internal stored procedure sp_ExternalMailQueueListener. Note that the mail message itself is saved to one or more of the msdb tables (such as sysmail_unsentitems and sysmail_attachments) if there are any attachments. 2. SSB launches DatabaseMail.exe (running under the credentials of the SQL Server service), which, in turn, connects back to SQL Server, using Windows Authentication. 3. DatabaseMail.exe reads the queued SSB send message, retrieves the mail message data, sends the email, and, finally (acting as the SSB target), places a message of type SendMailStatus in the mail status queue, reporting on the mail sending success or failure. 4. When there’s nothing left to be sent in the outbound queue, and the maximum process idle time has been reached, DatabaseMail.exe exits.

Download from www.wowebook.com

Sending and Receiving with Database Mail

435

By using SSB, Database Mail inherits the reliability of the SSB message transmission architecture. If you want to learn more about Service Broker and how its constructs work, consult Chapter 49 (on the CD) for full details.

Sending Email The SSB queues that Database Mail uses must first be enabled before you can send mail from a session. You do this by executing the msdb stored procedure sysmail_start_sp. This procedure is similar to its predecessor, xp_startmail (as it must be called before sending), except that it has no parameters and, of course, has nothing to do with MAPI. It returns 0 or 1, indicating success or failure. If you don’t call this procedure, you receive this error message: Mail not queued. Database Mail is stopped. Use sysmail_start_sp to start Database Mail.

15

To temporarily disable SSB’s activation of the mail process, you execute sysmail_stop_sp (also with no parameters), which returns 0 or 1. If you send mail from code after this disabling this process, these messages will be queued. The external process is not started until sysmail_start_sp is called again. To check on the status of Database Mail, you can execute sysmail_help_status_sp (with no parameters). To check on the status of the queues, you execute sysmail_help_queues_sp. After you execute sysmail_start_sp, you’re ready to begin sending mail using the sp_send_dbmail stored procedure. It has 21 parameters, most of which are optional. As the query engine will tell you if you try to execute it with no or too few parameters, at least one of the following parameters must be specified: @body, @query, @file_attachments, or @subject. You also must specify one of the following: @recipients, @copy_recipients, or @blind_copy_recipients.

NOTE For the following T-SQL examples to work, you must first configure a default profile using either the Database Mail Configuration Wizard or Database Mail stored procedures, as detailed earlier.

A minimally parameterized test call might look like the following: exec msdb.dbo.sp_send_dbmail @body=’Testing...’, @subject=’A Test’, @recipients=’[email protected]’ go Mail Queued.

Table 15.2 describes the parameters, their types, and the xp_sendmail parameters to which they may correspond, to help you along in converting your existing T-SQL code.

Download from www.wowebook.com

436

CHAPTER 15

Database Mail

TABLE 15.2 Parameters for Database Mail Stored Procedure sp_send_dbmail Parameter

Description

xp_sendmail

Parameter to Which It Corresponds @profile_name

The sysname of the profile whose SMTP accounts will be used to send.

Not available in xp_sendmail.

@recipients

A varchar(max) semicolon-delimited list of the recipients’ email addresses.

Same as xp_sendmail.

@copy_recipients

A varchar(max) semicolon-delimited list of the carbon copy recipients’ email addresses.

Same as xp_sendmail.

@blind_copy_recipients

A varchar(max) semicolon-delimited list of the blind carbon copy recipients’ email addresses.

Same as xp_sendmail.

@subject

The nvarchar(255) email subject. Same as xp_sendmail.

@body

The nvarchar(max) email body.

Was @message in xp_sendmail.

@body_format

One of the two varchar (20) email format type strings, either ’HTML’ or ’TEXT’ (the default).

Not available in xp_sendmail.

@importance

One of the three varchar (6) email importance strings, either ’Low’, ’Normal’ (the default), or ’High’.

Not available in xp_sendmail.

@sensitivity

One of the four varchar (12) email sensitivity strings, either ’Normal’ (the default), ’Personal’, ’Private’, or ’Confidential’.

Not available in xp_sendmail.

@file_attachments

An nvarchar(max) semicolondelimited list of absolute paths to files to attach.

Was @attachments in xp_sendmail.

Download from www.wowebook.com

Sending and Receiving with Database Mail

437

TABLE 15.2 Parameters for Database Mail Stored Procedure sp_send_dbmail Parameter

Description

xp_sendmail

Parameter to Which It Corresponds @query

An nvarchar(max) T-SQL code string to be executed when the message is sent. The code is executed in a different session than the calling session, so variable scope is a consideration.

Same as xp_sendmail.

@execute_query_database

The sysname of the database in which the T-SQL in query is to be executed.

Was @dbuse in xp_sendmail.

@attach_query_result_as_file A bit value indicating whether the results of the T-SQL in query should be an attachment (1) or appended to the body (0; the

Was @attach_results in xp_sendmail.

15

default). @query_attachment_filename

The nvarchar(255) filename for the attached query results (as per @query and @attach_query_result_as_file). If not specified, the generated filename is arbitrary (usually QueryResults [some number].txt)

In xp_sendmail, the first filename in @attachments was used.

@query_result_header

A bit value indicating whether the Was @no_header in query result (1; the default) should xp_sendmail. include the column headers.

@query_result_width

An int value (defaulting to 256; you specify a number between 10 and 32767) indicating how wide a line in the query results should be before line wrapping occurs.

Was @width in xp_sendmail.

@query_result_separator

A char(1) value (defaulting to a space) that indicates the query results column separator.

Was @separator in xp_sendmail.

Download from www.wowebook.com

438

CHAPTER 15

Database Mail

TABLE 15.2 Parameters for Database Mail Stored Procedure sp_send_dbmail Parameter

Description

xp_sendmail

Parameter to Which It Corresponds @exclude_query_output

A bit value that indicates whether Was @no_output in to suppress the query output (such xp_sendmail. as rowcounts, print statements, and so forth) from being printed on the query console. 0 (do not suppress) is the default.

@append_query_error

A bit value that indicates whether Not available in xp_sendmail, but to send the email if the query to be executed raises an error. If set similar to @echo_error. to 1, the error message is appended to the query output, and the query window for the session also displays the error (“A severe error occurred on the current command. The results, if any, should be discarded.”). If set to 0 (the default), the message is not sent, and sp_send_dbmail returns 1.

@query_no_truncate

A bit value that indicates whether Not available in xp_sendmail. to truncate query results having long values (such as varchar(max), text, xml, and so on) greater than 256. It defaults to 0 (off). Microsoft warns that using this can slow things down, but it is the only way to properly send these types.

@mailitem_id

An output parameter, an int value Not available in indicating the unique mailitem_id xp_sendmail. of the message. You see this as a column in the views discussed in the section “Related Views and Procedures,” later in this chapter.

Note that the @type and @set_user parameters for xp_sendmail are not available. @type, of course, is obsolete because it is MAPI specific. @set_user is also obsolete because the content of the T-SQL to be executed may contain an EXECUTE AS statement.

Download from www.wowebook.com

Sending and Receiving with Database Mail

439

Now that you’re familiar with the flurry of mail sending options, let’s look at a few examples and then examine how to track your sent messages by using the system views. Both of the following examples rely on sending via the default profile of the current user context. If the user has a default private profile assigned, it is used. If not, the default public profile is used (as in these examples). If there is no default public profile, an error is raised. The example shown in Listing 15.1 sends an email containing an xml result to a recipient as an attached Extensible Application Markup Language (XAML) document, retrieved from the AdventureWorks2008.Production.Illustration column.

LISTING 15.1 Sending XML as an Attachment with Database Mail

15

USE AdventureWorks2008 GO DECLARE @subject nvarchar(255), @body varchar(max), @query nvarchar(max), @IllustrationId int, @query_attachment_filename nvarchar(255), @mailitem_id int SELECT @IllustrationId = pi.IllustrationId, @subject = ‘XAML for “‘ + pm.Name + ‘“ attached. ‘ FROM Production.Illustration pi JOIN Production.ProductModelIllustration pmi ON pmi.IllustrationId = pi.IllustrationId JOIN Production.ProductModel pm ON pm.ProductModelID = pmi.ProductModelID SELECT @body = N’Attached, please find the XAML diagram for illustration #’ + CAST(@IllustrationId as nvarchar(10)) + ‘. A XAML browser plug-in is required to view this file.’ SELECT @query = N’SELECT Diagram FROM Production.Illustration WHERE IllustrationId = ‘ + CAST(@IllustrationId as nvarchar(10)) SELECT @query_attachment_filename = N’PM_’ + CAST(@IllustrationId as nvarchar(10)) + ‘.xaml’

Download from www.wowebook.com

440

CHAPTER 15

Database Mail

exec msdb.dbo.sp_send_dbmail @subject=@subject, @body=@body, @recipients=’[email protected]’, @query=@query, @execute_query_database=’AdventureWorks2008’, @attach_query_result_as_file=1, @query_attachment_filename=@query_attachment_filename, @query_no_truncate=1, @exclude_query_output=1, @query_result_width=32767, @mailitem_id=@mailitem_id OUTPUT SELECT sent_status, sent_date FROM msdb.dbo.sysmail_allitems WHERE mailitem_id = @mailitem_id GO sent_status sent_date —————- ————unsent NULL (1 row(s) affected)

Note that you must set @query_no_truncate to 1 and @query_result_width to the maximum (to be safe) value for the attached query results to contain consistently wellformed XML. In addition, you should not include any carriage returns or line feeds in the body of the message, or the SMTP servers may not be able to send it. The example in Listing 15.2 sends some query results as a comma-separated value (CSV) file that can be imported into programs such as Microsoft Excel. (You need to use the Get External Data command to accomplish this with Excel 9.)

LISTING 15.2 Sending CSV Data as an Attachment with Database Mail USE AdventureWorks2008 GO DECLARE @mailitem_id int, @tab char(1) SET @tab = char(13) exec msdb.dbo.sp_send_dbmail @subject=’D. Margheim, Contact Info’, @body=’Attached is Diane Margheim’’s contact info, in CSV format.’, @recipients=’[email protected]’, @query=N’SELECT BusinessEntityID, Title, FirstName, MiddleName, LastName FROM Person.Person WHERE BusinessEntityId = 8’, @execute_query_database=’AdventureWorks2008’,

Download from www.wowebook.com

Using SQL Server Agent Mail

441

@attach_query_result_as_file=1, @query_attachment_filename=’DMargheim.csv’, @exclude_query_output=1, @query_result_separator=’,’, @mailitem_id=@mailitem_id OUTPUT SELECT sent_status, sent_date FROM msdb.dbo.sysmail_allitems WHERE mailitem_id = @mailitem_id GO sent_status sent_date —————- ————unsent NULL (1 row(s) affected)

15

Notice that in both of these code listings, the values selected from the sent_status and sent_date columns of sysmail_allitems indicate that the mail has not yet been sent. The reason is that mail sending (like all other SSB messaging) is asynchronous: The message is immediately queued, and the Mail process later picks it up and sends it. To find out more about system views such as sysmail_allitems, see the section “Related Views and Procedures,” later in this chapter.

Receiving Email The only way for SQL Server 2008 to receive email is by using the legacy stored procedures, such as sp_processmail, with SQL Mail. Database Mail does not support receiving incoming messages because there is no IMAP or POP3 support. This may have something to do with the fact that receiving email can represent a major security risk. Imagine what a denial-of-service attack on a database cluster could do to an organization. Or consider the danger of an incoming email request resulting in the execution of a query such as DROP DATABASE X. Most SQL Server data is too precious to jeopardize in this manner. Microsoft has also made it clear that SQL Mail will be phased out in the next release of SQL Server. Plus, there are many better alternatives to using this methodology, such as using native Web services (as discussed in Chapter 48, “SQL Server Web Services”), using .NET CLR-integrated assembly code (as discussed in Chapter 45, “SQL Server and the .NET Framework”), or building a dedicated Service Broker application (as discussed in Chapter 49).

Using SQL Server Agent Mail As with SQL Server 2000, SQL Server 2008’s Agent has the capability to send email notifications. They may be triggered by alerts or scheduled task completions, such as jobs. SQL Server 2008 provides the option of using either SQL Mail or Database Mail to do the sending, but SQL Mail will soon be phased out, and Database Mail is by far the more robust choice. As with Database Mail, SQL Server Agent Mail is turned off by default, and you must configure it via SMSS or T-SQL, as described in the following sections.

Download from www.wowebook.com

442

CHAPTER 15

Database Mail

Job Mail Notifications The following sections show an example in which you create a SQL Server Agent Mail operator that SQL Server Agent will notify when a job completes. Creating an Operator First, you need to create an operator. To do so, using the Object Browser, you expand the SQL Server Agent node and then right-click the Operators folder and select New Operator. Then you should name this new operator Test Database Mail Operator and provide an email address for testing purposes in the Email Name text box. You can use any valid email address you can access with your email client software. You click OK to save the new operator. Enabling SQL Agent Mail Next, you need to enable SQL Server Agent to use Database Mail. You right-click the SQL Server Agent node and then select Properties. On the left side of the Properties dialog that appears (see Figure 15.2), you click the Alert System link. Under the Mail Session group, you check the Enable Mail Profile check box. In the Mail System drop-down list, you select Database Mail (this is also the place where you can choose SQL Mail, if you desire). In the Mail Profile drop-down list, you select the default SQL 2008 profile you created earlier and then click OK. By doing this, you are telling SQL Server Agent to use the SMTP servers in your default profile to send email. You need to restart SQL Server Agent by using the right-click menu.

FIGURE 15.2 Using the SQL Server Agent Properties dialog to configure Database Mail.

Download from www.wowebook.com

Using SQL Server Agent Mail

443

Creating the Job Next, you need to create the job. You begin by right-clicking the Jobs folder and then selecting New Job. You should name the job Database Mail Test Job and select an owner. Then you should check the Enabled check box near the bottom of the dialog and click the Steps link on the left side of the dialog. Next, you click the New button and add a step named Test Mail Step 1. You should leave the type as Transact-SQL and then change the database selection to AdventureWorks2008. In the Command text box, you enter the following code: RAISERROR(‘This is simply a test job.’, 10, 1)

Next, you click the Advanced link on the left side of the dialog, and in the On Success Action drop-down list, you select Quit the Job Reporting Success. Then you click the Notifications link on the left side of the dialog. Next, under Actions to Perform When the Job Completes, you check the Email check box and select the operator you just created. From the drop-down to the right, you select When the Job Completes and then click OK to save the job.

15

Testing the Job-Completion Notification To test the email configuration and notification you just set up, you right-click the job name under the Jobs folder and then select Start Job. If everything is set up properly, an email message appears in your inbox, indicating the job’s successful completion. Its body text might look something like this: JOB RUN: ‘Database Mail Test Job’ was run on 5/7/2009 at 8:37:22 PM DURATION: 0 hours, 0 minutes, 0 seconds STATUS: Succeeded MESSAGES: The job succeeded. The Job was invoked by User [TestUser]. The last step to run was step 1 (Test Mail Step 1).

Alert Mail Notifications As another example, in the following sections, you’ll create a simple user-defined alert that you can trigger directly from T-SQL script.

Creating an Alert You start by creating an alert. To do this, you use the Object Browser to expand the SQL Server Agent node; then you right-click the Alerts node and select New Alert. In the Alert Properties dialog that appears (see Figure 15.3), you name the new alert Database Mail Test Alert and make sure the Enabled check box is checked. For the Event type, you leave the selection on SQL Server Event Alert. Under Event Alert Definition, select AdventureWorks2008 from the Database Name drop-down list, and then click the Severity option button and choose 010 - Information. Next, check the Raise Alert When Message Contains check box and type the phrase This is a Test in the Message Text text box.

Download from www.wowebook.com

444

CHAPTER 15

Database Mail

FIGURE 15.3 Creating a SQL Server event alert with a Database Mail notification. On the left side of the alert properties dialog, you click the Response link. Then you check the Notify Operators check box and, in the Operator list, check the Email check box to the right of the Test Database Mail Operator grid row. Finally, you click OK to close and save the new custom alert. Testing the Alert Notification To test your new alert notification, you open a new query window in SMSS and enter the following code: USE AdventureWorks2008 go RAISERROR(‘This is an alert mail test’, 10, 1) WITH LOG go ‘This is an alert mail test’

Because you specified WITH LOG, this simple statement writes an event to the Windows Event log, which in turn triggers the alert because the database context, message text, and severity all match the conditions of the alert. An email message should have appeared in your inbox, indicating the alert’s successful triggering. This message should contain body text such as this: DATE/TIME: DESCRIPTION:

5/7/2009 9:00:45 PM Error: 50000 Severity:

10 State: 1 This is an alert

Download from www.wowebook.com

Related Views and Procedures

445

mail test COMMENT: (None) JOB RUN: (None)

Related Views and Procedures To report on the status of all your Database Mail objects without relying on wizards and properties pages, you need some tabular views and stored procedures. msdb contains many system tables, views, and corresponding stored procedures that make this task easy. The following section lists the tables (or views) and their columns, noting the stored procedure (if any) that you can use to read from them.

Viewing the Mail Configuration Objects The first set of msdb objects we’ll review are those related to system objects such as profiles, profile security, and accounts:

15

. sysmail_profile—Contains basic profile data, including the unique profile_id, name, description, last_mod_datetime, and last_mod_user name. You execute sysmail_help_profile_sp to retrieve this data by @profile_name or @profile_id. . sysmail_principalprofile—Contains profile security settings, including the profile_id, associated principal (or user) (principal_SID), profile default status (is_default: 1 for yes or 0 for no), last_mod_datetime, and last_mod_user name. You execute sysmail_help_principalprofile_sp to retrieve this data by @profile_name, @profile_id, @principal_name, or @principal_id (not principal SID). Here’s an example: exec msdb.dbo.sysmail_help_principalprofile_sp @profile_name=’Default SQL 2008 Profile’

. sysmail_account—Contains basic account data, including the unique account_id, name, description, email_address, display_name, replyto_address, last_mod_datetime, and last_mod_user name. You execute sysmail_help_account_sp to retrieve this data by @account_id or @account_name. . sysmail_server—Contains account SMTP server data, including the unique related account_id and servertype, servername, port, server username, server authentication data (credential_id), SSL status (enable_SSL), last_mod_datetime, and last_mod_user name. (sysmail_help_account_sp returns data from this table as well.) . sysmail_servertype—Contains servertype data for accounts’ servers. (SMTP is the only currently supported type, although it seems this system was built for extensibility, as the columns is_incoming and is_outgoing may leave the door open for adding POP or IMAP servers sometime in the future.) Also includes last_mod_datetime and last_mod_user name. (sysmail_help_account_sp returns data from this table as well.)

Download from www.wowebook.com

446

CHAPTER 15

Database Mail

To join sysmail_account, sysmail_server, and sysmail_servertype (as sysmail_help_account_sp seems to do), you can try a query such as the following: SELECT * FROM msdb.dbo.sysmail_account a JOIN msdb.dbo.sysmail_server s ON a.account_id = s.account_id JOIN msdb.dbo.sysmail_servertype st ON st.servertype = s.servertype

. sysmail_profileaccount—Maintains the profile-account relationship, including the profile_id, account_id, account priority sequence_number, last_mod_datetime, and last_mod_user name. You execute sysmail_help_profileaccount_sp to retrieve this data by @account_id, @account_name, @profile_id, or @profile_name. . sysmail_configuration—Contains the system-wide mail configuration settings (paramname, paramvalue, description), and when and by whom each was last modified (last_mod_datetime and last_mod_user name). You execute sysmail_help_configure_sp to query this data by @parameter_name. Here’s an example: exec msdb.dbo.sysmail_help_configure_sp @parameter_name=’accountretrydelay’

Viewing Mail Message Data The second set of msdb objects (and perhaps the more important ones) we’ll review are those used to discover the status of mail messages. The first thing you need to do is to check on the status of the mail messages you’ve attempted to send, without relying on inboxes to tell you if they’ve been received. Several views in msdb enable this, most of which may be filtered by mail account, sending user, send date, status, and more. To begin this process, you query the view sysmail_allitems, which contains all the data about your messages (subjects, recipients, importance, and so on) as well as send_request_date, sent_date, and sent_status. Here’s an example: SELECT mailitem_id, subject, sent_status FROM msdb.dbo.sysmail_allitems go mailitem_id subject sent_status ———————————————————————————————————————1 2 3 4

Database Mail Test C. Adams, Contact Info XAML for HL Touring Seat/Saddle attached. SQL Server Job System: ‘Database Mail Test Job’

sent sent sent sent

(4 row(s) affected)

Download from www.wowebook.com

Related Views and Procedures

447

Because all these messages have a sent_status of sent, the contents of this recordset are analogous to what you’d find if you queried the view sysmail_sentitems. But suppose your sent_status column read failed. In that case, you’d start by querying the sysmail_faileditems view (a subset of sysmail_allmailitems) in conjunction with sysmail_event_log (which contains the detailed textual reasons why failures have occurred). Here’s an example: SELECT f.subject, f.mailitem_id, l.description FROM msdb.dbo.sysmail_event_log l JOIN msdb.dbo.sysmail_faileditems f ON f.mailitem_id = l.mailitem_id WHERE event_type = ‘error’ ORDER BY log_date go subject mailitem_id description —————————————————————————————————————————Database Mail Test 3 The mail could not be sent because[...]the string is not in the form required for an e-mail address

15

(1 row(s) affected)

Note that the quality of the contents of sysmail_event_log depends on the Log Level system-wide mail configuration setting (discussed earlier in the section “Setting Systemwide Mail Settings”). The Log File Viewer also uses this table’s contents. To permanently delete its contents, you use the stored procedure sysmail_delete_log_sp. To query how many messages are queued (waiting to be sent) and for how long, you use the sysmail_unsentitems view. Here’s an example: SELECT mailitem_id, subject, DATEDIFF(hh, send_request_date, GETDATE()) HoursSinceSendRequest FROM msdb.dbo.sysmail_unsentitems

If you’re unsure why messages aren’t being sent, you can try the following: . Execute sysmail_help_queue_sp, whose resulting state column tells the state of the mail transmission queues: INACTIVE (off) or RECEIVES_OCCURRING (on). To see the status for only the mail (outbound) or status (send status) queues, you use the @queue_type parameter. . Execute sysmail_help_status_sp, whose resulting Status column tells you the state of Database Mail itself: STOPPED or STARTED.

Download from www.wowebook.com

448

CHAPTER 15

Database Mail

Summary This chapter showed how Database Mail has elevated the status of emailing with SQL Server from somewhat difficult to use to enterprise class. Microsoft has achieved this goal by relying on cross-platform industry standards, by making configuration easy, by providing a comprehensive set of system objects for storage and tracking, by adding failover capability, and by utilizing the Service Broker infrastructure. Chapter 16, “SQL Server Scheduling and Notification,” digs much deeper into configuring SQL Server Agent jobs and alerts, as well as using Database Mail for job and alert notifications.

Download from www.wowebook.com

CHAPTER

16

SQL Server Scheduling and Notification

IN THIS CHAPTER . What’s New in Scheduling and Notification . Configuring the SQL Server Agent . Viewing the SQL Server Agent Error Log

Automation is the key to efficiency, and the SQL Server Agent is your automation tool in SQL Server 2008. This chapter delves into the administrative capabilities of the SQL Server Agent and its capability to schedule server activity and respond to server events. The SQL Server Agent, which runs as a Windows service, is responsible for running scheduled tasks, notifying operators of events, and responding with predefined actions to errors and performance conditions. The SQL Server Agent can perform these actions without user intervention, utilizing the following:

. SQL Server Agent Security . Managing Operators . Managing Jobs . Managing Alerts . Scripting Jobs and Alerts . Multiserver Job Management . Event Forwarding

. Alerts—Alerts respond to SQL Server or user-defined errors, and they can also respond to performance conditions. An alert can be configured to run a job as well as notify an operator. . Jobs—A job is a predefined operation or set of operations, such as transferring data or backing up a transaction log. A job can be scheduled to run on a regular basis or called to run when an alert is fired. . Operators—An operator is a user who should be notified when an alert fires or a job requests notification. The operator can be notified by email, by pager, or via the NET SEND command.

Download from www.wowebook.com

450

CHAPTER 16

SQL Server Scheduling and Notification

NOTE The SQL Server Agent is not supported with the SQL Server Express Edition or SQL Server Express Advanced Edition. It is supported in all the other editions of SQL Server 2008, however. You can use the Windows Task Scheduler as an alternative for scheduling when using the SQL Server Express Editions. The Task Scheduler has basic scheduling capabilities but does not compare to the robust features found in the SQL Server Agent.

What’s New in Scheduling and Notification A new feature added to SQL Server 2008 Scheduling and Notification is the capability to execute PowerShell scripts. PowerShell is a command-line scripting language that allows administrators to achieve greater control and productivity. SQL Server 2008 comes with several PowerShell snap-ins that give you access to a variety of SQL Server objects. Scripts that are written to access these objects can be run from SQL Server jobs using the new PowerShell job type. You can find a more detailed discussion of PowerShell’s capabilities in the next chapter, “Administering SQL Server 2008 with PowerShell.” Policy-Based Management is another new feature in SQL Server 2008. This feature does not fall directly under Scheduling and Notification, but it provides related management features. For example, some of the multiserver concepts discussed later in this chapter can be replaced or augmented through the use of Policy-Based Management. This feature is covered in Chapter 22, “Administering Policy Based Management.”

Configuring the SQL Server Agent The primary configuration settings for the SQL Server Agent are located within the Object Explorer and SQL Server Configuration Manager. Most of the settings that define how the SQL Server Agent will execute are defined via the SQL Server Agent Properties accessible from the Object Explorer. The SQL Server Configuration Manager contains settings related to the SQL Server Agent’s service. The service settings are limited but contain important properties such as the Startup Account for the SQL Server Agent.

Configuring SQL Server Agent Properties Figure 16.1 shows the SQL Server Agent Properties dialog that appears when you rightclick and select Properties on the SQL Server Agent node located on the root of the Object Explorer tree. You can set several different types of properties in the SQL Server Agent Properties dialog. The General options are displayed by default, and they include the capability to set the

Download from www.wowebook.com

Configuring the SQL Server Agent

451

FIGURE 16.1 SQL Server Agent properties.

16 auto restart options and define an error log for the SQL Server Agent. Selecting the option Auto Restart SQL Server Agent If It Stops Unexpectedly is best for most installations. There is usually a heavy dependency on the Agent performing its actions, and you probably want the service to be restarted if it has been inadvertently stopped. The Advanced page contains options for event forwarding and idle CPU conditions. The event forwarding options are discussed in detail in the section “Event Forwarding,” later in this chapter. The idle CPU options define conditions related to the execution of jobs that have been set up to run when the CPU is idle. You can define idle CPU conditions such as the average CPU percentage that the CPU must be below to be considered idle. The Alert System page is related to configuring email notification and is discussed in the “Configuring Email Notification” section, later in this chapter. The Job System page has an option to set the shutdown time-out interval. This option determines the amount of time the SQL Server Agent waits for jobs to complete before finalizing the shutdown process. There is also an option related to proxy accounts discussed in the “SQL Server Agent Proxy Account” section, later in this chapter. The Connection page includes an option to set an alias for the local host server. This option is useful if you cannot use the default connection properties for the local host and need to define an alias instead.

Download from www.wowebook.com

452

CHAPTER 16

SQL Server Scheduling and Notification

The History page options are related to the amount of job history that will be retained. You have the option to limit the size of the job history log and/or remove job history that is older than a set period of time.

TIP Careful attention should be given to the amount of history that is retained. Every time a job is run, the history of that execution and the related detail is saved. The need for careful monitoring is particularly true when dealing with SQL Server instances that have a large number of databases. The msdb database contains the job history records and can become sizable over time if the history is not removed. For example, we have seen environments where close to 700 databases were installed on one SQL Server instance. The company was performing SQL Server log backups every 15 minutes on each of these databases and full backups each night. When you do the math (4 log backups/hour * 700 databases = 2800 backups/hour), you can see that the amount of history written to the msdb database can be significant.

Configuring the SQL Server Agent Startup Account The startup account defines the Microsoft Windows account the SQL Server Agent service uses. The selection of this account is critical in defining the level of security that the SQL Server Agent will have. Access to resources on the server on which SQL Server is running and access to network resources are determined by the startup account. This selection is particularly important in cases in which the SQL Server Agent needs to access resources on other machines. Examples of network access that the SQL Server Agent might need include jobs that write backups to a drive on another machine and jobs that look for files found on other servers on the network. The startup account for the SQL Server Agent is set initially during the installation of SQL Server, but you can change it by using several different tools such as the Windows Service Control Manager and SQL Server Configuration Manager. The Windows Service Control Manager is a good tool for viewing all the services on your server, but changes to the SQL Server services are better made through the SQL Server Configuration Manager. The Configuration Manager is more comprehensive and makes additional configuration settings, such as Registry permissions, that ensure proper operation. The SQL Server Configuration Manager is a consolidated tool that allows you to manage network options and services related to SQL Server. To launch this tool, you select Start, Microsoft SQL Server 2008, Configuration Tools. Figure 16.2 shows an example of the Configuration Manager with the SQL Server 2008 services selected for viewing. To change the startup account for the SQL Server Agent, you can right-click on its service and select Properties. The startup account used by the SQL Server Agent is initially determined during the installation of SQL Server. You have the option of choosing one of several built-in accounts, or you can select a domain account. The built-in accounts are available by default and do not

Download from www.wowebook.com

Configuring the SQL Server Agent

453

FIGURE 16.2 SQL Server Agent service properties. require any network administration to use them. These accounts, however, should be used with caution because they can provide network access to the SQL Server Agent that may not be desired. Generally, you want to provide the minimum amount of security necessary for the SQL Server Agent to perform its tasks.

16

The recommended startup account for the SQL Server Agent is a Windows account. You specify a Windows startup account for SQL Server Agent by using the This Account option on the Service Properties window. The Windows account can be a local user account or domain user account. It must be a member of the SQL Server sysadmin fixed server role on the local SQL Server instance. The use of this type of startup account provides the most flexibility and allows you to tailor the network and local resources that the SQL Server Agent has permission to access. The Windows account does not have to be a member of the Windows administrators group. In fact, exclusion from the administrators group is recommended in most cases. This approach adheres to the principle of least privileges, which says that you should limit the amount of security provided to only that which is needed. In many cases, inclusion in the administrators group is not needed and only increases exposure to security threats. The Windows account you choose with the This Account option must have certain security rights to be able to function as the startup account for SQL Server. The account must have permission to log on as a service. You can set this permission and others by using the Local Security Policy application, which can be found under Administrative Tools. You can select the Local Policies node and then select User Rights Assignment to display a list of all the security settings, including Log On as a Service Policy. You should make sure the account you chose or the group that it is in is included in this policy.

TIP The Local Security Policy editor can be hard to find. In most operating systems, you can click Start Run then enter secpol.msc to launch the Local Security Policy editor.

Download from www.wowebook.com

454

CHAPTER 16

SQL Server Scheduling and Notification

Configuring Email Notification The SQL Server Agent can send email notifications; it can send email via SQL Mail or Database Mail. SQL Mail was retained for backward compatibility. It utilizes an Extended Messaging Application Programming Interface (Extended MAPI) interface to send email and requires that you install an email application (such as Outlook) that supports Extended MAPI communication on the computer that is running SQL Server. Database Mail, which is now the recommended mail solution for the SQL Server Agent, is the focus of this section. It was added in SQL Server 2005, and it utilizes Simple Mail Transfer Protocol (SMTP) instead of Extended MAPI to send mail. This simplifies email setup and has many benefits over SQL Mail, including the following: . There is no requirement that an email client be installed on the SQL Server machine. . Email is queued for later delivery if the mail server stops or fails. . Multiple SMTP servers can be specified so that mail continues to be delivered in the event that one of the SMTP servers stops. . Database Mail is cluster aware. Database Mail is disabled by default in SQL Server 2008 but can be enabled using the Database Mail Configuration Wizard. This wizard provides a comprehensive means for configuring Database Mail. The Database Mail Configuration Wizard is not launched from the SQL Server Agent node. Instead, you can launch it by expanding the Management node, right-clicking Database Mail, and selecting Configure Database Mail. This wizard guides you through the configuration of mail profiles, SMTP accounts, and other options relevant to Database Mail. The Configuration Wizard and many other details related to Database Mail are discussed in detail in Chapter 15, “Database Mail.” After you set up Database Mail and confirm that it is working properly, you can select it as your mail system for the SQL Server Agent to send mail. You do this by right-clicking the SQL Server Agent node in the Object Explorer and selecting Properties. Then you select the Alert System page in the SQL Server Agent Properties dialog, and the screen shown in Figure 16.3 appears. In this figure, Database Mail is selected as the mail system, along with a mail profile for Database Mail created with the Database Mail Configuration Wizard. The mail profile you select can have multiple SMTP accounts assigned to it. This allows for redundancy in the event that the mail cannot be sent to one of the SMTP accounts. To ensure proper functioning of the alert system, you should restart the SQL Server Agent service after the alert system has been configured. If you experience problems sending notifications via the SQL Server Agent, you should check the service account that SQL Server is running under. If the SQL Server Agent is running with the local system account, resources outside the SQL Server machine will be unavailable; this includes mail servers that are on other machines. You should change the service account for the SQL Server Agent to a domain account to resolve this issue. Chapter 15 provides more information on using Database Mail in SQL Server 2008.

Download from www.wowebook.com

Configuring the SQL Server Agent

455

FIGURE 16.3 The Alert System page of the SQL Server Agent Properties dialog.

16

SQL Server Agent Proxy Account Proxy accounts allow non–Transact-SQL (non–T-SQL) job steps to execute under a specific security context. By default, only users in the sysadmin role can execute these job steps. Non-sysadmin users can be assigned to a proxy account to allow them to run the special job steps. In SQL Server 2000, a single proxy account was provided for this function. With SQL Server 2008, multiple proxy accounts can be established, each of which can be assigned to a different SQL Server Agent subsystem. To establish a proxy account for the SQL Server Agent, you must first create a credential. A credential contains the authentication information necessary to connect to a resource outside SQL Server. The credential is typically linked to a Windows account that has the appropriate rights on the server. To create a credential, you open the Security node in the Object Explorer, right-click the Credentials node, and select New Credential. You give the credential a name, enter an identity value that corresponds to a valid Windows account, and provide a password for the account. After creating a credential, you can create a new proxy account and link it to the credential. To create a new proxy account, you expand the SQL Server Agent node in the Object Explorer tree, right-click Proxies, and select New Proxy Account. Figure 16.4 shows an example of the New Proxy Account dialog. In this example, the proxy name and credential name are the same, but they do not need to be. The only subsystem selected for the

Download from www.wowebook.com

456

CHAPTER 16

SQL Server Scheduling and Notification

sample proxy account in Figure 16.4 is the operating system, but a proxy account can be linked to multiple subsystems.

FIGURE 16.4 Creating a new proxy account. After a proxy account is created, a sysadmin can assign one or more SQL logins, msdb roles, or server roles to the proxy. You do this by using the Principals page of the New Proxy Account dialog. A proxy account can have zero or many principals assigned to it. Conversely, a principal can be assigned to many different proxies. Linking non-admin principals to the proxy allows the principal to create job steps for subsystems that have been assigned to the proxy. Proxy accounts are referenced within a SQL Server Agent job step. The General page of the Job Step Properties dialog contains a Run As drop-down that lists valid accounts or proxies that can be used to run the particular job step. After you add a proxy account, you see it in this drop-down list. Keep in mind that the account is not visible for a T-SQL job step that does not utilize a proxy account. Steps that utilize the T-SQL subsystem execute under the job owner’s context and they do not utilize a proxy account.

Viewing the SQL Server Agent Error Log The SQL Server Agent maintains an error log that records information, warnings, and error messages concerning its operation. A node named Error Logs is located in the SQL Server Agent tree in the Object Explorer. The Error Logs node contains multiple versions of the

Download from www.wowebook.com

Viewing the SQL Server Agent Error Log

457

SQL Server Agent error log. By default, a maximum of 10 versions of the error log are displayed under the Error Logs node. The versions displayed include the current error log and the last 9 versions. Each time the SQL Server Agent is restarted, a new error log is generated, with a name that includes a time stamp. The first part of the current version’s name is Current. Names of older logs start with Archive #, followed by a number; the newer logs have lower numbers. The SQL Server error log works in much the same way as the SQL Server Agent’s error log.

TIP You can cycle the error log at any time without stopping and starting the SQL Server Agent. To do so, you right-click the Error Logs node in the Object Explorer and select Recycle; a new error log is then generated. You can also use the msdb.dbo.sp_cycle_agent_errorlog stored procedure to cycle the error log. You need to remember to also select the Refresh option to show the latest available error logs.

16

To view the contents of any of the logs, you need to double-click the particular log. Double-clicking a particular log file launches the Log File Viewer. The Log File Viewer contains the SQL Server Agent error logs in addition to logs that are associated with other SQL Server components, including Database Mail, SQL Server, and Windows NT. Figure 16.5 shows a sample Log File Viewer screen with the current SQL Server Agent error log selected for display. The Log File Viewer provides filtering capabilities that allow you to focus on a particular type of error message, along with other viewing capabilities that are common to all the logs available for viewing.

FIGURE 16.5 The SQL Server Agent error log.

Download from www.wowebook.com

458

CHAPTER 16

SQL Server Scheduling and Notification

SQL Server Agent Security Many changes were made to the security model related to the SQL Server Agent in SQL Server 2005. In the past, everyone could view the SQL Server Agent. Starting in SQL Server 2005, logins must be a part of the sysadmin server role or assigned to one of three msdb database roles to be able to view and modify the SQL Server Agent. The SQL Server Agent node does not appear in the Object Explorer tree if the login does not have the appropriate permissions. Following are the msdb database roles and their basic permissions: . SQLAgentUserRole—Users with this permission can create and manage local jobs and job schedules that they own. They cannot create multiserver jobs or manage jobs that they do not own. . SQLAgentReaderRole—Users with this permission can view jobs that belong to other users in addition to all the permissions associated with SQLAgentUserRole. . SQLAgentOperatorRole—Users with this permission can view operators and alerts and control jobs owned by other users. The job control on jobs owned by other users is limited to stopping or starting and enabling or disabling those jobs. SQLAgentOperatorRole also has all the permissions available to SQLAgentUserRole and SQLAgentReaderRole. SQLAgentUserRole has the fewest privileges, and each subsequent role has increasing levels

of security. In addition, each subsequent role inherits the permissions of the roles with fewer permissions. For example, SQLAgentReaderRole can do everything that SQLAgentUserRole can do and more. Refer to the topic “Implementing SQL Server Agent Security” in SQL Server Books Online for a detailed list of all the permissions related to the new database roles.

Managing Operators Operators are accounts that can receive notification when an event occurs. These accounts are not linked directly to the user and login accounts that are defined on the server. They are basically aliases for people who need to receive notification based on job execution or alerts. Each operator can define one or more electronic means for notification, including email, pager, and the NET SEND command. To add a new operator, you expand the SQL Server Agent node in the Object Explorer and right-click the Operators node. Then you select New Operator from the right-click menu. Figure 16.6 shows the New Operator screen, with many of the fields populated for the creation of a new operator named LauraG. The General page of the New Operator screen allows you to enter the name of the operator, the notification options, and the “on duty” scheduled for the operator. The operator name can be any name, but it must be unique within the SQL Server instance and must be no more than 128 characters. The operator name can be the same as another login or user on the server, but this is not required.

Download from www.wowebook.com

Managing Operators

459

FIGURE 16.6 Creating a new operator.

16

The notifications options are the key to operators. You create operators so that you can then define notification options and have messages sent from SQL Server. If you use the email notification option, the email address you specify must be a valid address that can be reached via Database Mail or SQL Mail. One of the two mail options must be configured before the email functionality will work. If Database Mail is configured, the email is sent via an SMTP server. To send email with SQL Mail, SQL Server must be able to access a Microsoft Exchange server, and you must have the Extended MAPI client installed on the SQL Server machine. The NET SEND notification option causes a pop-up window to appear on the recipient’s computer; this window contains the notification text. In the Net Send Address text box, you specify the name of the computer or user that is visible on the network to the SQL Server machine. For NET SEND to work, the Messenger service on SQL Server must be started. This Messenger service must also be started on the machine that is receiving the NET SEND message. You can test the basic NET SEND capabilities by executing NET SEND at the command prompt. The basic syntax for NET SEND follows: NET SEND {name | * | /domain[:name] | /users} message

The following example uses the NET SEND command to send the message “Test net send message” to the operator LauraG: NET SEND LauraG “Test net send message”

Download from www.wowebook.com

460

CHAPTER 16

SQL Server Scheduling and Notification

The final notification option is through a pager email address. Pager email requires that third-party software be installed on the mail server to process inbound email and convert it to a pager message. The methods for implementing pager email and the available software are dependent on the pager provider. You should contact your pager vendor for implementation details. If you implement pager notification, you can also define the pager schedule for the operator. The Pager on Duty Schedule section of the New Operator dialog allows you to define the days and times when the operator will be available to receive a page. The General page includes a check box for each day the operator can receive a page. It also includes the Workday Begin and Workday End settings, which you can use to define the valid time periods to receive a page. The other page available when defining a new operator is the Notifications page, which displays the alerts and jobs for which the operator will receive notifications. For a new operator, the Alert List or Job List is empty, as shown in Figure 16.7.

FIGURE 16.7 The Notifications page of the New Operator dialog.

You’ll have a better understanding of the usefulness of operators after you read the following discussions of jobs and alerts. Jobs and alerts can have operators linked to them for notification purposes.

Download from www.wowebook.com

Managing Jobs

461

Managing Jobs A job is a container for operations that can be executed by the SQL Server Agent. Jobs can be run once or scheduled to run on a regular basis. Jobs provide the basis for SQL Server automation and allow for the execution of many different types of operations, including T-SQL, SQL Server Integration Services (SSIS) packages, and operating system commands.

Defining Job Properties The Jobs node is located under SQL Server Agent in the Object Explorer. You right-click the Jobs node and select New Job to create a new SQL Server Agent job. A New Job dialog like the one shown in Figure 16.8 appears.

16

FIGURE 16.8 The New Job dialog.

NOTE Only logins that are part of one of the msdb fixed database roles or are members of the sysadmin fixed server role are able to create or modify jobs.

The General properties page shown in Figure 16.8 contains the basic information about the job, including the name and description. The owner of the job defaults to the login

Download from www.wowebook.com

462

CHAPTER 16

SQL Server Scheduling and Notification

for the person creating the job; however, if the login of the person creating the job is part of the sysadmin fixed server role, the default can be changed. You use the Category selection to group or organize jobs. There are several predefined categories for selection, including Database Maintenance and Log Shipping. The default category is set to [Uncategorized(local)].

Defining Job Steps After you add the general information for a new job, you are ready to add the job steps that actually perform the work. To do this, you select the Steps page on the left side of the New Job dialog, and the job steps for this job are listed. To create a new job step, you click the New button, and a New Job Step dialog like the one shown in Figure 16.9 appears.

FIGURE 16.9 The New Job Step dialog. A step name is the first piece of information you need to provide for the job step. It can be up to 128 characters long and must be unique within the job. Then you need to select a job step type. The SQL Server Agent can run a variety of types of job steps, including the following: . ActiveX script (Visual Basic, Java, Perl script) . Operating System (CmdExec) . PowerShell

Download from www.wowebook.com

Managing Jobs

463

. Replication Distributor . Replication Merge . Replication Queue Reader . Replication Snapshot . Replication Transaction Log Reader . SQL Server Analysis Services Command . SQL Server Analysis Services Query . SQL Server Integration Services Package . Transact-SQL script (T-SQL) SQL Server Analysis Services Command, Server Analysis Services Query, and SQL Server Integration Services Package are types that were added in SQL Server 2005.

They provide integration with SQL Server Analysis Services (SSAS) and SSIS. Chapters 45, “SQL Server and the .NET Framework,” and 46, “SQLCLR: Developing SQL Server Objects in .NET,” provide detailed discussions of these technologies. The PowerShell job type was added in SQL Server 2008; further information on PowerShell is provided in Chapter 17, “Administering SQL Server 2008 with PowerShell.”

16

The Step properties page displays different information, depending on the type of step selected. When the Transact-SQL script (T-SQL) type is selected, you see a window similar to the one shown in Figure 16.9. If you choose the SQL Server Integration Services Package type, the Step properties page changes to allow you to enter all the relevant information needed to execute an SSIS package. In many cases (including T-SQL), a command window is available to input the step commands. With a T-SQL command, you can enter the same type of commands you would enter in a query window. You click the Parse button to validate the SQL and ensure proper syntax. The Operating system (CmdExec) type allows you to enter the same types of commands that you can enter in a command prompt window. Each step type has its own command syntax that you can test in the native environment to ensure proper operation. You can select the Advanced page to configure job flow information and other information related to the job step. On Success Action allows you to specify the action to perform when the current job step completes. Actions include the execution of the next job step (if one exists) and the ability to set job status based on the step completion. The same selection options also exist for On Failure Action. The Retry options define the options that relate to retrying the job step in the event that the job step fails. Retry Attempts defines the number of times the job step will be reexecuted if it fails. Retry Intervals (Minutes) defines the amount of time (in minutes) between retry attempts.

Download from www.wowebook.com

464

CHAPTER 16

SQL Server Scheduling and Notification

TIP The Retry options are useful for polling scenarios. For example, you might have a job step that tests for the existence of a file during a given period of the day. The job can be scheduled to start at a time of day when the file is expected. If the file is not there and the step fails, Retry Attempts can be set to poll again for the file. Retry Interval determines how often it retries, and the combination of Retry Attempts and Retry Interval determines the total polling window. For example, if you want to check for the file for 2 hours, you can set Retry Attempts to 24 with a Retry Interval of 5 minutes. If the job step fails more than the number of retries, the step completes in failure.

The last set of options on the Advanced page relate to the output from the job step. Job step output can be saved to an output file that can be overwritten each time the job step is run, or the output can be appended each time. The Log to Table option writes the job step output to the sysjobstepslogs table in the msdb database. The table contains one row for each job step with the Log to Table option enabled. If Append Output to Existing Entry in Table is enabled, the sysjobstepslogs data row for the step can contain output for more than one execution. If this option is not selected, the table contains only execution history for the last execution of the step.

CAUTION If you choose the Append Output to Existing Entry in Table option, the size of the sysjobstepslogs table will grow over time. You should consider using the sp_delete_jobsteplog stored procedure to remove data from the sysjobstepslogs table. This stored procedure has several different parameters that allow you to filter the data that will be removed. You can use these parameters to remove log data by job, job step, date, or size of the log for the job step.

Defining Multiple Jobs Steps You can define multiple jobs steps in a single job. This allows you to execute multiple dependent job actions. The job steps run one at a time (serially), and you can specify the order of the job steps. The job order and the related dependencies are called control of flow. Figure 16.10 shows an example of a job that has multiple dependent job steps. Take note of the On Success and On Failure columns, which define the control of flow. For example, if step 1 succeeds, the next step occurs. If step 1 fails, no further steps are executed, and the job quits, reporting a job failure. The control of flow is slightly different for the second step, whereby the control of flow passes to the next step on success but flows to the fourth step if a failure occurs. The control of flow is defined on each job step. As discussed earlier in this chapter, the Advanced tab of the New Job Step dialog provides drop-down lists that allow you to specify the actions to take on success and on failure. In addition, the Steps page that lists all of a job’s steps allows you to specify the start step for the job. The drop-down box at

Download from www.wowebook.com

Managing Jobs

465

FIGURE 16.10 Multiple job steps.

16

the bottom of the Steps page provides this function. You can also use the Move Step arrows to change the start step. Manipulating the start step is useful when you’re restarting a job manually, as in the case of a job failure; in this situation, you might want to set the job to start on a step other than the first step.

NOTE SSIS provides the same type of flow control capabilities as the SQL Server Agent. In fact, maintenance plans that contain multiple related actions (such as optimization, backup, and reporting) utilize SSIS packages. A scheduled job starts an SSIS package, which executes the package in a single step, but the actual maintenance steps are defined within the package. The SSIS Designer utilizes a graphical tool that depicts the flow of control and allows you to modify the individual steps.

Defining Job Schedules The SQL Server Agent contains a comprehensive scheduling mechanism you can use to automate the execution of your jobs. A job can have zero, one, or more schedules assigned to it. You can view the schedules associated with a job by selecting the Schedules page of the Job Properties screen. To create a new schedule for a job, you can click the New button

Download from www.wowebook.com

466

CHAPTER 16

SQL Server Scheduling and Notification

at the bottom of the Schedules page. Figure 16.11 shows the New Job Schedule Properties page, with a sample schedule and options defined. The options on this screen vary, depending on the frequency of the job schedule. For example, if the frequency of the schedule shown in Figure 16.11 were changed from daily to weekly, the screen would change to allow for the selection of specific days during the week to run the job.

FIGURE 16.11 The New Job Schedule Properties page. You have the ability to share job schedules so that one job schedule can be utilized by more than one job. When you select the Schedule page, a Pick button is available at the bottom of the page. If you click the Pick button, a screen appears showing all the defined schedules. If you highlight one of the schedules in the list and click OK, the schedule is linked to the related job. You can also view all the jobs associated with a particular schedule by editing the schedule and clicking the Jobs in Schedule button in the top-right portion of the Job Schedule Properties screen. Tracking multiple job schedules and schedule execution can be challenging in an environment that has many jobs and schedules. The sp_help_jobs_in_schedule, and sp_help_jobactivity stored procedures are helpful system stored procedures that are found in the msdb database. The sp_help_jobs_in_schedule stored procedure provides information about the relationship between jobs and schedules. The sp_help_jobactivity stored procedure provides point-in-time information about the runtime state of SQL

Download from www.wowebook.com

Managing Jobs

467

Server jobs. This stored procedure returns a lot of information, including recent job executions, the status of those executions, and the next scheduled run date.

Defining Job Notifications The Notifications page of the Job Properties dialog, as shown in Figure 16.12, allows you to define the notification actions to perform when a job completes.

16

FIGURE 16.12 The Notifications page of the Job Properties dialog.

As discussed earlier in this chapter, notifications can be sent via email, pager, or NET SEND command. The notifications for a Schedule Job can be sent based on the following events: . When the job succeeds . When the job fails . When the job completes Each of these events can have a different notification action defined for it. For example, a notification might send an email if the job succeeds but page someone if it fails. You also have the option of writing notification information into the Windows Application event log or automatically deleting the job when it completes. These two

Download from www.wowebook.com

468

CHAPTER 16

SQL Server Scheduling and Notification

options are also available on the Notifications page. Writing events to the Application log is a useful tracking mechanism. Monitoring software is often triggered by events in the application log. The automatic job deletion options are useful for jobs that will be run only once. As with the other notification options, you can set up the delete job action such that it is deleted only when a specific job event occurs. For example, you might want to delete the job only if the job succeeds.

Viewing Job History You view job history via the Log File Viewer, which is a comprehensive application that allows for many different types of logs to be viewed. You right-click a job in the SQL Server Agent and select History to display the Log File Viewer. Figure 16.13 shows the Log File Viewer with several examples of job history selected for viewing.

FIGURE 16.13 Job history shown in the Log File Viewer. Compared to viewing job history in SQL Server versions prior to SQL Server 2005, the current form of the Log File Viewer has some distinct advantages for viewing job history. In the Log File Viewer, you can select multiple jobs for viewing at one time. To view job step details, you expand the job entries and select a job step. You can use the row details shown below the log file summary to troubleshoot job errors and isolate problems. The Log File Viewer also has filtering capabilities that allow you to isolate the jobs to view. Click on the Filter button and the Filter Settings dialog appears. You can filter jobs by using a number of different settings, including User, Start Date, and Message Text. You must click the Apply Filter button for the selected filtering option to take effect. The amount of history that is kept is based on the history settings defined for the SQL Server Agent. You access the history settings by right-clicking the SQL Server Agent node, selecting Properties, and then selecting the History page on the left part of the screen. The settings available on the History page are shown in Figure 16.14. By default, the job

Download from www.wowebook.com

Managing Alerts

469

history log is limited to 1,000 rows, with a maximum of 100 rows per job. You can also select the Automatically Remove Agent History option and select a period of time to retain history. This setting causes the SQL Server Agent to periodically remove job history from the log. This is a good approach for keeping the size of the log manageable.

16

FIGURE 16.14 Job history settings.

Managing Alerts The SQL Server Agent can monitor events that occur on the database server and automatically respond to these events with alerts. Alerts can be fired based on SQL Server events, performance conditions, and Windows Management Instrumentation (WMI) events. After an alert is fired, the SQL Server Agent can respond by notifying an operator or executing a job. This provides a proactive means for identifying and reacting to critical conditions on a database server.

Defining Alert Properties To define alerts, you select the SQL Server Agent node in the Object Explorer tree and then right-click on the Alerts node and select New Alert. Figure 16.15 shows an example of the New Alert dialog that appears.

Download from www.wowebook.com

470

CHAPTER 16

SQL Server Scheduling and Notification

FIGURE 16.15 The General page of the New Alert dialog.

The General page selected in Figure 16.15 allows you to define the basic alert properties, including the name of the alert and type of event you want the alert to respond to. The default type of alert, the SQL Server event alert, is triggered by SQL Server events that write to the Windows Application event log. SQL Server writes to the Application event log when the following events occur: . When sysmessages errors with a severity of 19 or higher are generated. You can use the sys.sysmessages catalog view to view all the sysmessages that are stored in the server. You can create new user-defined messages by using the sp_addmessage stored procedure; they must have a msg_id (or error number) that is greater than 50,000. The error message must be created before you can reference the error number in an alert. . When sysmessages errors are generated by the database engine. These messages have error numbers lower than 50,000 and are installed by default. . When any RAISERROR statement is invoked with the WITH LOG option. The WITH LOG statement forces the event to be written to the Application event log. Messages generated with RAISERROR that have a severity level greater than 18 are required to write to the Application event log.

Download from www.wowebook.com

Managing Alerts

471

. When sysmessages have been altered with the sp_altermessage statement to write to the application log. The sp_altermessage command has a write_to_log parameter that you can use to modify error numbers found in sys.messages. When the write_to_log parameter is set to WITH_LOG, these message automatically write to the Application event log, regardless of whether the WITH_LOG option is used when the error is raised. . When application calls are made to xp_logevent to log an event to the application log. The bottom portion of the General page of the New Alert dialog allows you to define which events in the Application event log the alert should respond to. You can have the event respond to a specific error number, the error severity level, or specific text that is contained in the error message. The sys.sysmessages catalog view contains a complete list of all the error message details for all the supported languages. You can use the following SELECT statement to list the error messages for the English language: SELECT * FROM SYS.SYSMESSAGES where msglangid = 1033 order by msglangid, error

16

You can define an alert for hundreds of messages. For example, you can define an alert that responds to changes to database options. You do this by selecting error number 5084, which is triggered whenever a change is made to the database options. You can also narrow the scope of the alert to look at a specific database by using the Database Name drop-down. This limits the alert to errors that occur in the specific database you choose. The default option is to look at all databases. The two other types of alerts you can define are SQL Server performance condition alerts and WMI event alerts. A SQL Server performance condition alert reacts to performance conditions on the server. Figure 16.16 shows an example of this type of alert. When you select a SQL Server performance condition alert, you need to select the performance object and counter for that object to monitor. The SQL Server performance objects and counters available on the General page of the New Alert dialog are a subset of those available in the Windows Performance Monitor application. These performance metrics encompass key indicators, such as memory, CPU, and disk space. After selecting the object and counter, you need to define the performance threshold for the alert at the bottom of the General page, below the Alert if Counter label. In the example shown in Figure 16.16, the alert is monitoring the transaction log file for the AdventureWorks database. The threshold has been set such that the alert will fire if the transaction log for this database rises above 2KB. The WMI event alerts use WMI to monitor events in an instance of SQL Server. The SQL Server Agent can access SQL Server events by using the WMI provider for server events by issuing WMI Query Language (WQL) statements. WQL is a scaled-down version of SQL that contains some WMI-specific extensions. When a WMI query is run, it essentially creates an event notification in the target database so that a related event will fire. The

Download from www.wowebook.com

472

CHAPTER 16

SQL Server Scheduling and Notification

FIGURE 16.16 A SQL Server performance condition alert on the General page. number of WMI events is extensive. Refer to the “WMI Provider for Server Events Classes and Properties” topic in SQL Server Books Online for a complete list. Figure 16.17 shows an example of a WMI event alert. This example uses a WQL query that detects any Data Definition Language (DDL) changes to any of the databases on the server. After the alert is created, you can test it by running a DDL statement against the database (for example, alter table Person.address add newcol int null).

Defining Alert Responses The definition of an alert has two primary components. As discussed earlier in this chapter, the first component involves the identification of the event or performance condition that will trigger the alert. The second part of an alert definition involves the desired response when the alert condition is met. You can define an alert response by using the Response page on the alert’s Properties screen. Figure 16.18 shows a sample response that has been configured to use NET SEND on a message to the operator named ChrisG. Operator notification and job execution are the two responses to an alert. Operator notification allows for one or more operators to be notified via email, pager, or the NET SEND command. Job execution allows for the execution of a job that has been defined in the SQL Server Agent. For example, you could execute a job that does a database backup for an alert that is triggered based on database size. You can define both job execution and operator notification in a single alert; they are not mutually exclusive.

Download from www.wowebook.com

Managing Alerts

473

FIGURE 16.17 The General page showing a WMI event alert.

16

FIGURE 16.18 Configuring an alert response.

Download from www.wowebook.com

474

CHAPTER 16

SQL Server Scheduling and Notification

You can further define an alert response by using the Options page of an alert’s Properties window (see Figure 16.19).

FIGURE 16.19 Alert options. You can include an alert’s error text in the operator notification message on this page. This alert error text provides further details about why the alert was fired. For example, if you have an alert that is triggered by changes to database options, the alert error text would include the actual option that was changed. You can also define additional notification text that is included when the message is sent. This message could include directives for the operators or additional instructions. Finally, you can define the amount of time that the alert will wait before responding to the alert condition again. You do this by using the Delay Between Responses drop-downs (Minutes and Seconds) to set the wait time. This capability is useful in situations in which an alert condition can happen repeatedly within a short period of time. You can define a response delay to prevent an unnecessarily large number of alert notifications from being sent.

Scripting Jobs and Alerts SQL Server has options that allow for the scripting of jobs and alerts. As with many of the other objects in SQL Server, you might find that it is easier and more predictable to generate a script that contains the jobs and alerts on the server. You can use these scripts to

Download from www.wowebook.com

Scripting Jobs and Alerts

475

reinstall the jobs and alerts or deploy them to another server. You can right-click the job or alert you want to script and choose a scripting option to generate the T-SQL for the individual object. You can also select the Job or Alerts node to view the Object Explorer Details that lists all the objects. You can also display the Object Explorer Details through the View menu or by selecting it as the active tab. When Object Explorer Details is selected, you have the option of selecting one or more jobs to script. You can select multiple jobs by holding down the Ctrl key and clicking the jobs you want to script. Figure 16.20 shows a sample Object Explorer Details for jobs, with several of the jobs selected for scripting. To generate the script, you simply right-click one of the selected jobs and select the Script Job As menu option to generate the desired type of script.

16

FIGURE 16.20 Script generation for jobs.

NOTE With SQL Server 2008, you can also filter the jobs you want to script by using the filtering capabilities that are available on the Object Explorer Details. For example, you can filter on jobs whose names contain specific text. After you filter the jobs, you can script the jobs that are displayed. The filtering options and the capability to selectively script jobs are particularly useful in environments in which many jobs and alerts exist.

Download from www.wowebook.com

476

CHAPTER 16

SQL Server Scheduling and Notification

Multiserver Job Management Multiserver job management allows you to centralize the administration of multiple target servers on a single master server. The master server is a SQL Server instance that contains the job definitions and status information for all the enlisted target servers. The target servers are SQL Server instances that obtain job information from the master server and continually update the master server with job statistics. Multiserver job management is beneficial in SQL Server environments in which there are many instances to manage. You can establish jobs, operators, and execution schedules one time on the master server and then deploy them to all the target servers. This promotes consistency across the enterprise and can ease the overall administrative burden. Without multiserver job management, administrative jobs must be established and maintained on each server.

Creating a Master Server The first step in creating a multiserver environment involves the creation of a master server. SQL Server 2008 provides the Master Server Wizard, which simplifies this task. You launch the Master Server Wizard by right-clicking the SQL Server Agent node in the Object Explorer and selecting Multi Server Administration and Make This a Master. The Master Server Wizard then guides you through the creation of an operator to receive multiserver job notifications and allows you to specify the target servers for SQL Server Agent jobs. Figure 16.21 shows the Master Server Wizard screen that allows you to add information related to the master server’s operator. The operator created on the master server, named MSXOperator, is the only one that can receive notifications for multiserver jobs.

FIGURE 16.21 The Master Server Wizard.

Download from www.wowebook.com

Event Forwarding

477

The Master Server Wizard also validates the service accounts that the SQL Server Agent uses on the target servers. These accounts are typically Windows domain accounts that are in the same domain as the master server. The service accounts are important because the target servers utilize Windows security to connect to the master server and download jobs for the SQL Server Agent. The validation process and security considerations are simplified if the master server and target servers are run with the same domain account.

Enlisting Target Servers The Master Server Wizard allows you to enlist one or more target servers. Enlisting a target server identifies it to the master server and allows the master server to manage the administration of its jobs. You can also enlist additional target servers after the wizard completes. You do this by right-clicking the SQL Server Agent node of the target server and then selecting Multi Server Administration and then Make This a Target. Doing so launches the Target Server Wizard, which guides you through the addition of another target server. The Target Server Wizard performs some of the same actions as the Master Server Wizard, including the following: . It ensures that the SQL Server versions on the two servers are compatible. . It ensures that the SQL Server Agent on the master server is running.

. It enlists the target server.

16

. It ensures that the Agent Startup account has rights to log in as a target server.

Creating Multiserver Jobs After setting up the master and target servers, you can create jobs on the master server and specify which target servers they should run on. Periodically, the target servers poll the master server. If any jobs defined for them have been scheduled to run since the last polling interval, the target server downloads the jobs and runs them. When a job completes, the target server uploads the job outcome status to the master server.

Event Forwarding Event forwarding is another multiserver feature that allows a single SQL Server instance to process events for other servers in your SQL Server environment. This involves the designation of an alerts management server to which other servers can forward their events. You enable the alerts management server by right-clicking the SQL Server Agent node and selecting Properties. When the Properties pages appears, you click the Advanced page (see Figure 16.22).

Download from www.wowebook.com

478

CHAPTER 16

SQL Server Scheduling and Notification

FIGURE 16.22 Configuring event forwarding.

To configure event forwarding, you select the Forward Events to a Different Server option on the Advanced page. You can then select the SQL Server instance you want as the alerts management server by using the Server drop-down. The servers shown in the drop-down are those that have been registered in SSMS. If the server you want does not appear in the drop-down, you need to choose Registered Servers from the View menu and ensure that the server is registered. You can choose to forward unhandled events, all events, or only a subset of the events. The default is to send all unhandled events, but you can customize this for your needs. You can further limit the messages that are forwarded by specifying the severity level that the message must have in order to be forwarded. For example, you can configure the servers to forward only fatal error messages that have a severity greater than or equal to Level 19. In this scenario, you could define alerts on the alerts management server that respond to these fatal errors and notify operators that specialize in their resolution. You need to consider a number of trade-offs when using event forwarding. You need to weigh the benefits of central administration and a lack of redundancy against the disadvantages of having a single point of failure and increased network traffic. The available network bandwidth, number of servers involved in event forwarding, and stability of the alerts management server are some of the key factors you need to think about in making your decision.

Download from www.wowebook.com

Summary

479

Summary The SQL Server Agent in SQL Server 2008 delivers a powerful set of tools to make your administrative life easier. It provides automation in the form of jobs, operators, and alerts that help you deliver a consistent and healthy database environment. After you have set up the appropriate automation with the SQL Server Agent, you can rest assured that you have been proactive in managing your database environment. PowerShell is another tool to help with your automation needs. This new tool, that was integrated into SQL Server 2008, provides a powful command-line facility you can use to access SQL Server objects. This tool is discussed in Chapter 17.

16 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

17

. Overview of PowerShell . PowerShell Scripting Basics

Administering SQL Server 2008 with PowerShell

. PowerShell in SQL Server 2008 . Step-By-Step Examples

Windows PowerShell is Microsoft’s next-generation scripting language. More and more server-based products are being released with various levels of support for this scripting language. This chapter provides an overview of what Windows PowerShell is and describes some of the basic features of Windows PowerShell that SQL Server 2008 users should find useful. It also presents examples that demonstrate the use of these features with SQL Server 2008. SQL Server 2008 includes additional features to support PowerShell. The chapter also presents step-by-step examples showing how to use Windows PowerShell for various OS and database tasks.

What’s New with PowerShell The integration of Windows PowerShell into the SQL Server environment is new to SQL Server 2008. The PowerShell scripting language has been around for some time, but it was not installed with prior versions of SQL Server or integrated into the SQL Server environment. With SQL Server 2008, it is installed, and there are now means for easily accessing SQL Server objects via this powerful scripting shell. The SQLPS utility is at the crux of the new PowerShell integration in SQL Server 2008. SQLPS is a command-line shell that loads and registers SQL Server snap-ins that provide access to SQL Server via PowerShell. There is no need to manually reference or load the SQL Server libraries, which is

Download from www.wowebook.com

482

CHAPTER 17

Administering SQL Server 2008 with PowerShell

necessary if you launch the PowerShell environment independently using the native PowerShell (powershell.exe) utility. In SQL Server 2008, the new SQLPS utility has also been integrated into the SQL Server Management Studio (SSMS) environment. You can launch a SQLPS session by right-clicking on an object in the Object Explorer tree and selecting Start PowerShell. A SQLPS command window is launched with the path for that object already referenced. You can now work with the properties of that object in a command-line environment that provides options that go beyond the traditional GUI environment. The integration of SQLPS is also visible in the SQL Server Agent. You can now add PowerShell job steps to SQL Server jobs. The PowerShell commands that you can enter for the job step are the same as you would enter interactively in a PowerShell session. This new kind of job step allows you to schedule PowerShell commands and integrate PowerShell actions with other SQL Server Agent job steps.

Overview of PowerShell Windows PowerShell is Microsoft’s next-generation automation and scripting language. It is built on the Microsoft .NET 2.0 Framework. Windows PowerShell was first released to the public in November 2006 as version 1.0. It was released as a separate install for Windows XP and Windows 2003, and shortly after, an install for Windows Vista was made available. Since its release, Windows PowerShell has been downloaded over two million times.

NOTE From this point on, we refer to Windows PowerShell simply as PowerShell.

When Windows Server 2008 was released, PowerShell was provided with the operating system. To have access to PowerShell, you simply had to add the Windows PowerShell feature through the new Server Manager.

NOTE Currently, PowerShell is not available on Windows Server 2008 Core because of the .NET Framework requirement. Server 2008 Core officially doesn’t support the .NET Framework.

In 2008, Microsoft announced that PowerShell is now part of its Common Engineering Criteria for 2009 and beyond. This announcement basically means that all of Microsoft’s server products should have some level of PowerShell support. Microsoft Exchange 2007 was the earliest server-class product to come out with full PowerShell support. In fact, all of Exchange’s administrative tasks are based on PowerShell. The PowerShell functionality in Exchange is actually named Exchange Management Shell.

Download from www.wowebook.com

Overview of PowerShell

483

NOTE PowerShell 1.0 is installed by default when SQL Server 2008 client software or Database Services are installed. Keep in mind that PowerShell 1.0 is not the latest version available. The next version, PowerShell version 2, is available for download and is installed by default with newer operating systems such as Windows Server 2008 R2. V2 introduces a number of new features that are not covered in this chapter.

NOTE The intent of this chapter is to introduce the basic concepts and functionality of PowerShell and how it integrates with SQL Server 2008. Use of more advanced features is beyond the scope of what can be covered in a single chapter. For more information on PowerShell, be sure to check out the main PowerShell address at http://www.microsoft.com/powershell and also the PowerShell team blog at http:/ /blogs.msdn.com/powershell. A number of script examples and resources are also available in the Microsoft Technet PowerShell Script Center: http://technet.microsoft.com/en-us/scriptcenter/ powershell.aspx If you want to get into some of the more advanced features and capabilities of PowerShell, you may also want to check out a PowerShell-specific book such as Windows PowerShell Unleashed from Sams Publishing.

Start Using PowerShell Now 17

PowerShell supports all the regular DOS commands and can run scripts written in any other language (the script engine specific to that scripting language still needs to be used). If any kind of scripting is currently being done, there is no reason why users can’t start using PowerShell now, even if they are not using its vast functionality.

Common Terminology Here are some of the common terms used when working with PowerShell: . Cmdlet—This is the name given to the built-in commands in PowerShell. Cmdlets are the most basic component within PowerShell and are used when doing anything in PowerShell. They are always of the form “verb-noun.” Cmdlets also have arguments called parameters, and values can be passed to these parameters. . Script—With automation comes the requirement for scripts. Using scripts is as simple as putting a single cmdlet in a file and then executing the file. In PowerShell, scripts have the extension .ps1 and can be executed or invoked by simply calling it as ./my_script.ps1. . Pipeline—This PowerShell functionality allows a series of cmdlets to be combined together using the pipe character (|). The output from one cmdlet is then piped to the following cmdlet for further processing.

Download from www.wowebook.com

484

CHAPTER 17

Administering SQL Server 2008 with PowerShell

. Provider—Using this PowerShell functionality, a data store is presented to the user in a format similar to a file system. Some of the “core” cmdlets are typically used to do various tasks such as creating items like files and/or folders. . Snap-in—PowerShell functionality can be extended with the use of snap-ins. They are basically DLL files written in a .NET programming language such as C# or VB.NET. DBAs can load these snap-ins in their PowerShell session to add additional functionality such as additional cmdlets and/or providers. . Tab completion—This PowerShell functionality allows the user to press the Tab key to autocomplete supported commands and parameters. . Aliases—Theseare shorter names that can be used for cmdlets. For example, some typical UNIX and DOS commands have had aliases for them created in PowerShell. These aliases map to the actual PowerShell cmdlet.

Object-Based Functionality As mentioned earlier, PowerShell is built on the .NET Framework. This implies that everything within PowerShell is object based. This is a familiar concept for anyone who is already familiar with the .NET Framework or .NET programming languages such as C# or VB.NET. This object-based functionality is an important concept to remember if you want to dive deeper into PowerShell. PowerShell provides many features, and it can also use additional features provided by other .NET assemblies.

SQL Server Management Objects SQL Server Management Objects (SMO) are a very useful tool to advanced users and developers when dealing with the automation of SQL Server 2005 and 2008. A lot of the features within SQL Server (core engine, agent, mail, and so on) are packaged into easy-toaccess .NET libraries that can be accessed from PowerShell. Most of the functionality provided by the new PowerShell support in SQL 2008 is based on SMO. As for SQL Server 2005, PowerShell can still be used to administer this version via SMO. The only difference is that the relevant assemblies must be loaded manually.

WMI Windows Management Instrumentation (WMI) is a Windows service that provides remote control and management. PowerShell provides some built-in support for retrieving information via WMI. Although the main goal of WMI may be to provide remote access, it can also be used locally and can provide a wealth of information about a system. For example, WMI can be

Download from www.wowebook.com

Overview of PowerShell

485

used to easily query disk space and installed patches. Examples of using WMI are shown later in this chapter.

Installing PowerShell As of Windows Server 2008, adding the PowerShell feature is easy using the new Server Manager application. With previous versions of Windows, PowerShell was a separate install, which required downloading and installing an external package. To install PowerShell on Server 2008, start Server Manager, go to the Features node, then click Add Features, and simply check the box for Windows PowerShell, as shown in Figure 17.1.

17

FIGURE 17.1 Selecting the Windows PowerShell feature.

PowerShell Console You can accessing PowerShell directly from the Start menu, by opening All Programs, and choosing Windows PowerShell 1.0, then finally Windows PowerShell (alternatively, on some systems, such as Windows 7, you can find the Windows PowerShell folder under the Accessories folder in the Start menu). The Windows PowerShell console opens, as shown in Figure 17.2.

Download from www.wowebook.com

486

CHAPTER 17

Administering SQL Server 2008 with PowerShell

FIGURE 17.2 Opening the PowerShell console.

NOTE The prompt displayed in examples of the PowerShell console in this chapter has been changed from the default.

Scriptable and Interactive PowerShell can be used as a scripting language, by creating reusable scripts that can automate various tasks, and it can also be used interactively, by opening up a console window and entering commands line by line. In interactive mode, PowerShell is intelligent enough to know when a command is not complete and actually displays >> on a new line when it believes a complete command has not been entered.

Default Security After PowerShell has been installed, it is very secure out of the box. Here are two of the default security features: . PowerShell cannot run any scripts. If you attempt to double-click on any .ps1 script, it simply opens the contents in Notepad. . PowerShell cannot be accessed remotely.

Download from www.wowebook.com

Overview of PowerShell

487

Execution Policy By default, PowerShell can only be used interactively from the console. This is part of the default security. To be able to actually run scripts, you must set the execution policy. The easiest way to set this policy is to use the Set-ExecutionPolicy cmdlet, as follows: PS>Set-ExecutionPolicy RemoteSigned

Basically, when you use the value RemoteSigned, PowerShell is set to be able to run scripts that have been created locally, but if a script is downloaded from the Internet, for example, it must be signed.

NOTE The details of the different execution policy settings available or the advantages and disadvantages of different possibilities are not covered in this chapter. Using RemoteSigned is one of the better trade-offs between functionality and security for most users.

Profiles As users become more and more familiar with PowerShell, they typically develop customizations that they may want to save for the next time PowerShell is opened. PowerShell has several profiles that can be used to configure user and system-wide settings. The system-wide profile is easy to access using the following: PS>notepad $profile

17

NOTE On a new install, this file typically doesn’t exist, so don’t be surprised if a window pops up asking you to create the file. Adding commands to the profile is usually as easy as adding the exact same commands that you would execute in the shell directly into the profile.

Built-in Help Features As mentioned earlier, cmdlets are the most basic component of PowerShell. Three of these cmdlets are essential in attempting to learn PowerShell. Even advanced users may still use these cmdlets on a daily basis: . Get-Command—This cmdlet is essential in discovering what commands can be used and what might be available on the system to help with a certain task. . Get-Help—When you are looking for additional details, specifically on other cmdlets, this is the main cmdlet to use.

Download from www.wowebook.com

488

CHAPTER 17

Administering SQL Server 2008 with PowerShell

. Get-Member—Absolute beginners don’t typically start using this cmdlet when first initiated into PowerShell, but for advanced users, and easier discovery, this cmdlet is very useful. Let’s look at each of these cmdlets in more detail. Get-Command The Get-Command cmdlet can be used to get a listing of an entire list of cmdlets on the system, but it can also be used to get cmdlets that can be used for a specific task or purpose. For example, Get-Command alone in the console prints the entire list of available cmdlets available in the current console: PS>Get-Command

If this is the first time you have ever opened a PowerShell console, how do you write to the console? How about displaying something as simple as “Welcome to SQL 2008”? You can pass something basic to Get-Command, such as the string ”*write*”: PS>Get-Command *write*

What results is a listing of all the cmdlets that have the string ”write” in any part of their name. In addition, the preceding command also displays any applications and aliases (aliases are discussed later in this chapter) found in the current user’s path. PowerShell can be pretty smart. The preceding sample is actually a shortcut for something longer like this: PS>Get-Command -Name *write*

Based on how the cmdlet is programmed, cmdlets can automatically assign a particular value to a parameter even when the parameter isn’t explicitly typed out. Originally, we were looking for a cmdlet to display something on the console and found the cmdlet Write-Host. Let’s try it: PS>Write-Host “Welcome to SQL 2008”

Get-Help The learning curve with PowerShell can be relatively steep. Sometimes you can find a particular command for a particular task, such as the Write-Host cmdlet in the preceding section, but you might not always be sure how to actually use it. Write-Host is simple, but what if Write-Host had other useful features, or help was required for some other cmdlet? Get-Help is a very useful cmdlet. Just using Get-Help alone provides some default help

information: PS>Get-Help

Download from www.wowebook.com

Overview of PowerShell

489

To get help on a particular cmdlet, you can use Get-Help and pass the other cmdlet as an argument: PS>Get-Help Write-Host

That approach might not provide a lot of useful information; perhaps the –Full and –Examples parameters are more useful: PS>Get-Help Write-Host -Full

Passing the –Full parameter gives a detailed description of the cmdlet and all its parameters (including what types of values they accept). If you are a more experienced user, the –Examples parameter is very useful, because it just gives some examples of using the cmdlet, which is an easy way to remember the syntax of a particular command: PS>Get-Help Write-Host -Examples

NOTE Get-Help works on other cmdlets, but it can also be used when you are looking for

additional details on other concepts in PowerShell. To get a listing of the built-in help for various concepts in PowerShell, you can run the command Get-Help about_*.

17

Get-Member Because everything in PowerShell is object based, some of the features that can be accessed are always visible. To find out more about a particular object, you can use the Get-Member cmdlet to look at all its members (the more interesting members of a .NET object are usually its properties and methods). Using something simple like ”AdventureWorks2008R2”, you can easily look at PowerShell’s members (possibly without having to consult any .NET developer-focused documentation). ”AdventureWorks2008R2” is a string—in other words, a combination of alphanumeric characters (that can include spaces). The following example is another way to display a string in the PowerShell console: PS>”AdventureWorks2008R2”

PowerShell automatically recognizes this is a simple string and displays it. A string can be easily displayed to the console, but what else can you do with a string object? In the .NET Framework, a string is really a System.String object. The .NET Framework provides a lot of functionality that can be used to deal with strings. Now let’s consider another example: PS>” AdventureWorks2008R2”|Get-Member

Download from www.wowebook.com

490

CHAPTER 17

Administering SQL Server 2008 with PowerShell

From the preceding command, more information is displayed now, including TypeName:System.String, which confirms that this is a System.String object. One particular feature that Get-Member indicates is that there is a ToLower method supported by this particular object: PS>”AdventureWorks2008R2”.ToLower()

In this example, the ToLower method of the System.String object is used to change the string into all lowercase letters.

PowerShell Scripting Basics The following sections cover some of the basics of scripting with PowerShell. We hope this information will help you understand how you can use PowerShell in various situations to automate various tasks.

A Few Basic Cmdlets Following is a list of a few basic cmdlets and how they can be used, with a brief example: . Get-ChildItem (aka dir, gci)—Cmdlet used to list child items in a provider. Mostly used to list things such as files and directories in a file system. Example: GetChildItem *.ps1

. Select-Object—Cmdlet used to retrieve only specific properties. See Get-Help Select-Object –Examples for examples. . Group-Object—Cmdlet used to group objects based on their properties. See Get-Help Group-Object –Examples for examples. . Sort-Object—Cmdlet used to sort objects based on their properties. See Get-Help Sort-Object –Examples for examples. . Read-Host—Cmdlet used to read input from the screen, usually from a user, before continuing. Example: Read-Host “Enter a database name”. . Measure-Command—Cmdlet used to measure how much time a particular scriptblock took to run. Example: Measure-Command {Get-Command}. . Write-Host—Cmdlet used to basically display output to the console. This cmdlet was covered earlier. . New-Object—Cmdlet used to create an instance of a .NET (or COM) object. Examples are provided later. . Get-Alias—Cmdlet used to get a listing of the aliases on the system. Get-Alias, with no arguments, lists all the aliases configured on the local system. . Get-Content—Cmdlet used to read the contents of a file. Typically, only text-based files are supported. Example: Get-Content my_script.ps1.

Download from www.wowebook.com

PowerShell Scripting Basics

491

. Add-Content—Cmdlet used to add or append content to a file. Example: AddContent my_file.txt “testing”. . Set-Content—Cmdlet used to set the contents of a file (it overwrites any existing content). Example: Set-Content my_file.txt “testing 123”. . Start-Transcript—Cmdlet used also with Stop-Transcript to record everything in the console to a specific text file. Example: Start-Transcript.

Creating a PowerShell Script Creating a PowerShell script is as simple as placing a few commands into a .ps1 script and then invoking that script. Here’s a simple example of putting the Write-Host cmdlet into a script and then running it. PS> add-content c:\temp\test.ps1 “Write-Host `testing`” PS>c:\temp\test.ps1 testing PS>

In the preceding example, a Write-Host cmdlet was placed in a file named test.ps1, and then the file was invoked. The output resulted in the string ”testing” being output to the script. Notepad or any other simple text editor could also be used to create more complicated scripts. Sample PowerShell scripts that directly apply to SQL Server administration are provided later in this chapter. Refer to the ”The Step-By-Step Examples” section.

Adding comments to a PowerShell script is as simple as adding the # character at the beginning of the line. To comment out entire blocks of code, you must use a # on each line.

17

Adding Comments

NOTE Another way to comment out blocks of code is to use something called a here string. This technique is not covered in this book.

Variables Strings and objects were discussed earlier in this chapter. A very useful feature of PowerShell, and thus of SQL-PowerShell, is the ability to place objects into a variable. This allows you to run any kind of command and place any objects produced into a variable for later use. Examples of using variables are presented later in this chapter. For now, a string can be easily saved as a variable: PS>$var=”AdventureWorks2008R2”

Download from www.wowebook.com

492

CHAPTER 17

Administering SQL Server 2008 with PowerShell

PS>$var AdventureWorks2008R2

In the preceding example, the string is saved as the variable $var and then output to the script when the variable is simply invoked: PS>$database=read-host “Enter a database name” Enter a database name:AdventureWorks2008R2 PS>$database AdventureWorks2008R2

The Read-Host cmdlet was introduced briefly already. In this example, the Read-Host cmdlet is used to read input from the console, and the information input is passed to the $database variable.

NOTE When you perform certain actions in a script, a function, and even from the command line, the scope assigned to the variable or function determines how this variable will be seen by other scripts, functions, and so on. The details of scoping are not discussed any further, but it is still an important concept to remember as you use PowerShell more and more.

NOTE You can issue the Get-Help about_shell_variable and Get-Help about_scope commands in Powershell for more information and examples about shell variables.

An example provided later in this chapter demonstrates that objects much more complicated than simple strings can be saved to a variable for later use.

Escaping Characters Often a special character may be used—for example, in DOS commands—but PowerShell tries to interpret it differently. Let’s consider the dollar sign character ($). PowerShell normally tries to interpret it as a variable: PS C:\> $var=”$5 discount” PS C:\> $var discount PS C:\> $var=”`$5 discount” PS C:\> $var $5 discount PS C:\>

The preceding example shows how the escape character, which is the backtick (`), is used to escape the dollar sign, so that PowerShell doesn’t try to interpret the character literally as the beginning of a variable.

Download from www.wowebook.com

PowerShell Scripting Basics

493

NOTE You can execute the Get-Help about_escape_character command in PowerShell for more information and examples.

Special Variable $_ In PowerShell, $_ is a special variable that represents the current object in the pipeline. When several cmdlets are piped together, this special variable may be used often. Several examples of using this special variable are shown later in this chapter.

NOTE A special variable named $input also represents objects passed along the pipeline, but we do not look at this variable in any further detail in this chapter.

NOTE See Get-Help about_automatic_variables for more information and examples.

Joining Variables and Strings

17

The concept of objects was already introduced briefly. When you are dealing with simple strings, you can easily concatenate them together using the plus (+) sign to create a new string: PS>$last_name=”Doe” PS>$first_name=”John” PS>$full_name=$last_name+”, “+$first_name PS>$full_name Doe, John PS>

In this example, two variables containing simple strings are defined, and they are simply concatenated together to create a third variable, which is then displayed to the console.

NOTE This kind of concatenation works when both variables are strings. An error may be returned if the variable is of another data type.

An example is provided later with the AdventureWorks2008R2 database where string variables from two different columns in the same table will be joined together using this feature.

Download from www.wowebook.com

494

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Passing Arguments PowerShell has a special reserved variable named $args. It can be used with scripts and functions, and represents any arguments passed to the script or function when it is invoked, as shown here: PS>add-content c:\temp\parameter.ps1 “`$args.count” PS>add-content c:\temp\parameter.ps1 “`$args[0]” PS>c:\temp\parameter.ps1 1 2 3 3 1 PS>

In the preceding example, a two-line script is created, and then it is invoked while passing some arguments to it. $args.count displays the number of arguments passed to the script, whereas $args[0] displays the value of the first argument only. Later, an example of a PowerShell script that can do a database backup is provided. The example is extended to show how a script could be used to accept an argument that would be the name of the database the script will back up.

Using Param A special construct, param, can be used to force the way arguments are passed to a script or function: PS>function test_param { >> param([string]$arg1) >> write-host “Argument 1 is $arg1” >> } >>PS>test_param “testing” Argument 1 is testing PS>test_param -arg1 “testing” Argument 1 is testing PS>

In this example, param is used to specify that a parameter passed to this script will be a string object and will be contained in the variable $arg1 for later use in the script.

NOTE The biggest difference between using param or $args with arguments occurs when the number of arguments is known versus unknown. The param keyword should not be used when the number of arguments passed is not known.

Download from www.wowebook.com

PowerShell Scripting Basics

495

NOTE [string] is a shortcut in PowerShell where you specify that the argument, as in the

preceding example, will be a string, and not something else such as a number or integer. A dozen or so of these shortcuts are available in PowerShell, and they are typically known as type accelerators.

Arrays To PowerShell, arrays are simply a listing of data. They can be used for various tasks and can be created easily, as you can see here: PS>$var=”foo”,”bar” PS>$var foo bar PS>

In this example, an array is created with two values, and then it is simply invoked, which simply results in outputting each element of the array, one per line. When an array is created, a reference can be made to a particular element of the array using a special “[]” syntax, like this:

17

PS>$var[0] foo PS>

NOTE The first element of an array is the element zero; therefore, the first record in an array is retrieved by referencing the element id [0].

The count property is also useful as a property of array objects (remember that everything n PowerShell is a .NET object: PS>$var.count 2 PS>

The count property is used to iterate through each element of an array.

Download from www.wowebook.com

496

CHAPTER 17

Administering SQL Server 2008 with PowerShell

NOTE Arrays can also be defined in at least two other ways: with a type accelerator ([array]$var is an example) or using a notation like this: $var=@(“foo”,”bar”).

Several other type accelerators are used in PowerShell, but they are not described in this chapter.

NOTE You can execute the Get-Help about_array command for more information and examples on using arrays in PowerShell.

In a later example, this feature of retrieving a particular element of an array is used with the AdventureWorks2008R2 database.

Operators A task commonly performed both from the console and also in scripts is to compare two strings against each other. The most common operators are as follows: . Arithmetic—When comparing numbers or integers, for example: 5 -gt 4

. Comparison—When comparing strings, for example: ”user” -eq “user”

In both of these cases, a Boolean value is returned (True or False).

NOTE Execute the Get-Help about_operator command for more information and examples.

Conditional Statements Often in scripting, some kind of decision must be made by comparing values before a script or set of commands continues. Operators can provide a simple example of how conditional statements work, as shown here: PS>if(“userA” -eq “userA”) >> { >> Write-Host “Equal”

Download from www.wowebook.com

PowerShell Scripting Basics

497

>> } >> else >> { >> Write-Host “Not equal” >> } >>Equal PS>$user=”userB” PS>if(“userA” -eq “$user”) >> { >> Write-Host “Equal” >> } >> else >> { >> Write-Host “Not equal” >> } >>Not equal PS>

The preceding code provides a simple example and shows how interactive the PowerShell console can be. The >> character is simply PowerShell informing the user that the commands entered are basically not complete, and more input is required. A later example using the AdventureWorks2008R2 database uses a conditional statement to make a particular decision based on the results from evaluating a particular expression.

Functions 17

Quite often, as the usage of SQL-PowerShell increases, some efficiencies are gained by using functions. Functions are especially useful when you are creating things that are done on a regular basis either directly in the console or in a script. For example, a long script may have been developed that contains several checks for the existence of a file, such as a long database filename, as in the following: PS>Function test { >> param($user1,$user2) >> if(“$user1” -eq “$user2”) >> { >> Write-Host “Equals” >> } >> else >> { >> Write-Host “Not equal” >> } >> } >>PS>test “userA” “userB” Not equal PS>test “userA” “userA”

Download from www.wowebook.com

498

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Equals PS>

Using the earlier example of comparing two strings, this example writes a function named test, so if future comparisons are required, the typing requirements will be greatly reduced.

NOTE Execute the Get-Help about_function command in PowerShell for more information and examples.

In a later example, a function is used to create a quick reference for sending out an email via PowerShell.

Looping Statements Often a script needs to loop through items and act on each. PowerShell supports several looping constructs. Examples of the for and foreach constructs are demonstrated here. Others, such as while, also exist but are not covered in this chapter. PS>for($i=0;$i -lt 5;$i+=2){ >> $i >> } >>0 2 4 PS>

The preceding example shows a for loop. The method to jump or way to use a step is shown. A jump or step is indicated by the last part of the preceding for loop, where $i+=2 is used. If this example had used $i++ instead, the output would be each number from 0 to 5. Here’s an example of using foreach: PS C:\book>dir Directory: Microsoft.PowerShell.Core\FileSystem::C:\book Mode LastWriteTime Length Name --------------------- ---d---8/4/2008 11:29 PM directory -a--8/5/2008 12:01 AM 53 database.csv -a--8/4/2008 11:27 PM 0 file.ps1 -a--8/4/2008 11:27 PM 0 file.txt -a--8/4/2008 11:47 PM 1813 list.csv PS C:\book>$contents=dir PS C:\book>$contents

Download from www.wowebook.com

PowerShell Scripting Basics

499

Directory: Microsoft.PowerShell.Core\FileSystem::C:\book Mode LastWriteTime Length Name --------------------- ---d---8/4/2008 11:29 PM directory -a--8/5/2008 12:01 AM 53 database.csv -a--8/4/2008 11:27 PM 0 file.ps1 -a--8/4/2008 11:27 PM 0 file.txt -a--8/4/2008 11:47 PM 1813 list.csv PS C:\book>foreach($each in $contents){ >> $each.name >> } >>directory database.csv file.ps1 file.txt list.csv PS C:\book>

In this example, within the foreach scriptblock, any number of commands could have been added, and they would have acted on each object.

NOTE Use the Get-Help about_for, Get-Help about_foreach, and Get-Help about_while commands for more information and examples.

17

NOTE Another feature that can also be useful in scripting is keywords, such as break, continue, and return. They can be used in various circumstances to basically end the execution of conditional statements and also looping statements. See Get-Help about_break and Get-Help about_continue for more information and examples.

Filtering Cmdlets PowerShell also has a few useful filtering cmdlets: . Where-Object (alias where and ?)—Participates in a pipeline by helping to narrow down the objects passed along the pipeline based on some specific criteria. . ForEach-Object (alias foreach and %)—Participates in a pipeline by applying a scriptblock to every object passed along the pipeline. By looking at a few files and a directory contained within a test directly, we can easily demonstrate the use of both cmdlets: PS C:\book> dir

Download from www.wowebook.com

500

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Directory: Microsoft.PowerShell.Core\FileSystem::C:\book Mode ---d----a---a---

LastWriteTime -------------8/4/2008 11:29 PM 8/4/2008 11:27 PM 8/4/2008 11:27 PM

Length Name ------ ---directory 0 file.ps1 0 file.txt

PS C:\book> dir|ForEach-Object{$_.Name.ToUpper()} DIRECTORY FILE.PS1 FILE.TXT PS C:\book> dir|Where-Object{$_.PsIsContainer} Directory: Microsoft.PowerShell.Core\FileSystem::C:\book Mode ---d----

LastWriteTime ------------8/4/2008 11:29 PM

Length Name ------ ---directory

PS C:\book>

In this example, first the ForEach-Object cmdlet is demonstrated, where each object passed along from the dir command is acted on, and the name of the object (filename or directory name) is changed to uppercase. Next, the Where-Object cmdlet is demonstrated, where each object passed along is evaluated this time to determine whether it is a file or directory. If it is a directory (the scriptblock {$_.PsIsContainer} returns as True), the object continues along the pipeline, but in this case, the pipeline has ended.

NOTE There is a ForEach-Object cmdlet and a foreach keyword, and they are not the same. Something useful to remember is that ForEach-Object would be used as part of a pipeline.

Formatting Cmdlets Several formatting cmdlets are very useful: . Format-Table (alias ft)—Cmdlet that prints out properties in a table-based format. . Format-List (alias fl)—Cmdlet that prints out properties in a list-style format. Some simple examples of Format-Table can be easily demonstrated, as you can see here: PS C:\book\test> Get-Process powershell Handles NPM(K) PM(K) WS(K) VM(M)

CPU(s)

Download from www.wowebook.com

PowerShell Scripting Basics

Id ProcessName ------- ------- ---------548 13 2600 powershell

-----

----- -----

54316

13192

164

501

-----25.55

PS C:\book\test> Get-Process powershell| ` >> Format-Table -autosize handles,id >> Handles Id -------561 2600 PS C:\book\test>

In this example, you use the Get-Process cmdlet to list the properties of the powershell.exe process. By default, the PowerShell formatting subsystem determines what properties to display. Using Format-Table, you modify the properties displayed. The –autosize parameter is used to shorten and align all the columns neatly.

NOTE There are also Format-Custom and Format-Wide cmdlets. See the built-in help for each cmdlet for more information and examples.

Dealing with CSV Files 17

PowerShell provides two cmdlets that help greatly when you are dealing with files in the comma-separated value (CSV) format: . Import-Csv—This cmdlet reads in a CSV file and creates objects from its contents. . Export-Csv—This cmdlet takes an object (or objects) as input and create sa CSV file, as shown here: PS>dir | Export-Csv c:\temp\file.csv

This simple example shows how to output the contents of the current directory to a CSVformatted file. Looking at the contents of this file displays information about the objects, though, instead of just plain strings such as filenames. The following example creates a simple CSV-formatted file and then is read in using the Import-Csv cmdlet. The Select-Object cmdlet is used to display only the database column: PS PS PS PS PS

C:\> cd c:\temp C:\temp> Add-Content C:\temp> Add-Content C:\temp> Add-Content C:\temp> Get-Content

database.csv “server,database” database.csv “server1,database1” database.csv “server2,database2” database.csv

Download from www.wowebook.com

502

CHAPTER 17

Administering SQL Server 2008 with PowerShell

server,database server1,database1 server2,database2 PS C:\temp> Import-Csv database.csv|Format-Table -AutoSize server database ------ -------server1 database1 server2 database2 PS C:\temp> Import-Csv database.csv|Select-Object database database -------database1 database2 PS C:\temp>

NOTE The Format-Table cmdlet is used in the preceding example simply to format the data in a more appropriate format for this book.

Dealing with Dates and Times Being able to do date/time calculations is very useful. Fortunately PowerShell provides all kinds of quick date/time calculations. Some of the more common tricks are shown in the following example: PS>[DateTime]::Now Tuesday, August 05, 2008 2:01:22 PM PS>([DateTime]::Now).AddDays(-1) Monday, August 04, 2008 2:01:44 PM PS>

Here, a .NET method is used to get a new value from the original object. This is done in a “single step,” in contrast to saving the object to a variable and then using the method on the variable. The use of a minus sign indicates that a value is being requested from the past. Other common date/time methods include . AddHours—Add/subtract based on a number of hours. . AddMilliseconds—Add/subtract based on a number of milliseconds. . AddMinutes—Add/subtract based on a number of minutes.

Download from www.wowebook.com

PowerShell in SQL Server 2008

503

. AddMonths—Add/subtract based on a number of months. . AddSeconds—Add/subtract based on a number of seconds. . AddYears—Add/subtract based on a number of years.

-WhatIf/-Confirm Parameters Several of the core PowerShell cmdlets support –whatif and/or –confirm parameters. The cmdlets that support these parameters could actually make system changes that cannot be reserved, such as deleting a file. Consider the following example using these parameters: PS>New-Item -Type File -Path file.tmp

Directory: Microsoft.PowerShell.Core\FileSystem::C:\book Mode ----a---

LastWriteTime -------------8/4/2008 10:33 PM

Length Name ------ ---0 file.tmp

PS>Remove-Item -Path file.tmp -WhatIf What if: Performing operation “Remove File” on Target “C:\book\file.tmp”. PS>

17

Two new cmdlets are demonstrated in the preceding example: New-Item, used to create things such as files, and Remove-Item, used to delete or remove things such as files.

PowerShell in SQL Server 2008 This section covers what has been specifically added to SQL Server 2008 to provide support for PowerShell.

Adding PowerShell Support NOTE This discussion is based on SQL Server 2008 Enterprise Edition. SQL Server 2008 Express doesn’t provide all the same features. For example, the Express version doesn’t provide the SQL Server Agent functionality briefly discussed later.

Download from www.wowebook.com

504

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Either during the initial installation of SQL 2008 or afterward while changing the installed features, you are able to add the SQL Server–specific PowerShell features by using the setup utility. The Management Tools-Basic feature must be added, as shown in Figure 17.3.

FIGURE 17.3 Installing the PowerShell features.

The Management Studio add-on is also required to get the PowerShell-specific features installed. This specific feature adds the following: . Management Studio—The graphical user interface for managing SQL Server 2008 . SQLCMD—The utility that SQL scripters should already be familiar with . SQL Server PowerShell provider—The PowerShell-specific extra functionality

NOTE An added bonus is that you can install Management Studio by itself on either the server or another remote system, and be able to administer your SQL Server database remotely. Consideration should be given to whether the SQL Server is set up for remote connections, and the appropriate firewall changes have been made to the network and on the database server, if applicable.

Download from www.wowebook.com

PowerShell in SQL Server 2008

505

Accessing PowerShell Now that you have added the SQL Server–specific PowerShell features, you can access a SQL Server PowerShell session.

NOTE From this point on, we make the distinction between PowerShell and SQL Server PowerShell. The details are discussed shortly, but for now PowerShell is the basic or default PowerShell console, and SQL Server PowerShell is a more restricted version of PowerShell that has all the SQL Server–specific PowerShell features packaged within it.

SQL Server PowerShell can be accessed in either of two ways: . You can open SQL Server PowerShell via the SQL Server Management Studio by right-clicking on a particular object in the Object Explorer and selecting Start PowerShell, as shown in Figure 17.4. This way is handy because it provides a prompt in the SQL provider (which is discussed shortly) in the location of the object that was right-clicked.

17

FIGURE 17.4 Accessing PowerShell via SSMS. . You also can open SQL Server PowerShell directly from regular DOS or a regular PowerShell console by simply navigating to the appropriate location, as shown in Figure 17.5.

Download from www.wowebook.com

506

CHAPTER 17

Administering SQL Server 2008 with PowerShell

FIGURE 17.5 Accessing PowerShell using sqlps.exe.

NOTE When you first open the shell, some errors may appear on the screen, which simply indicates that PowerShell execution policy should be set. This topic was covered near the beginning of the chapter. The execution policy for SQL Server PowerShell should also be RemoteSigned, at least.

SQL Server PowerShell When you first get into SQL Server PowerShell, you might notice that this is a restricted version of the default PowerShell console. In other words, several of the core cmdlets are not available in SQL Server PowerShell, and others might not work exactly the same way. For example, invoking the Get-Command cmdlet alone with no other arguments does not list all the available commands.

NOTE Running Get-Command in SQL Server PowerShell without any parameters might generate the following message: Get-Command : Object reference not set to an instance of an object.

Download from www.wowebook.com

PowerShell in SQL Server 2008

507

However, other invocations of this command work fine (such as the other examples of Get-Command in this section). Microsoft has identified this issue but as of this writing has not released a fix for it. Because the error occurs only within the SQL provider, the current workaround is to switch from the SQL Server provider to a different drive (such as C:\) before running Get-Command: PS SQLSERVER:\> cd c:\ PS C:\> Get-Command PS C:\> cd SQLSERVER: PS SQLSERVER:\>

NOTE Profiles were discussed earlier in this chapter. The SQL Server PowerShell minishell also has its own profile, and you can manage it by simply typing notepad $profile in SQL Server PowerShell. A prompt may come up that the file cannot be found and asking whether it should be created.

SQL Provider Earlier in this chapter, the term provider was briefly introduced. The SQL team decided to implement a SQL Server provider. What this provides is a layout of the SQL object structure, which resembles that of a regular file system.

17

You use the SQL provider when accessing SQL Server PowerShell via SQL Server Management Studio: depending on what object you right-click to access SQL Server PowerShell, a prompt opens in the context of that particular object. Basically, the way certain commands work is also affected by the current location within the SQL Server provider. Here are two different examples of being placed in different locations within the SQL Server provider. In the first example, the AdventureWorks2008R2 database was rightclicked within SSMS, as shown in Figure 17.6. In the second example, a specific table (Person.Address) within the AdventureWorks2008R2 database was right-clicked, as shown in Figure 17.7. When you start the SQL Server PowerShell minishell by simply invoking sqlps.exe as seen earlier, a prompt opens at the root of the SQL Server provider.

NOTE Some of the core cmdlets like Get-Item, Remove-Item, and New-Item are typically used within providers to retrieve, remove, and create items, respectively. Within the SQL Server provider, creating items using the New-Item cmdlet is currently not supported. Other methods are required to actually create items.

Download from www.wowebook.com

508

CHAPTER 17

Administering SQL Server 2008 with PowerShell

FIGURE 17.6 SQL Server provider at the database level.

FIGURE 17.7 SQL Server provider at the table level.

NOTE Four SQL-based providers are actually available in SQL Server 2008 and six in SQL Server 2008 R2. We look only at the SQL provider that provides functionality for the database engine itself in any detail in this chapter. Refer to the SQL Server Books Online documentation for more information on the other providers (SQLPolicy, SQLRegistration, DataCollection, Utility, and DAC). The Utility and DAC providers are available only in SQL Server 2008 R2.

SQL Cmdlets A number of cmdlets available in SQL Server PowerShell are part of the basic PowerShell functionality. However, within SQL Server PowerShell, five additional cmdlets are available only after the minishell is started (or if the snap-in is loaded manually, which is not covered in any detail here): . Invoke-PolicyEvaluation—A cmdlet that evaluates a SQL Server Policy-Based Management policy (or policies) against a target server. . Invoke-SqlCmd—A cmdlet that runs any regular T-SQL command and any languages and commands supported by the sqlcmd utility, which may be more familiar to most users.

Download from www.wowebook.com

Step-By-Step Examples

509

. Encode-SqlName—A cmdlet that helps to encode SQL Server identifiers into a format that PowerShell can use. . Decode-SqlName—A cmdlet that helps to return the original SQL Server identifiers from a value previously given by the Encode-SqlName cmdlet. . Convert-UrnToPath—A cmdlet that converts the SMO Uniform Resource Name to a SQL Server provider path. Later, examples of using the core cmdlets are provided, as well as the first two cmdlets introduced in the preceding list.

NOTE For more details on the three other cmdlets not discussed here, see the built-in help for more information and examples.

NOTE The intent is to ship more cmdlets as part of SQL-PowerShell in the future after more database users become more familiar with SQL Server PowerShell.

SQL Server Agent Support PowerShell has been integrated into the SQL Server Agent subsystem. In other words, you can create jobs that call PowerShell-specific commands to run.

17

Consult SQL Server Books Online for more details on incorporating PowerShell into your SQL Server Agent job steps.

Step-By-Step Examples The following sections provide examples of using PowerShell both for general tasks and for SQL Server 2008–specific tasks. We expand on some of the basic concepts introduced earlier with SQL Server 2008–specific examples.

General Tasks Often you might be required to send out emails containing particular reports and/or output from commands run. To do so, you use features from the .NET Framework via PowerShell to send out emails, as shown in here: Function Send-Mail { param([string]$To,[string]$From,[string]$Subject, `

Download from www.wowebook.com

510

CHAPTER 17

Administering SQL Server 2008 with PowerShell

[string]$Body,[string]$File,[string]$SmtpServer) If($SmtpServer -eq ““){ $SmtpServer = “FQDN of your SMTP server here” } $Smtp = New-Object System.Net.Mail.SMTPclient($SmtpServer) $Message = New-Object System.Net.Mail.MailMessage($From,$To,$Subject,$Body) If ($File -ne ““) { $Attach = New-Object System.Net.Mail.Attachment $File $Message.Attachments.Add($Attach) } $smtp.Send($message) }

You can enter the preceding code into a script or directly to the console. If you type the code in the console, you must press the Enter key twice (once to close the function and another time on an empty line) before the PowerShell prompt returns. In the preceding code listing, functionality from the .NET Framework is used to get SMTP functionality. A function is used so that this code could be easily copied as required into new scripts, and so on. Calling the function is then easy, and passing the command-line arguments is shown here (the PowerShell prompt can vary depending on whether the default PowerShell is used or the new SQL minishell): PS>Send-Mail -To “[email protected] “ -From “[email protected]” –Subject “Automated Email” -Body “Testing” -File “C:\reports\report.txt”

NOTE You might need to configure some antivirus programs to allow the PowerShell.exe process (or sqlps.exe) to “talk” over the SMTP protocol port (TCP 25).

Scheduling Scripts From time to time, it may be useful to have a method to schedule PowerShell scripts to run automatically based on a particular schedule (when the SQL Server Agent isn’t available locally, for example). You can easily view the method to call PowerShell scripts by simply typing powershell.exe /? from a PowerShell session, as shown here: PS>powershell.exe /? ... PowerShell -Command “& {Get-EventLog -LogName security}” ...

Download from www.wowebook.com

Step-By-Step Examples

511

Only a very small section of the text displayed is shown in this example. The powershell.exe can be used for scheduling regular PowerShell scripts. sqlps.exe works similarly, and you can also access its help by passing a slash and question mark (/?) to the command: PS SQLSERVER:\> sqlps.exe /?

sqlps [ [ [-NoLogo] [-NoExit] [-NoProfile] [-OutputFormat {Text | XML}] [-InputFormat {Text | XML}] ] [-Command { | [ ] | [ -args ] } ] ] [ -Help | -?]

17

-NoLogo Do not display the copyright banner on startup. -NoExit Keep running after completing all startup commands. -NoProfile Do not load a user profile. -OutputFormat Format the output of all objects as either text strings (Text) or in a serialized CLIXML format (XML). -InputFormat The input from stdin is formatted as either text strings (Text) or in a serialized CLIXML format (XML). -Command sqlps runs the commands specified and then exits, unless -NoExit is also specified. Do not specify other characters after the -Command switch, they will be read as command arguments. Read input commands from the keyboard by using stdin. [ ] Specifies a string containing the PowerShell commands to be run. Use the format “&{}”. The quotation marks identify a string and the invocation operator (&) causes sqlps to run the command. [ -args ] Specifies a block of PowerShell commands to be run. Use the format {}. -Help | -? Show the syntax summary help.

Download from www.wowebook.com

512

CHAPTER 17

Administering SQL Server 2008 with PowerShell

NOTE How do you know whether to use powershell.exe or sqlps.exe when scheduling jobs? If you’re using anything relating to SMO and/or the SQL cmdlets in the script, sqlps.exe would seem to be easier to use because all the prerequisites to using SMO and the SQL cmdlets are already loaded, which can save several lines in a script. As a reminder, the SQL minishell is limited in its functionality, so powershell.exe may be required in particular if you need to load some PowerShell functionality from another application, such as Exchange.

As discussed briefly earlier, SQL Server Agent can also be used to run scheduled PowerShell commands.

Common OS-Related Tasks Now let’s look at some more OS-related tasks, while keeping our focus on SQL Server–related tasks. Let’s check the status of the SQL Server service using the Get-Service cmdlet in the regular PowerShell console: PS>Get-Service “mssqlserver” Status Name DisplayName -------------------Stopped MSSQLSERVER SQL Server (MSSQLSERVER) PS>

NOTE When multiple instances are in use, the service name is something like MSSQL$INSTANCE01. To start such an instance from PowerShell or even the SQL minishell, you would have to use the following syntax for the service name: MSSQL`$INSTANCE01. The dollar sign ($) character is escaped so that PowerShell doesn’t try to interpret this as the beginning of a variable when the string is parsed.

The service is stopped. When you use the pipeline feature of PowerShell, the service is started: PS>Get-Service “mssqlserver”|Start-Service WARNING: Waiting for service ‘SQL Server (SQLSERVER)

Download from www.wowebook.com

Step-By-Step Examples

513

(MSSQLSERVER)’ to finish starting... WARNING: Waiting for service ‘SQL Server (SQLSERVER) (MSSQLSERVER)’ to finish starting... PS>

This example demonstrates using the pipeline to chain commands together. Alternatively, you could use Start-Service directly: PS>Start-Service “mssqlserver”

The difference between the two methods demonstrates some of the power in PowerShell. When you use Get-Service, a service object is retrieved. When you use the pipeline, this object is passed to Start-Service. Start-Service is built to basically accept input from the pipeline and autofills its parameters based on what was input; thus, it knows to start the SQL Server service.

NOTE You could use SQL Server PowerShell, but because SQL Server wasn’t started, Management Studio would not have been able to connect, and you could not open SQL Server PowerShell by right-clicking. You could use PowerShell to start sqlps.exe, though, and then you could use the Get-Service and Start-Service cmdlets to start SQL Server. If you use SQL Server PowerShell by calling sqlps.exe directly from within a default PowerShell console, the SQL Server could still be started, but a connection wouldn’t be automatically made to the default instance of the database.

PS>Get-Process sqlservr Handles NPM(K) PM(K) Id ProcessName ------- ----------- -----------318 45 64156 572 sqlservr PS>

WS(K) VM(M)

CPU(s)

----- -----

------

44288

1554

17

Most administrators have probably already used the Windows Task Manager to look at the SQL Server processes. Perhaps it was to determine whether SQL seemed to be using too much memory or some other issue. PowerShell provides the Get-Process cmdlet, shown here, to look at running processes:

2.03

Another common OS-related task is to look for events in the Windows application event log: PS>Get-EventLog Application -New 10 PS>Get-EventLog Application -New 10| `

Download from www.wowebook.com

514

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Where {$_.EntryType -eq “Error”} PS>Get-EventLog Application -New 10| ` Where {$_.EntryType -eq “Error”}|Select-Object TimeWritten

The preceding example demonstrates another useful feature of the PowerShell pipeline where you can join several commands together to get specific results. First, only the 10 newest entries are retrieved; then a pipe is used to get only the entries classified as an error, and finally, only the TimeWritten property is displayed. We mentioned WMI earlier in this chapter as a method for remote control and administration of servers. WMI is packed full of features that are useful for system administration. A few examples of using PowerShell’s built-in WMI features are shown here. . Getting a listing of all the fixed local logical drives: PS>Get-WmiObject -query “select * from Win32_LogicalDisk DriveType=’3’”

where

. Getting a listing of all the fixed remote logical drives: PS>Get-WmiObject -computerName server -query “select * from Win32_LogicalDisk where DriveType=’3’”

. Getting a listing of all the local patches/hotfixes installed (the –computerName parameter could be used with a value to retrieve this information from a remote system): PS>Get-WmiObject Win32_QuickFixEngineering

NOTE Remote WMI connections may require that appropriate firewall rules be open in the network and also with a client firewall on the remote system. In addition, remote WMI queries must also be authenticated. By default, WMI queries use the current user’s authentication credentials. In some scenarios WMI authentication can be more complicated.

The preceding examples show only the beginning of all the things WMI can provide quick access to. Another common task is trying to find files or folders. You can use the GetChildItem cmdlet to recursively search through a directory structure. The following example shows how to search for the location of the powershell.exe executable: PS>Get-ChildItem c:\ -recurse powershell.exe

SQL Server–Specific Tasks Before jumping into more hardcore SQL Server PowerShell features, let’s briefly look at the SQL Server event log. Fortunately, the log simply contains text-based files, which PowerShell can read. You could use the Get-Content cmdlet to view the entire log, but

Download from www.wowebook.com

Step-By-Step Examples

515

instead you can use the Select-String cmdlet to look for a specific string or pattern in the error log file. First, you change the current location to the SQL Server log directory: PS>Set-Location “C:\Program Files\Microsoft SQL Server” PS>Set-Location (join-path $pwd “MSSQL10_50.MSSQLSERVER\MSSQL\Log”) PS>Select-String “error” ERRORLOG

The PowerShell prompt in the preceding example is simply a generic one because the preceding commands would work both in the default PowerShell console and in the SQL Server PowerShell minishell. An example of taking this further would be to retrieve all the errors in the ERRORLOG file. When you use Get-Member and Format-List to look at the object output by SelectString, the date is hidden inside a string in the Line property: PS > Select-String “error” ERRORLOG|foreach{$_.line}|where{$_ -match “^20*”}| foreach{$date,$time=$_.split()[0],$_.split()[1];[datetime]$($date+” “+$time) } PS >

17

The preceding example demonstrates how to look for the string ”error” in the current SQL Server ERRORLOG file. For all the lines that match, the Line property is passed along the pipeline. Next, based on some testing, it appears that you want to search only lines that start with ”20*-”. From that object, two values are retrieved: $_.split()[0] and $_.split[1]. These values are placed in the $date and $time variables, respectively. From there, they are recombined, and a type accelerator is used to indicate that this is a date/time object, so any calculations against this value will be simplified. What is finally output is the time stamp showing when the error occurred.

Using the Provider Using the SQL Server provider can be very handy in navigating the system. Starting PowerShell from SSMS, DBAs can easily find their way through different objects as if working with files and directories. When the SSMS is used to start PowerShell at the server level, the databases are down one level, and from there tables and users, for example, can also be easily accessed. In the session shown in Figure 17.8, we navigated to a particular database and entered a dir Tables command. The output from the last command would scroll beyond the current screen, so only the first part of the output is displayed.

Creating a Database Table Creating a database and a table are common tasks that a DBA may undertake. You can use T-SQL with the Invoke-SqlCmd cmdlet to do this, but a demonstration on how to do this with the SQL Server PowerShell minishell using SMO is presented here to help you better understand the new functionality that is available:

Download from www.wowebook.com

516

CHAPTER 17

Administering SQL Server 2008 with PowerShell

FIGURE 17.8 Navigating the SQL Server provider. cd databases $my_db=New-Object Microsoft.SqlServer.Management.Smo.Database $my_db.Name=”my_database” $my_db.Parent=(Get-Item ..) $my_db.Create() cd my_database cd tables $my_tbl=New-Object Microsoft.SqlServer.Management.Smo.Table $my_tbl.Name=”my_table” $my_tbl.Parent=(Get-Item ..) $my_col=New-Object Microsoft.SqlServer.Management.Smo.Column $my_col.Name=”my_column” $my_col.Parent=$my_tbl $my_col.DataType= ([Microsoft.SqlServer.Management.Smo.DataType]::Int) $my_tbl.Columns.Add($my_col) $my_tbl.Create()

In the preceding example, some new objects are created, some of their properties are set, and some methods are called. You can search for the particular SMO classes used in this example to gain further information. In the future, there may be something like New-Database and New-Table cmdlets that help to create a database and table, which would likely reduce the preceding code to fewer than five lines.

Performing a Database Backup Another example that may be useful is performing a database backup using SMO. Using the AdventureWorks2008R2 database, you can back up the database using just a few lines: $server=New-Object Microsoft.SqlServer.Management.Smo.Server

Download from www.wowebook.com

Step-By-Step Examples

517

$backup=new-object Microsoft.SqlServer.Management.Smo.Backup $file=new-object Microsoft.SqlServer.Management.Smo.BackupDeviceItem $file.Name=”C:\backup\AW_DB.bak” $backup.Devices.Add($file) $backup.Database=”AdventureWorks2008R2” $backup.SqlBackup($server)

The preceding code could be copied into a .ps1 file (for this example, assume it’s copied to c:\temp\backup.ps1), and it could be changed to accept two arguments. The preceding code could be modified to the following code snippet so that it accepts parameters from the command line: param([string]$device=$(throw Write-Host “Device required”), [string] $database=$(throw Write-Host “Database required”)) Write-Host “backup of $database to $device starting...” $server=New-Object Microsoft.SqlServer.Management.Smo.Server $backup=new-object Microsoft.SqlServer.Management.Smo.Backup $file=new-object Microsoft.SqlServer.Management.Smo.BackupDeviceItem $file.Name=$device $backup.Devices.Add($file) $backup.Database=$database $backup.SqlBackup($server) Write-Host “backup complete” Get-Item $device

17

The changes in the preceding example introduce a new keyword, throw. Without it, error messages would be thrown to the console, but this might not help the end user to understand why it failed. For the purpose of printing feedback to the console, the Write-Host and Get-Item cmdlets were also added to provide a limited amount of feedback and to finally provide the details of the final backup file. Then to invoke the script, as shown in the following example, you simply need to pass two parameters to the script: the names of the file to back up to and the database to actually back up. PS>$backup_to=”C:\backup\AdventureWorks2008R2.bak” PS>$db=”AdventureWorks2008R2” PS> c:\temp\backup.ps1 $backup_to $db

As an example of using a conditional statement in the preceding script, perhaps a check could be done to see whether a backup has already been completed within the past seven days. To accomplish this, you would add this particular section of code just before the line Write-Host “backup of $database to $device starting...”: If((Test-Path $device) -and (Get-Item $device).LastWriteTime ` -gt (Get-Date).AddDays(-7)){ “Backup has been performed in last 7 days” Break }

Download from www.wowebook.com

518

CHAPTER 17

Administering SQL Server 2008 with PowerShell

In the preceding code, a conditional statement is added to accomplish the check. The AddDays() method is passed a negative number which subtracts days from the current date..

NOTE When you use the param keyword, this section of code must be on the first noncommented line in all scripts. Otherwise, the PowerShell parser returns an error.

Again, using SMO isn’t necessarily for beginners, but the good thing is that scripts can easily be created and passed around. The preceding example shows the bare minimum required to do a database backup; several other options are available, and the preceding code would actually overwrite the backup each time it is run. There also isn’t any error checking of any sort, which isn’t the best way to develop scripts. Along with the New-Database and New-Table cmdlets that may come in the future, maybe a Start-DbBackup will be another good cmdlet to have available.

Checking Server Settings From the SSMS, by right-clicking on the SQL Server node and then starting a SQL Server PowerShell session, you can open a console directly in the root of the default SQL Server in the example. From here, you can easily obtain information on the SQL Server. First, the location is set to the instance that is to be queried, and then an object representing the SQL Server is saved to a variable (this demonstrates the advanced features mentioned earlier where objects can be saved to variables). The properties of that variable can then be accessed as follows: PS>Set-Location SQLSERVER:\SQL\\ PS>$sql_server=get-item . PS>$sql_server.Information.VersionString

Using the Get-Member cmdlet discussed earlier, you can easily discover other members of the object contained in $sql_server, but this is left as an exercise for you to perform on your own.

NOTE This example demonstrates an important feature of the SQL Server provider: context sensitivity. In the preceding example, the current location was in the root of the SQL Server provider or database, and the command Get-Item. was used. The dot in this command basically indicates that you want an object that represents the current location in the provider. If the dot were moved to a different location, this command would no longer work the same way.

Download from www.wowebook.com

Step-By-Step Examples

519

Checking the Database Usage Using the object retrieved in the $sql_server variable, you can create a quick report of database usage using the databases property of that object, as shown here: PS SQLSERVER:\SQL\\> $sql_server.databases| Format-Table -autosize Name,@{ Label= “% Used” Expression={[math]::round((($_.spaceavailable/1kb)/$_.size),2)} }Name % Used --------AdventureWorks2008R2 0.02 AdventureWorksDW2008R2 0 AdventureWorksLT2008R2 0.02 bigpubs2008 0.18 Customer 0.74 master 0.24 model 0.39 msdb 0.02 my_database 0.38 tempdb 0.8

Using the Format-Table cmdlet, you can easily and quickly create all kinds of reports. Some capabilities we haven’t discussed yet were used to create this report:

17

. Calculated properties—The values displayed by Format-Table can be calculated using scriptblocks. That allows the logic to be highly customized. These scriptblocks are laid out as follows: @{Label=”some text value” Expression={the scriptblock to evaluate here} }

. Direct access to the .NET Framework—The following line is directly from the .NET Framework: ”[math]::round(value,decimal)”

.NET functionality is being used to round out the numbers to the second decimal point. PowerShell has special meaning for 1kb, 1mb, 1gb and 1tb, which all present the value of the counterpart in number of bytes—for example, 1kb=1024. The values can also be uppercase.

Download from www.wowebook.com

520

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Getting Table Properties Another common task is to get a row count of the tables in a particular database: PS SQLSERVER:\SQL\\\Databases\ AdventureWorks2008R2\Tables> Get-ChildItem .| Sort-Object -descending|SelectObject -First 10| Format-Table -autosize Name,RowCountNote

NOTE An easy-to-remember alias for Get-ChildItem is basically dir.

In the preceding example using the AdventureWorks2008R2 database, the top 10 tables with the highest row count value are returned.

NOTE The preceding example shows how many features are packaged within PowerShell, which applies not only to SQL tables, but also to all .NET objects. Simply using GetItem on a particular table returns only the default properties of Schema, Name, and Created. Piping something like Get-Item [table_name] to either Format-Table * or Get-Member exposes all the properties available for a particular object.

Cmdlet Example: Invoke-SqlCmd The Invoke-SqlCmd cmdlet was mentioned earlier. It will likely be the most commonly used cmdlet currently provided. Here is a simple example using this cmdlet: Invoke-sqlcmd -query “exec sp_help”

Using Invoke-SqlCmd, you can simply pass any T-SQL–based query as a value to the cmdlet. The preceding basic example is provided by running a basic built-in stored procedure: sp_help. This example demonstrates several important issues, especially how powerful the provider can be. Based on the location in the SQL provider, some of the values passed to the cmdlet are automatically provided to the cmdlet by the provider itself: the server and database to query aren’t required in the command line. Let’s consider this example a bit further and do a few extra things with it. First, this cmdlet can accept input from the pipeline: ”exec sp_help”|ForEach-Object{Invoke-SqlCmd $_}

The preceding line demonstrates a few more issues that have already been discussed: the ForEach-Object cmdlet, the special variable $_, and also the way parameters can automat-

Download from www.wowebook.com

Step-By-Step Examples

521

ically match values to parameters even when the parameter name isn’t explicitly added to the command entered. The sp_help stored procedure provides a lot of information. What if only the extended stored procedures were required? When Get-Member is used, the members from this particular query are inspected, and it is determined that the Object_type property is the value that indicates what kind of stored procedure is being dealt with. The query to get only extended stored procedures is now the following: ”exec sp_help”|ForEach-Object{Invoke-SqlCmd $_}| ` Where{$_.Object_type -eq “extended stored proc”}|Select Name

Finally, the output consists only of extended stored procedures.

Cmdlet Example: Invoke-PolicyEvaluation Another one of the provided cmdlets is Invoke-PolicyEvaluation. This cmdlet is used to specify a SQL Server Policy-Based Management policy (or policies) that will be evaluated against the target server. You can easily cycle through all the available policies and evaluate each one, or simply provide a list of policies to evaluate separated by a comma. Consider this example: sl “C:\Program Files\Microsoft SQL Server\100\Tools\Policies\DatabaseEngine\1033” Invoke-PolicyEvaluation -Policy “Database Auto Shrink.xml” -TargetServerName “MSSQLSERVER”

17

The preceding command returns the output to the console of the result of the policy evaluation. By default, the particular policy passed to the cmdlet is only checked. In other words, by default, properties are actually changed so that they are now compliant with the policy.

Joining Columns Quite often, databases provide a table for users. Frequently, these users have their last name and first name in separate columns. Because these are typically simple strings, a feature, already discussed, allows two strings to be easily joined together. The following code snippet shows how two columns from the AdventureWorks2008R2 database are easily joined together from within the SQL minishell: PS SQLSERVER:\SQL\D830\DEFAULT\databases\adventureworks2008r2> Invoke-SqlCmd “Select * from Person.Person”| ` >> Select-Object -First 10|ForEach-Object{$_.LastName + “, “ + $_.FirstName} Sánchez, Ken Duffy, Terri Tamburello, Roberto Walters, Rob

Download from www.wowebook.com

522

CHAPTER 17

Administering SQL Server 2008 with PowerShell

Erickson, Gail Goldberg, Jossef Miller, Dylan Margheim, Diane Matthew, Gigi Raheem, Michael

Here, the first 10 records are selected, and then the LastName and FirstName values are combined together.

Retrieving an Entry On occasion, you might need to get a particular entry from a table. When the following code snippet is run, an array is automatically returned: PS SQLSERVER:\SQL\D830\DEFAULT\databases\adventureworks2008r2> “Select * from Person.Person”

Invoke-SqlCmd

PowerShell provides a simple way to look at particular elements within an array. In the following example, entry 100 is returned and then entries 95 to 105: PS SQLSERVER:\SQL\D830\DEFAULT\databases\adventureworks2008r2> “Select * from Person.Person”)[100] PS SQLSERVER:\SQL\D830\DEFAULT\databases\adventureworks2008r2> “Select * from Person.Person”)[95..105]

(Invoke-SqlCmd (Invoke-SqlCmd

NOTE The first element of an array is the element zero; therefore, the first record in an array is retrieved by referencing the element id [0].

Summary This chapter provides an overview of PowerShell and how it has been specifically implemented in SQL Server 2008. Microsoft is putting a lot of effort into integrating PowerShell into all its server-based products, including SQL Server. Support for PowerShell in SQL Server 2008 still has a way to go before it could ever be considered the main scripting language, but the functionality available now is worth looking at. The next chapter delves into high availability and the options available in SQL Server 2008.

Download from www.wowebook.com

CHAPTER

18

SQL Server High Availability

IN THIS CHAPTER . What’s New in High Availability144 . What Is High Availability?145 . The Fundamentals of HA147 . Building Solutions with One or More HA Options150

With SQL Server 2008, Microsoft continues to push the high availability (HA) bar higher and higher. Extensive high-availability options, coupled with a variety of Windows server family enhancements, provide almost everyone with a chance at achieving the mythical “fivenines” (that is, 99.999% uptime).

. Other HA Techniques That Yield Great Results159 . High Availability from the Windows Server Family Side162

Understanding your high-availability requirements is only the first step in implementing a successful high-availability application. Knowing what technical options exist is equally as important. Then, by following a few basic design guidelines, you can match your requirements to the best high-availability technical solution. This chapter introduces a variety of fundamental HA options—such as redundant hardware configurations, RAID, and MSCS clustering—as well as more high-level options— such as SQL clustering, data replication, and database mirroring—that should lead you to a solid high-availability foundation. Microsoft has slowly been moving in the direction of trying to make SQL Server (and the Windows operating systems) as continuously available as possible for as many of its options as possible. Remember that Microsoft is competing with the UNIX/Linux-based worlds that have offered (and achieved) much higher uptime levels for years. The SQL Server RDBMS engine itself and the surrounding services, such as Analysis Services, Integration Services, Notification Services, and Reporting Services, have all taken big steps toward higher availability.

Download from www.wowebook.com

524

CHAPTER 18

SQL Server High Availability

What’s New in High Availability In general, a couple of Microsoft SQL Server 2008 configuration options offer a very strong database engine foundation that can be highly available (7 days a week, 365 days a year). Microsoft’s sights are set on being able to achieve five-nines reliability with almost everything it builds. An internal breakthrough introduced with SQL Server 2005 called “copyon-write” technology, has enabled Microsoft to greatly enhance several of its database high availability options. Here are a few of the most significant enhancements and new features that have direct or indirect effects on increasing high availability for a SQL Server 2008–based implementation: . Increased number of nodes in a SQL cluster—You can create a SQL cluster of up to 64 nodes on Windows Server Data Center 2008. . Enhancements to do unattended cluster setup—Instead of having to use wizards to set up SQL clustering, you can use the Unattended Cluster Setup mode. This is very useful for fast re-creation or remote creation of SQL clustering configurations. . All SQL Server 2008 services as cluster managed resources—All SQL Server 2008 services are now cluster aware. . SQL Server 2008 database mirroring—Database mirroring creates an automatic failover capability to a “hot” standby server. (Chapter 20, “Database Mirroring,” covers this topic in detail.) . SQL Server 2008 peer-to-peer replication—This option of data replication uses a publisher-to-publisher model (hence peer-to-peer). . SQL Server 2008 automatic corruption recovery from mirror—This enhancement in database mirroring recognizes and corrects corrupt pages during mirroring. . SQL Server 2008 mirroring transaction record compression—This feature allows for compression of the transaction log records used in database mirroring to increase the speed of transmission to the mirror. . SQL Server 2008 fast recovery—Administrators can reconnect to a recovering database after the transaction log has been rolled forward (and before the rollback processing has finished). . Online restore—Database administrators can perform a restore operation while the database is still online. . Online indexing—The online index option allows concurrent modifications (updates, deletes, and inserts) to the underlying table or clustered index data and any associated indexes during index creation time. . Database snapshot—SQL Server 2008 allows for the generation and use of a readonly, stable view of a database. The database snapshot is created without the overhead of creating a complete copy of the database or having completely redundant storage.

Download from www.wowebook.com

What Is High Availability?

525

. Hot additions—This feature allows for hot additions to memory and CPU. . Addition of a snapshot isolation level—A new snapshot isolation (SI) level is being provided at the database level. With SI, users can access the last committed row, using a transactionally consistent view of the database. . Dedicated administrator connection—SQL Server 2008 supports a dedicated administrator connection that administrators can use to access a running server even if the server is locked or otherwise unavailable. This capability enables administrators to troubleshoot problems on a server by executing diagnostic functions or Transact-SQL statements without having to take down the server. At the operating system (OS) level, Virtual Server 2005 has firmly established virtualization for both development and production environments and allows entire application and database stacks to run on a completely virtual operating system footprint that will never bring down the physical server.

NOTE Microsoft has announced that log shipping will be deprecated soon. Although it has been functionally replaced with database mirroring, log shipping remains available in SQL Server 2008. However, you should plan to move off log shipping as soon as you can.

Keep in mind that Microsoft already has an extensive capability in support of high availability. The new HA features add significant gains to the already feature-rich offering.

What Is High Availability? 18

The availability continuum depicted in Figure 18.1 shows a general classification of availability based on the amount of downtime an application can tolerate without impacting the business. You would write your service-level agreements (SLAs) to support and try to achieve one of these continuum categories. Topping the chart is the category extreme availability, so named to indicate that this is the least tolerant category and is essentially a zero (or near zero) downtime requirement (that is, sustained 99.5% to 100% availability). The mythical five-nines falls at the high end of this category. Next is the high availability category, which has a minimal tolerance for downtime (that is, sustained 95% to 99.4% availability). Most “critical” applications would fit into this category of availability need. Then comes the standard availability category, with a more normal type of operation (that is, sustained 83% to 94% availability). The acceptable availability category is for applications that are deemed noncritical to a company’s business, such as online employee benefit package self-service applications. These applications can tolerate much lower availability ranges (sustained 70% to 82% availability) than the more critical services. Finally, the marginal availability category is for nonproduction custom applications, such as marketing mailing label applications that can tolerate significant downtime (that is, sustained 0% to 69% availability). Again, remember that availability is measured by the planned operation times of the application.

Download from www.wowebook.com

526

CHAPTER 18

SQL Server High Availability

Availability Continuum Characteristic

Availability Range

Extreme Availability

Near zero downtime!

(99.5%-100%) 1.8 days/yr–5.26 min/yr

High Availability

Minimal downtime

(95%-99.4%) 18 days/yr–2.0 days/yr

Standard Availability

With some downtime tolerance

(83%-94%)

Acceptable Availability

Non-critical Applications

(70%-82%)

Marginal Availability

Non-production Applications

(up to 69%)

Availability Range describes the percentage of time relative to the “planned” hours of operations 8,760 hours/year | 168 hours/week | 24 hours/day 525,600 minutes/year | 7,200 minutes/week | 1,440 minutes/day

FIGURE 18.1 Availability continuum.

NOTE Another featured book from Sams Publishing, called Microsoft SQL Server High Availability, can take you to the depths of high availability from every angle. This landmark offering provides a complete guide to high availability, beginning with ways to gather and understand your HA requirements, assess your HA needs, and completely build out high-availability implementations for the most common business scenarios in the industry. Pick up this book if you are serious about achieving five-nines of reliability.

Achieving the mythical five-nines (that is, a sustained 99.999% availability) falls into the extreme availability category (which tolerates between 5.26 minutes and 1.8 days of down time per year). In general, the computer industry calls this high availability, but we push this type of near-zero downtime requirement into its own extreme category, all by itself. Most applications can only dream about this level of availability because of the costs involved, the high level of operational support required, the specialized hardware that must be in place, and many other extreme factors.

The Fundamentals of HA Every minute of downtime you have today translates into losses that you cannot well afford. You must fully understand how the hardware and software components work together and how, if one component fails, the others will be affected. High availability of

Download from www.wowebook.com

The Fundamentals of HA

527

an application is a function of all the components together, not just one by itself. Therefore, the best approach for moving into supporting high availability is to work on shoring up the basic foundation components of hardware, backup/recovery, operating system upgrading, ample vendor agreements, sufficient training, extensive quality assurance/testing, rigorous standards and procedures, and some overall risk-mitigating strategies, such as spreading out critical applications over multiple servers. By addressing these first, you add a significant amount of stability and high-availability capability across your hardware/system stack. In other words, you are moving up to a necessary level before you completely jump into a particular high-availability solution. If you do nothing further from this point, you have already achieved a portion of your high-availability goals.

Hardware Factors You need to start by addressing your basic hardware issues for high availability and fault tolerance. This includes redundant power supplies, UPS systems, redundant network connections, and ECC memory (error correcting). Also available are “hot-swappable” components, such as disks, CPUs, and memory. In addition, most servers are now using multiple CPUs, fault-tolerant disk systems such as RAID, mirrored disks, storage area networks (SANs), Network Attached Storage (NAS), redundant fans, and so on. Cost may drive the full extent of what you choose to build out. However, you should start with the following: . Redundant power supplies (and UPSs) . Redundant fan systems . Fault-tolerant disks, such as RAID (1 through 10), preferably “hot swappable” . ECC memory . Redundant Ethernet connections

18

Backup Considerations After you consider hardware, you need to look at the basic techniques and frequency of your disk backups and database backups. For many companies, the backup plan isn’t what it needs to be to guarantee recoverability and even the basic level of high availability. At many sites, database backups are not being run, are corrupted, or aren’t even considered necessary. You would be shocked by the list of Fortune 1000 companies where this occurs.

Operating System Upgrades You need to make sure that all upgrades to your OS are applied and also that the configuration of all options is correct. This includes making sure you have antivirus software installed (if applicable), along with the appropriate firewalls for external-facing systems.

Download from www.wowebook.com

528

CHAPTER 18

SQL Server High Availability

Vendor Agreements Followed Vendor agreements come in the form of software licenses, software support agreements, hardware service agreements, and both hardware and software service-level agreements. Essentially, you are trying to make sure you can get all software upgrades and patches for your OS and for your application software at any time, as well as get software support, hardware support agreements, and both software and hardware SLAs in place to guarantee a level of service within a defined period of time.

Training Kept Up to Date Training is multifaceted in that it can be for software developers to guarantee that the code they write is optimal, for system administrators who need to administer applications, and even for end users themselves to make sure they use the system correctly. All these types of training play into the ultimate goal of achieving high availability.

Quality Assurance Done Well Testing as much as possible—and doing it in a very formal way—is a great way to guarantee a system’s availability. Dozens of studies over the years have clearly shown that the more thoroughly you test (and the more formal your QA procedures), the fewer software problems you will have. Many companies foolishly skimp on testing, which has a huge impact on system reliability and availability.

Standards/Procedures Followed Standards and procedures are interlaced tightly with training and QA. Coding standards, code walkthroughs, naming standards, formal system development life cycles, protection of tables from being dropped, use of governors, and so on all contribute to more stable and potentially more highly available systems.

Server Instance Isolation By design, you may want to isolate applications (such as SQL Server’s applications and their databases) away from each other to mitigate the risk of such an application causing another to fail. Plain and simple, you should never put applications in each other’s way if you don’t have to. The only things that might force you to load up a single server with all your applications would be expensive licensing costs for each server’s software and perhaps hardware scarcity (strict limitations to the number of servers available for all applications). A classic example occurs when a company loads up a single SQL Server instance with between two and eight applications and their associated databases. The problem is that the applications are sharing memory, CPUs, and internal work areas, such as tempdb. Figure18.2 shows an overloaded SQL Server instance that is being asked to service seven major applications (Appl 1 DB through Appl 7 DB). The single SQL Server instance in Figure 18.2 is sharing memory (cache) and critical internal working areas, such as tempdb, with all seven major applications. Everything runs fine

Download from www.wowebook.com

The Fundamentals of HA

OS/SQL Binaries

C:

RAID Disk Array

Memory/Cache 8GB

Processors - 4

Network

Web Services

Windows 2003

Master DB MSDB DB Temp DB Appl 1 DB Appl 2 DB Appl 3 DB Appl 4 DB Appl 5 DB Appl 6 DB Appl 7 DB

D: SCSI

529

E: F:

SQL Server 2008

High Risk: Single SQL Server Instance

FIGURE 18.2 High risk: Many applications sharing a single SQL Server 2008 instance. until one of these applications submits a runaway query, and all other applications being serviced by that SQL Server instance come to a grinding halt. Most of this built-in risk could be avoided by simply putting each application (or perhaps two applications) onto their own SQL Server instance, as shown in Figure 18.3. This fundamental design approach greatly reduces the risk of one application affecting another.

F:

RAID Disk Array

Appl 1 DB Appl 5 DB

Memory/Cache 8GB

E:

Processors - 4

D: SCSI

Network

Web Services

Master DB TempDB

RAID Disk Array

Memory/Cache 8GB

Processors - 4

Network

Windows 2003

C:

C:

Master DB TempDB D: SCSI

E: F:

SQL Server 2008

18

Web Services

Windows 2003

Appl 2 DB Appl 3 DB

SQL Server 2008

RAID Disk Array

Memory/Cache 8GB

Processors - 4

Network

Web Services

Windows 2003

C:

Master DB TempDB D: SCSI

E: F:

SQL Server 2008

Appl 4 DB Appl 6 DB Appl 7 DB

FIGURE 18.3 Mitigated risk: Isolating critical applications away from each other.

Download from www.wowebook.com

530

CHAPTER 18

SQL Server High Availability

Many companies make this fundamental error. The trouble is that they keep adding new applications to their existing server instance without a full understanding of the shared resources that underpin the environment. It is often too late when they finally realize that they are hurting themselves “by design.” You have now been given proper warning of the risks. If other factors, such as cost or hardware availability, dictate otherwise, then at least it is a calculated risk that is entered into knowingly (and is properly documented as well).

Building Solutions with One or More HA Options When you have the fundamental foundation in place, as described in the preceding section, you can move on to building a tailored software-driven high-availability solution. Which HA option(s) you should be using really depends on your HA requirements. The following high-availability options are used both individually and, very often, together to achieve different levels of HA: . Microsoft Cluster Services (non–SQL Server based) . SQL clustering . Data replication (including peer-to-peer configurations) . Log shipping . Database mirroring All these options are readily available “out of the box” from Microsoft, from the Windows Server family of products and from Microsoft SQL Server 2008. It is important to understand that some of these options can be used together, but not all go together. For example, you might use Microsoft Cluster Services (MSCS) along with Microsoft SQL Server 2008’s SQL Clustering to implement the SQL clustering database configuration, whereas, you wouldn’t necessarily need to use MSCS with database mirroring.

Microsoft Cluster Services (MSCS) MSCS could actually be considered a part of the basic HA foundation components described earlier, except that it’s possible to build a high-availability system without it (for example, a system that uses numerous redundant hardware components and disk mirroring or RAID for its disk subsystem). Microsoft has made MSCS the cornerstone of its clustering capabilities, and MSCS is utilized by applications that are cluster enabled. A prime example of a cluster-enabled technology is Microsoft SQL Server 2008. MSCS is the advanced Windows operating system configuration that defines and manages between 2 and 16 servers as “nodes” in a cluster. These nodes are aware of each other and can be set up to take over cluster-aware applications from any node that fails (for example, a failed server). This cluster configuration also shares and controls one or more disk subsystems as part of its high-availability capability. Figure 18.4 illustrates a basic twonode MSCS configuration.

Download from www.wowebook.com

Building Solutions with One or More HA Options

Node A

Windows 2008 R2 Enterprise Edition

531

Local Binaries

C:

D:

Shared Disk

SCSI

Node B

Windows 2008 R2 Enterprise Edition

C:

Local Binaries

FIGURE 18.4 Basic two-node MSCS configuration. MSCS is available only with Microsoft Windows Enterprise Edition and Data Center operating system products. Don’t be alarmed, though. If you are looking at a high-availability system to begin with, there is a great probability that your applications are already running with these enterprise-level OS versions. MSCS can be set up in an active/passive or active/active mode. Essentially, in an active/passive mode, one server sits idle (that is, is passive) while the other is doing the work (that is, is active). If the active server fails, the passive one takes over the shared disk and the cluster-aware applications instantaneously.

18

SQL Clustering If you want a SQL Server instance to be clustered for high availability, you are essentially asking that this SQL Server instance (and the database) be completely resilient to a server failure and completely available to the application without the end user ever even noticing that there was a failure (or at least with minimal interruption). Microsoft provides this capability through the SQL Clustering option. SQL Clustering is built on top of MSCS for its underlying detection of a failed server and for its availability of the databases on the shared disk (which is controlled by MSCS). SQL Server is said to be a “clusteraware/enabled” technology. A SQL Server instance that is clustered can be created by actually creating a virtual SQL Server instance that is known to the application (the constant in the equation) and then

Download from www.wowebook.com

532

CHAPTER 18

SQL Server High Availability

two physical SQL Server instances that share one set of databases. In an active/passive configuration, only one SQL Server instance is active at a time and just goes along and does its work. If that active server fails (and with it, the physical SQL Server instance), the passive server (and the physical SQL Server instance on that server) simply takes over instantaneously. This is possible because MSCS also controls the shared disk where the databases are. The end user and application never really know which physical SQL Server instance they are on or whether one failed. Figure 18.5 illustrates a typical SQL Clustering configuration built on top of MSCS. SQL Connections C: Local Binaries

Windows 2008 Enterprise Edition SQL A

SQL Server 2008 (physical)

D:

SQL Server 2008 (Virtual SQL Server)

Master DB Temp DB Appl 1 DB

SCSI

SQL B C:

SQL Server 2008 (physical) Windows 2008 Enterprise Edition

Local Binaries

FIGURE 18.5 Basic SQL Clustering two-node configuration (active/passive). Setup and management of this type of configuration are much easier than you might think. More and more often, SQL Clustering is the method chosen for most high-availability solutions. Later in this chapter, you see that other methods may also be viable for achieving high availability (based on the application’s HA requirements). Chapter 21, “SQL Server Clustering,” covers this topic in more detail. Extending the clustering model to include Network Load Balancing (NLB) pushes this particular solution even further into higher availability—from client traffic high availability to back-end SQL Server high availability. Figure 18.6 shows a four-host NLB cluster architecture acting as a virtual server to handle the network traffic coupled with a two-node SQL cluster on the back end. This setup is resilient from top to bottom.

Download from www.wowebook.com

Building Solutions with One or More HA Options

533

Front-End LAN

Back-End LAN

SQL Cluster (virtual) (IP 100.122134.32) CL Node B (IP 100.122.134.34)

CL Node A (IP 100.122.134.33)

SQL B Local Binaries

SQL A Local Binaries scsi

scsi Instance data

FIGURE 18.6 An NLB host cluster with a two-node server cluster.

The four NLB hosts work together, distributing the work efficiently. NLB automatically detects the failure of a server and repartitions client traffic among the remaining servers. The following apply to SQL Clustering in SQL Server 2008:

18

. Full SQL Server 2008 Services as cluster-managed resources—All SQL Server 2008 services, including the following, are cluster aware: . SQL Server DBMS engine . SQL Server Agent . SQL Server Full-Text Search . Analysis Services . Integration Services . Notification Services . Reporting Services . Service Broker

Download from www.wowebook.com

534

CHAPTER 18

SQL Server High Availability

Now, you can extend this fault-tolerant solution to embrace more SQL Server instances and all of SQL Server’s related services. This is a big deal because things like Analysis Services previously had to be handled with separate techniques to achieve near high availability. Not anymore; each SQL Server service is now cluster aware.

Data Replication The next technology option that can be utilized to achieve high availability is data replication. Originally, data replication was created to offload processing from a very busy server (such as an OLTP application that must also support a big reporting workload) or to geographically distribute data for different, very distinct user bases (such as worldwide product ordering applications). As data replication (transactional replication) became more stable and reliable, it started to be used to create “warm” (almost “hot”) standby SQL Servers that could also be used to fulfill basic reporting needs. If the primary server ever failed, the reporting users would still be able to work (hence a higher degree of availability achieved for them), and the replicated reporting database could be used as a substitute for the primary server, if needed (hence a warm-standby SQL Server). When doing transactional replication in the “instantaneous replication” mode, all data changes were replicated to the replicate servers extremely quickly. With SQL Server 2000, updating subscribers allowed for even greater distribution of the workload and, overall, increased the availability of the primary data and distributed the update load across the replication topology. There are plenty of issues and complications involved in using the updating subscribers approach (for example, conflict handlers, queues). With SQL Server 2005, Microsoft introduced peer-to-peer replication, which is not a publisher/subscription model, but a publisher-to-publisher model (hence peer-to-peer). It is a lot easier to configure and manage than other replication topologies, but it still has its nuances to deal with. This peer-to-peer model allows excellent availability for this data and great distribution of workload along geographic (or other) lines. This may fit some companies’ availability requirements and also fulfill their distributed reporting requirements as well. The top of Figure 18.7 shows a typical SQL data replication configuration of a central publisher/subscriber using continuous transactional replication. This can serve as a basis for high availability and also fulfills a reporting server requirement at the same time. The bottom of Figure 18.7 shows a typical peer-to-peer continuous transactional replication model that is also viable. The downside of peer-to-peer replication comes into play if ever the subscriber (or the other peer) needs to become the primary server (that is, take over the work from the original server). This takes a bit of administration that is not transparent to the end user. Connection strings have to be changed, ODBC data sources need to be updated, and so on. But this process may take minutes as opposed to hours of database recovery time, and it may well be tolerable to end users. Peer-to-peer configurations handle recovery a bit better in that much of the workload is already distributed to either of the nodes. So, at most, only part of the user base will be affected if one node goes down. Those users can easily be redirected to the other node (peer), with the same type of connection changes described earlier.

Download from www.wowebook.com

Building Solutions with One or More HA Options

535

SQL Server 2008

Adventure Works

Central Publisher/ Subscriber

SQL Server 2008

“continuous” transactional replication

AW DB

Hot Spare (Fail-over)

translog

distribution

SQL Server 2008

Adventure Works DB

Peer-to-Peer

SQL Server 2008

translog

Adventure Works DB translog

Publication Server

Publication Server

SQL Server 2008

MSDB DB

Distribution Server

FIGURE 18.7 Basic data replication configurations for HA.

18

With either the publisher/subscriber or peer-to-peer replication approach, there is a risk of not having all the transactions from the publishing server. However, often, a company is willing to live with this small risk in favor of availability. Remember that a replicated database is an approximate image of the primary database (up to the point of the last update that was successfully distributed), which makes it very attractive as a warm standby. For publishing databases that are primarily read-only, using a warm standby is a great way to distribute the load and mitigate the risk of any one server failing. Chapter 19, “Replication,” covers data replication and all the various implementation scenarios that you might ever need to use.

Log Shipping Another, more direct, method of creating a completely redundant database image is to utilize log shipping. Microsoft “certifies” log shipping as a method of creating an “almost hot” spare. Some folks even use log shipping as an alternative to data replication (it has been referred to as “the poor man’s data replication”). There’s just one problem: Microsoft has formally announced that log shipping (as we know and love it) will be deprecated in the near future. The reasons are many, but the primary one is that it is being replaced by database mirroring (referred to as real-time log shipping, when it was first being conceived). If you still want to use log shipping, it is perfectly viable—for now. Log shipping does three primary things: . Makes an exact image copy of a database on one server from a database dump . Creates a copy of that database on one or more other servers from that dump

Download from www.wowebook.com

536

CHAPTER 18

SQL Server High Availability

. Continuously applies transaction log dumps from the original database to the copy In other words, log shipping effectively replicates the data of one server to one or more other servers via transaction log dumps. Figure 18.8 shows a source/destination SQL Server pair that has been configured for log shipping.

FIGURE 18.8 Log shipping in support of high availability. Log shipping is a great solution when you have to create one or more failover servers. It turns out that, to some degree, log shipping fits the requirement of creating a read-only subscriber as well. The following are the gating factors for using log shipping as a method of creating and maintaining a redundant database image: . Data latency lag is the time that exists between the transaction log dumps on the source database and when these dumps are applied to the destination databases. . Sources and destinations must be the same SQL Server version. . Data is read-only on the destination SQL Server until the log shipping pairing is broken (as it should be to guarantee that the transaction logs can be applied to the destination SQL Server). The data latency restriction might quickly disqualify log shipping as an instantaneous high-availability solution (if you need rapid availability of the failover server). However, log shipping might be adequate for certain situations. If a failure ever occurs on the primary SQL Server, a destination SQL Server that was created and maintained via log shipping can be swapped into use fairly quickly. The destination SQL Server would contain exactly what was on the source SQL Server (right down to every user ID, table, index, and file allocation map, except for any changes to the source database that

Download from www.wowebook.com

Building Solutions with One or More HA Options

537

occurred after the last log dump was applied). This directly achieves a level of high availability. It is still not completely transparent, though, because the SQL Server instance names are different, and the end user may be required to log in again to the new server instance.

NOTE Log shipping is not covered further in this book because of its limited life going forward. The SQL Server 2000 Unleashed version of this book covers log shipping in extensive detail. Remember that log shipping is not data replication and uses a completely different technology than data replication.

Database Mirroring Another failover option with SQL Server is database mirroring. Database mirroring essentially extends the old log shipping feature of SQL Server and creates an automatic failover capability to a “hot” standby server. Database mirroring is being billed as creating a faulttolerant database that is an “instant” standby (ready for use in less than three seconds). At the heart of database mirroring is the “copy-on-write” technology. Copy-on-write means that transactional changes are shipped to another server as the logs are written. All logged changes to the database instance become immediately available for copying to another location. As you can see in Figure 18.9, database mirroring utilizes a witness server as well as client components to insulate the client applications from any knowledge of a server failure.

Client

Client

Client

Client

Network

18

SQL Server 2008

SQL Server 2008

Mirror Server Principal Server

Adventure Works DB

Adventure Works DB

translog

translog

SQL Server xyz

Witness Server

MSDB DB

FIGURE 18.9 SQL Server 2008 database mirroring high-availability configuration.

Download from www.wowebook.com

538

CHAPTER 18

SQL Server High Availability

Chapter 20 dives much more deeply into database mirroring setup, configuration, and architecture. It is sufficient to say here that with database mirroring, an application can possibly be failed over to the mirrored database in 3 seconds or less, with nearly complete client transparency. You can also leverage this mirrored database for offloading reporting by creating a snapshot from it. Again, this topic is covered in Chapter 20.

Combining Failover with Scale-Out Options SQL Server 2008 pushes combinations of options to achieve higher availability levels. A prime example would be combining data replication with database mirroring to provide maximum availability of data, scalability to users, and fault tolerance via failover, potentially at each node in the replication topology. By starting with the publisher and perhaps the distributor, you make them both database mirror failover configurations. Building up a combination of both options together is essentially the best of both worlds: the super-low latency of database mirroring for fault tolerance and high availability (and scalability) of data through replication. Check out Chapter 20 for more details on this creative configuration.

Other HA Techniques That Yield Great Results Microsoft has been revisiting (and architecting) several operations that previously required a table or whole database to be offline. For several critical database operations (such as recovery operations, restores, indexing, and others), Microsoft has either made the data in the database available earlier in the execution of the operation or made the data in the database completely available simultaneously with the operation. The following primary areas are now addressed: . Fast recovery—This faster recovery option directly improves the availability of SQL Server databases. Administrators can reconnect to a recovering database after the transaction log has been rolled forward (and before the rollback processing has finished). Figure 18.10 illustrates how Microsoft makes a SQL Server 2008 database available earlier than would SQL Server 2000. In particular, a database in SQL Server 2008 becomes available when committed transaction log entries are rolled forward (termed redo) and no longer have to wait for the “in flight” transactions to be rolled back (termed undo). . Online restore—Database administrators can perform a restore operation while the database is still online. Online restore improves the availability of SQL Server because only the data being restored is unavailable; the rest of the database remains online and available to users. In addition, the granularity of the restore has changed to be at the filegroup level and even at the page level, if needed. The remainder of the database remains available. . Online indexing—Concurrent modifications (updates, deletes, and inserts) to the underlying table or clustered index data and any associated indexes can now be done during index creation time. For example, while a clustered index is being

Download from www.wowebook.com

Other HA Techniques That Yield Great Results

539

SQL Server

SQL Server 2008

SQL Server

SQL Server 2005 and 2008 database is available

Restart complete

SQL Server 2000 database is available

Transactions Rolled Forward

SQL Server 2000

Transactions Rolled Back

time

Restart Stage

FIGURE 18.10 SQL Server 2008 databases become available earlier than databases with SQL Server 2000 database recovery (fast recovery). rebuilt, you can continue to make updates to the underlying data and perform queries against the data. . Database snapshots—You can now create a read-only, stable view of a database. A database snapshot is created without the overhead of creating a complete copy of the database or having completely redundant storage. A database snapshot is simply a reference point of the pages used in the database (that is defined in the system catalog). When pages are updated, a new page chain is started that contains the data pages changed since the database snapshot was taken, as illustrated in Figure 18.11.

18

As the original database diverges from the snapshot, the snapshot gets its own copy of original pages when they are modified. The snapshot can even be used to recover an accidental change to a database by simply reapplying the pages from the snapshot back to the original database. The copy-on-write technology used for database mirroring also enables database snapshots. When a database snapshot is created on a database, all writes check the system catalog of “changed pages” first; if not there, the original page is copied (using the copy-on-write technique) and is put in a place for reference by the database snapshot (because this snapshot must be kept intact). In this way, the database snapshot and the original database share the data pages that have not changed. . Data partitioning improvements—Data partitioning has been enhanced with native table and index partitioning. It essentially allows you to manage large tables and indexes at a lower level of granularity. In other words, a table can be defined to identify distinct partitions (such as by date or by a range of key values). This approach effectively defines a group of data rows that are unique to a partition.

Download from www.wowebook.com

540

CHAPTER 18

SQL Server High Availability

Source Data Pages

Snapshot Users SELECT…data…… FROM AdventureWorks SNAPSHOT

SQL Server 2008

SQL Server Adventure Works DB

Sparse File Pages

System Catalog of changed pages

Snapshot AdventureWorks DB

FIGURE 18.11 Database snapshots and the original database share pages and are managed within the system catalog of SQL Server 2008. These partitions can be taken offline, restored, or loaded independently while the rest of the table is available. . Addition of a snapshot isolation level—This snapshot isolation (SI) level is a database-level capability that allows users to access the last committed row, using a transactionally consistent view of the database. This capability provides improved scalability and availability by not blocking data access of this previously unavailable data state. This new isolation level essentially allows data reading requests to see the last committed version of data rows, even if they are currently being updated as part of a transaction (for example, they see the rows as they were at the start of the transaction without being blocked by the writers, and the writers are not blocked by readers because the readers do not lock the data). This isolation level is probably best used for databases that are read-mostly (with few writes/updates) due to the potential overhead in maintaining this isolation level. . Dedicated administrator connection—This feature introduces a dedicated administrator connection that administrators can use to access a running server even if the server is locked or otherwise unavailable. This capability enables administrators to troubleshoot problems on a server by executing diagnostic functions or Transact-SQL statements without having to take down the server.

High Availability from the Windows Server Family Side To enhance system uptimes, numerous system architecture enhancements that directly reduce unplanned downtime, such as improved memory management and driver verification, were made in Windows 2000, 2003, and 2008 R2. New file protection capabilities

Download from www.wowebook.com

High Availability from the Windows Server Family Side

541

prevent new software installations from replacing essential system files and causing failures. In addition, device driver signatures identify drivers that may destabilize a system. And, perhaps another major step toward stabilization is the use of virtual servers.

Microsoft Virtual Server 2005 Virtual Server 2005 is a much more cost-effective virtual machine solution designed on top of Windows Server 2008 to increase operational efficiency in software testing and development, application migration, and server consolidation scenarios. Virtual Server 2005 is designed to increase hardware efficiency and help boost administrator productivity, and it is a key Microsoft deliverable toward the Dynamic Systems Initiative (eliminating reboots of servers, which directly affects downtime!). As shown in Figure 18.12, the host operating system—Windows Server 2008 in this case—manages the host system (at the bottom of the stack).

Virtual Machine

Virtual Machine

Operating System and Applications

Operating System and Applications

Virtual Hardware

Virtual Hardware

Virtual Server 2005

Windows Server 2008

18

Any x86/x64 (32/64 bit) Server

FIGURE 18.12 Microsoft Virtual Server 2005 server architecture. Virtual Server 2005 provides a Virtual Machine Monitor (VMM) virtualization layer that manages virtual machines and provides the software infrastructure for hardware emulation. As you move up the stack, each virtual machine consists of a set of virtualized devices, the virtual hardware for each virtual machine. A guest operating system and applications run in the virtual machine—unaware, for example, that the network adapter they interact with through Virtual Server is only a software simulation of a physical Ethernet device. When a guest operating system is running, the special-purpose VMM kernel takes mediated control over the CPU and hardware during virtual machine operations, creating an isolated environment in which the guest

Download from www.wowebook.com

542

CHAPTER 18

SQL Server High Availability

operating system and applications run close to the hardware at the highest possible performance. Virtual Server 2005 is a multithreaded application that runs as a system service, with each virtual machine running in its own thread of execution; I/O occurs in child threads. Virtual Server derives two core functions from the host operating system: the underlying host operating system kernel schedules CPU resources, and the device drivers of the host operating system provide access to system devices. The Virtual Server VMM provides the software infrastructure to create virtual machines, manage instances, and interact with guest operating systems. An often-discussed example of leveraging Virtual Server 2005 capabilities would be to use it in conjunction with a disaster recovery implementation.

Virtual Server 2005 and Disaster Recovery Virtual Server 2005 enables a form of server consolidation for disaster recovery. Rather than maintaining redundancy with costly physical servers, customers can use Virtual Server 2005 to back up their mission-critical functionality in a cost-effective way by means of virtual machines. The Virtual Machine Monitor (VMM) and Virtual Hard Disk (VHD) technologies in Virtual Server 2005, coupled with the comprehensive COM API, can be used to create similar failover functionality as standard, hardware-driven disaster recovery solutions. Customers can then use the Virtual Server COM API to script periodic duplication of physical hard disks containing vital business applications to virtual machine VHDs. Additional scripts can switch to the virtual machine backup in the event of catastrophic failure. In this way, a failing device can be taken offline to troubleshoot, or the application or database can be moved to another physical or virtual machine. Moreover, because VHDs are a core Virtual Server technology, they can be used as a disaster recovery agent, wherein business functionality and data can be easily archived, duplicated, or moved to other physical machines.

Summary As you come to completely understand and assess your application’s high-availability requirements, you can create a matching high-availability solution that will serve you well for years to come. The crux of high availability is laying a fundamentally sound foundation that you can count on when failures occur and then, when failures do occur, determining how much data loss you can tolerate, how much downtime is possible, and what the downtime is costing you. The overall future seems to be improving greatly in all the basic areas of your Microsoft platform footprint, including . Cheaper and more reliable hardware components that are highly swappable . The advent of virtual server capabilities (with Windows Virtual Server 2005) to insulate software failures from affecting hardware . Enhancements that Microsoft is making to SQL Server 2008 that address availability

Download from www.wowebook.com

Summary

543

The critical enhancements to the cornerstone availability capabilities of SQL Clustering will help this fault-tolerant architecture grow more reliable for years to come. The big bonuses come with the features of database mirroring as another fault-tolerant solution at the database level and the database snapshots feature to make data more available to more users more quickly than the older method of log shipping. To top it all off, Microsoft is making great strides in the areas of online maintenance operations (online restores, online index creates, and so on) and leaping into the realm of one or more virtual server machines (with Virtual Server 2005) that will not bring down a physical server that houses them (which is very UNIX-like). Chapter 19 delves into the complexities of the major data replication options available with SQL Server 2008.

18 Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

19

Replication

IN THIS CHAPTER . What’s New in Data Replication . What Is Replication? . The Publisher, Distributor, and Subscriber “Magazine” Metaphor . Replication Scenarios

There is no such thing as a typical configuration or application anymore. Companies now have to support numerous hardware and software configurations in multitiered, distributed environments. These diverse configurations and applications (and users of the applications) come in all sizes and shapes. And, of course, you need a way to deal with varied data access requirements for these different physical locations; these remote or mobile users over a local area network, wide area network, wireless connections, and dialup connections; and any needs over the Internet. Microsoft’s data replication facility allows for a great breadth of capability to deal with many of these demands. However, to build a proper data replication implementation that meets many of these user requirements, you must have a thorough understanding of the business requirements and technical capabilities of data replication. Data replication is a set of technologies for storing and forwarding data and database objects from one database to another and then synchronizing this data between databases to maintain consistency. With SQL Server 2008, the data replication feature set offers numerous improvements in manageability, availability, programmability, mobility, scalability, and performance.

. Subscriptions . Replication Agents . Planning for SQL Server Data Replication . SQL Server Replication Types . Basing the Replication Design on User Requirements . Setting Up Replication . Scripting Replication . Monitoring Replication

This chapter does the following: . Helps you understand what data replication is . Shows you how to understand and analyze user requirements of data . Allows you to choose which replication configuration best meets these requirements (if any)

Download from www.wowebook.com

546

CHAPTER 19

Replication

. Demonstrates how to implement a replication configuration . Describes how to administer and monitor a data replication implementation

What’s New in Data Replication Much of what’s new for Microsoft SQL Server data replication revolves around simplifying setup, administration, and monitoring of a data replication topology. This is the result of years of practical experience and thousands of production replication implementations around the globe. The overall data replication approach that Microsoft has developed (since replication’s inception back in SQL Server 6.5 days) has been so solid that competitors, such as Oracle (with its Oracle Streams technology), have tried to mimic this architectural approach. Among many others, the following are some of the new replications features and enhancements that make SQL Server 2008 data replication one of the best data distributions tools on the market: . Highly available replication node additions—SQL Server 2008 offers the capability to add nodes to a replication topology without quiescing the topology. . Topology Viewer—Enhancements have been made to the Peer-to-Peer Topology Wizard so that you can now visually see what the peer-to-peer topology looks like with the Topology Viewer. . Capability to centrally monitor all agents and jobs at the Publisher—You are able to view information about all the agents and jobs associated with publications at the selected Publisher. . Minor Replication Monitor enhancements—Replication Monitor has undergone slight tweaks to make it easier to monitor your full replication topologies. It allows you to monitor the overall health of a replication topology and provides detailed information about the status and performance of publications and subscriptions. . Capability to replicate switch partition ALTER—Enhanced Transactional Replication Support for Partitioned Tables is now available, including the capability to replicate the switch partition ALTER for Tables. . Scripting integrated into wizards—You can almost completely script your replication setup or breakdown during or after wizard executions. . Conflict Viewer—This feature helps you view and resolve any conflicts that occurred during the synchronization of a merge subscription or queued updating subscription. . Peer-to-peer transactional replication—Further enhancements have been introduced to the peer-to-peer replication model. They allow replication between identical participants in the topology (a master/master or symmetric publisher concept). . Peer-to-peer conflict detection—The capability to detect conflicts during synchronization in a peer-to-peer replication topology has been added.

Download from www.wowebook.com

What Is Replication?

547

. More replication mobility—Merge replication provides the capability to replicate data over HTTPS with the web synchronization option, which is useful for synchronizing data from mobile users over the Internet or synchronizing data between Microsoft SQL Server databases across a corporate firewall. . Microsoft Sync Framework—This comprehensive synchronization platform enables collaboration and offline access for applications, services, and devices. It features technologies and tools that enable roaming, sharing, and taking data offline. By using Sync Framework, developers can build sync ecosystems that integrate any application with any data from any store that uses any protocol over any network. We mention it here because of its replication-like behavior for “occasionally connected” applications. Many of these terms and references might be new or foreign to you now, but they are all explained in this chapter. At the end of this chapter, when you review these new features, you’ll be able to appreciate much more readily their significance.

What Is Replication? Long before you ever start setting up and using SQL Server data replication, you need to have a solid grasp of what data replication is and how it can be used to meet your company’s needs. In its classic definition, data replication is based on the “store-andforward” data distribution model, as shown in Figure 19.1. In other words, data that is inserted, updated, or deleted in one location (stored) is automatically distributed (forwarded) to one or more locations.

Insert “A” (Store)

Distribute “A” (Forward)

A

A

A

19

A

FIGURE 19.1 The store-and-forward data distribution model. Of course, the data distribution model addresses all the other complexities of updates, deletes, data latency, autonomy, and so on. It is this data distribution model that Microsoft’s data replication facility serves to implement. It has come a long way since the early days of Microsoft SQL Server replication (earlier than 6.5) and is now easily categorized as “production worthy.” Numerous worldwide data replication scenarios have been implemented for some of the biggest companies in the world without a hitch. These scenarios fall into five major types:

Download from www.wowebook.com

548

CHAPTER 19

Replication

. Offloading—You might need to deliver data to different locations to eliminate network traffic and unnecessary load on a single server (for example, when you need to isolate reporting activity away from your online transaction processing). The industry trend is to create an operational data store (ODS) data architecture that replicates core transactional data to a separate platform in real-time and delivers the data to the reporting systems, web services, and other data consumers without impacting the transactional systems in any way. . Enabling—You might need to enable a group of users with a copy of data or a subset of data (vertically or horizontally) for their private use. . Partitioning—You might need to move data off a single server onto several other servers to provide for high availability and decentralization of data (or partitioning of data). This might be the basis of serving customer call centers around the globe that must service “active” support calls (partitioned on active versus closed service requests). . Regionalization—You might have regional ownership of data (for example, regional customers and their orders). In this case, it is possible to set up data replication to replicate data bidirectionally from two or more publishers of the same data. . Failover—You could be replicating all data on a server to another server (that is, a failover server) so that if the primary server crashes, users can switch to the failover server quickly and continue to work with little downtime or data loss. Figure 19.2 illustrates the topology of some of these replication variations. SQL Server 2008

Primary OLTP

SQL Server 2008

Reporting/ODS

OLTP DB

Rpt DB

SQL Server 2008

USA (Headquarters)

Reporting Server

SQL Server 2008

Enabling/Partitioning

xyz DB

Europe Server xyz DB SQL Server 2008

Asia Server xyz DB

SQL Server 2008

North America Region

SQL Server 2008

Regionalization

Europe Region

(multiple owners) xyz DB

xyz DB

SQL Server 2008

SQL Server 2008

Primary

xyz DB

Failover

Hot Spare (Fail-over) xyz DB

FIGURE 19.2 Data replication scenarios.

Download from www.wowebook.com

The Publisher, Distributor, and Subscriber Magazine Metaphor

549

As you may notice, you can use data replication for many reasons. Many of these reasons are discussed later in this chapter. First, however, you need to understand some of the common terms and metaphors Microsoft uses in relationship to data replication. They started with the “magazine” concept as the basis of the metaphor. A magazine is created by a publisher, distributed via the mail, and delivered to only those who have a subscription to the magazine. The frequency of the magazine publication can vary, as can the frequency of the subscription (depending on how often the subscriber wants to receive a new magazine). The publication (magazine) consists of one or more articles. One or more articles can be subscribed to.

The Publisher, Distributor, and Subscriber Magazine Metaphor Any SQL Server can play up to three distinct roles in a data replication environment: . Publication server—The publication server (or publisher) contains the database or databases that will be published (the magazine!). This is the source of the data that is to be replicated to other servers. In Figure 19.3, the Customer table (an article in the magazine) in the AdventureWorks2008 database is the data to be published. To publish data, the database that contains the data that will be published must first be enabled for publishing. Full publishing configuration requirements are discussed later in this chapter, in the section “Setting Up Replication.” Customer (Sales) Customer ID Territory ID AccountNumber Customer Type rowguid ModifiedDate

Publisher Customer (Sales)

AdventureWorks

CustomerID

SQL Server

TerritoryID AccountNumber

Distributor

CustomerType

19

rowguid

Subscriber(s)

ModifiedDate

Customer (Sales)

Adventure Works

CustomerID

translog

distribution

SQL Server 2008

SQL Server 2008

TerritoryID AccountNumber CustomerType rowguid ModifiedDate

“Magazine” metaphor AdventureWorks

SQL Server 2008

FIGURE 19.3 The publisher, distributor, and one or more subscribers.

Download from www.wowebook.com

550

CHAPTER 19

Replication

. Distribution server—The distribution server (or distributor) can either be on the same server as the publication server or on a different server (in which case it is a remote distribution server). This server contains the distribution database. This database, also called the store-and-forward database, holds all the data changes that are to be forwarded from the published database to any subscription servers that subscribe to the data. A single distribution server can support several publication servers. The distribution server is truly the workhorse of data replication; it is essentially the mail system that picks up the magazine and delivers it to the subscription holder. . Subscription server—The subscription server (or subscriber) contains a copy of the database or portions of the database being published (for example, the Customer table in the AdventureWorks2008 database). The distribution server sends any changes made to this table (in the published database) to the subscription server’s copy of the Customer table. This is known as store-and-forward. Some data replication configurations send the data to the subscription server, and then the data is readonly. It is also possible for subscribers (known as updating subscribers) to make updates, which are sent back to the publisher. More on this in the Updating Subscribers Replication Model section. There are now new variations of this update subscriber option called peer-to-peer replication. Peer-to-peer allows for more than one publisher of the same data (table) at the same time! Essentially, each publisher is also a subscriber at the same time (hence, peer-to-peer). This chapter provides more information on updating subscribers and peer-to-peer configurations in the “The Updating Subscribers Replication Model” section, later. Along with enabling distinct server roles (publisher, distributor, and subscriber), Microsoft utilizes a few more magazine metaphors, including publications and articles. A publication is a group of one or more articles and is the basic unit of data replication. An article is simply a pointer to a single table, or a subset of rows or columns out of a table, that will be made available for replication.

Publications and Articles A single database can contain more than one publication. You can publish data from tables, from database objects, from the execution of stored procedures, and even from schema objects, such as referential integrity constraints, clustered indexes, nonclustered indexes, user triggers, extended properties, and collation. Regardless of what you plan to replicate, all articles in a publication are synchronized at the same time. Figure 19.4 shows an example of a publication (named Cust_Orders publication) with three articles (three tables from the AdventureWorks2008 database). You can also choose to replicate whole tables or just parts of tables via filtering.

Filtering Articles You can create articles within a publication in several different ways. The basic way to create an article is to publish all the columns and rows contained in a table. Although this is the easiest way to create articles, your business needs might require that you publish only specific columns or certain rows of a table. This is referred to as filtering vertically or

Download from www.wowebook.com

The Publisher, Distributor, and Subscriber Magazine Metaphor

551

Publisher

Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid ModifiedDate

Publication SalesOrderHeader (Sales)

Cust_Orders

SalesOrderID RevisionNumber

Adventure Works

Cust_Orders

translog

SalesOrderHeader (Article)

SQL Server 2008

SalesOrderDetail (Article)

OrderDate DueDate ShipDate Status OnlineOrderFlag SalesOrderNumber PurchaseOrderNumber AccountNumber CustomerID ContactID SalesPersonID TerritoryID BillToAddressID ShipToAddressID ShipMethodID CreditCardID CreditCardApprovalCode CurrencyRateID SubTotal TaxAmt Freight TotalDue

SalesOrderDetail (Sales) SalesOrderID SalesOrderDetailID CarrierTrackingNumber OrderQty ProductID SpecialOfferID UnitPrice UnitPriceDiscount LineTotal rowguid ModifiedDate

Comment rowguid ModifiedDate

FIGURE 19.4 The Cust_Orders publication (in the AdventureWorks2008 database). horizontally. When you filter vertically, you filter only specific columns, whereas with horizontal filtering, you filter only specific rows. In addition, SQL Server 2008 provides the added functionality of join filters and dynamic filters. As Figure 19.5 shows, you might need to replicate only a customer’s CustomerID, TerritoryID, and CustomerType to various subscribing servers around your company. In your company, the other data, such as AccountNumber, may be restricted information that should not be replicated for general use. For that reason, you simply create an article for data replication that contains a subset of the Customer table that will be replicated to these other locations and excludes AccountNumber (and rowguid and ModifiedDate as well).

19

As another example, you might need to publish only the Customer table data for a specific customer type, such as “individual” customers ((CustomerType = ‘I’) or customers that are “stores” (CustomerType = ‘S’). This process, as shown in Figure 19.6, is known as horizontal filtering. It is possible to combine horizontal and vertical filtering, as shown in Figure 19.7. This way, you can weed out unneeded columns and rows that aren’t required for replication (that is, are not needed by the subscribers). For example, you might need only the customers that are stores and need only CustomerID, TerritoryID, and CustomerType data to be published.

Download from www.wowebook.com

552

CHAPTER 19

Replication

Publisher

Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid ModifiedDate

Publication AW_Vertical Adventure Works

CustomerV (Article)

translog

SQL Server 2008

CustomerID

TerritoryID

AccountNumber

CustomerType

ModifiedDate

CustomerID

TerritoryID

CustomerType

1345

1

AW1345

I

X69G9..

1345

1345

1

I

1356

2

AW1356

I

W211G..

rowguid

1356

1356

2

I

2354

1

AW2354

S

7SQ78K..

2354

2354

1

S

3346

2

AW3346

I

W12DV..

3346

3346

2

I

7643

3

AW7643

S

WZ8R4..

7643

7643

3

S

7901

5

AW7901

I

S2345X..

7901

7901

5

I

8921

4

AW8921

I

RT66Y..

8921

8921

4

I

FIGURE 19.5 Vertical filtering creates a subset of columns from a table to be replicated to subscribers.

Publisher

Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid

Publication

ModifiedDate

AW_Horizontal Adventure Works

CustomerH (Article)

translog

SQL Server 2008 CustomerID

TerritoryID

AccountNumber

CustomerType

1345

1

AW1345

I

X69G9..

120203

1356

2

AW1356

I

W211G..

rowguid

ModifiedDate

051605

2354

1

AW2354

S

7SQ78K..

106705

3346

2

AW3346

I

W12DV..

022305

7643

3

AW7643

S

WZ8R4..

122205

7901

5

AW7901

I

S2345X..

041506

8921

4

AW8921

I

RT66Y..

0321206

Only these Rows!

CustomerID

TerritoryID

AccountNumber

CustomerType

rowguid

ModifiedDate

2354

1

AW2354

S

7SQ78K..

106705

7643

3

AW7643

S

WZ8R4..

122205

FIGURE 19.6 Horizontal filtering creates a subset of rows from a table to be replicated to subscribers.

Download from www.wowebook.com

The Publisher, Distributor, and Subscriber Magazine Metaphor

553

Publisher

Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid

Publication

ModifiedDate

AW_H_and_V Adventure Works

CustomerHV (Article)

translog

SQL Server 2008 CustomerID

TerritoryID

AccountNumber

CustomerType

1345

1

AW1345

I

X69G9..

120203

1356

2

AW1356

I

W211G..

051605

2354

1

AW2354

S

7SQ78K..

106705

3346

2

AW3346

I

W12DV..

022305

7643

3

AW7643

S

WZ8R4..

122205

7901

5

AW7901

I

S2345X..

041506

8921

4

AW8921

I

RT66Y..

0321206

rowguid

ModifiedDate

Only these Columns and these Rows!

CustomerID

TerritoryID

CustomerType

2354

1

S

7643

3

S

FIGURE 19.7 Combining horizontal and vertical filtering allows you to pare down the information in an article to only the important information needed by the subscribers.

As mentioned earlier, it is now possible to use join filters. Join filters enable you to use the values of one article (that is, values from a table) to determine what gets replicated from another article (that is, what values can be associated with another table) via a join. In other words, if you are publishing the Customer table data based on the customers that are stores, you can extend filtering (that is, a join filter) to replicate only those orders for these types of customers (as shown in Figure 19.8). This way, you replicate only orders for customers that are stores to a subscriber that needs to see only this filtered data. This type of replication can be efficient if it is done well.

19

You also can publish stored procedure executions, along with their parameters, as articles. This can be either a standard procedure execution article or a serializable procedure execution article. The difference is that the latter is executed as a serializable transaction; the serializable option is recommended because it replicates the procedure execution only if the procedure is executed within the context of a serializable transaction. If that same stored procedure is executed from outside a serializable transaction, changes to data in published tables are replicated as a series of DML statements. In general, replicating stored procedure executions gives you a major reduction in the number of SQL statements being replicated across the network versus standard DML statements.

Download from www.wowebook.com

CHAPTER 19

554

Replication

SalesOrderHeader (Sales) SalesOrderID RevisionNumber OrderDate

AW_H_and_J (Publication)

DueDate ShipDate

Customer (Sales) CustomerID

Status

TerritoryID

OnlineOrderFlag

AccountNumber

SalesOrderNumber

CustomerType

PurchaseOrderNumber

rowguid

AccountNumber

ModifiedDate

CustomerID

CustomerH (Article) OrdersHJ (Article)

ContactID SalesPersonID TerritoryID BillToAddressID ShipToAddressID

CustomerID

TerritoryID

AccountNumber

CustomerType

1345

1

AW1345

I

X69G9..

120203

1356

2

AW1356

I

W211G..

rowguid

051605

2354

1

AW2354

S

7SQ78K..

106705

CustomerID

3346

2

AW3346

I

W12DV..

022305

2354

7643

3

AW7643

S

WZ8R4..

122205

7643

7901

5

AW7901

I

S2345X..

041506

8921

4

AW8921

I

RT66Y..

0321206

ModifiedDate

Only the orders for customer type “S”

join

SalesOrderID

RevisionNumber

OrderDate

DueDate

Status

CustomerID

43659

1

7/1/2001

7/13/2001

5

1345

43660

1

7/1/2001

7/13/2001

5

1356

43661

1

7/1/2001

7/13/2001

5

2354

SalesOrderID

OrderDate

CustomerID

43662

2

7/1/2001

7/13/2001

5

3346

43661

7/1/2001

2354

43663

1

7/1/2001

7/13/2001

5

7643

43663

7/1/2001

7643

43664

1

7/1/2001

7/13/2001

5

7901

43665

1

7/1/2001

7/13/2001

5

8921

FIGURE 19.8 Horizontal and Join publication: Joining customers that are stores (type “S”) to corresponding SalesOrderHeader rows. For instance, if you wanted to update the Customer table for every customer via an UPDATE SQL statement, the resulting Customer table updates would be replicated as a large multistep transaction involving at least 5,000 separate UPDATE statements at a minimum. This number of statements would significantly bog down your network. However, with stored procedure execution articles, only the execution of the stored procedure is replicated to the subscription server, and the stored procedure—not the numerous update statements— is executed on that subscription server. Figure 19.9 illustrates the difference in execution described earlier. Some subtleties when utilizing this type of data replication processing can’t be overlooked, such as making sure the published stored procedure behaves the same on the subscribing server side. Many more data replication terms are presented in this chapter, but it is essential that you first learn about the different types of replication scenarios that can be built and the reasons any of them would be desired over the others. It is also worth noting that Microsoft SQL Server 2008 supports replication to and from many different “heterogeneous” data sources. In other words, OLE DB and ODBC data sources can subscribe to SQL Server publications, and they can receive data replicated from a number of data sources, including Microsoft Exchange, Microsoft Access, Oracle, and DB2.

Download from www.wowebook.com

Replication Scenarios

555

Customer (Sales) CustomerID TerritoryID

Publisher

AccountNumber

Subscriber AdventureWorks (Publication)

CustomerType rowguid

PRC_Cust_Updt (Article)

ModifiedDate

Customers (Article)

Adventure Works translog

SQL Server 2008

Adventure Works distribution

translog

Distributor

SQL Server 2008

is replicated as: UPDATE Customers set AccountNumber=null where CustomerID >=1 and CustomerID GROUP (simple naming is used here to better illustrate the point). The public network name is ClusterPublic, and the internal heartbeat network name is ClusterInternal. This spreadsheet has also been included in the download files on the CD for this book. It’s a good idea to fill out this spreadsheet before you start installing and configuring your servers.

Download from www.wowebook.com

664

CHAPTER 21

SQL Server Clustering

FIGURE 21.5 An Excel spreadsheet for a two-node active/passive SQL Cluster configuration.

The cluster controls the following resources: . Physical disks (Q: is for the quorum disk, S: is for the shared disks, and so on.) . The cluster IP address . The cluster name (network name) . The Distributed Transaction Coordinator (MSDTC) . The SQL Server virtual IP address . The SQL Server virtual name (network name) . SQL Server . SQL Server Agent . The SQL Server Full-Text Search service instance (if installed) After you successfully install, configure, and test your cluster (MSCS), you are ready to add the SQL Server components as resources to be managed by MSCS. This is where the magic

Download from www.wowebook.com

Installing SQL Server Clustering

665

happens. Figure 21.6 shows how the Cluster Administrator should look after you install/configure MSCS. It doesn’t have SQL Server 2008 installed yet.

21

FIGURE 21.6 Windows 2003 Cluster Administrator, showing managed resources prior to installing SQL Server.

Installing SQL Server Clustering When you install SQL Server in a clustered server configuration, you create it as a virtual SQL Server. A virtual SQL Server is not tied to a specific physical server; it is associated with a virtualized SQL Server name that is assigned a separate IP address (not the IP address or name of the physical servers on which it runs). Handling matters this way allows for your applications to be completely abstracted away from the physical server level. Failover clustering has a new workflow for all Setup scenarios in SQL Server 2008. The two options for installation are . Integrated installation—This option creates and configures a single-node SQL Server failover cluster instance. Additional nodes are added by using the Add Node functionality in Setup. For example, for Integrated installation, you run Setup to create a single-node failover cluster. Then you run Setup again for each node you want to add to the cluster. . Advanced/Enterprise installation—This option consists of two steps; the prepare step prepares all nodes of the failover cluster to be operational. Nodes are defined and prepared during this initial step. After you prepare the nodes, the Complete step is run on the active node—the node that owns the shared disk—to complete the failover cluster instance and make it operational. Figure 21.7 shows the same two-node cluster configuration as Figure 21.1, with all the SQL Server components identified. This virtual SQL Server is the only thing the end user will ever see. As you can also see in Figure 21.7, the virtual server name is VSQLSERVER2008, and the SQL Server instance name defaults to blank (you can, of course, give your instance a name). Figure 21.7 also shows the other cluster group resources that will be part of the SQL Server Clustering configuration: MSDTC, SQL Agent, SQL Server Full-Text Search, and the shared disk where the databases will live.

Download from www.wowebook.com

666

CHAPTER 21

SQL Server Clustering

SQL Clustering basic configuration C:

SQL Connections

Local Binaries

Windows 2003 EE

CLUSTER 1 CLUSTER GROUP Resources

SQL Server 2008 (physical)

MS DTC SQL Agent

VSQLSERVER2008

ClusterInternal

SQL Server 2008 (Virtual SQL Server)

S Shared hared

ClusterPublic

SQL Full Text Search

Master DB TempDB Appl 1 DB

Q:

SQL Server 2008 (physical)

Quorum Disk

CLUSTER 2 C:

Windows 2003 EE

Local Binaries

FIGURE 21.7 A basic SQL Server Clustering configuration. SQL Server Agent will be installed as part of the SQL Server installation process, and it is associated with the SQL Server instance it is installed for. The same is true for SQL Server Full-Text Search; it is associated with the particular SQL Server instance that it is installed to work with. The SQL Server installation process completely installs all software on all nodes you designate.

Configuring SQL Server Database Disks Before we go too much further, we need to talk about how you should lay out a SQL Server implementation on the shared disks managed by the cluster. The overall usage intent of a particular SQL Server instance dictates how you might choose to configure your shared disk and how it might be best configured for scalability and availability. In general, RAID 0 is great for storage that doesn’t need fault tolerance; RAID 1 or RAID 10 is great for storage that needs fault tolerance but doesn’t have to sacrifice too much performance (as with most online transaction processing [OLTP] systems); and RAID 5 is great for storage that needs fault tolerance but whose data doesn’t change that much (that is, low data volatility, as in many decision support systems [DSSs]/read-only systems). All this means that there is a time and place to use each of the different fault-tolerant disk configurations. Table 21.1 provides a good rule of thumb to follow for deciding which SQL Server database file types should be placed on which RAID level disk configuration. (This would be true regardless of whether or not the RAID disk array was a part of a SQL Server cluster.)

Download from www.wowebook.com

Installing SQL Server Clustering

667

TABLE 21.1 SQL Server Clustering Disk Fault-Tolerance Recommendations Description

Fault Tolerance

Quorum drive

The quorum drive used with MSCS should be isolated to a drive by itself (often mirrored as well, for maximum availability).

RAID 1 or RAID 10

OLTP SQL Server database files For OLTP systems, the database data/index files should be placed on a RAID 10 disk system.

RAID 10

DSS SQL Server database files For DSSs that are primarily read-only, the database data/index files should be placed on a RAID 5 disk system.

RAID 5

tempdb

RAID 10

This is a highly volatile form of disk I/O (when not able to do all its work in the cache).

21

Device

SQL Server transaction log files The SQL Server transaction log files should RAID 10 or RAID 1 be on their own mirrored volume for both performance and database protection. (For DSSs, this could be RAID 5 also.)

TIP A good practice is to balance database files across disk arrays (that is, controllers). In other words, if you have two (or more) separate shared disk arrays (both RAID 10) available within a cluster group’s resources, you should put the data file of Database 1 on the first cluster group disk resource (for example, DiskRAID10-A) and its transaction log on the second cluster group disk resource (for example, DiskRaid10-B). Then you should put the data file of Database 2 on the second cluster group disk resource of DiskRAID10-B and its transaction log on the first cluster group disk resource of DiskRAID10-A. In this way, you can stagger these allocations and in general balance the overall RAID controller usage, minimizing any potential bottlenecks that might occur on one disk controller. In addition, FILESTREAM filegroups must be put on a shared disk, and FILESTREAM must be enabled on each node in the cluster that will host the FILESTREAM instance. You can also use geographically dispersed cluster nodes, but additional items such as network latency and shared disk support must be verified before you get started. Check the Geographic Cluster hardware Compatibility List (http://msdn.microsoft.com/en-us/library/ms189910.aspx). On Windows 2008, most hardware and ISCSI supported hardware can be used, without the need to use “certified hardware.” When you are creating a cluster on Windows 2008, you can use the cluster validation tool to validate the Windows cluster; it also blocks SQL Server Setup when problems are detected with the Windows 2008 cluster.

Download from www.wowebook.com

668

CHAPTER 21

SQL Server Clustering

Installing Network Interfaces You might want to take a final glance at Cluster Administrator so that you can verify that both CLUSTER1 and CLUSTER2 nodes and their private and public network interfaces are completely specified and their state (status) is up. If you like, you should also doublecheck the IP addresses and network names against the Excel spreadsheet created for this cluster specification.

Installing MSCS As you can see in Figure 21.8, the MSCS “service” is running and has been started by the ClusterAdmin login account for the GOTHAM domain.

FIGURE 21.8 You need to make sure MSCS is running and started by the cluster account for the domain.

NOTE If MSCS is not started and won’t start, you cannot install SQL Server Clustering. You have to remove and then reinstall MSCS from scratch. You should browse the Event Viewer to familiarize yourself with the types of warnings and errors that can appear with MSCS.

Installing SQL Server For SQL Clustering, you must install a new SQL Server instance within a minimum twonode cluster. You should not move a SQL Server instance from a nonclustered configuration to a clustered configuration. If you already have SQL Server installed in a nonclustered environment, you need to make all the necessary backups (or detach databases) first, and then you need to uninstall the nonclustered SQL Server instance. Some

Download from www.wowebook.com

Installing SQL Server Clustering

669

21

upgrade paths and migration paths are possible from prior versions of SQL Server and Windows server. You are also limited to a maximum of 25 instances of SQL Server per failover cluster. There is no uninstall SQL Server failover cluster option; you must run Setup from the node that is to be removed. You must specify the same product key on all the nodes that you are preparing for the same failover cluster. You also should make sure you use the same SQL Server instance ID for all the nodes that are prepared for the failover cluster. With all MSCS resources running and in the online state, you run the SQL Server Setup program from the node that is online (for example, CLUSTER1). You are asked to install all software components required prior to installing SQL Server (.NET Framework 3.0 or 3.5, Microsoft SQL Native Client, and the Microsoft SQL Server 2008 Setup support files). SQL Server integrated failover cluster installation consists of the following steps: 1. Create and configure a single-node SQL Server failover cluster instance. When you configure the node successfully, you have a fully functional failover cluster instance. At this point, it does not have high availability because there is only one node in the failover cluster. 2. On each node to be added to the SQL Server failover cluster, run Setup with Add Node functionality to add that node. Alternatively, you can use the following SQL Server Advanced/Enterprise failover cluster installation: 1. On each node that will be an owner of the new SQL Server failover cluster, follow the Prepare Failover Cluster setup steps listed in the Prepare section. After you run the Prepare Failover Cluster on one node, Setup creates the Configuration.ini file, which lists all the settings you specified. On the additional nodes to be prepared, instead of following these steps, you can supply the Configuration.ini file from first node as an input to the Setup command line. This step prepares the nodes ready to be clustered, but there is no operational instance of SQL Server at the end of this step. 2. After the nodes are prepared for clustering, run Setup on one of the prepared nodes, preferably on the node that owns the shared disk that has the Complete Failover Cluster functionality. This step configures and finishes the failover cluster instance. After completing this step, you have an operational SQL Server failover cluster instance. and all the nodes prepared previously for that instance are the possible owners of the newly created SQL Server failover cluster. After you take these steps, the standard Welcome to SQL Server Installation Center Wizard begins. It starts with a System Configuration check of the node in the cluster (CLUSTER1). Figure 21.9 shows the SQL Server Installation Center launch dialog and the results of a successful system check for CLUSTER1.

Download from www.wowebook.com

670

CHAPTER 21

SQL Server Clustering

FIGURE 21.9 A Microsoft SQL Server Setup Support Rules check.

NOTE SQL Server Clustering is available with SQL Server 2008 Standard Edition, Enterprise Edition, and Developer Edition. However, Standard Edition supports only a two-node cluster. If you want to configure a cluster with more than two nodes, you need to upgrade to SQL Server 2008 Enterprise Edition.

If this check fails (warnings are acceptable), you must resolve them before you continue. If the check is successful, you are then prompted for the checklist of features you want to install. Figure 21.10 shows the Feature Selection to install dialog. You then see the Instance Configuration dialog, as shown in Figure 21.11, where you specify the network name for the new SQL Server failover cluster (the Virtual Server name, VSQLSERVER2008 in this example) and then either can use the default SQL Server instance name (no name) or specify a unique SQL Server instance name (we chose to use the default instance name of MSSQLSERVER). This virtual SQL Server name is the name the client applications will see (and to which they will connect). When an application attempts to connect to an instance of SQL Server 2008 that is running on a failover cluster, the application must specify both the virtual server name and instance name (if an instance name was used), such as VSQLSERVER2008\VSQLSRV1 (virtual server name\SQL Server instance name) or VSQLSERVER2008 (just the virtual server name without the default SQL Server instance

Download from www.wowebook.com

Installing SQL Server Clustering

671

21

FIGURE 21.10 The SQL Server Setup Feature Selection dialog for a SQL Server Failover Cluster.

FIGURE 21.11 Specifying the virtual server name (VSQLSERVER2008) and default instance.

Download from www.wowebook.com

672

CHAPTER 21

SQL Server Clustering

name). The virtual server name must be unique on the network. You also specify the local directory locations (root) for the installation.

NOTE A good naming convention to follow is to preface all virtual SQL Server names and virtual SQL Server instance names with a V. This way, you can easily identify which SQL Server machines on your network are clustered. For example, you could use VSQLSERVER2008 as a virtual SQL Server name and VSQLSRV1 as an instance name.

Next comes the disk space requirements dialog, followed by the Cluster Resource Group specification. This is where the SQL Server resources are placed within MSCS. Here, you use the existing resource cluster group (named Cluster Group). Immediately following the resource group assignment comes the identification of which clustered disks are to be used via the Cluster Disk Selection dialog, shown in Figure 21.12. It contains an S: drive (which you want SQL Server to use) and Q: and R: drive being used for the quorum files (do not select this drive!). You simply select the available drive(s) where you want to put your SQL database files (the S: drive in this example). As you can also see, the only “qualified” disk is the S: drive. If the quorum resource is in the cluster group you have selected, a warning message is issued, informing you of this fact. A general rule of thumb is to isolate the quorum resource to a separate cluster group.

FIGURE 21.12 Cluster resource group specification and Cluster Disk Selection.

Download from www.wowebook.com

Installing SQL Server Clustering

673

21

The next thing you need to do for this new virtual server specification is to identify an IP address and which network it should use. As you can see in the Cluster Network Configuration dialog, shown in Figure 21.13, you simply type in the IP address (for example, 192.168.3.110) that is to be the IP address for this virtual SQL Server for the available networks known to this cluster configuration (in this example, it is for the ClusterPublic network). If the IP address being specified is already in use, an error occurs.

FIGURE 21.13 Specifying the virtual SQL Server IP address and which network to use.

NOTE Keep in mind that you are using a separate IP address for the virtual SQL Server that is completely different from the cluster IP addresses. In a nonclustered installation of SQL Server, the server can be referenced using the machine’s IP address. In a clustered configuration, you do not use the IP addresses of the servers themselves; instead, you use this separately assigned IP address for the “virtual” SQL Server.

Figure 21.14 shows the next step in identifying the Cluster Security Policy for each SQL Server component (Database Engine, SQL Server Agent, and Analysis Services). Here, you use the domain Admin group. Figure 21.14 also shows the Server Configuration “service accounts” to use for all the services within this SQL Server install. You use a ClusterAdmin account set up for this purpose. Remember, this account must have administrator rights within the domain and on each server (that is, it must be a member of the Administrators local group on any node in the cluster). This is followed by the Database Engine Configuration dialog, where you set what type of authentication mode to use, the data

Download from www.wowebook.com

674

CHAPTER 21

SQL Server Clustering

directories for the root and subfolders, and the FILESTREAM options. Needless to say, the Data root directory is on the S: drive.

FIGURE 21.14 Specifying Cluster Security Policy, Server Config and Database Engine Config. You then are prompted through the Analysis Services Configuration and Reporting Services Configuration dialogs. Your Analysis Services Data directories are within a subfolder of S:\OLAP\. At this point, you have worked your way down to the Cluster Installation Rules check to determine if everything specified to this point is correct. Figure 21.15 shows this rules check “passing” status, a summary of what is about to be done, and the location of the configuration file (and path) that can be used later if you are doing command-line installs of new nodes in the cluster. A box appears around this configuration file path location at the bottom right of the Ready to Install dialog to show you where it is being created (if needed). The next step is to click on the Install button. The setup process installs SQL Server binaries locally on each node in the cluster (that is, in C:\Program Files\Microsoft SQL Server). The database files for the master, model, tempdb, and msdb databases are placed on the S: drive in this example. This is the shared disk location that must be available to all nodes in the SQL Server cluster. When the process is complete, you can pop over into the Cluster Administrator and see all the resources just installed within the failover cluster. This is not highly available yet because you have completed only one node of the two-node failover cluster. But, as you

Download from www.wowebook.com

Installing SQL Server Clustering

675

21

FIGURE 21.15 Cluster Installation Rules check and Ready to Install dialog. can see in Figure 21.16, the SQL Server components have been successfully installed and are usable within the cluster. Adding the next node (and any more subsequent nodes) to the cluster will make this configuration highly available because you will have other nodes to fail over to. To install the second node, you must now start back over that the Setup process (using SQL Server Installation Center). But this time, you can choose the Add Node to a SQL Server Failover Cluster option, as shown in Figure 21.17. Just as before, the Setup Support Rules check occurs for the next cluster node (CLUSTER2, in this example). As you can also see, adding a node is much simpler (many fewer steps) than creating a completely new SQL Server failover cluster installation. If all items have passed on the new node, you come to the Cluster Node Configuration dialog, as shown in Figure 21.18. Here, you can see that the name of this node (CLUSTER2) is being associated with(added to) the original cluster node (CLUSTER1). This is truly where the magic occurs. You are then prompted to specify the service accounts and collation configuration of this second node. Again, you should specify the domain account that was specified in the first cluster configuration setup (ClusterAdmin in this example). Now you are ready to verify that the rules for adding this node are being followed. If any check doesn’t pass, you must correct it before the node can be added. Figure 21.19 shows this Add Node Rules check along with the summary of all the features to be installed as part of the add node operation. Again, click the Install button to install the SQL Server features and add this node to the cluster.

Download from www.wowebook.com

676

CHAPTER 21

SQL Server Clustering

FIGURE 21.16 SQL Server Failover Cluster Node 1 install complete and within the Cluster Administrator.

FIGURE 21.17 Adding a node to a SQL Server failover cluster and doing a Setup Support Rules check for the new cluster node.

Download from www.wowebook.com

Installing SQL Server Clustering

677

21

FIGURE 21.18 Specifying the cluster node configuration and the service accounts for the second node.

FIGURE 21.19 Cluster Installation Rules check and Ready to Install second node.

Download from www.wowebook.com

678

CHAPTER 21

SQL Server Clustering

You must specify what type of authentication mode you want for SQL Server access: Windows Authentication (only) or mixed mode (Windows Authentication and SQL Server Authentication). For this example, you should choose the mixed mode option and provide a password for the sa SQL Server administration login. Finally, you must specify the collation settings used for sorting order and compatibility with previous versions of SQL Server. The SQL Setup program now has enough information to do the complete installation of the new node in the SQL Server cluster. Figure 21.20 shows the installation of the new SQL Server Failover Cluster node is complete. In particular, binaries are being installed locally, additional services are being created on the second node for SQL Server, and SQL resources are being associated to both cluster nodes.

FIGURE 21.20 Second node installed (Complete) and the Cluster Administrator showing both nodes up. As you can also see in Figure 21.20, Cluster Administrator shows the online resources within the cluster group and that both clusters are up and all resources are online (but controlled by CLUSTER1 now). Following are the SQL Server resource entries: . The SQL Server virtual IP address . The SQL Server network name . SQL Server (MSSQLSERVER)

Download from www.wowebook.com

Installing SQL Server Clustering

679

. SQL Server Agent (for the instance)

21

. Analysis Services . Disk S: (physical disks where the DBs reside) . MSDTC Each resource entry should say Online in the State column and be owned by the same node (CLUSTER1 in this example). In the Cluster Administrator, you can easily view the properties of each of the new SQL Server resources by right-clicking a resource and selecting Properties. Figure 21.21 shows the properties of the Networks and Network Interface IP Address resources.

FIGURE 21.21 Properties of the Networks and Network Interfaces. When you right-click a resource entry in the Cluster Administrator, you have an option to take the resource offline or to initiate a failure. You sometimes need to do this when you’re trying to fix or test a SQL Server Clustering configuration. However, when you’re initiating full SQL Server failover to another node (for example, from CLUSTER1 to CLUSTER2), you typically use the Move Group cluster group technique because you want all the resources for the cluster group to fail over—not just one specific resource. Figure 21.22 shows that you simply right-click the Cluster Group item entry and select Move Group. All resources then fail over to CLUSTER2.

Failure of a Node As you can see in Figure 21.23, one of the nodes in the SQL Server cluster (CLUSTER1) has failed, and MSCS is in the middle of failing over to the other node in the cluster (CLUSTER2). As you can also see, the CLUSTER2 node item group has an hourglass on it, indicating that an MSCS operation is under way. The states of the resources on CLUSTER2

Download from www.wowebook.com

680

CHAPTER 21

SQL Server Clustering

are mostly Online Pending. In other words, these resources are in the middle of failing over to this node. As they come up successfully, Online Pending turns to Online.

FIGURE 21.22 Using Move Group to fail over to another node in a cluster.

FIGURE 21.23 Failing over from CLUSTER1 to CLUSTER2, Online Pending state.

In addition, the failure of a node (for any reason) is also written to the System event log. This example showed an intentional failure of the SQL Server instance via the Cluster Administrator. SQL Server Failover Clustering does the right thing by failing over to the

Download from www.wowebook.com

Installing SQL Server Clustering

681

21

other node. This serves to verify that SQL Server Clustering is working properly. The next section illustrates what this effect has on a typical client application point of view, using a custom client test program called Connection Test Program. Congratulations! You are now up and running, with your SQL Server Failover Cluster intact and should now be able to start achieving significantly higher availability for your end users. You ca easily register this new virtual SQL Server (VSQLSERVER2008) within SQL Server Management Studio (SSMS) and completely manage it as you would any other SQL Server instance.

The Connection Test Program for a SQL Server Cluster To help in visualizing exactly what effect a SQL Server failure and subsequent failover may have on an end-user application, we have created a small test program using Visual Studio 2008. This small C# test program accesses the AdventureWorks2008 database available for SQL Server 2008 (see the Introduction chapter for information on how to download and install the AdventureWorks2008 sample database), and it was created in about 10 minutes. It displays a few columns of data, along with a couple system variables that show connection information, including the following: . ProductID, Name, and ProductNumber—This is a simple three-column display of data from the Product table in the AdventureWorks2008 database. . SHOWDATETIME—This shows the date and time (to the millisecond) of the data access being executed. . SERVERNAME—This is the SQL Server name that the client is connected to. . SPID—This is the SQL Server process ID (SPID) that reflects the connection ID to SQL Server itself by the client application. This type of small program is useful because it always connects to the virtual SQL Server. This enables you to see what effect a failover would have with your client applications. To populate this display grid, you execute the following SQL statement: SELECT ProductID, Name, ProductNumber, CONVERT (varchar(32), GETDATE(), 9) AS SHOWDATETIME, @@SERVERNAME AS SERVERNAME, @@SPID AS SPID FROM Production.Product WHERE (ProductID LIKE ‘32%’)

You use Visual Studio 2008 to set up a simple Windows form like the one shown in Figure 21.24. You build a simple button that will retrieve the data from the SQL Server database on the virtual server and also show the date, time, server name, and SPID information for each access invocation.

Download from www.wowebook.com

682

CHAPTER 21

SQL Server Clustering

FIGURE 21.24 Visual Studio 2008 Windows form and data adapters needed for the test client C# program.

The Visual Studio 2008 project files for the Connection Test Program are available on the CD included with this book. The program, called WindowsApplication4.sln SQLClientTest4 Visual Studio 2008 project, is zipped up in a file named SQL Client SQL Clustering test program .zip. If you want to install this program, you just unzip the SQLClientTest.zip file and locate the WindowsApplication4.sln solution file. You open this from your Visual Studio 2008 start page. Then you rebuild and deploy it after you have modified the connection string of the dataset adapter. After deploying this simple test program, you simply execute it from anywhere on your network. As you can see in the App.config XML file for this application, shown here, the connection string references the VSQLSERVER2008 virtual server name only:

Download from www.wowebook.com

Installing SQL Server Clustering

683

21

Figure 21.25 shows the first execution of the Connection Test Program. If you click the Retrieve button, the program updates the data grid with a new data access to the virtual SQL Server machine, shows the name of the server that the client program is connecting to (SERVERNAME), shows the date and time information of the data access (in the SHOWDATETIME column), and displays the SQL SPID that it is using for the data access (in the SPID column). You are now executing a typical C# program against the virtual SQL Server. Note that the SPID value is 55; this represents the SQL connection to the virtual SQL Server machine servicing the data request.

FIGURE 21.25 Executing the Connection Test Program with current connection information.

Now let’s look at how this high-availability approach works from the client application point of view. To simulate the failure of the active node, you simply turn off the machine (CLUSTER1 in this case). This is the best (and most severe) test case of all. Or, if you like, you can use the Cluster Administrator Move group approach shown earlier. After you simulate this failure, you click the Retrieve button in the Connection Test Program again, and an unhandled exception occurs (see Figure 21.26). You can view the details of the error message, choose to quit the application, or choose to continue. You should click Continue for now.

FIGURE 21.26 An unhandled exception has occurred; it is a transport-level error (that is, a TCP provider error).

Download from www.wowebook.com

684

CHAPTER 21

SQL Server Clustering

What has happened is that the application can no longer connect to the failed SQL Server (because you turned off CLUSTER1), and it is still in the middle of failing over to CLUSTER2 in the two-node cluster. A failover occurs in a short amount of time; the actual amount of time varies, depending on the power and speed of the servers implemented and the number of in-flight transactions that need to be rolled back or forward at the time of the failure. (A complete SQL failover often occurs in about 15 to 45 seconds. This is very minor and well within most service-level agreements and high-availability goals.) You then simply click the Retrieve button again in the Connection Test Program, and you are talking to SQL Server again, but now to CLUSTER2. As you can see in Figure 21.27, the data connection has returned the customer data, SHOWDATETIME has been updated, and SERVERNAME still shows the same virtual SQL Server name that the application needs to connect to, but the SPID has changed from 55 to 52. This is due to the new connection of the Connection Test Program to the newly owned (failed-over) SQL Server machine. The Connection Test Program has simply connected to the newly started SQL Server instance on CLUSTER2. The unhandled exception (error) goes away, and the end user never knows a complete failover occurred; the user simply keeps processing as usual.

FIGURE 21.27 Executing the Connection Test Program again against the failed-over cluster node.

NOTE You could program better error handling that would not show the “unhandled exception” error. You might want to display a simple error message, such as “database momentarily unavailable—please try again,” which would be much more user friendly.

Potential Problems to Watch Out for with SQL Server Clustering Many potential problems can arise during setup and configuration of SQL Server Clustering. Following are some items you should watch out for: . SQL Server service accounts and passwords should be kept the same on all nodes, or a node will not be able to restart a SQL Server service. You can use administrator or

Download from www.wowebook.com

Summary

685

a designated account (for example, Cluster or ClusterAdmin) that has administrator rights within the domain and on each server.

21

. Drive letters for the cluster disks must be the same on all nodes (servers). Otherwise, you might not be able to access a clustered disk. . You might have to create an alternative method to connect to SQL Server if the network name is offline and you cannot connect using TCP/IP. You can use named pipes, specified as \\.\pipe\$$\SQLA\sql\query. . It is likely that you will run into trouble getting MSCS to install due to hardware incompatibility. Be sure to check Microsoft’s Hardware Compatibility List before you venture into this installation.

Summary Building out your company’s infrastructure with clustering technology at the heart is a huge step toward achieving five-nines reliability. If you do this, every application, system component, or database you deploy on this architecture has that added element of resilience. And, in many cases, the application or system component changes needed to take advantage of these clustering technologies are completely transparent. Utilizing a combination of NLB and MSCS allows you not only to fail over applications but to scale for increasing network capacity. The two-node, active/passive node is one of the most common SQL Server Clustering configurations used. As you become more familiar with SQL Server Clustering and your high-availability requirements get closer to five-nines), you might need to put in place other, more advanced configurations, such as four-node SQL Server clusters and/or datacenter-class clusters (of up to eight-node SQL Server clusters and active/active variations). If you follow the basic guidelines of disk configurations and database allocations across these disk configurations, as described in this chapter, you can guarantee a certain level of stability, performance, and scalability. SQL Server Clustering is one of the best, most cost-effective solutions, and it is literally “out of the box” with SQL Server and the Windows family of servers. Remember that SQL Server 2008 supports other concepts related to high availability, such as data replication, log shipping (soon to be deprecated), and database mirroring. You might use these solutions rather than SQL Server Clustering, depending on your requirements. Clustering is a very complex subject. The information contained in this chapter is sufficient to start you in this area, but for a much more complete and thorough understanding of how to assess your high-availability needs, to evaluate what you should build for high availability, and to implement a high-availability platform that uses MSCS and SQL Server Clustering, you should find a copy of Microsoft SQL Server High Availability by Paul Bertucci (Sams Publishing). This book is loaded with full explanations, a formal approach to achieving five-nines reliability, and numerous live examples. Chapter 22, “Administering Policy-Based Management,” explains how to affectively administer servers using the Declarative Management Framework.

Download from www.wowebook.com

This page intentionally left blank

Download from www.wowebook.com

CHAPTER

22

Administering PolicyBased Management

IN THIS CHAPTER . Introduction to Policy-Based Management . Policy-Based Management Concepts . Implementing Policy-Based Management

Policy-Based Management is one of the new management features introduced in SQL Server 2008. Policy-Based Management enables an organization to define policies to manage one or more SQL Server instances, databases, or objects within the enterprise. In addition, policies can be evaluated against target systems to ensure that the standard configuration settings are not out of compliance. PolicyBased Management was developed in response to the following industry trends:

. Sample Templates and RealWorld Examples . Policy-Based Management Best Practices

. Increasing amounts of data being stored . Data center consolidation and virtualization . Growing product capabilities . Proliferation of SQL Server systems within the enterprise . Need for a way to manage SQL Server settings from a holistic perspective . Regulatory compliance demanding secure and standardized settings

Introduction to Policy-Based Management A data explosion has been occurring over the past several years. In a 2006 study, International Data Corporation (IDC; http://www.idc.com) reported that 5 exabytes of digital media (5 billion gigabytes) were stored in 2003, and in 2006 this had ballooned to 161 exabytes. Not only is more data

Download from www.wowebook.com

688

CHAPTER 22

Administering Policy-Based Management

being stored, but users are accessing more data than before. Part of this data growth is a result of the need for business intelligence (BI) systems to deliver actionable insights becoming more critical in the enterprise. Obtaining these insights requires large data volumes for trending and forecasting. As a result, data warehouses are becoming more critical in every enterprise. This data explosion frequently results in a proliferation of SQL Servers. Essentially, DBAs are being required to do more, frequently with less. In addition, the increasing complexities of the SQL Server product set are forcing DBAs to focus on efficient, scalable management and standardization. Due to the large numbers of SQL Servers involved, management by automation becomes critical as well to lessen the administrative burden. Monitoring also becomes more important to provide proactive support. A well-managed SQL Server enterprise that follows best practices offers the following advantages: . Standardization—Every SQL Server will have a common disk layout and settings, as well as consistent naming standards. As a result, DBAs moving from one SQL Server to another will not be surprised by different disk layouts or unusual settings that could account for a performance problem. . Best practices—Microsoft internal studies have shown that 80% of the support calls to their Customer Service and Support (CSS) could have been avoided if the customer had been following best practices. Best practices not only offer performance advantages but also lead to fewer failure events caused by poorly configured SQL Servers, and security breaches due to SQL Servers that have not been hardened (security holes not locked down). . Ease of deployment—A well-managed data center will have automated procedures for building SQL Servers (that is, unattended installations using configuration files) that require less time to build and minimal administrative interaction, resulting in fewer mistakes in a build and a reduction in administrative tasks. . Regulatory compliance—By maintaining controlled and standardized settings, organizations can easily adhere to the demanding requirements of regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA), and Payment Card Industry (PCI) standards. The intent of Policy-Based Management is to provide a management framework that allows DBAs to automate management in their enterprise according to their own set of predefined standards. By implementing Policy-Based Management within a SQL Server infrastructure, organizations can reap the following benefits: total cost of ownership associated with managing SQL Server systems will be reduced, configuration changes to the SQL Server system can be monitored, unwanted system configuration changes can be prevented, and policies will ensure compliance. The stated goals of Policy-Based Management fall into three categories: . Management by intent—Allows DBAs to enforce standards and best practices from the start rather than in response to a performance problem or failure event

Download from www.wowebook.com

Policy-Based Management Concepts

689

. Intelligent monitoring—Allows DBAs to detect changes that have been made to their SQL Server environments that deviate from the desired configuration . Virtualized management—Provides a scalable framework that allows for management across the enterprise

22

Microsoft SQL Server 2008 and SQL Server 2008 R2 also ship with several predefined policies. These policies are not automatically imported into a default installation of SQL Server 2008. However, you can manually import them into SQL Server and use them as is or as a foundation for defining your own similar policies. These sample policies can be found in C:\Program Files\Microsoft SQL Server\100\Tools\Policies\DatabaseEngine\1033. Note that there are also policies for Reporting Services and Analysis Services, which can be found in the ReportingServices and AnalysisServices subdirectories of the Policies directory. Also note that Policy-Based Management can be used to manage SQL 2005 and 2000 servers.

NOTE Microsoft has a blog focusing on Policy-Based Management (http://blogs.msdn.com/ sqlpbm/) where it publishes scripts that can be used to enforce Microsoft best practices for SQL Server, as well as tips, tricks, and tutorials for using Policy-Based Management.

Policy-Based Management Concepts Before we start learning about enforcing Policy-Based Management, there are a few key concepts DBAs must understand. These concepts include . Facets . Conditions . Policies . Categories . Targets . Execution mode . Central Management Servers

Facets A facet is a logical grouping of predefined SQL Server 2008 configuration settings. When a facet is coupled with a condition, a policy is formed and can be applied to one or more SQL Server instances and systems. Common facets include Surface Area Configuration, Server Audit, Database File, and Databases. Table 22.1 illustrates the complete list of predefined facets that can be selected, along with an indication of how each facet can be automated. Check On Schedule uses a SQL Server Agent job to evaluate a policy. Check On

Download from www.wowebook.com

690

CHAPTER 22

Administering Policy-Based Management

Change uses event notification to evaluate based on when changes occur. Facets are included with SQL Server 2008 and cannot be modified.

TABLE 22.1 Facets for Policy-Based Management

Facet Name

Check on Change: Prevent

Check on Change: Log

Check on Schedule

Application Role

X

X

X

Asymmetric Key

X

X

X

Audit

X

Backup Device

X

Broker Priority

X

Broker Service

X

Certificate

X

Credential

X

Cryptographic Provider

X

Data File

X

Database

X

Database Audit Specification

X

Database DDL Trigger

X

Database Maintenance

X

Database Option

X

Database Performance Database Role

X X

X

X

X

Database Security

X

Default

X

Endpoint

X

X

X

File Group

X

Full Text Catalog

X

Full Text Index

X

Full Text Stop List

X

Index

X

Download from www.wowebook.com

Policy-Based Management Concepts

691

TABLE 22.1 Facets for Policy-Based Management

Facet Name

Check on Change: Prevent

Check on Change: Log

Check on Schedule X

Log File

X

Login

X

Login Options

X

X

Message Type Multipart Name

X X

X

X

X

Name

X

Partition Function

X

Partition Scheme

X

Plan Guide

X

Remote Service Binding

X

Resource Governor

X

Resource Pool

X

X

Rule Schema

X X

X

X

X

Server

X

Server Audit

X

Server Audit Specification

X

Server Configuration

22

Linked Server

X

X

Server DDL Trigger

X

Server Information

X

Server Performance

X

Server Security

X

Server Settings

X

Server Setup

X

Service Contract

X

Service Queue

X

Download from www.wowebook.com

692

CHAPTER 22

Administering Policy-Based Management

TABLE 22.1 Facets for Policy-Based Management

Facet Name

Check on Change: Prevent

Check on Change: Log

Check on Schedule

Service Route

X

Statistic

X

Stored Procedure

X

Surface Area

X

X

X

X

Surface Area for AS Surface Area for RS Symmetric Key

X

Synonym

X

Table

X

Table Options

X

X

X

Trigger

X

User

X

User Defined Aggregate

X

User Defined Data Type

X

User Defined Function

X

X

X

User Defined Table Type

X

User Defined Type

X

User Options

X

X

View

X X

View Options

X

X

X

Workload Group

X

X

X

Xml Schema Collection

X

The complete list of facets can be viewed in SQL Server 2008 Management Studio by expanding the Management folder, the Policy-Based Management node, and then the Facets folder. Alternatively, to view facets applied to a specific database, you can rightclick the database and select Facets.

Download from www.wowebook.com

Policy-Based Management Concepts

693

NOTE Currently, there are 74 facets available for use. Going forward, Microsoft will undoubtedly create more facets, which will be included with upcoming service packs.

A condition is a Boolean expression that dictates an outcome or desired state of a specific management condition, also known as a facet. Condition settings are based on properties, comparative operators, and values such as String, equal, not equal, LIKE, NOT LIKE, IN, or NOT IN. For example, a check condition could verify that data and log files reside on separate drives, that the state of the database recovery model is set to Full Recovery, that database file sizes are not larger than a predefined value, and that database mail is disabled.

22

Conditions

Policies A policy is a standard for a single setting of an object. It ultimately acts as a verification mechanism of one or more conditions of the required state of SQL Server targets. Typical scenarios for creating policies include imposing Surface Area Configuration settings, enforcing naming conventions on database objects, enforcing database and transaction log placement, and controlling recovery models. As mentioned earlier, a tremendous number of policies can be created against SQL Server 2008 systems. Surface Area Configurations are a very common policy, especially because the SQL Server 2005 Surface Area Configuration tool has been deprecated in SQL Server 2008.

NOTE A policy can contain only one condition and can be either enabled or disabled.

Categories Microsoft recognized that although you may want to implement a set of rigid standards for your internal SQL Server development or deployments, your enterprise may have to host third-party software that does not follow your standards. Although your internally developed user databases will subscribe to your own policies, the third-party user applications will subscribe to their own categories. To provide flexibility, you can select which policies you want a table, database, or server to subscribe to and group them into groups called categories, and then have a database subscribe to a category and unsubscribe from a group of other policies if necessary. A policy can belong to only one policy category.

Targets A target is one or more SQL Server instances, databases, or database objects that you want to apply your categories or policies to. Targets can be only SQL Server 2008 R2, 2008, 2005, or 2000 systems. All targets in a server instance form a target hierarchy. A target set is the set of targets that results from applying a set of target filters to the target hierarchy—for example, all the tables in a database contained in a specific schema.

Download from www.wowebook.com

694

CHAPTER 22

Administering Policy-Based Management

Execution Modes When you are implementing policies, there are three types of execution modes. The On Change mode has two variations: . On Demand—The On Demand policy ensures that a target or targets are in compliance. This task is invoked manually by right-clicking on the policy in the Management folder, Policy Management folder, Policy folder, and selecting Evaluate. The policy is not enforced and is only verified against all targets that have been subscribed to that policy. You can evaluate a policy also by right-clicking on the database and selecting Policies and Evaluate. . On Schedule—Policies can be evaluated on a schedule. For example, a policy can be scheduled to check all SQL Server 2008 systems once a day. If any anomalies arise, these out-of-compliance policies are logged to a file. This file should be reviewed on a periodic basis. In addition, whenever a policy fails, the complete tree in SQL Server Management Studio displays a downward-pointing arrow next to the policy, as shown in Figure 22.1.

FIGURE 22.1 SQL Server management tree illustrating failed policies for table name.

. On Change Prevent—The On Change Prevent execution mode prevents changes to server, server object, database, or database objects that would make them out of

Download from www.wowebook.com

Policy-Based Management Concepts

695

compliance. For example, if you select a policy that restricts table names to only those that begin with the prefix tbl, and you attempt to create a table called MyTable, you get the following error message, and your table is not be created:

22

Policy ‘table name’ has been violated by ‘/Server/(local)/Database/iFTS/Table/dbo.mytable’. This transaction will be rolled back. Policy description: ‘’ Additional help: ‘’ : ‘’. Msg 3609, Level 16, State 1, Procedure sp_syspolicy_ dispatch_event, Line 50 The transaction ended in the trigger. The batch has been aborted.

. On Change Log Only—If you select On Change Log Only, a policy condition that is evaluated as failed is logged in the SQL Server Error log. The change does not prevent out-of-compliance changes.

Central Management Servers In large enterprises, organizations most likely have more than one SQL Server system they want to effectively manage from a Policy-Based Management perspective. Therefore, if DBAs want to implement policies to multiple servers, they have two options. The first option includes exporting the policy and then importing it into different SQL Server systems. After the policy is imported, it must be configured to be evaluated on demand, on schedule, or on change. The second option includes creating one or more Central Management Servers in SQL Server 2008. Basically, by registering one or more SQL Servers with a Central Management Server, a DBA can deploy multiserver policies and administration from a central system. For example, you could create two Central Management Servers, one called OLAP and another called OLTP, and then register servers into each Central Management Server, import the different policies into each Central Management Server, and then evaluate the polices on each different Central Management Server. So, on your OLTP Central Management Server, the servers OLTP1, OLTP2, OLTP3, which are registered in the OLTP Central Management Server, would have the OLTP policies evaluated on them.

Creating a Central Management Server Follow these steps to register a Central Management Server: 1. In SQL Server Management Studio, open the View menu and click Registered Servers. 2. In Registered Servers, expand the Database Engine node, right-click Central Management Servers, and then select Register Central Management Server.

Download from www.wowebook.com

696

CHAPTER 22

Administering Policy-Based Management

3. In the New Server Registration dialog, specify the name of the desired Central Management Server. 4. If necessary, specify additional connection properties on the Connection Properties tab or click Save.

Registering SQL Server Instances in a Central Management Server The next task registers SQL Server instances to be associated with a Central Management Server. The following steps outline this task: 1. Right-click on the Central Management Server with which you want to associate your SQL Server instance. 2. Select New Server Registration. 3. In the New Server Registration dialog, specify the name of the SQL Server Instance and the proper connection information and click Save 4. Repeat steps 1-3 for all SQL Server instances that you want to register with this Central Management Server. Figure 22.2 illustrates a Central Management Server with one Server Group and two SQL Server instances registered.

FIGURE 22.2 Central Management Server with Registered SQL Server instances.

Importing and Evaluating Polices to the Central Management Server After the Central Management Server is established, the Server Group is created, and the desired SQL Server instances are registered, it is time to import and evaluate policies. You can import policies for multiple instances by right-clicking the Central Management Server or Server Group and selecting Import Policies. After the policies are imported, the next step is to evaluate the policies by right-clicking the Central Management Server or Server

Download from www.wowebook.com

Implementing Policy-Based Management

697

Group and selecting Evaluate. The output indicates the status of policies associated with all the SQL Server instances associated with the Central Management Server or Server Group.

NOTE

22

Importing, exporting, and evaluating policies are covered throughout the rest of the chapter.

Implementing Policy-Based Management Now that you understand the basic purpose and concepts behind Policy Based Management, let’s look at how to administer Policy-Based Management, then how to apply it to a server, and then a group of servers. There are essentially six steps to implementing and administering Policy-Based Management: . Creating a condition based on a facet . Creating a policy based on that condition . Creating a category . Creating a Central Management Server . Subscribing to a category . Exporting or importing a policy Let’s look at each of these steps in turn. The upcoming sections explain each step in its entirety.

Creating a Condition Based on a Facet When you are creating conditions, the general principle includes three elements: selecting a property, an operator, and then a value. The following example walks through the steps to create a condition based on a facet which will enforce a naming standard on a table: 1. To create a condition, connect to a SQL Server 2008 instance on which you want to create a policy. 2. Launch SQL Server Management Studio (SSMS). In Object Explorer, expand the Management folder, expand the Policy Management folder, and then expand the Facets folder. 3. Within the Facets folder, browse to the desired facet on which you want to create the policy (in this case, the Table facet).

Download from www.wowebook.com

698

CHAPTER 22

Administering Policy-Based Management

4. To invoke the Create New Condition window, right-click the facet and select New Condition. 5. In the Create New Condition dialog, type a name for the condition (for example, Table Name Convention) and ensure that the facet selected is correct. 6. In the Expression section, perform the following tasks: a. Select the property on which you want to create your condition. For this example, use the @Name property. b. In the Operator drop-down box, select the NOT LIKE operator. c. In the value text box, enter ’tbl%’. 7. Repeat step 6 for any additional expressions. For this example, the following expressions were entered, as displayed in Figure 22.3. AndOr

Field

Operator

Value

@Name

NOT LIKE

’tbl%’

AND

Len(@Name)

0), DEFAULT (N’system’),

You can create the same constraints as in Listing 24.11 by using the ALTER TABLE statement. This means you can first create the table (without the constraints) and then add the constraints afterward. Listing 24.12 shows the creation of the same titleHistory table, with the constraints added later via the ALTER TABLE statement.

LISTING 24.12 Example of Creating Constraints with ALTER TABLE IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = OBJECT_ID(N’[dbo].[TitleHistory]’) AND OBJECTPROPERTY(id, N’IsUserTable’) = 1) DROP TABLE [dbo].[TitleHistory] CREATE TABLE dbo.TitleHistory( title_id dbo.tid NOT NULL,

Download from www.wowebook.com

Modifying Tables

765

change_date datetime NOT NULL, title varchar(80) NOT NULL, type char(12) NOT NULL, price money NULL, modify_user nchar(10) NOT NULL ) GO

24

--PRIMARY KEY/UNIQUE CONSTRAINT ALTER TABLE dbo.TitleHistory ADD CONSTRAINT PK_TitleHistory UNIQUE CLUSTERED ( title_id ASC, change_date ASC )WITH (SORT_IN_TEMPDB = OFF, ONLINE = OFF) go --FOREIGN KEY CONSTRAINT ALTER TABLE dbo.TitleHistory WITH CHECK ADD CONSTRAINT FK_titles_titleHistory FOREIGN KEY( title_id) REFERENCES dbo.titles (title_id) GO --CHECK CONSTRAINT ALTER TABLE dbo.TitleHistory WITH CHECK ADD CONSTRAINT CK_TitleHistory_Price CHECK ((Price>(0))) GO --DEFAULT CONSTRAINT ALTER TABLE dbo.TitleHistory ADD CONSTRAINT DF_TitleHistory_modify_user DEFAULT (N’system’) FOR modify_user

Modifying Tables You often need to modify database tables after you create them. Fortunately, you can use several tools to accomplish this task. These tools are the same set of tools you can use to add, modify, and delete tables: the SSMS Object Explorer, Table Designer, Database Diagram Editor, and T-SQL. The following sections touch on each of these tools but focus most heavily on the use of T-SQL. Regardless of the method you use, you must always exercise caution when modifying tables, particularly in a production environment. Table relationships and the impact to data that may already exist in a table are key considerations in modifying a table. A visual tool such as a database diagram can assist you in determining the impact to related tables

Download from www.wowebook.com

766

CHAPTER 24

Creating and Managing Tables

and can be used to generate the T-SQL script. The following section looks at the underlying T-SQL that can be used to modify a table, and then we delve into the visual tools that can simplify your life and generate some of the T-SQL for you.

Using T-SQL to Modify Tables You can modify tables in many different ways, including making changes to the columns, constraints, and indexes associated with a table. Some of the changes have a bigger impact on the database than others. Some modifications require that the modified table be dropped and re-created to effect the change. Fortunately, you can use the T-SQL ALTER TABLE statement to mitigate the database impact and help streamline many of the most common modifications. You can make the following types of changes by using the ALTER TABLE statement: . Change a column property, such as a data type or NULL property. . Add new columns or drop existing columns. . Add or drop constraints. . Enable or disable CHECK and FOREIGN KEY constraints. . Enable or disable triggers. . Reassign partitions. . Alter an index associated with a constraint. The following sections discuss a few examples of these types of changes to familiarize you with the ALTER TABLE command. The full syntax for the ALTER TABLE command is extensive, and you can find it in SQL Server Books Online. Changing a Column Property You can use the ALTER COLUMN clause of the ALTER TABLE command to modify column properties, including the NULL property or the data type of a column. Listing 24.13 shows an example of changing the data type of a column.

LISTING 24.13 Changing the Data Type of a Column by Using ALTER TABLE alter table titles alter column notes varchar(400) null

You must be aware of several restrictions when you modify the data type of a column. The following rules apply when altering columns: . You cannot modify a text, image, ntext, or timestamp column. . The column cannot be the ROWGUIDCOL for the table. . The column cannot be a computed column or be referenced by a computed column.

Download from www.wowebook.com

Modifying Tables

767

. The column cannot be a replicated column. . If the column is used in an index, the column length can only be increased in size. In addition, it must be of varchar, nvarchar, or varbinary data type, and the data type cannot change. . If statistics have been generated using CREATE STATISTICS, the statistics must first be dropped before the column can be altered. . The column cannot have a PRIMARY KEY or FOREIGN KEY constraint or be used in a CHECK or UNIQUE constraint. The exception is that a column with a CHECK or UNIQUE constraint, if defined as variable length, can have the length altered. . A column with a default defined for it can have only the length, nullability, or precision and scale altered.

24

. If a column has a schema-bound view defined on it, the same rules that apply to columns with indexes apply.

TIP Changing some data types can result in changing the data. For example, changing from nchar to char could result in any extended characters being converted. Similarly, changing precision and scale could result in data truncation. Other modifications, such as changing from char to int, might fail if the data doesn’t match the restrictions of the new data type. Before you change data types, you should always validate that the data conforms to the desired new data type.

Adding and Dropping Columns You add columns to a table by using the ADD COLUMN clause. Listing 24.14 illustrates the addition of a new column named ISBN to the titles table.

LISTING 24.14 Adding a Column by Using ALTER TABLE ALTER TABLE titles add ISBN int null

When you use the ALTER TABLE statement to add a column, the new column is added at the end of the table. In most cases, this location is acceptable. The location of the column in the table generally has no bearing on the use of the table. There are, however, situations in which it is desired to have the new column added in the middle of the table. The ALTER TABLE statement does not work for this situation. To add a column in the middle of the table, you need to create a new version of the table with a different name and the columns in the desired order, copy the data from the old table, drop the old table, and

Download from www.wowebook.com

768

CHAPTER 24

Creating and Managing Tables

rename the new table with the old table name. Alternatively, you can also accomplish this by using SSMS, as described in the following section. There are also some issues you need to consider with regard to the null option specified for a new column. In the case of a column that allows nulls, there is no real issue: SQL Server adds the column and allows a NULL value for all rows. If NOT NULL is specified, however, the column must be an identity column or have a default specified. Note that even if a default is specified, if the column allows nulls, the column is not populated with the default if no value is provided for the column. You use the WITH VALUES clause as part of the default specification to override this and populate the column with the default. With some restrictions, columns can also be dropped from a table. Listing 24.15 shows the syntax for dropping a column. You can specify to drop multiple columns, separated by commas.

LISTING 24.15 Dropping a Column by Using ALTER TABLE alter table titles drop column ISBN

The following columns cannot be dropped: . A column in a schema-bound view . An indexed column . A replicated column . A column used in a CHECK, FOREIGN KEY, UNIQUE, or PRIMARY KEY constraints . A column associated with a default or bound to a default object . A column bound to a rule

NOTE Be careful when using ALTER TABLE to modify columns that hold existing data. When you add, drop, or modify columns, SQL Server places a schema lock on the table, preventing any other access until the operation completes. Changes to columns in tables that have many rows can take a long time to complete and generate a large amount of log activity.

As mentioned earlier, the ALTER TABLE statement is not the only T-SQL statement you can use to modify tables. You accomplish some table changes by using T-SQL that drops and re-creates the tables that are being modified. The following sections look at some examples of these types of changes.

Download from www.wowebook.com

Modifying Tables

769

Using Object Explorer and the Table Designer to Modify Tables The Object Explorer in SSMS is your window into the various tables available for modification in a database. You expand the Tables node in the Object Explorer tree and right-click the table you would like to modify. Then you select the Design option, and a Table Designer window appears, showing all the table columns. In addition, a Table Designer menu option appears at the top of the SSMS window. The Table Designer menu includes many options, including Insert Columns, Delete Columns, and Remove Primary Key. The full list of available options is shown in Figure 24.4. A Table Designer window for the BigPubs2008.Authors table is shown as the active tab on the right side of Figure 24.4.

24

FIGURE 24.4 The Table Designer.

To illustrate the power of the Table Designer, let’s add a new column to the authors table. You can add the column to the middle of the table, just prior to the address column. You do this by highlighting the entire address row in the Table Designer grid and then selecting Table Designer, Insert Column. A new data entry row is added to the Table Designer grid, where you can specify the name of the new column, the data type, and a null option. For this example, you can name the new column Gender, with a data type of char(1) and the setting ALLOW NULLS. Figure 24.5 shows the Table Designer grid with the newly added Gender column highlighted. In addition, the figure shows the Table Designer menu options with the newly enabled Generate Change Script option selected.

Download from www.wowebook.com

770

CHAPTER 24

Creating and Managing Tables

FIGURE 24.5 Inserting a column in Table Designer. You do not need to use the Generate Change Script option for changes you make in the Table Designer. You can close the Table Designer tab where you made your changes, and the Table Designer makes the changes for you behind the scenes. Sometimes, though, you might want to script the changes and see exactly what is going to happen to the database. Clicking the Script button is also the preferred method for deploying changes to other environments. You can save a script in a change repository and execute it in your target environments. This approach ensures that you have a repeatable, well-documented means for making table changes. Listing 24.16 shows the contents of a script that would be generated based on the new Gender column you added to the authors table. For the sake of space, some of the initial script options and the triggers associated with the authors table have been removed from the script. The important point to note is how extensive this script is. A new temporary authors table is created, and it includes the new column; the data from the authors table is copied into the temporary table; and then the table is renamed. In addition, the script must manage the constraints, indexes, and other objects associated with the authors table. The good news is that Table Designer does most of the work for you.

LISTING 24.16 Changing Script Generated from the Table Designer ALTER TABLE dbo.authors DROP CONSTRAINT DF__authors__phone__04C4C0F4 GO

Download from www.wowebook.com

Modifying Tables

24

CREATE TABLE dbo.Tmp_authors ( au_id dbo.id NOT NULL, au_lname varchar(40) NOT NULL, au_fname varchar(20) NOT NULL, phone char(12) NOT NULL, Gender char(1) NULL, address varchar(40) NULL, city varchar(20) NULL, state char(2) NULL, zip char(5) NULL, contract bit NOT NULL ) ON [PRIMARY] GO ALTER TABLE dbo.Tmp_authors ADD CONSTRAINT DF__authors__phone__04C4C0F4 DEFAULT (‘UNKNOWN’) FOR phone GO IF EXISTS(SELECT * FROM dbo.authors) EXEC(‘INSERT INTO dbo.Tmp_authors (au_id, au_lname, au_fname, phone, address, city, state, zip, contract) SELECT au_id, au_lname, au_fname, phone, address, city, state, zip, contract FROM dbo.authors WITH (HOLDLOCK TABLOCKX)’) GO ALTER TABLE dbo.titleauthor DROP CONSTRAINT FK__titleauth__au_id__14070484 GO

771

DROP TABLE dbo.authors GO EXECUTE sp_rename N’dbo.Tmp_authors’, N’authors’, ‘OBJECT’ GO ALTER TABLE dbo.authors ADD CONSTRAINT UPKCL_auidind PRIMARY KEY CLUSTERED ( au_id ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO CREATE NONCLUSTERED INDEX aunmind ON dbo.authors ( au_lname, au_fname ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = OFF) ON [PRIMARY] GO ALTER TABLE dbo.authors WITH NOCHECK ADD CONSTRAINT

Download from www.wowebook.com

772

CHAPTER 24

Creating and Managing Tables

CK__authors__au_id__03D09CBB CHECK (([au_id] like ‘[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]’)) GO ALTER TABLE dbo.authors WITH NOCHECK ADD CONSTRAINT CK__authors__zip__05B8E52D CHECK (([zip] like ‘[0-9][0-9][0-9][0-9][0-9]’)) GO

You will find that you can make most of the changes you want to make by using the Table Designer. To make other changes, you can use the same approach you just used to add a column. This approach involves making the changes via the Table Designer menu options and then using the option to script the change. This is a great way to evaluate the impact of your changes and to save those changes for later execution.

Using Database Diagrams to Modify Tables Database diagrams offer an excellent visual view of your database tables that you can also use to modify tables. You do this by adding the table you want to modify to a new or existing database diagram. Oftentimes, it is best to also add all the related tables to the diagram as well. You can easily do this by right-clicking the table and choosing the Add Related Tables option. With a database diagram, you have the same options that you have with the Table Designer, plus you have diagramming options. Both the Table Designer and Database Diagrams menus are shown when a database diagram is in focus. These menus disappear if you change the tabbed window to a Database Engine query window, so remember that you must select the diagram window to be able to display the menu options. Figure 24.6 shows a database diagram for the HumanResouces.Department table, along with its related table. The Table Designer menu is selected to show that it is available when you work with a database diagram. You must have one of the tables selected to enable all the menu options. In Figure 24.6, the Department table has been highlighted, and a new ModifiedUser column has been added to the end of the table. Figure 24.6 also shows that the Database Diagram menu is available for selection. This menu includes options to add tables to the diagram and manipulate the tables within the diagram. The same scripting options are available with a database diagram as are available in the Table Designer. You can make your changes from within the diagram and then choose the Generate Change Script menu option. Listing 24.17 shows the change script generated based on the addition of the ModifiedUser column to the end of the Department table. As expected, this change is accomplished with an ALTER TABLE statement.

LISTING 24.17 The Change Script Generated from a Database Diagram ALTER TABLE HumanResources.Department ADD ModifiedUser varchar(20) NULL GO

Download from www.wowebook.com

Dropping Tables

773

24

FIGURE 24.6 Modifying tables by using a database diagram. The use of the ALTER TABLE statement in this listing brings us full circle, back to our initial method for making table modifications. Using all the tools discussed in this section together will usually give you the best results.

Dropping Tables There are several different methods for dropping (or deleting) a table. You can right-click the table in the SSMS Object Explorer and select Delete, you can right-click a table in a database diagram and choose Delete Tables from Database, or you can use the old-fashioned method of utilizing T-SQL. Here’s an example of the T-SQL DROP TABLE statement: DROP TABLE [HumanResources].[Department]

You can reference multiple tables in a single DROP TABLE command by separating the table names with commas. Any triggers and constraints associated with the table are also dropped when the table is dropped. A big consideration when dropping a table is the table’s relationship to other tables. If a foreign key references the table that you want to drop, the referencing table or foreign key constraint must be dropped first. In a database that has many related tables, dropping elements can get complicated. Fortunately, a few tools can help you through this. The system stored procedure sp_helpconstraint is one of these tools. This procedure lists all

Download from www.wowebook.com

774

CHAPTER 24

Creating and Managing Tables

the foreign key constraints that reference a table. Listing 24.18 shows an execution of this stored procedure for the Sales.Store table in the AdventureWorks2008 database. The procedure results include information about all the constraints on the table. The results to focus on are those that follow the heading Table Is Referenced by Foreign Key. The partial results shown in Listing 24.18 for the Sales.Store table indicate that FK_StoreContact_Store_CustomerID must be dropped first before you can drop the Sales.Store table.

LISTING 24.18 Using sp_helpconstraint to Find Foreign Key References sp_helpconstraint [Sales.Store]

/*partial results of sp_helpconstraint execution Table is referenced by foreign key ------------------------------------------------------------------AdventureWorks2008.Sales.StoreContact: FK_StoreContact_Store_CustomerID */

Two other approaches are useful for identifying foreign key references prior to dropping a table. The first is using a database diagram. You can create a new database diagram and add the table that you are considering for deletion. After the table is added, you right-click the table in Object Explorer and select Add Related Tables. The related tables, including those that have foreign key references, are then added. You can then right-click the relationship line connecting two tables and select Delete Relationships from Database. When you have deleted all the foreign key relationships from the diagram, you can right-click the table you want to delete and select Generate Change Script to create a script that can be used to remove the foreign key relationship(s). The other approach is to right-click the table in Object Explorer and choose View Dependencies. The dialog that appears gives you the option of viewing the objects that depend on the table or viewing the objects on which the table depends. If you choose the option to view the objects that depend on the table, all the dependent objects are displayed, but you can focus on the objects that are tables.

Using Partitioned Tables In SQL Server 2008, tables are stored in one or more partitions. Partitions are organizational units that allow you to divide data into logical groups. By default, a table has only a single partition that contains all the data. The power of partitions comes into play when you define multiple partitions for a table that is segmented based on a key column. This column allows the data rows to be horizontally split. For example, a date/time column can be used to divide each month’s data into a separate partition. These partitions can also be aligned to different filegroups for added flexibility, ease of maintenance, and improved performance.

Download from www.wowebook.com

Using Partitioned Tables

775

The important point to remember is that you access tables with multiple partitions (which are called partitioned tables) the same way you access tables with a single partition. Data Manipulation Language (DML) operations such as INSERT and SELECT statements reference the table the same way, regardless of partitioning. The difference between these types of tables has to do with the back-end storage and the organization of the data. Generally, partitioning is most useful for large tables. Large is a relative term, but these tables typically contain millions of rows and take up gigabytes of space. Often, the tables targeted for partitioning are large tables experiencing performance problems because of their size. Partitioning has several different applications, including the following:

. Maintenance—Table partitions that have been assigned to different filegroups can be backed up and maintained independently of each other. With very large tables, maintenance activities on the entire table (such as backups) can take a prohibitively long time. With partitioned tables, these maintenance activities can be performed at the partition level. Consider, for example, a table that is partitioned by month: all the new activity (updates and insertions) occurs in the partition that contains the current month’s data. In this scenario, the current month’s partition would be the focus of the maintenance, thus limiting the amount of data you need to process.

24

. Archival—Table partitions can be moved from a production table to another archive table that has the same structure. When done properly, this partition movement is very fast and allows you to keep a limited amount of recent data in the production table while keeping the bulk of the older data in the archive table.

. Query performance—Partitioned tables joined on partitioned columns can experience improved performance because the Query Optimizer can join to the table based on the partitioned column. The caveat is that joins across partitioned tables not joining on the partitioned column may actually experience some performance degradation. Queries can also be parallelized along the partitions. Now that we have discussed some of the reasons to use partitioned tables, let’s look at how to set up partitions. There are three basic steps: 1. Create a partition function that maps the rows in the table to partitions based on the value of a specified column. 2. Create a partition scheme that outlines the placement of the partitions in the partition function to filegroups. 3. Create a table that utilizes the partition scheme. These steps are predicated on a good partitioning design, based on an evaluation of the data within the table and the selection of a column that will effectively split the data. If multiple filegroups are used, those filegroups must also exist before you execute the three steps in partitioning. The following sections look at the syntax related to each step, using simple examples. These examples utilize the BigPubs2008 database.

Download from www.wowebook.com

776

CHAPTER 24

Creating and Managing Tables

Creating a Partition Function A partition function identifies values within a table that will be compared to the column on which you partition the table. As mentioned previously, it is important that you know the distribution of the data and the specific range of values in the partitioning column before you create the partition function. The following query provides an example of determining the distribution of data values in the sales_big table by year: --Select the distinct yearly values SELECT year(ord_date) as ‘year’, count(*) ‘rows’ FROM sales_big GROUP BY year(ord_date) ORDER BY 1 go year rows ----------- ----------2005 30 2006 613560 2007 616450 2008 457210

You can see from the results of the SELECT statement that there are four years’ worth of data in the sales_big table. Because the values specified in the CREATE PARTITION FUNCTION statement are used to establish data ranges, at a minimum, you would need to specify at least three data values when defining the partition function, as shown in the following example: --Create partition function with the yearly values to partition the data CREATE PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE RIGHT FOR VALUES (‘01/01/2006’, ‘01/01/2007’, ‘01/01/2008’) GO

In this example, four ranges, or partitions, would be established by the three RANGE RIGHT values specified in the statement: . values < 01/01/2006—This partition includes any rows prior to 2006. . values >= 01/01/2006 AND values < 01/01/2007—This partition includes all rows for 2006. . values >= 01/01/2007 AND values < 01/01/2008—This partition includes all rows for 2007. . values > 01/01/2008—This includes any rows for 2008 or later. This method of partitioning would be more than adequate for a static table that is not going to be receiving any additional data rows for different years than already exist in the

Download from www.wowebook.com

Using Partitioned Tables

777

table. However, if the table is going to be populated with additional data rows after it has been partitioned, it is good practice to add additional range values at the beginning and end of the ranges to allow for the insertion of data values less than or greater than the existing range values in the table. To create these additional upper and lower ranges, you would want to specify five values in the VALUES clause of the CREATE PARTITION FUNCTION, as shown in Listing 24.19. The advantages of having these additional partitions are demonstrated later in this section.

LISTING 24.19 Creating a Partition Function

24

if exists (select 1 from sys.partition_functions where name = ‘SalesBigPF1’) drop partition function SalesBigPF1 go --Create partition function with the yearly values to partition the data Create PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE RIGHT FOR VALUES (‘01/01/2005’, ‘01/01/2006’, ‘01/01/2007’, ‘01/01/2008’, ‘01/01/2009’) GO

In this example, six ranges, or partitions, are established by the five range values specified in the statement: . values < 01/01/2005—This partition includes any rows prior to 2005. . values >= 01/01/2005 AND values < 01/01/2006—This partition includes all rows for 2005. . values >= 01/01/2006 AND values < 01/01/2007—This partition includes all rows for 2006. . values >= 01/01/2007 AND values < 01/01/2008—This partition includes all rows for 2007. . values >= 01/01/2008 AND values < 01/01/2009—This partition includes all rows for 2008. . values >= 01/01/2009—This partition includes any rows for 2009 or later. An alternative to the RIGHT clause in the CREATE PARTITION FUNCTION statement is the LEFT clause. The LEFT clause is similar to RIGHT, but it changes the ranges such that the < operands are changed to = operands are changed to >.

TIP Using RANGE RIGHT partitions for datetime values is usually best because this approach makes it easier to specify the limits of the ranges. The datetime data type can store values only with accuracy to 3.33 milliseconds. The largest value it can store is 0.997 milliseconds. A value of 0.998 milliseconds rounds down to 0.997, and a value of 0.999 milliseconds rounds up to the next second.

Download from www.wowebook.com

778

CHAPTER 24

Creating and Managing Tables

If you used a RANGE LEFT partition, the maximum time value you could include with the year to get all values for that year would be 23:59:59.997. For example, if you specified 12/31/2006 23:59:59.999 as the boundary for a RANGE LEFT partition, it would be rounded up so that it would also include rows with datetime values less than or equal to 01/01/2007 00:00:00.000, which is probably not what you would want. You would redefine the example shown in Listing 24.19 as a RANGE LEFT partition function as follows: CREATE PARTITION FUNCTION SalesBigPF1 (datetime) AS RANGE LEFT FOR VALUES (‘12/31/2004 23:59:59.997’, ‘12/31/2005 23:59:59.997’, ‘12/31/2006 23:59: 59.997’, ‘12/31/2007 23:59:59.997’, ‘12/31/2008 23:59:59.997’)

As you can see, it’s a bit more straightforward and probably less confusing to use RANGE RIGHT partition functions when dealing with datetime values or any other continuous-value data types, such as float or numeric.

Creating a Partition Scheme After you create a partition function, the next step is to associate a partition scheme with the partition function. A partition scheme can be associated with only one partition function, but a partition function can be shared across multiple partition schemes. The core function of a partition scheme is to map the values defined in the partition function to filegroups. When creating the statement for a partition scheme, you need to keep in mind the following: . A single filegroup can be used for all partitions, or a separate filegroup can be used for each individual partition. . Any filegroup referenced in the partition scheme must exist before the partition scheme is created. . There must be enough filegroups referenced in the partition scheme to accommodate all the partitions. The number of partitions is one more than the number of values specified in the partition function. . The number of partitions is limited to 1,000. . The filegroups listed in the partition scheme are assigned to the partitions defined in the function based on the order in which the filegroups are listed. Listing 24.20 creates a partition schema that references the partition function created in Listing 24.19. This example assumes that the referenced filegroups have been created for each of the partitions. (For more information on creating filegroups and secondary files, see Chapter 23.)

Download from www.wowebook.com

Using Partitioned Tables

779

NOTE If you would like to create the same filegroups and files used by the examples in this section, check out the script file called Create_Filegroups_and_Files_for_ Partitioning.sql on the included CD in the code listings directory for this chapter. If you run this script, it creates all the necessary file groups and files referenced in the examples. Note that you need to edit the script to change the FILENAME value if you need the files to be created in a directory other than C:\MSSQL2008\DATA.

LISTING 24.20 Creating a Partition Scheme

24

--Create a partition scheme that is aligned with the partition function CREATE PARTITION SCHEME SalesBigPS1 AS PARTITION SalesBigPF1 TO ([Older_data], [2005_data], [2006_data], [2007_data], [2008_data], [2009_data]) GO

Alternatively, if all partitions are going to be on the same filegroup, such as the PRIMARY filegroup, you could use the following: Create PARTITION SCHEME SalesBigPS1 as PARTITION SalesBigPF1 ALL to ([PRIMARY]) go

Notice that SalesBigPF1 is referenced as the partition function in Listing 24.20. This ties together the partition scheme and partition function. Figure 24.7 shows how the partitions defined in the function would be mapped to the filegroup(s). At this point, you have made no changes to any table, and you have not even specified the column in the table that you will partition. The next section discusses those details.

Creating a Partitioned Table Tables are partitioned only when they are created. This is an important point to keep in mind when you are considering adding partitions to a table that already exists. Sometimes, performance issues or other factors may lead you to determine that a table you have already created and populated may benefit from being partitioned. The re-creation of large tables in a production environment requires some forethought and planning. The data in the table must be retained in another location for you to recreate the table. Bulk copying the data to a flat file and renaming the table are two possible solutions for retaining the data. After you determine the data retention method, you can re-create the table, with the new partition scheme. For simplicity’s sake, the example in Listing 24.21 creates a new table named sales_big_Partitioned instead of using the

Download from www.wowebook.com

780

CHAPTER 24

Creating and Managing Tables

Boundary 1

Boundary 2

Boundary 3

Boundary 4

Boundary 5

1992-01-01

1993-01-01

1994-01-01

1995-01-01

1996-01-01

Partition # 1 1991 and Earlier Data

2

3

4

5

6

1992 Data

1993 Data

1994 Data

1995 Data

1996 Data Later Data

Partition Scheme Older_data Filegroup

1992_data Filegroup

1993_data Filegroup

1994_data Filegroup

1995_data Filegroup

1996_data Filegroup

FIGURE 24.7 Mapping of partitions to filegroups, using a RANGE RIGHT partition function.

original sales_big table. The second part of Listing 24.21 copies the data from the sales_big table into the sales_big_Partitioned table.

LISTING 24.21 Creating a Partitioned Table CREATE TABLE dbo.sales_big_Partitioned( sales_id int IDENTITY(1,1) NOT NULL, stor_id char(4) NOT NULL, ord_num varchar(20) NOT NULL, ord_date datetime NOT NULL, qty smallint NOT NULL, payterms varchar(12) NOT NULL, title_id dbo.tid NOT NULL ) ON SalesBigPS1 (ord_date) --this statement is key to Partitioning the table GO GO --Insert data from the sales_big table into the new sales_big_partitioned table SET IDENTITY_INSERT sales_big_Partitioned ON GO INSERT sales_big_Partitioned with (TABLOCKX) (sales_id, stor_id, ord_num, ord_date, qty, payterms, title_id) SELECT sales_id, stor_id, ord_num, ord_date, qty, payterms, title_id FROM sales_big

Download from www.wowebook.com

Using Partitioned Tables

781

go SET IDENTITY_INSERT sales_big_Partitioned OFF GO

The key clause to take note of in this listing is ON SalesBigPS1 (ord_date). This clause identifies the partition scheme on which to create the table (SalesBigPS1) and the column within the table to use for partitioning (ord_date).

24

After you create the table, you might wonder whether the table was partitioned correctly. Fortunately, there are some catalog views related to partitions that you can query for this kind of information. Listing 24.22 shows a sample SELECT statement that utilizes the sys.partitions view. The results of the statement execution are shown immediately after the SELECT statement. Notice that there are six numbered partitions and that the estimated number of rows for each partition corresponds to the number of rows you saw when you selected the data from the unpartitioned SalesBig table.

LISTING 24.22 Viewing Partitioned Table Information select convert(varchar(16), ps.name) as partition_scheme, p.partition_number, convert(varchar(10), ds2.name) as filegroup, convert(varchar(19), isnull(v.value, ‘’), 120) as range_boundary, str(p.rows, 9) as rows from sys.indexes i join sys.partition_schemes ps on i.data_space_id = ps.data_space_id join sys.destination_data_spaces dds on ps.data_space_id = dds.partition_scheme_id join sys.data_spaces ds2 on dds.data_space_id = ds2.data_space_id join sys.partitions p on dds.destination_id = p.partition_number and p.object_id = i.object_id and p.index_id = i.index_id join sys.partition_functions pf on ps.function_id = pf.function_id LEFT JOIN sys.Partition_Range_values v on pf.function_id = v.function_id and v.boundary_id = p.partition_number - pf.boundary_value_on_right WHERE i.object_id = object_id(‘sales_big_partitioned’) and i.index_id in (0, 1) order by p.partition_number /* Results from the previous SELECT statement partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 0 SalesBigPS1 2 2005_Data 2005-01-01 00:00:00 30 SalesBigPS1 3 2006_Data 2006-01-01 00:00:00 613560 SalesBigPS1 4 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 5 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 6 2009_Data 2009-01-01 00:00:00 0 */

Download from www.wowebook.com

782

CHAPTER 24

Creating and Managing Tables

Adding and Dropping Table Partitions One of the most useful features of partitioned tables is that you can add and drop entire partitions of table data in bulk. If the table partitions are set up properly, these commands can take place in seconds, without the expensive input/output (I/O) costs of physically copying or moving the data. You can add and drop table partitions by using the SPLIT RANGE and MERGE RANGE options of the ALTER PARTITION FUNCTION command: ALTER PARTITION FUNCTION partition_function_name() { SPLIT RANGE ( boundary_value ) | MERGE RANGE ( boundary_value ) }

Adding a Table Partition The SPLIT RANGE option adds a new boundary point to an existing partition function and affects all objects that use this partition function. When this command is run, one of the function partitions is split in two. The new partition is the one that contains the new boundary point. The new partition is created to the right of the boundary value if the partition is defined as a RANGE RIGHT partition function or to the left of the boundary if it is a RANGE LEFT partition function. If the partition is empty, the split is instantaneous. If the partition being split contains data, any data on the new side of the boundary is physically deleted from the old partition and inserted into the new partition. In addition to being I/O intensive, a split is also log intensive, generating log records that are four times the size of the data being moved. In addition, an exclusive table lock is held for the duration of the split. If you want to avoid this costly overhead when adding a new partition to the end of the partition range, it is recommended that you always keep an empty partition available at the end and split it before it is populated with data. If the partition is empty, SQL Server does not need to scan the partition to see whether there is any data to be moved.

NOTE Avoiding the overhead associated with splitting a partition is the reason the code in Listing 24.19 defined the SalesBigPF1 partition function with a partition for 2009, even though there is no 2009 data in the sales_big_partitioned table. As long as you split the partition before any 2009 data is inserted into the table and the 2009 partition is empty, no data needs to be moved, so the split is instantaneous.

Before you split a partition, a filegroup must be marked to be the NEXT USED partition by the partition scheme that uses the partition function. You initially allocate filegroups to partitions by using a CREATE PARTITION SCHEME statement. If a CREATE PARTITION SCHEME statement allocates more filegroups than there are partitions defined in the CREATE PARTITION FUNCTION statement, one of the unassigned filegroups is automatically marked as NEXT USED by the partition scheme, and it will hold the new partition.

Download from www.wowebook.com

Using Partitioned Tables

783

If there are no filegroups currently marked NEXT USED by the partition scheme, you must use ALTER PARTITION SCHEME to either add a filegroup or designate an existing filegroup to hold the new partition. This can be a filegroup that already holds existing partitions. Also, if a partition function is used by more than one partition scheme, all the partition schemes that use the partition function to which you are adding partitions must have a NEXT USED filegroup. If one or more do not have a NEXT USED filegroup assigned, the ALTER PARTITION FUNCTION statement fails, and the error message displays the partition scheme or schemes that lack a NEXT USED filegroup. The following SQL statement adds a NEXT USED filegroup to the SalesBigPS1 partition scheme. Note that in this example, the filegroup specified is a new filegroup, 2010_DATA: ALTER PARTITION SCHEME SalesBigPS1 NEXT USED ‘2010_Data’

24

Now that you have specified a NEXT USED filegroup for the partition scheme, you can go ahead and add the new range for 2010 and later data rows to the partition function, as in the following example: --Alter partition function with the yearly values to partition the data ALTER PARTITION FUNCTION SalesBigPF1 () SPLIT RANGE (‘01/01/2010’) GO

Figure 24.8 shows the effects of splitting the 2009 table partition.

Boundary 1

Boundary 2

Boundary 3

Boundary 4

Boundary 5

1992-01-01

1993-01-01

1994-01-01

1995-01-01

1996-01-01

1 1991 and Earlier Data

2

3

1992 Data

1993 Data

4 1994 Data

5 1995 Data

Boundary 6 Added 1997-01-01

6

7

1996 Data

1997 and Later Data

Any 1997 and later data will be moved

FIGURE 24.8 The effects of splitting a RANGE RIGHT table partition. You can also see the effects of splitting the partition on the system catalogs by running the same query as shown earlier, in Listing 24.22:

Download from www.wowebook.com

784

CHAPTER 24

Creating and Managing Tables

/* New results from the SELECT statement in Listing 24.22 partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 0 SalesBigPS1 2 2005_Data 2005-01-01 00:00:00 30 SalesBigPS1 3 2006_Data 2006-01-01 00:00:00 613560 SalesBigPS1 4 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 5 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 6 2009_Data 2009-01-01 00:00:00 0 SalesBigPS1 7 2010_Data 2010-01-01 00:00:00 0 */

Dropping a Table Partition You can drop a table partition by using the ALTER PARTITION FUNCTION ... MERGE RANGE command. This command essentially removes a boundary point from a partition function as the partitions on each side of the boundary are merged into one. The partition that held the boundary value is removed. The filegroup that originally held the boundary value is removed from the partition scheme unless it is used by a remaining partition or is marked with the NEXT USED property. Any data that was in the removed partition is moved to the remaining neighboring partition. If a RANGE RIGHT partition boundary was removed, the data that was in that boundary’s partition is moved to the partition to the left of boundary. If it was a RANGE LEFT partition, the data is moved to the partition to the right of the boundary. The following command merges the 2005 partition into the Old_Data partition for the sales_big_partitioned table: ALTER PARTITION FUNCTION SalesBigPF1 () MERGE RANGE (‘01/01/2005’)

Figure 24.9 demonstrates how the 2005 RANGE RIGHT partition boundary is removed and the data is merged to the left, into the Old_Data partition.

CAUTION Splitting or merging partitions for a partition function affects all objects using that partition function.

You can also see the effects of merging the partition on the system catalogs by running the same query as shown in Listing 24.22: /* New results from the SELECT statement in Listing 24.20 partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 30 SalesBigPS1 3 2006_Data 2006-01-01 00:00:00 613560

Download from www.wowebook.com

Using Partitioned Tables

SalesBigPS1 SalesBigPS1 SalesBigPS1 SalesBigPS1 */

4 5 6 7

2007_Data 2008_Data 2009_Data 2010_Data

2007-01-01 2008-01-01 2009-01-01 2010-01-01

00:00:00 00:00:00 00:00:00 00:00:00

616450 457210 0 0

Boundary 1 Removed

Boundary 2

Boundary 3

Boundary 4

Boundary 5

Boundary 6

1992-01-01

1993-01-01

1994-01-01

1995-01-01

1996-01-01

1996-07-01

1

2

4

1993 Data

1994 Data

5

6

7 24

3

785

1991 and Earlier Data

1992 Data

1995 Data

1996 Data

1997 and Later Data

1992 Data Moved

FIGURE 24.9 The effects of merging a RANGE RIGHT table partition. Like the split operation, the merge operation occurs instantaneously if the partition being merged is empty. The process can be very I/O intensive if the partition has a large amount of data in it. Any rows in the removed partition are physically moved into the remaining partition. This operation is also very log intensive, requiring log space approximately four times the size of data being moved. An exclusive table lock is held for the duration of the merge. If you no longer want to keep the data in the table for a partition you are merging, you can move the data in the partition to another empty table or empty table partition by using the SWITCH PARTITION option of the ALTER TABLE command. This option is discussed in more detail in the following section.

Switching Table Partitions One of the great features of table partitions is that they enable you to instantly swap the contents of one partition to an empty table, the contents from a partition on one table to a partition in another table, or an entire table’s contents into another table’s empty partition. This operation performs changes only to metadata in the system catalogs for the affected tables/partitions, with no actual physical movement of data.

Download from www.wowebook.com

786

CHAPTER 24

Creating and Managing Tables

For you to switch data from a partition to a table or from a table into a partition, the following criteria must be met: . The source table and target table must both have the same structure (that is, the same columns in the same order, with the same names, data types, lengths, precisions, scales, nullabilities, and collations). The tables must also have the same primary key constraints and settings for ANSI_NULLS and QUOTED_IDENTIFIER. . The source and target of the ALTER TABLE...SWITCH statement must reside in the same filegroup. . If you are switching a partition to a single, nonpartitioned table, the table receiving the partition must already be created, and it must be empty. . If you are adding a table as a partition to an already existing partitioned table or moving a partition from one partitioned table to another, the receiving partition must exist, and it must be empty. . If you are switching a partition from one partitioned table to another, both tables must be partitioned on the same column. . The source must have all the same indexes as the target, and the indexes must also be in the same filegroup. . If you are switching a nonpartitioned table to a partition of an already existing partitioned table, the nonpartitioned table must have a constraint defined on the column corresponding to the partition key of the target table to ensure that the range of values fits within the boundary values of the target partition. . If the target table has any FOREIGN KEY constraints, the source table must have the same foreign keys defined on the corresponding columns, and those foreign keys must reference the same primary keys that the target table references. If you are switching a partition of a partitioned table to another partitioned table, the boundary values of the source partition must fit within those of the target partition. If the boundary values do not fit, a constraint must be defined on the partition key of the source table to make sure all the data in the table fits into the boundary values of the target partition.

CAUTION If the tables have IDENTITY columns, partition switching can result in the introduction of duplicate values in IDENTITY columns of the target table and gaps in the values of IDENTITY columns in the source table. You can use DBCC_CHECKIDENT to check the identity values of tables and correct them if necessary. When you switch a partition, data is not physically moved. Only the metadata information in the system catalogs indicating where the data is stored is changed. In addition, all associated indexes are automatically switched, along with the table or partition.

Download from www.wowebook.com

Using Partitioned Tables

787

To switch table partitions, you use the ALTER TABLE command: ALTER TABLE table_name SWITCH [ PARTITION source_partition_number_expression ] TO target_table [ PARTITION target_partition_number_expression ]

You can use the ALTER TABLE...SWITCH command to switch an unpartitioned table into a table partition, switch a table partition into an empty unpartitioned table, or switch a table partition into another table’s empty table partition. The code shown in Listing 24.23 creates a table to hold the data from the 2006 partition and then switches the 2006 partition from the sales_big_partitioned table to the new table.

LISTING 24.23 Switching a Partition to an Empty Table

24

CREATE TABLE dbo.sales_big_2006( sales_id int IDENTITY(1,1) NOT NULL, stor_id char(4) NOT NULL, ord_num varchar(20) NOT NULL, ord_date datetime NOT NULL, qty smallint NOT NULL, payterms varchar(12) NOT NULL, title_id dbo.tid NOT NULL ) ON ‘2006_data’ -- required in order to switch the partition to this table go alter table sales_big_partitioned switch partition $PARTITION.SalesBigPF1 (‘1/1/2006’) to sales_big_2006 go

Note that Listing 24.23 uses the $PARTITION function. You can use this function with any partition function name to return the partition number that corresponds with the specified partitioning column value. This prevents you from having to query the system catalogs to determine the specific partition number for the specified partition value. You can run the query from Listing 24.22 to show that the 2006 partition is now empty: partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 30 SalesBigPS1 2 2006_Data 2006-01-01 00:00:00 0 SalesBigPS1 3 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 4 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 5 2009_Data 2009-01-01 00:00:00 0 SalesBigPS1 6 2010_Data 2010-01-01 00:00:00 0

Download from www.wowebook.com

788

CHAPTER 24

Creating and Managing Tables

Now that the 2006 data partition is empty, you can merge the partition without incurring the I/O cost of moving the data to the Older_data partition: ALTER PARTITION FUNCTION SalesBigPF1 () merge RANGE (‘1/1/2006’)

Rerunning the query in Listing 24.22 now returns the following result set: partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 30 SalesBigPS1 2 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 3 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 4 2009_Data 2009-01-01 00:00:00 0 SalesBigPS1 5 2010_Data 2010-01-01 00:00:00 0

To demonstrate switching a table into a partition, you can update the date for all the rows in the sales_big_2006 table to 2009 and switch it into the 2009 partition of the sales_big_partitioned table. Note that before you can do this, you need to copy the data to a table in the 2009_data filegroup and also put a check constraint on the ord_date column to make sure all rows in the table are limited to values that are valid for the 2009_data partition. Listing 24.24 shows the commands you use to create the new table and switch it into the 2009 partition of the sales_big_partitioned table.

LISTING 24.24 Switching a Table to an Empty Partition CREATE TABLE dbo.sales_big_2009( sales_id int IDENTITY(1,1) NOT NULL, stor_id char(4) NOT NULL, ord_num varchar(20) NOT NULL, ord_date datetime NOT NULL constraint CK_sales_big_2009_ord_date check (ord_date >= ‘1/1/2009’ and ord_date < ‘1/1/2010’), qty smallint NOT NULL, payterms varchar(12) NOT NULL, title_id dbo.tid NOT NULL ) ON ‘2009_data’ -- required to switch the table to the 2009 partition go set identity_insert sales_big_2009 on go insert sales_big_2009 (sales_id, stor_id, ord_num, ord_date, qty, payterms, title_id) select sales_id, stor_id, ord_num, dateadd(yy, 3, ord_date), qty, payterms, title_id from sales_big_2006 go set identity_insert sales_big_2009 off

Download from www.wowebook.com

Creating Temporary Tables

789

go alter table sales_big_2009 switch to sales_big_partitioned partition $PARTITION.SalesBigPF1 (‘1/1/2009’) go

Rerunning the query from Listing 24.22 now returns the following result:

24

partition_scheme partition_number filegroup range_boundary rows ---------------- ---------------- ---------- ------------------- --------SalesBigPS1 1 Older_Data 30 SalesBigPS1 2 2007_Data 2007-01-01 00:00:00 616450 SalesBigPS1 3 2008_Data 2008-01-01 00:00:00 457210 SalesBigPS1 4 2009_Data 2009-01-01 00:00:00 613560 SalesBigPS1 5 2010_Data 2010-01-01 00:00:00 0

TIP Switching data into or out of partitions provides a very efficient mechanism for archiving old data from a production table, importing new data into a production table, or migrating data to an archive table. You can use SWITCH to empty or fill partitions very quickly. As you’ve seen in this section, split and merge operations occur instantaneously if the partitions being split or merged are empty first. If you must split or merge partitions that contain a lot of data, you should empty them first by using SWITCH before you perform the split or merge.

Creating Temporary Tables A temporary table is a special type of table that is automatically deleted when it is no longer used. Temporary tables have many of the same characteristics as permanent tables and are typically used as work tables that contain intermediate results. You designate a table as temporary in SQL Server by prefacing the table name with a single pound sign (#) or two pound signs (##). Temporary tables are created in tempdb; if a temporary table is not explicitly dropped, it is dropped when the session that created it ends or the stored procedure it was created in finishes execution. If a table name is prefaced with a single pound sign (for example, #table1), it is a private temporary table, available only to the session that created it. A table name prefixed with a double pound sign (for example, ##table2) indicates that it is a global temporary table, which means it is accessible by all database connections. A global temporary table exists until the session that created it terminates. If the creating session terminates while other sessions are accessing the table, the temporary table is available to those sessions until the last session’s query ends, at which time the table is dropped.

Download from www.wowebook.com

790

CHAPTER 24

Creating and Managing Tables

A common way of creating a temporary table is to use the SELECT INTO method as shown in the following example: SELECT* INTO #Employee2 FROM Employee

This method creates a temporary table with a structure like the table that is being selected from. It also copies the data from the original table and inserts it into this new temporary table. All of this is done with this one simple command.

NOTE Table variables are a good alternative to temporary tables. These variables are also temporary in nature and have some advantages over temporary tables. Table variables are easy to create, are automatically deleted, cause fewer recompilations, and use fewer locking and logging resources. Generally speaking, you should consider using table variables instead of temporary tables when the temporary results are relatively small. Parallel query plans are not generated with table variables, and this can impede overall performance when you are accessing a table variable that has a large number of rows. For more information on using temporary tables and table variables, see Chapter 43, “Transact-SQL Programming Guidelines, Tips, and Tricks,” that is found on the bonus CD.

Tables created without the # prefix but explicitly created in tempdb are also considered temporary, but they are a more permanent form of a temporary table. They are not dropped automatically until SQL Server is restarted and tempdb is reinitialized.

Summary Tables are the key to a relational database system. When you create tables, you need to pay careful attention to choosing the proper data types to ensure efficient storage of data, adding appropriate constraints to maintain data integrity, and scripting the creation and modification of tables to ensure that they can be re-created, if necessary. Good table design includes the creation of indexes on a table. Tables without indexes are generally inefficient and cause excessive use of resources on your database server. Chapter 25, “Creating and Managing Indexes,” covers indexes and their critical role in effective table design.

Download from www.wowebook.com

CHAPTER

25

Creating and Managing Indexes

IN THIS CHAPTER . What’s New in Creating and Managing Indexes . Types of Indexes . Creating Indexes . Managing Indexes . Dropping Indexes

Just like the index in this book, an index on a table or

. Online Indexing Operations

view allows you to efficiently find the information you are looking for in a database. SQL Server does not require indexes to be able to retrieve data from tables because it can perform a full table scan to retrieve a result set. However, doing a table scan is analogous to scanning every page in this book to find a word or reference you are looking for.

. Indexes on Views

This chapter introduces the different types of indexes available in SQL Server 2008 to keep your database access efficient. It focuses on creating and managing indexes by using the tools Microsoft SQL Server 2008 provides. For a more in-depth discussion of the internal structures of indexes and designing and managing indexes for optimal performance, see Chapter 34, “Data Structures, Indexes, and Performance.”

What’s New in Creating and Managing Indexes The creation and management of indexes are among the most important performance activities in SQL Server. You will find that indexes and the tools to manage them in SQL Server 2008 are very similar to those in SQL Server 2005. New to SQL Server 2008 is the capability to compress indexes and tables to reduce the amount of storage needed for these objects. This new data compression feature is discussed in detail in Chapter 34. Also new to SQL Server 2008 are filtered indexes. Filtered indexes utilize a WHERE clause that filters or limits the number of rows included in the index. The smaller filtered index

Download from www.wowebook.com

792

CHAPTER 25

Creating and Managing Indexes

allows queries that are run against rows in the index to run faster. These can also save on the disk space used by the index. Spatial indexes also are new to SQL Server 2008. These indexes are used against spatial data defined by coordinates of latitude and longitude. The spatial data is essential for efficient global navigation. The Spatial indexes are grid based and help optimize the performance of searches against the Spatial data. Spatial indexes are also discussed in more detail in Chapter 34.

Types of Indexes SQL Server has two main types of indexes: clustered and nonclustered. They both help the query engine get at data faster, but they have different effects on the storage of the underlying data. The following sections describe these two main types of indexes and provide some insight into when to use each type.

Clustered Indexes Clustered indexes sort and store the data rows for a table, based on the columns defined in the index. For example, if you were to create a clustered index on the LastName and FirstName columns in a table, the data rows for that table would be organized or sorted according to these two columns. This has some obvious advantages for data retrieval. Queries that search for data based on the clustered index keys have a sequential path to the underlying data, which helps reduce I/O. A clustered index is analogous to a filing cabinet where each drawer contains a set of file folders stored in alphabetical order, and each file folder stores the files in alphabetical order. Each file drawer contains a label that indicates which folders it contains (for example, folders A–D). To locate a specific file, you first locate the drawer containing the appropriate file folders, then locate the appropriate file folder within the drawer, and then scan the files in that folder in sequence until you find the one you need. A clustered index is structured as a balanced tree (B-tree). Figure 25.1 shows a simplified diagram of a clustered index defined on a last name column. The top, or root, node is a single page where searches via the clustered index are started. The bottom level of the index is the leaf nodes. With a clustered index, the leaf nodes of the index are also the data pages of the table. Any levels of the index between the root and leaf nodes are referred to as intermediate nodes. All index key values are stored in the clustered index levels in sorted order. To locate a data row via a clustered index, SQL Server starts at the root node and navigates through the appropriate index pages in the intermediate levels of the index until it reaches the data page that should contain the desired data row(s). It then scans the rows on the data page until it locates the desired value. There can be only one clustered index per table. This restriction is driven by the fact that the underlying data rows can be sorted and stored in only one way. With very few exceptions, every table in a database should have a clustered index. The selection of columns

Download from www.wowebook.com

Types of Indexes

793

Intermediate Page Albert

Data Page

Brown

Albert, John, ...

Root Page

Exeter

Alexis, Amy, ...

Albert

Houston

Amundsen, Fred, ...

Jones Mason Quincy

Jones Jude Klein

Baker, Joe, ... Best, Elizabeth, ... ...

Loon Mason, Emma, ...

Neenan

Narin, Mabelle, ...

Parker

Naselle, Juan, ...

Paul

Neat, Juanita

...

...

25

Mason

Masonelli, Irving, ...

FIGURE 25.1 A simplified diagram of a clustered index. for a clustered index is very important and should be driven by the way the data is most commonly accessed in the table. You should consider using the following types of columns in a clustered index: . Those that are often accessed sequentially . Those that contain a large number of distinct values . Those that are used in range queries that use operators such as BETWEEN, >, >=,