Wrox.Beginning.Microsoft.SQL.Server.2008.Admini.. - X

Wrox.Beginning.Microsoft.SQL.Server.2008.Admini.. - X
spine=1.632"
Programmer to Programmer™
Get more out of
WROX.com
Beginning
Microsoft
®
SQL Server 2008 Administration
®
Professional Microsoft SQL Server 2008 Integration
Services
978-0-470-24795-2
This book shows developers how to master the 2008 release of SSIS, covering topics
including data warehousing with SSIS, new methods of managing the SSIS platform,
and improved techniques for ETL operations.
Professional SQL Server 2008 Reporting Services
978-0-470-24201-8
This book teaches solutions architects, designers, and developers how to use
Microsoft’s reporting platform to create reporting and business intelligence solutions.
Professional Microsoft SQL Server 2008 Analysis Services
978-0-470-24798-3
Interact
Chapters on Demand
Take an active role online by participating in
our P2P forums
Purchase individual book chapters in pdf
format
This shows readers how to build data warehouses and multidimensional databases,
query databases, and how to use Analysis Services and other components of SQL
Server to provide end-to-end solutions.
Professional Microsoft SQL Server 2008 Programming
978-0-470-25702-9
Wrox Online Library
Join the Community
Hundreds of our books are available online
through Books24x7.com
Sign up for our free monthly newsletter at
newsletter.wrox.com
Wrox Blox
Browse
Download short informational pieces and
code to keep you up to date and out of
trouble!
Ready for more Wrox? We have books and
e-books available on .NET, SQL Server, Java,
XML, Visual Basic, C#/ C++, and much more!
This updated new edition of Wrox’s best-selling SQL Server book has been expanded
to include coverage of SQL Server 2008’s new datatypes, new indexing structures,
manageability features, and advanced time-zone handling.
Professional Microsoft SQL Server 2008 Administration
Enhance Your Knowledge
Advance Your Career
978-0-470-24796-9
A how-to guide for experienced database administrators, this book is loaded with
unique tips, tricks, and workarounds for handling the most difficult SQL Server
administration issues. The authors discuss data capture, performance studio, Query
Governor, and new techniques for monitoring and policy management.
Beginning Microsoft SQL Server 2008 Programming
978-0-470-25701-2
This comprehensive introduction to SQL Server covers the fundamentals and moves on to discuss how to create and change tables, manage
keys, write scripts, work with stored procedures, and much more.
Beginning Microsoft SQL Server 2008 Administration
978-0-470-44091-9
This book teaches both novice and experienced database administrators how to leverage all of the features of SQL Server to deliver solid,
reliable performance. All features and techniques are illustrated with real-world examples and step-by-step instructions. With this book, you’ll
develop the skills required to successfully administer a SQL Server 2008 database, regardless of your experience level.
Contact Us.
Beginning Database Design Solutions
We always like to get feedback from our readers. Have a book idea?
Need community support? Let us know by e-mailing [email protected]
This introduces IT professionals—both DBAs and database developers—to database design. It explains what databases are, their goals,
and why proper design is necessary to achieve those goals. It tells how to decide what should be in a database to meet the application’s
requirements. It tells how to structure the database so the database performs well while minimizing the chance for error.
978-0-470-38549-4
Leiter ffirs.tex V2 - 03/25/2009
1:24pm
Beginning Microsoft® SQL Server® 2008 Administration
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Chapter 1: Introducing SQL Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 2: Installing SQL Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 3: SQL Server 2008 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapter 4: SQL Server 2008 Storage Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapter 5: SQL Server 2008 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Chapter 6: SQL Server 2008 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Chapter 7: Configuring SQL Server Network Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Chapter 8: Automating Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Chapter 9: Disaster Prevention and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Chapter 10: Monitoring SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Chapter 11: Optimizing SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Chapter 12: SQL Server High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Chapter 13: Introduction to Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Chapter 14: Introduction to the Common Language Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Chapter 15: An Administrator’s Guide to Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . 639
Chapter 16: Introduction to SQL Server Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Chapter 17: Introduction to SQL Server Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Chapter 18: Introduction to SQL Server Reporting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Chapter 19: Introduction to Service Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Page i
Leiter ffirs.tex
V2 - 03/25/2009
1:24pm
Page ii
Leiter
ffirs.tex V2 - 03/25/2009
1:24pm
Beginning
Microsoft® SQL Server® 2008 Administration
Page iii
Leiter ffirs.tex
V2 - 03/25/2009
1:24pm
Page iv
Leiter ffirs.tex V2 - 03/25/2009
1:24pm
Beginning
Microsoft® SQL Server® 2008 Administration
Chris Leiter
Dan Wood
Albert Boettger
Michael Cierkowski
Wiley Publishing, Inc.
Page v
Leiter ffirs.tex
V2 - 03/25/2009
Beginning Microsoft® SQL Server® 2008 Administration
Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com
Copyright © 2009 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-0-470-44091-9
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
Library of Congress Cataloging-in-Publication Data
Beginning Microsoft SQL server 2008 administration / Chris Leiter ... [et al.].
p. cm.
Includes index.
ISBN 978-0-470-44091-9 (paper/website)
1. SQL server. 2. Database management. 3. Relational databases. I. Leiter,
Chris, 1975QA76.9.D3B4465 2009
005.4’476--dc22
2009004135
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any
means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections
107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or
authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood
Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201)
748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties
with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties,
including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended
by sales or promotional materials. The advice and strategies contained herein may not be suitable for every
situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting,
or other professional services. If professional assistance is required, the services of a competent professional person
should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an
organization or Web site is referred to in this work as a citation and/or a potential source of further information
does not mean that the author or the publisher endorses the information the organization or Web site may provide
or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may
have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services please contact our Customer Care Department within the
United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related trade dress
are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other
countries, and may not be used without written permission. Microsoft and SQL Server are registered trademarks of
Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their
respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
available in electronic books.
1:24pm
Page vi
Leiter
ffirs.tex V2 - 03/25/2009
1:24pm
For my wife, Bridget Your patience, love, and support have made everything I have, and everything I am, possible.
Thanks for believing in me
— Chris Leiter
I dedicate my contribution of this book to my dad, Reginald Kaaikaula Wood, who lost his battle with cancer while
I was writing this book. He was a great encouragement and proud that his son was a published author even though
he said, ‘‘I don’t understand a darn word of it.’’ My dad left an amazing legacy and he will be missed.
— Dan Wood
I dedicate this book to my daughter, Rachel. Watching you grow and re-experiencing the beauty and wonder of the
world through your eyes, is and has been the greatest joy in my life. So few years to give you wings to fly.
I love you.
— Albert Boettger
I would like to dedicate this accomplishment to my daughter, Alina. You are the best thing that has ever happened
to me and I love you very much.
— Michael Cierkowski
Page vii
Leiter ffirs.tex V2 - 03/25/2009
1:24pm
Page viii
Leiter
f02.tex
V3 - 03/25/2009
1:26pm
About the Authors
Chris Leiter (Auburn, WA) is a Senior Consultant for Hitachi Consulting. His primary focus is Microsoft’s
Business Intelligence and Performance Management products. Chris has been a Microsoft Certified Professional since 1997 and a Microsoft Certified Trainer since 2001. He currently holds the MCSE: Security,
MCITP: Database Administrator, and ITIL: Foundation certifications. Chris is also co-author of Beginning
SQL Server 2005 Administration by Dan Wood, Chris Leiter, and Paul Turley from Wrox Press 2006. When
not writing about or working with Microsoft SQL Server, he enjoys watching movies from his extensive
DVD collection with his wife, Bridget, and their cat, Cosmo. Chris contributed Chapters 1, 2, 3, 6, 7, 8, 12,
13, 15, 16, 17, and 19.
Dan Wood (Silverdale, WA) is the senior database administrator for Avalara, a sales tax compliance
company where he both administers and develops database solutions for several enterprise applications
that handle global address validation, tax rate calculation, and sales tax remittance for e-commerce and
ERP clients. He has been working with SQL Server as a DBA, consultant, and trainer since 1999. Dan
was a co-author on Beginning Transact-SQL with SQL Server 2000 and 2005 by Paul Turley and Dan Wood
(2005) and Beginning T-SQL with Microsoft SQL Server 2005 and 2008 by Paul Turley and Dan Wood (2008)
and the lead author of Beginning SQL Server 2005 Administration, all from WROX press. Dan contributed
Chapters 4 and 9.
Albert Boettger (Federal Way, WA) is the Senior Software Engineer and Database Administrator for
Sagem Morpho, Inc. Albert has more than 20 years of experience as a solution developer, database architect, and software engineer. Albert contributed Chapters 10 and 11.
Michael Cierkowski (Maple Valley, WA) currently works as an instructor for Netdesk Corporation,
with a primary focus on SQL Server Administration. Michael has been a Microsoft Certified Professional
and Trainer since 2000. He currently holds his MCSD, MCDBA, MCAD, MCSA, MCPD: (Windows,
Web, and Enterprise), and MCITP: (Database Administrator, Database Developer, BI Developer, Server
Administrator, and Enterprise Administrator). Michael contributed Chapters 5, 14, and 18.
Page ix
Leiter f02.tex
V3 - 03/25/2009
1:26pm
Page x
Leiter
f03.tex
Credits
Executive Editor
Bob Elliott
Development Editor
Maureen Spears
Technical Editor
Jim Adams
Senior Production Editor
Debra Banninger
Copy Editor
Cate Caffrey
Vice President and Executive
Group Publisher
Richard Swadley
Vice President and Executive
Publisher
Barry Pruett
Associate Publisher
Jim Minatel
Project Coordinator, Cover
Lynsey Stanford
Editorial Manager
Mary Beth Wakefield
Proofreader
Nancy Carrasco
Production Manager
Tim Tate
Indexer
J & J Indexing
V3 - 03/25/2009
1:27pm
Page xi
Leiter f03.tex
V3 - 03/25/2009
1:27pm
Page xii
Leiter f04.tex
V3 - 03/25/2009
1:30pm
Acknowledgments
First and foremost, I thank my wife, Bridget, for once again supporting and encouraging me through this
process. It’ll be nice to have our evenings back. Thanks also to Dan Wood, for letting me take the reins
on this one. I’m really glad that you were able to stay on as a Contributing Author. Michael Cierkowski
and Albert Boettger also deserve my gratitude for stepping up to the plate and co-authoring this book.
Both of you are absolutely brilliant, and I’m lucky to know you. I also thank Lance Baldwin, one of the
best people I’ve had the privilege of working for (twice!), and Paul Turley, who helped Dan and me
get introduced to Wiley. And speaking of Wiley, I must also thank Bob Elliott for his support on this
project and faith that I could pull it all together; Maureen Spears for having the patience of a saint; and
Jim Adams, who never let anything get by him (and provided a huge contribution to Chapter 17!). There
are several other people whom I would like to thank for helping me in one way or another during the
process of creating this book. They include (in no particular order) Jeff Sparks, for constantly feeding my
ego; Rick Kinglsan, for setting the bar and letting me raise it; D.J. Norton, for being as much of a gadget
geek as I am; Stephanie Gulick, for being so supportive; everyone at Hitachi Consulting; and, of course,
the Banz and Leiter families, who put up with me working through yet another holiday season.
— Chris Leiter
A great deal of thanks to Chris Leiter for taking over this book and being an outstanding Project Lead.
Special thanks to all the wonderful people at Wrox for their patience for missed deadlines and support
when my dad was ill. Lastly, but most importantly, my gratitude and undying love goes to my beautiful
wife, Sarah, who supported me through yet another book project and expressed her pride and love while
spending many nights and weekends without me. Thank you, my love.
— Dan Wood
A special thanks to Chris Leiter for convincing me to join the team and introducing me to Wiley Publishing. You were right. Thank you to Jeff Sparks for being a friend and mentor, and for always pushing me
to explore and master new technologies. Your opinions and insights were invaluable. Thanks to everyone at Wiley Publishing who helped to make this book a reality, and especially to Bob Elliot for all his
hard work. Thanks, Maureen, for keeping us all on schedule and answering all of our questions (kind of
like herding cats), and to Jim for his excellent technical editing. To my loving wife, Elise, and beautiful
daughter, Rachel, thank you for your love, patience, and understanding. You mean more to me than
words can convey.
— Albert C. Boettger
First, I thank both Dan and Chris for considering me for this project. It has been a wonderful experience
working with you, and I hope we can do it again sometime. I also thank everyone at Wrox for making the
entire process a fairly painless affair. And finally, I thank my wife, Stacy, for dealing with many nights
of neglect while I worked on my many projects. I love you more each and every day. A task that I didn’t
think was possible.
— Michael Cierkowski
Page xiii
Leiter
f04.tex
V3 - 03/25/2009
1:30pm
Page xiv
Leiter
ftoc.tex V3 - 03/25/2009
1:31pm Page xv
Contents
Introduction
Chapter 1: Introducing SQL Server 2008
A Condensed History of SQL Server
In the Beginning
The Evolution of a Database
Microsoft Goes It Alone
BI for the Masses
2008 . . . and Beyond!
What Is SQL Server 2008?
Database Engine
Integration Services
Analysis Services
Reporting Services
Service Broker
Data Tier Web Services
Replication Services
Multiple Instances
Database Mail
A Note about Notification Services
SQL Server 2008 Editions
SQL Server Compact 3.5 SP1
SQL Server 2008 Express Edition
SQL Server 2008 Web Edition
SQL Server 2008 Workgroup Edition
SQL Server 2008 Standard Edition
SQL Server 2008 Enterprise Edition
SQL Server 2008 Architecture
xxvii
1
1
1
1
2
2
3
3
3
5
5
6
6
6
6
6
7
7
7
8
9
9
10
10
10
11
SQL Server 2008 Communication
SQL Server 2008 Services
11
13
SQL Server 2008 Database Objects
15
Server
Database
Schema
Object Names
15
16
16
16
Leiter ftoc.tex V3 - 03/25/2009
Contents
SQL Server 2008 Databases
System Databases
User Databases
Distribution Databases
SQL Server 2008 Database Storage
Data Files and Filegroups
Log Files
SQL Server Security
Windows Authentication Mode
SQL Server and Windows Authentication Mode (Mixed Mode)
Summary
Chapter 2: Installing SQL Server 2008
SQL Server Installation Planning
18
18
20
20
20
21
21
22
22
22
23
25
25
Hardware Considerations
Processor Considerations
Memory Considerations
Storage Considerations
Virtualization Considerations
Software Prerequisites
26
27
27
28
32
32
SQL Server Installation Center
34
Setup Support Rules (for Setup Support Files)
Setup Support Rules (for Installation)
Feature Selection
Installing to a Windows Cluster
Configuring the Virtual Server Name
Sample Databases
Installation Review
Summary
34
36
37
45
46
49
50
50
Chapter 3: SQL Server 2008 Tools
51
SQL Server Management Studio
52
Tool Windows
Toolbars
SQL Server Management Studio Configuration
Log File Viewer
SQL Server Business Intelligence Development Studio
SQL Server Profiler
SQL Server Trace
Trace Properties
xvi
53
65
82
90
91
93
93
94
1:31pm
Page xvi
Leiter ftoc.tex V3 - 03/25/2009
1:31pm
Contents
Database Engine Tuning Advisor
General Tab
Tuning Options Tab
SQL Server Configuration Manager
Reporting Services Configuration Manager
Command-Line Tools
SQLCMD
Bulk Copy Program (BCP)
PowerShell
Summary
Chapter 4: SQL Server 2008 Storage Architecture
The Resource Database
The sys Schema
SQL Server Database Physical Structure
Physical Storage Data Types
FILESTREAM Data
Other Data Types
SQL Server Database Files
Data Files
Transaction Log
Summary
Chapter 5: SQL Server 2008 Databases
System Databases
User Databases
Database Planning
97
98
99
100
100
102
102
104
106
109
111
112
112
113
114
118
119
119
120
123
127
129
129
129
129
Capacity Planning
130
Creating Databases
131
Getting Started
Creating a New Database
Schemas
Tables
Indexes
Enforcing Data Integrity
Database Diagrams
Views
System Views
Synonyms
Programming Objects
132
132
152
155
165
181
190
191
191
192
193
xvii
Page xvii
Leiter
ftoc.tex V3 - 03/25/2009
Contents
Stored Procedures
Functions
Triggers
Assemblies
Types
Defaults
Rules
Summary
Chapter 6: SQL Server 2008 Security
SQL Server Authentication Modes
Changing the Authentication Mode from Management Studio
Using the xp_instance_regwrite Extended Stored Procedure
Principals
Logins
Credentials
Server Roles
Database Users
Fixed Database Roles
Permissions
Server Permissions
Database Scope Permissions
Schema Scope Permissions
Using SQL Server Management Studio for Managing Permissions
SQL Server Encryption
Extensible Key Management (EKM)
Encryption Tools
Best Practices
Summary
Chapter 7: Configuring SQL Server Network Communication
SQL Server 2008 Network Protocols
193
193
194
196
196
199
200
200
201
201
202
202
204
205
210
212
214
219
225
229
235
238
240
243
246
246
257
259
261
261
Shared Memory
Named Pipes
TCP/IP
Virtual Interface Adapter (VIA)
262
262
262
264
SQL Native Client Configuration
SQL Server Endpoints
264
265
Default TSQL Endpoints
TSQL TCP Endpoints
Database Mirroring Endpoints
266
269
270
xviii
1:31pm
Page xviii
Leiter ftoc.tex V3 - 03/25/2009
1:31pm
Contents
SOAP Endpoints
Service Broker Endpoints
Securing Endpoints
Summary
Chapter 8: Automating Administrative Tasks
Policy-Based Management
Targets
Facets
Conditions
Policies
Policy Categories
Effective Policies
Central Management Servers
Database Mail
How It Works
How to Configure Database Mail
Configuring Database Mail Options
Managing Profiles and Accounts
Guidelines for Deleting Mail Objects
Sending Mail
Managing Messages
Event Notifications
SQL Server Agent
Configuring the SQL Server Agent Service
SQL Server Agent Security
Creating Jobs
Creating Schedules
Creating Operators
Creating Alerts
Creating Proxies
Multi-Server Jobs
Maintenance Plans
Maintenance Plan Wizard
Maintenance Plan Designer
Best Practices
Summary
Chapter 9: Disaster Prevention and Recovery
Chapter Preparation
Database Recovery Models
272
278
278
284
285
286
286
287
287
288
289
289
292
294
294
295
300
301
309
310
314
315
316
316
321
323
335
342
345
353
356
358
358
358
360
361
363
363
365
xix
Page xix
Leiter
ftoc.tex V3 - 03/25/2009
Contents
Full Recovery Model
Bulk-Logged Recovery Model
Simple Recovery Model
SQL Server 2008 Database Backup
Backup Devices
SQL Server 2008 Backup Types
Full Backup
Differential Backup
File/Filegroup Backup
Transaction Log Backup
Partial Backup
Copy Only Backup
Backup Options
Backup Stripe
Mirrored Backup
Compressed Backup
WITH Options
Backup Strategies
Full Backup Only
Full Backup with Differential
Full Backup with Transaction Log
Full and Differential Backup with Transaction Log
File and Filegroup Backup
Filegroup with Differential
Partial Backup
Backup Summary
367
367
369
369
370
370
371
371
372
372
372
372
373
373
375
375
376
376
377
377
378
378
378
Restoring Databases
379
Restore Process
Delaying Recovery
379
380
RESTORE Command
RESTORE DATABASE database_name
FROM Options
WITH Clause
Database Restore Preparation
Restoring User Databases
Recovering System Databases
Database Restore Summary
Database Snapshots
Database Snapshot Limitations
Disaster Recovery and Database Snapshots
Summary
xx
365
366
366
380
381
382
382
385
387
393
395
396
398
398
400
1:31pm Page xx
Leiter ftoc.tex V3 - 03/25/2009
1:31pm
Contents
Chapter 10: Monitoring SQL Server
Performance Monitoring
Performance Monitoring Strategy
Creating a Performance Baseline
Tools and Techniques for Monitoring
Log File Viewer
Activity Monitor
System Stored Procedures
Using Profiler
Monitoring Files
Auditing
SQL Server Audit
Login Auditing
C2 Audit Mode
Security Audit Event Category
SQL Trace
Tracking Changes
Change Data Capture
Change Tracking
Data Collection
Terminology
Architecture and Processing
Configuring Data Collection
Data Collector Types
Data Collection Sets
Error Handling
Reporting
Management Data Warehouse
Monitoring Database Modifications
Data Definition Language (DDL) Triggers
Summary
Chapter 11: Optimizing SQL Server
401
401
402
403
409
410
411
413
420
427
430
430
438
440
441
442
444
444
452
455
456
456
458
461
461
465
466
466
468
469
472
473
Hardware Optimization
474
CPU Selection
Hyperthreading
Memory
Storage Options
Network Design
Virtualizing SQL Server
475
475
475
476
477
478
xxi
Page xxi
Leiter ftoc.tex V3 - 03/25/2009
Contents
Design Considerations
Database Recovery Model
Designing Efficient Tables
Declarative Referential Integrity (DRI)
Constraints versus Triggers
Deciding What to Index
Indexed Views and Filtered Indexes
Minimizing Blocking
Hidden Dangers of Time-Outs
Query Optimization
Execution Plans
Updating Statistics
Managing Indexes
Query Optimizer Hints
Plan Guides
Database Engine Tuning Advisor
T-SQL Optimization Tips
Limiting Result Sets
ANSI-Style Join Syntax
Dealing with Null Values
Alternatives to Cursors
Merge Joins
Grouping Sets
Distinct Aggregation
How Many Records Are in That Table?
Temp Tables versus Table Variables
Resource Governor
Configuring the Resource Governor
Monitoring the Resource Governor
Summary
Chapter 12: SQL Server High Availability
Introduction to High Availability
Failover Clustering
Windows Clustering — A Quick Primer
Clustering Components
Active/Passive Clustering
Active/Active Clustering
Considering Clustering
Log Shipping
Preparing for Log Shipping
Configuring Log Shipping with SQL Server Management Studio
xxii
478
479
480
485
488
488
494
497
498
499
500
504
504
510
512
517
526
527
530
531
533
534
536
537
538
539
540
541
545
551
553
553
554
555
556
556
557
558
558
558
558
1:31pm
Page xxii
Leiter
ftoc.tex V3 - 03/25/2009
1:31pm
Contents
Configuring Log Shipping with Transact-SQL
Configuring Failover
Database Mirroring
Client Redirection
Database Mirroring Modes
Configuring Database Mirroring
Monitoring Database Mirroring
Managing Database Mirroring
Summary
Chapter 13: Introduction to Replication
Replication Overview
SQL Server Replication Agents
Snapshot Agent
Log Reader Agent
Distribution Agent
Merge Agent
Queue Reader Agent
SQL Server Replication Types
Distributed Transactions
Transactional Replication
Snapshot Replication
Merge Replication
Oracle Replication
SQL Server Replication Models
Single Publisher/Multiple Subscribers
Multiple Publishers/Single Subscriber
Multiple Publishers/Multiple Subscribers
Replication Tools
Filtering
Replicating Partitioned Tables and Indexes
New Publication Wizard
New Subscription Wizard
Replication Monitor
Summary
Chapter 14: Introduction to the Common Language Runtime
Databases and Programming
Is Transact-SQL Going Away?
.NET and the CLR
563
571
572
574
574
576
581
584
587
589
589
590
591
591
591
591
591
591
592
593
594
594
595
595
595
596
596
596
596
598
598
601
602
605
607
607
608
609
xxiii
Page xxiii
Leiter ftoc.tex V3 - 03/25/2009
Contents
Assemblies
Namespaces
Classes
Methods
SQL Server CLR Objects
609
609
609
610
610
Enabling SQL CLR
Creating a SQL CLR Assembly
Adding an Assembly
Compatible Data Types
User-Defined Functions
Stored Procedures
Triggers
User-Defined Types
Aggregates
611
611
617
618
619
621
622
623
627
Deployment with Visual Studio
Programming Support
629
632
Threading
Impersonation
Security Options
.NET Security
Securing SQL CLR
SQL Server CLR Permission Sets
Summary
Chapter 15: An Administrator’s Guide to Business Intelligence
Understanding BI
Performance Management
Business Intelligence Components
Data Goes In, Data Comes Out
Analyze This!
Did You Get the Memo about Cover Pages?
Beyond SQL
The BI Side of SharePoint
ProClarity and PerformancePoint Server
So Many Tools, So Little Time
Summary
Chapter 16: Introduction to SQL Server Integration Services
About SSIS
Integration Services
Integration Services Object Model
xxiv
633
633
633
634
634
634
637
639
639
640
640
640
641
642
642
642
643
644
644
645
645
646
647
1:31pm
Page xxiv
Leiter ftoc.tex V3 - 03/25/2009
1:31pm
Contents
Integration Services Run Time
Integration Services Data Flow
648
648
Importing and Exporting Data
649
Using the Import Wizard
Using the Export Wizard
Transforming Data with SSIS
Understanding the Development Environment
Package Elements
Creating a Simple Package
Summary
Chapter 17: Introduction to SQL Server Analysis Services
Understanding OLAP
OLAP Terminology
Working with SSAS
Creating the Project
Defining a Data Source
Creating the Data Source View
Defining Dimensions
Creating the Cube
Create Hierarchies
Deploying the Project
Managing SSAS
Browsing the Cube
SSAS Security
Advanced SSAS Concepts
MDX
Data Mining
Summary
Chapter 18: Introduction to SQL Server Reporting Services
SQL Server Reporting Services Overview
Components and Tools
Installation and Configuration
Hardware and Software Requirements
Security Considerations
Installation Mode
Multiple Instances and Versions
649
656
658
659
661
670
675
677
677
678
679
679
679
682
684
684
686
695
696
697
698
702
703
704
705
707
707
708
717
717
718
719
719
Creating Reports
720
Report Designer
Report Builder
720
721
xxv
Page xxv
Leiter ftoc.tex V3 - 03/25/2009
Contents
Report Delivery
729
Caching
Snapshots
Subscriptions
729
729
730
Summary
Chapter 19: Introduction to Service Broker
Service-Oriented Architecture
Service Broker Overview
Service Broker Elements
Conversations
Contracts
Queues
Services
Routes
Security Considerations for Service Broker
Dialog Security
Transport Security
Creating a Sample Application
Creating and Preparing the Database
Creating the Service Broker Objects
Creating Objects for the TicketInputService
Creating Objects for the TicketNotifyService
Testing the Application
Managing Service Broker with SSMS
Summary
Index
xxvi
731
733
733
734
734
734
737
737
737
737
738
738
739
739
740
741
744
746
749
753
753
755
1:31pm
Page xxvi
Leiter f05.tex
V3 - 03/25/2009
1:39pm
Introduction
Microsoft officially announced SQL Server 2008, codenamed Katmai, at the first Microsoft Business Intelligence (BI) conference in May 2007. I suppose I had the same reaction as many others — ‘‘Already?’’
SQL Server 2005 had only been released a year and a half earlier, and I started to wonder if it was too
soon. I can’t tell you why I thought that. I also knew that it wasn’t unusual for Microsoft’s product teams
to start planning for the next version of a product by the time the current version had been released. I
knew that the time between the SQL Server 2000 and the SQL Server 2005 releases was too long. And I
knew that Microsoft was committed to more frequent and consistent release cycles of two to three years
for new versions of SQL Server.
I expected SQL Server 2008 to be more of a product refresh than a full new release. Most of the public
material available hinted at that. It was designed to build on the framework laid out by SQL Server 2005,
which offered two benefits. First, organizations that had already migrated to SQL Server 2005 would
find the transition to SQL Server 2008 to be easier than moving from SQL Server 2000, or other database
products. Additionally, Microsoft had solidified itself as a player in the BI market space by bundling
Analysis Services, Integration Services, and Reporting Services as part of the SQL platform.
What I didn’t expect was that some of the changes made were not incidental, but fairly significant. As
you’ll read in this book, Notification Services is gone, and Reporting Services no longer uses Internet
Information Services to publish access to the Report Server. Having decided to withhold judgment for
the time being, I have to admit I was concerned about how existing implementations of both these tools
would be affected.
As information about Katmai became available, I tried to absorb as much as I could. I read articles online
and in print magazines that outlined new features to make management of the system, and data, much
easier. One of the more compelling features for me was FILESTREAM, which allowed files to be stored
in an NTFS file system while still being maintained through SQL. I immediately saw how this feature
could be leveraged for a product that had been developed by my co-workers for receiving, archiving,
and forwarding Electronic Fingerprint Transmission records. Looking beyond that, I could envision how
other Microsoft products, like SharePoint, might eventually leverage FILESTREAM for storing extremely
large files that, if stored as BLOB data, would cause the database size to quickly become unwieldy and
difficult to manage.
In 2007, Microsoft announced that it intended to release Windows Server 2008, SQL Server 2008, and
Visual Studio 2008 on February 27, 2008. They had been releasing CTPs on a fairly regular schedule every
couple of months or so. However, by the time CTP 6 had come around in February 2008, it was clear that
SQL Server 2008 (and Visual Studio 2008) would not be ready by the intended release date. Microsoft has
announced that they were targeting Q3 of 2008 for a release. Being somewhat of a cynic, I honestly didn’t
expect to see a release until November 2008. In fact, I thought it would have been appropriate to release
it on November 7, coinciding with the third anniversary of the release of SQL Server 2005.
Page xxvii
Leiter
f05.tex
V3 - 03/25/2009
Introduction
CTP 6 was considered to be ‘‘feature complete,’’ which meant that changes from that point on were
likely to be cosmetic, or relatively insignificant. At this point, components such as Data Compression,
Policy-Based Management, and the Resource Governor had been through the ringer by beta testers and
application developers, and most were happy with what they saw.
SQL Server 2008 was officially released on August 6, 2008 (although MSDN and TechNet subscribers
had already been able to access it for a week). By this time, its features, tools, and components had gone
through rigorous internal certification processes as well as significant public beta testing through the
CTP availability. As I write this, it’s been just over five months since the release of SQL Server 2008. I,
and my associates, have had a chance to put SQL Server 2008 through its paces in both production and
test environments. While, admittedly, there have been some growing pains, I believe that SQL Server
2008 is a solid product. I have worked with a number of people who often state, ‘‘I won’t install Product
X until at least Service Pack 1!’’ Because SQL Server 2008 is built on a stable SQL Server 2005 platform
and improves upon it, I find it hard to justify a statement like that.
A common theme I reiterate with my clients, and also throughout this book, is that SQL Server is much
more than a relational database management system. While the heart of SQL Server is, and always will
be, the Database Engine, it’s the client features, the performance management tools, the data integrity
components, and the Business Intelligence solutions that make SQL Server an attractive solution to many
people — DBAs and business users alike.
If you’re reading this book, then chances are you’re responsible for managing a SQL Server 2008 system,
or you will be. Several years ago, when I worked for a training company in Seattle, I would find that
students would usually (although not always) fit into one of three categories. The most common was
IT administrators who have ‘‘inherited’’ a SQL Server. Typically, this would be a new server that was
required by a new application or service the business was implementing. These students would have a
good working knowledge of Windows system management, but were new to SQL. If you find that you
fit in this category, this book is for you.
Another type of student I frequently saw was the developer who was involved in a project that used a
SQL Server database for storing application data. These developers understood how the data needed to
be stored, but were responsible for configuring and managing the development and test environments.
Often, they would have limited (if any) knowledge of systems administration, but they knew what they
were trying to accomplish. If you’re one of these developers, this book is for you.
A third category of students I sometimes saw, although admittedly less frequently than the first two,
were experienced DBAs who were familiar with Oracle, or other database technology, who needed to
know how things worked in the Microsoft realm. Although there may be a difference in terminology or
implementation, for the most part, the core technology is pretty standard. If you have experience with
other database applications and are looking to get a better understanding of how Microsoft SQL Server
2008 can meet your needs, this book is for you.
Some of you may not fit into any of these categories, or you may fit into more than one. Whatever
your intent for reading this book is, the subject matter is the same. This book, as the title suggests, is
all about database administration. But what is database administration? Database administrators are
more and more often being called on to perform duties that are not strictly ‘‘administrative’’ in nature.
Along with typical administrative duties such as backups, database maintenance, and user management,
database administrators are increasingly being asked to perform tasks such as building complex data
xxviii
1:39pm Page xxviii
Leiter f05.tex
V3 - 03/25/2009
1:39pm
Introduction
transformations for data import, building distributed data solutions, and maintaining the security and
integrity of the database while enabling the integration of managed-code into the Database Engine.
In a nutshell, for many organizations, the database administrator has become the one-stop shop for all
things related to data storage. This makes the job of being a database administrator much more complicated and difficult than in the past because of the scope and power of each subsequent release.
As a result of the database administrator’s increasingly broadening role in the enterprise, it is impossible
for one book to adequately cover every facet of this critical skill set. This book lays the foundation by
covering in detail the most common database administrative tasks. It will also introduce you to many
of the more advanced areas that enterprise database administrators need to be familiar with. Read these
pages carefully, and apply what you learn. From here, move on to more complex jobs and tasks. The
opportunities for talented and hard-working database administrators are virtually unlimited.
Who This Book Is For
I’ve already given you an outline of who might be reading the book. When Dan Wood and I originally
set out to write a book on SQL Server Administration, we knew our primary audience would be IT
professionals (both developers and administrators) who have found themselves responsible for the management and maintenance of a SQL Server database. You may have been responsible for another database
application, or even an earlier version of SQL, when you learned that SQL Server 2008 was now going to
be part of the business plan.
We wrote this book for you. You may be thinking, ‘‘I’m a senior DBA and this book’s title is Beginning
Microsoft SQL Server 2008 Administration. I am not a beginner.’’ I understand. However, we also wrote
this book for you. Although SQL Server 2008 is based on SQL Server 2005, there are some key differences
that are addressed in this book. SQL Server 2008 is also a dramatic departure from even earlier versions,
and, even if you are an expert on SQL Server 2000 or SQL Server 7, you will find a great deal of very
useful information in this book. Go ahead, flip through the pages, and check it out for yourself. I believe
you will find what you’re looking for.
A Note about This Second Edition
This book is technically a second edition of Beginning SQL Server 2005 Administration. If you’ve read
through our first book (and we thank you, by the way), you may already be familiar with some of the
concepts in this book. However, each chapter has been updated to accommodate new features and tools
that are in SQL Server 2008 that were not available in its predecessor.
Assumptions
Even though we made no assumptions about prior SQL Server experience in this book, we did make
a couple of other assumptions. This book assumes that you are familiar with relational database concepts. It also assumes that you are comfortable with navigating a Windows Operating System (all of our
examples were built using Windows Server 2008). Probably the biggest assumption is that you are at
least marginally experienced with the Structured Query Language (SQL). The examples in this book are
all clearly defined, but there will be times when you will be required to alter the provided scripts to work
xxix
Page xxix
Leiter
f05.tex
V3 - 03/25/2009
Introduction
in your environment. A basic knowledge of SQL will be invaluable in this case. Beginning T-SQL with
Microsoft SQL Server 2005 and 2008 (Wiley, 2008) is a great resource if you need some help in this area.
What This Book Covers
As much as we would like to have included everything that any database administrator might need
for any given circumstance, there just isn’t enough time or paper to cover it all. We have made every
attempt to cover the main areas of SQL Server 2008 Administration. Inside this book, you will find
detailed information about how to maintain and manage your SQL Server 2008 installation. Most of
the day-to-day tasks of the DBA are described within the pages of this book. Installation, configuration,
backups, restores, security, availability, performance monitoring, and the tools to manage these areas are
all covered. Our intent, our goal, and our sincere desire are to provide you with the information necessary
to be a competent and successful database administrator.
With this edition, we were also able to add additional material that was not covered in the first edition.
This includes new chapters on SQL Server Analysis Services and SQL Server Reporting Services, the two
key offerings in the Microsoft SQL Server BI stack. There is also a new chapter on optimizing SQL Server
2008 that beginners and experienced DBAs alike will find useful.
How This Book Is Structured
When putting this book together, we made a conscious effort to cover the material in a logical and sequential order:
❑
The first four chapters (Chapters 1–4) cover the overall structure of SQL Server 2008, as well as
the installation process.
❑
Once that foundation is laid, we moved on to the administration process of building and securing databases in the next two chapters (Chapters 5 and 6).
❑
This is followed by seven chapters (Chapters 7–13) on specific administrative tasks and
high-availability solutions.
❑
The last six chapters (Chapters 14–19) are dedicated to introducing you to the SQL Server 2008
services, and features including the Common Language Runtime (CLR), SQL Server’s Business
Intelligence offerings, and the Service Broker.
As mentioned, we tried to follow a logical order in the structure of this book, but like most technical
books, it is not absolutely essential to read it in any particular order. However, if you are fairly new to
SQL Server, you may want to read through Chapter 1 first to get an overall picture of the product before
diving in to the remaining chapters.
What You Need to Use This Book
To take full advantage of this book, you will need to have an edition of SQL Server 2008 installed
along with the AdventureWorks2008 sample database. To perform all the steps outlined in the following chapters, the Developer Edition (with its full support of the Enterprise Edition feature set) is highly
xxx
1:39pm
Page xxx
Leiter f05.tex
V3 - 03/25/2009
1:39pm
Introduction
recommended. In order to duplicate the examples in Chapter 14, ‘‘Introduction to the Common Language
Runtime,’’ as well as the example on using SOAP endpoints in Chapter 7, you will also need to have
either Visual Basic 2008 or Visual C# 2008 installed (Visual Studio 2008 Professional is recommended).
Conventions
To help you get the most from the text and keep track of what’s happening, we’ve used a number of
conventions throughout the book.
Examples that you can download and try out for yourself generally appear in a box like this:
Try It Out
The ‘‘Try It Out’’ is an exercise you should work through, following the text in the book.
1.
2.
3.
They usually consist of a set of steps.
Each step has a number.
Follow the steps through with your copy of the database.
Boxes like this one hold important, not-to-be forgotten information that is directly
relevant to the surrounding text.
Tips, hints, tricks, and asides to the current discussion are offset and placed in italics like this.
Styles in the text are presented as follows:
❑
We highlight new terms and important words when we introduce them.
❑
We show keyboard strokes like this: [Ctrl]+A.
❑
We show URLs and code within the text like so: persistence.properties.
❑
We present code in two different ways:
We use a monofont type with no highlighting for most code examples.
We use gray highlighting to emphasize code that’s particularly important in the
present context.
Source Code
As you work through the examples in this book, you may choose either to type in all the code manually or
to use the source code files that accompany the book. All of the source code used in this book is available
for download at www.wrox.com. Once at the site, simply locate the book’s title (either by using the Search
box or by using one of the title lists) and click on the ‘‘Download Code’’ link on the book’s detail page to
obtain all the source code for the book.
xxxi
Page xxxi
Leiter f05.tex
V3 - 03/25/2009
Introduction
Because many books have similar titles, you may find it easiest to search by ISBN; this book’s ISBN is
978-0-470-44091-9.
Once you download the code, just decompress it with your favorite compression tool. Alternatively, you
can go to the main Wrox code download page at www.wrox.com/dynamic/books/download.aspx to see
the code available for this book and all other Wrox books.
Errata
We make every effort to ensure that there are no errors in the text or in the code. However, no one is
perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty
piece of code, we would be very grateful for your feedback. By sending in errata, you may save another
reader hours of frustration, and at the same time you will be helping us provide even higher quality
information.
To find the errata page for this book, go to www.wrox.com and locate the title using the Search box or one
of the title lists. Then, on the Book Search Results page, click on the Errata link. On this page, you can
view all errata that have been submitted for this book and posted by Wrox editors.
A complete book list including links to errata is also available at www.wrox.com/
misc-pages/booklist.shtml.
If you don’t spot ‘‘your’’ error on the Errata page, click on the ‘‘Errata Form’’ link and complete the form
to send us the error you have found. We’ll check the information and, if appropriate, post a message to
the book’s Errata page and fix the problem in subsequent editions of the book.
p2p.wrox.com
For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a web-based
system for you to post messages relating to Wrox books and related technologies and interact with other
readers and technology users. The forums offer a subscription feature to e-mail you topics of interest of
your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts,
and your fellow readers are present on these forums.
At http://p2p.wrox.com, you will find a number of different forums that will help you not only as you
read this book, but also as you develop your own applications. To join the forums, just follow these steps:
xxxii
1.
2.
3.
Go to p2p.wrox.com and click on the Register link.
4.
You will receive an e-mail with information describing how to verify your account and complete the joining process.
Read the Terms of Use and click Agree.
Complete the required information to join as well as any optional information you wish to
provide and click Submit.
1:39pm
Page xxxii
Leiter
f05.tex
V3 - 03/25/2009
1:39pm Page xxxiii
Introduction
You can read messages in the forums without joining P2P, but in order to post your own messages, you
must join.
Once you join, you can post new messages and respond to messages other users post. You can read
messages at any time on the Web. If you would like to have new messages from a particular forum
e-mailed to you, click on the ‘‘Subscribe to this Forum’’ icon by the forum name in the forum listing.
For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to
questions about how the forum software works as well as many common questions specific to P2P and
Wrox books. To read the FAQs, click the FAQ link on any P2P page.
xxxiii
Leiter f05.tex
V3 - 03/25/2009
1:39pm
Page xxxiv
Leiter c01.tex
V3 - 03/25/2009
1
Introducing SQL Ser ver
2008
Before getting into the meat (or tofu, if you prefer) and potatoes of SQL Server 2008, it’s important
that you understand what exactly it is that you have on your plate. In this chapter, you will learn
about the history of SQL Server, the key components of SQL Server, and the different editions, or
flavors, of SQL Server. This chapter also covers architecture, database objects, database storage, and
server security from a very high level, with more detail to follow in subsequent chapters.
A Condensed Histor y of SQL Ser ver
Now that the world revolves around SQL Server (at least, it feels that way, doesn’t it?), it’s interesting to trace Microsoft SQL Server 2008 back to its humble origins. While this is by no means a
comprehensive history of SQL, it does provide some insight into the evolution of the product, as
well as an idea of where it might be headed. And who knows? This bit of trivia may still show up
in Trivial Pursuit: Geek Edition for a yellow pie slice.
In the Beginning
Microsoft’s foray into the enterprise database space came in 1987 when it formed a partnership
with Sybase to market Sybase’s DataServer product on the Microsoft/IBM OS/2 platform. From
that partnership, SQL Server 1.0 emerged, which was essentially the UNIX version of Sybase’s
DataServer ported to OS/2.
The Evolution of a Database
After several years, the developers at Microsoft were allowed more and more access to the Sybase
source code for test and debugging purposes, but the core SQL Server application continued to be
a product of Sybase until SQL Server 4.2 was released for Windows NT in March 1992.
SQL Server 4.2 was the first true joint product developed by both Sybase and Microsoft. The
Database Engine was still Sybase, but the tools and database libraries were developed by
11:33am
Page 1
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
Microsoft. While SQL Server had been developed to run primarily on the OS/2 platform, the
release of Windows NT heralded in a new era. The developers at Microsoft essentially abandoned any
OS/2 development and focused on bringing a version of SQL Server to Windows NT.
Microsoft Goes It Alone
With the growing success of Sybase in the UNIX market and Microsoft in Windows, the two companies
found themselves competing for market share on a product essentially developed by Sybase. As a result,
in 1994, the two companies terminated their joint development agreement, and Sybase granted Microsoft
a limited license to use and modify Sybase technology exclusively for systems running on Windows.
A year later, in June 1995, Microsoft released the first version of SQL Server developed exclusively by
Microsoft developers — SQL Server 6.0 — but the core technology was still largely Sybase code-base.
Less than a year later, more changes were made, and Microsoft released SQL Server 6.5 in April 1996.
With SQL Server 6.5 complete, the developers on the SQL Server team were beginning work on a new
database system code-named Sphinx. The Sybase code-base was rewritten almost from scratch for Sphinx,
and only a handful of code remained to indicate SQL Server’s humble beginnings in OS/2.
In December 1998, Sphinx was officially released as SQL Server 7.0. The changes from SQL Server 6.5
were readily apparent from the first second a database administrator launched the new Enterprise Manager. Finally, there was a robust and reliable database system that was easy to manage, easy to learn, and
still powerful enough for many businesses.
As SQL Server 7.0 was being released, the next version was already in development. It was code-named
Shiloh. Shiloh became SQL Server 2000 and was released in August 2000. The changes to the underlying data engine were minimal, but many exciting changes that affected SQL Server’s scalability issues
were added (such as indexed views and federated database servers), along with improvements like cascading referential integrity. Microsoft’s enterprise database server was finally a true contender in the
marketplace.
Over the next few years, the SQL team was working on an even more powerful and exciting release
code-named Yukon, which is now SQL Server 2005. After more than five years in development, a product
that some were calling ‘‘Yukon the giant (Oracle) killer’’ was finally released.
BI for the Masses
While calling SQL Server 2005 an ‘‘Oracle killer’’ might have been a bit optimistic, no one can deny the
broad appeal of SQL Server 2005 as a great leap forward for Microsoft. Since its release, it has been the
core technology behind a great number of Microsoft products, including SharePoint, PerformancePoint,
and the System Center family of products. Many third-party vendors have also leveraged SQL for ERP
systems and other software products.
Where SQL Server 2005 really stood apart from its competitors was in its Business Intelligence (BI) offerings. These include tools for moving and transforming data (SQL Server Integration Services), analyzing
data (SQL Server Analysis Services), and reporting on data (SQL Server Reporting Services). These three
components, in addition to Notification Services and the Service Broker, were part of Microsoft’s commitment to make SQL Server 2005 stand out as more than just a Database Engine. The inclusion of these
technologies made SQL Server 2005 extremely attractive to businesses that were just starting to discover
and utilize BI.
2
11:33am
Page 2
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
2008 . . . and Beyond!
In August 2008, Microsoft SQL Server 2008 was released to manufacturing (RTM). While SQL Server 2008
isn’t as much of a paradigm shift from SQL Server 2005 as its predecessor was from SQL Server 2000, it
contains many improvements and new features that make it a compelling upgrade (which we will cover
throughout this book). SQL Server 2000 reached its end-of-life mainstream support in April 2008, which
should also help drive the adoption of SQL Server 2008.
Microsoft has invested heavily in SQL Server as a core technology and key platform, and there doesn’t
appear to be any slowdown in the near future. Rumors continue to persist that Microsoft Exchange and
Active Directory, as well as a new file system, will leverage SQL Server 2008’s Database Engine.
What Is SQL Ser ver 2008?
As you most likely know, SQL Server 2008 is primarily thought of as a Relational Database Management
System (RDBMS). It is certainly that, but it is also much more.
SQL Server 2008 can be more accurately described as an Enterprise Data Platform. It builds on many of the
features that had first been incorporated in SQL Server 2005, while also expanding its offerings to include
several improvements and additions. Primarily known for its traditional RDBMS role, SQL Server 2008
also provides rich reporting capabilities, powerful data analysis, and data mining. It also has features
that support asynchronous data applications, data-driven Event Notification, and more.
This book is primarily focused on the administration of the Database Engine. However, as mentioned,
SQL Server 2008 includes many more features than just the relational engine. In light of that, it is important to start with some point of common reference. This section introduces the features of SQL Server
2008. It is not meant to be all-inclusive, but it will provide the context for the remainder of the book.
Database Engine
The Database Engine is the primary component of SQL Server 2008. It is the Online Transaction Processing (OLTP) engine for SQL Server and has received further enhancements since SQL Server 2005. The
Database Engine is a high-performance component responsible for the efficient storage, retrieval, and
manipulation of relational and Extensible Markup Language (XML) formatted data.
SQL Server 2008’s Database Engine is highly optimized for transaction processing, but offers exceptional
performance in complex data retrieval operations. The Database Engine is also responsible for the controlled access and modification of data through its security subsystem. The Relational Database Engine in
SQL Server 2008 has many improvements to support scalability, availability, security, and programmability. The following list is by no means a comprehensive list, but just a short overview of what’s new in
SQL Server 2008:
❑
Hot Add CPU — If your hardware or software environment supports it, SQL Server 2008 will
allow you to dynamically add one or more CPUs to a running system. These CPUs can be physical, logical, or virtual.
❑
Option to Optimize for Ad Hoc Workloads — SQL Server 2008 includes a new feature that
allows administrators to configure the server to improve plan cache efficiency for ad hoc batches.
With this feature enabled, the Database Engine no longer needs to store fully compiled plans that
will not be reused. Instead, the plan cache stores a stub of the ad hoc workload.
3
Page 3
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
4
❑
SQL Server Extended Events — SQL Server 2005 introduced the ability to associate SQL Profiler
traces with Windows Performance Log counters. This was extremely helpful in identifying
poorly performing queries or the lack of sufficient resources in the system to handle certain
events. SQL Server 2008 takes this a step further by introducing SQL Server Extended Events.
Extended events allow database administrators to get a better understanding of the system
behavior by correlating SQL Server data to the operating system or database applications. This
is handled by directing output from extended events to Event Tracing for Windows (ETW).
❑
Resource Governor — The Resource Governor is a new feature that allows administrators to
specify configuration options that limit the amount of CPU and memory available to incoming
requests. This can help prevent applications or queries from consuming 100 percent of the CPU
or all available memory. The Resource Governor uses configurable workload groups, which
define what the CPU and memory limits are for any session that is classified as being a member of that group. Classification can be performed based on a number of system functions or
user-defined functions.
❑
Policy-Based Management — SQL Server 2008 includes features that allow administrators
greater control over their server environments by enforcing behaviors or constraints through a
policy-based mechanism. In addition to using the included policies, administrators can create
their own policies to configure servers to meet compliance requirements and standardize
naming conventions, thereby simplifying administration.
❑
Centralized Management — Central Management servers are SQL Servers that can be configured to manage multiple servers as part of a group. You can also execute queries against a SQL
Server group that can return results to either a combined set or a separate pane per server. A
Central Management server can also be used to enforce management policies against multiple
target servers simultaneously.
❑
Query Editor IntelliSense — SQL Server Management Studio now provides IntelliSense functionality in the Query Editor. The IntelliSense functionality provides auto-completion ability,
error underlining, quick info help, syntax pair matching, and parameter help.
❑
PowerShell Provider — SQL Server 2008 includes new features that integrate with Windows
PowerShell to help administrators automate many SQL Server 2008 tasks. PowerShell is an
administrative command-line shell and scripting language that can make it easier to perform
many common tasks through automation. The PowerShell provider in SQL Server 2008 exposes
SQL Server Management Objects (SMO) in a structure similar to file system paths. SQL Server
PowerShell also includes several SQL Server cmdlets for running scripts and other common
tasks.
❑
Compressed Indexes and Tables — Compression is now supported for tables, indexes, and
indexed views on either rows or pages. Compression operations will have an effect on performance. Because of this, row and page compression can be configured on a per-partition basis.
For example, you could choose to compress a Read Only partition, but leave a Write-intensive
partition uncompressed to minimize impact on the CPU.
❑
FILESTREAM — FILESTREAM is a new storage mechanism for storing data on the file system,
rather than in the database itself. SQL Server 2008 applications can use FILESTREAM to take
advantage of the storage and performance benefits of the NTFS file system while maintaining
transactional consistency with the files themselves. Developers can leverage FILESTREAM as
a mechanism for allowing large files to be maintained by the application database, without
causing the database to become unnecessarily bloated. (Although this is just speculation on
my part, I would be surprised if future releases of SharePoint didn’t leverage FILESTREAM
storage.)
11:33am
Page 4
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
❑
Partition Switching — Simply put, Partition Switching enables you to move data between partitions for a table or index. Data can be transferred between partitions without disrupting the
integrity of the table or index.
❑
Spatial Data Types — Two new data types have been created for storing planar, or ‘‘flat-earth’’
data as well as ellipsoidal, or ‘‘round-earth’’ data. These data types are known as the geometry
data type and geography data type, respectively.
❑
MERGE Statement — Transact-SQL includes a new MERGE statement that, based on the results of a
join with a source table, can perform INSERT, UPDATE, or DELETE operations against a target table.
For example, you can use MERGE to incrementally update a destination table by comparing the
differences from a source table.
Integration Services
SQL Server Integration Services (SSIS) is Microsoft’s enterprise class data Extract, Transform, and Load
(ETL) tool. SSIS was originally introduced in SQL Server 2005 as a significant re-design of SQL Server
2000’s Data Transformation Services (DTS). SSIS offers a much richer feature set and the ability to create
much more powerful and flexible data transformations than its predecessor, and this has been further expanded in SQL Server 2008. As another component in SQL Server’s BI stack, SSIS provides a
rich environment for moving and transforming data from a variety of source and destinations systems.
SSIS 2008 includes performance enhancements, new ADO.NET components, and a new script environment that integrates with Visual Studio Tools for Applications (VSTA). SSIS is covered in more detail in
Chapter 16.
For a very thorough discussion of this feature of SQL Server 2008, read the book by Brian Knight, Erik
Veerman, Grant Dickinson, Douglas Hinson, and Darren Herbold, Professional Microsoft SQL Server
2008 Integration Services (Wiley, 2008).
Analysis Services
Analysis Services delivers Online Analytical Processing (OLAP) and Data Mining functionality for Business Intelligence applications. As its name suggests, Analysis Services provides a very robust environment for the detailed analysis of data. It does this through user-created, multidimensional data structures
that contain de-normalized and aggregated data from diverse data sources (such as relational databases,
spreadsheets, flat files, and other multidimensional sources). Unlike the OLTP engine, which is optimized for Write performance, the OLAP engine is optimized for Read performance, allowing queries
and reports to return results from millions of rows of data in a short period of time, with minimal (if any)
impact to the OLTP engine.
The Data Mining component of Analysis Services allows the analysis of large quantities of data. This
data can be ‘‘mined’’ for hidden relationships and patterns that may be of interest to an organization’s
data analyst. In fact, a well-known story about data mining involves Wal-Mart, Pop-Tarts, and hurricanes. Data mining revealed that prior to a hurricane event, sales of Pop-Tarts, particularly strawberry
Pop-Tarts, would surge. In fact, they concluded that sales of strawberry Pop-Tarts before a hurricane
were seven times that of normal sales. This allowed Wal-Mart to plan their inventory accordingly and
meet customer demands. What’s interesting about this example is that it seems completely random. Data
mining does not attempt to answer the question of why Strawberry Pop-Tarts sell at a much higher rate,
and sometimes, it may not even matter. Data mining revealed an absolute and consistent pattern that
was used to plan inventory accordingly and paid off for the retailer.
5
Page 5
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
A more detailed introduction to SSAS and Data Mining is in Chapter 17.
Reporting Services
Reporting Services is a Web Service–based solution for designing, deploying, and managing flexible,
dynamic web-based reports, as well as traditional paper reports. These reports can contain information
from virtually any data source. Although Reporting Services is implemented as a Web Service, it does
not depend on Internet Information Services (IIS). In fact, in SQL Server 2008, IIS is no longer used to
manage SQL Server Reporting Services. SQL Server Reporting Services (SSRS) can publish reports to a
Virtual Directory hosted by the SQL Server itself, or to a SharePoint library. More information about
SSRS can be found in Chapter 18.
For a detailed description of SQL Server 2008 Reporting Services and information about how to implement and extend SQL Server 2008 reports, check out an excellent book, Professional Microsoft SQL
Server 2008 Reporting Services (Wiley, 2008), by my friends and co-workers Paul Turley, Thiago
Silva, Bryan C. Smith, and Ken Withee.
Service Broker
Service Broker provides the framework and services to enable the creation of asynchronous, loosely
coupled applications. Service Broker implements a Service Oriented Architecture (SOA) in the data tier.
It provides more controlled transaction-based communications than traditionally available in other SOA
implementations such as Microsoft Message Queuing (MSMQ), without some of the limitations that
MSMQ has (e.g., message size). Service Broker allows developers to create database applications that
focus on a particular task and allows the asynchronous communication with other applications that
perform related (yet disconnected) tasks. For more information, see Chapter 19.
Data Tier Web Services
SQL Server 2008 provides support for creating and publishing data tier objects via HTTP without the
use of an Internet Information Services (IIS) server. SQL Server 2008 registers itself with the HTTP.sys
listener, allowing it to respond to Web Services requests. Developers can take advantage of this by creating applications that interact with a database across the Internet or through a firewall by using a Web
Service. For more information, see Chapter 7.
Replication Services
SQL Server 2008 Replication Services provides the ability to automate and schedule the copying and
distribution of data and database objects from one database or server to another, while ensuring
data integrity and consistency. Replication has been enhanced in SQL Server 2008 to include a new
Peer-to-Peer Topology Wizard, which allows replication nodes to be managed using a topology viewer.
The process of adding and removing nodes has also been made easier in this version of SQL Server.
More detail about replication can be found in Chapter 13.
Multiple Instances
As with previous versions, SQL Server 2008 provides the capability of installing multiple instances of
the database application on a single computer. SQL Server 2008 can also coexist with SQL Server 2000
and SQL Server 2005 instances installed on the same server. Depending on the edition of SQL Server
6
11:33am
Page 6
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
being installed, up to 50 instances can be installed. This feature allows for one high-performance server
to host multiple instances of the SQL Server services, each with its own configuration and databases.
Each instance can be managed and controlled separately with no dependency on each other.
Database Mail
In the past, SQL Server relied on a Messaging Application Programming Interface (MAPI) mail client
configured on the server to facilitate e-mail and pager notification for administrative and programmatic
purposes. What this essentially meant was that to fully utilize administrative notifications, the administrator needed to install Outlook (or some other MAPI-compliant client) on the server and then create a
mail profile for the service account to use.
Many organizations wanted to take advantage of the SQL Server Agent’s ability to send job and Event
Notification via e-mail but were unwilling to install unnecessary and potentially risky software on production server assets. The Database Mail feature removes this requirement by supporting Simple Mail
Transfer Protocol (SMTP) for all mail traffic. In addition, multiple mail profiles can be created in the
database to support different database applications. Configuring Database Mail is covered in Chapter 8.
A Note about Notification Services
In our Beginning SQL Server 2005 Administration (Wiley, 2006) book, Notification Services was introduced.
If you are familiar with Notification Services and have used it with SQL Server 2000 or SQL Server 2005,
you might be dismayed (or overjoyed, depending on your experience) that SQL Server Notification
Services is no more. Most of the functionality of Notification Services has been absorbed into SQL Server
Reporting Services, eliminating the need for Notification Services in SQL Server 2008.
SQL Ser ver 2008 Editions
SQL Server 2008 comes in several different flavors, and each has its specific place in the data management
infrastructure with the probable exception of the Enterprise Evaluation Edition, which is only useful for
short-term evaluation of the product (180 days). At the top of the list is the Enterprise Edition, which
supports absolutely everything that SQL Server 2008 has to offer. On the other end of the spectrum is
the Express Edition, which offers very limited (but still exciting) features. Each edition, with the exception of the Compact Edition, has an x64 and x86 version. The Enterprise Edition (and consequently, the
Developer Edition) also supports IA64 environments.
The available editions are:
❑
Enterprise Edition
❑
Standard Edition
❑
Workgroup Edition
❑
Web Edition
❑
Express Edition
❑
Express Advanced Edition
❑
Developer Edition
❑
Compact Edition
7
Page 7
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
The following table contrasts the major differences between the four main editions of SQL Server 2008.
The Developer Edition includes the same feature set as the Enterprise Edition but is not licensed for
production use.
Feature
Enterprise Edition
Standard
Edition
Workgroup
Edition
Web
Edition
Failover Clustering
Yes (limited by OS)
2-node
No
No
Multi-Instance Support
50
16
16
16
Database Mirroring
Yes
Limited
Witness Server
Role only
Witness
Server
Role only
Enhanced Availability
Features
Yes
No
No
No
Table and Index Physical
Partitioning
Yes
No
No
No
Policy-Based Management
Yes
Yes
Yes
Yes
T-SQL and MDX
IntelliSense
Yes
Yes
Yes
No
Spatial and Location
Services
Yes
Yes
Yes
Yes
Service Broker
Yes
Yes
Yes
Client only
Analysis Services
Yes
Limited
No
No
Data Mining
Yes
Limited
No
No
Reporting Services
Yes
Limited
Limited
Limited
Integration Services
Yes
Limited
Very limited
Very
limited
Replication Services
Yes
Limited
Limited features
available to
Subscriber only
Limited
features
available to
Subscriber
only
For a complete list of supported features, consult SQL Server 2008 Books Online under the topic ‘‘Features Supported by the Editions of SQL Server 2008.’’
SQL Server Compact 3.5 SP1
There have been several iterations of the SQL Server Compact Edition, beginning with SQL Server CE,
first offered in SQL Server 2000. When SQL Server 2005 was released, it was rebranded as SQL Server
2005 Mobile Edition, specifically targeting Smartphones and PDAs. The new Compact Edition enables
the installation of a small SQL Server database on a mobile device or Windows platform to support a
8
11:33am
Page 8
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
Windows Embedded CE or Windows Mobile application, as well as supporting desktop applications
that require a much smaller feature set than offered in the Express Edition.
This ability creates a world of opportunity for collecting data in a remote scenario and synchronizing
that data with a land-based database. For example, consider an overnight delivery service that must
maintain a record of a delivery truck’s inventory, including packages delivered and picked up. The
truck inventory could be uploaded via replication to a mobile device, where a mobile application keeps
track of the deliveries and new packages picked up at delivery locations. Once the truck comes back to
the delivery center, the mobile device could be synchronized with the central database via replication
or data upload.
SQL Server 2008 Express Edition
Back in the old days, when I had to manage database systems (in the snow, uphill both ways), the
Microsoft Desktop Edition (MSDE) of SQL Server was the primary client-side Database Engine. It was
extremely limited and included almost no management tools (except for the command-line osql utility)
but had a compelling price — free. This has since been replaced with the SQL Server 2008 Express Edition. It’s still not as robust as the Standard or Enterprise Editions, but for its very low price (you can’t
beat free), it still contains a great deal of functionality.
What makes this edition compelling is that it is perfect for many organizations that are starting or running
small businesses. They have a genuine need for a centralized managed database but aren’t ready to
pay for a more scalable and robust solution. At the risk of offending my friends in the Open Source
community, many small businesses that are not in the tech industry often don’t have the benefit of having
tech-savvy personnel on staff. Viable Open Source solutions like MySQL running on Linux or Windows
is simply not appropriate when a Database Engine with an intuitive and free graphical management
tool exists.
One of the most exciting improvements to Microsoft’s free version of its database system is that it comes
with a graphical management environment, SQL Server Management Studio Basic. It also supports
databases up to 4 GB in size and contains much of the same functionality as the other editions. There
is even an ‘‘advanced’’ edition of SQL Server 2008 Express that includes full-text search and Reporting
Services (still free!).
SQL Express can be installed on any Microsoft desktop or server operating system from Windows 2000
and beyond, so a very small company can still leverage the database technology without making a large
investment. Once the company starts to grow, it will inevitably need to make the move to one of the more
robust editions, but the upgrade process from SQL Express to its bigger siblings is a piece of cake because
the data structures are nearly identical. Even larger organizations can take advantage of the SQL Server
Express Edition by using it for smaller, departmental or business unit installations.
SQL Server 2008 Web Edition
SQL Server 2008 Web Edition is the newest entry in the SQL Server product family. The Web Edition is
designed around support for Web-facing environments and applications. With support for up to four
processors and no limits on memory or database size, the Web Edition positions itself as a cost-efficient
means for hosting services that rely on SQL Server databases. The Web Edition is targeted toward service
providers, or Select Licensing customers that need to host public data.
9
Page 9
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
The Web Edition has some very specific licensing guidelines and requirements. For example, it is licensed
for public-facing web applications, sites, and services. It is not licensed for internal line-of-business
applications. Because it is designed around public consumption, Client Access Licenses (CALs) are not
applicable to the Web Edition.
The Web Edition is only available to Select Licensing and Service Provider License Agreement Customers. Contact your reseller or licensing representative to find out if the Web Edition is appropriate for
your scenario.
SQL Server 2008 Workgroup Edition
The Workgroup Edition contains all the functionality of the SQL Server 2008 Express Edition and then
some. This edition is targeted to those small companies that have either outgrown the Express Edition
or needed a more flexible solution to begin with and yet do not need all the features of the Standard or
Enterprise Editions.
The Workgroup Edition is very flexible and contains many of the features of the more expensive editions.
What the Workgroup Edition doesn’t provide is support for more advanced Business Intelligence applications, because SQL Server Integration Services and Analysis Services are not included in this edition.
The Workgroup Edition also has a reduced feature set in regard to Reporting Services, but the Reporting
Services features supported should satisfy most small organizations.
Like the Express Edition, the Workgroup Edition can be installed on both desktop and server operating
systems, with the exception of Windows XP Home (which is not supported).
SQL Server 2008 Standard Edition
Most of the capabilities of SQL Server 2008 are supported in the Standard Edition, which makes it the
ideal data platform for many organizations. What the Standard Edition does not provide are many of
the features designed for the support of large enterprise databases. These features include many of the
high-availability and scalability enhancements, such as Partitioned Tables and Parallel index operations. It also lacks some of the more advanced features of the Analysis Services and Integration Services
engines.
SQL Server 2008 Enterprise Edition
The Enterprise Edition is the bee’s knees. Nothing is held back. Parallel operations, physical table partitioning, complete business intelligence, and data-mining support — you name it, the Enterprise Edition
has it.
If you require an easy-to-implement-and-maintain platform that will allow you to dynamically add
memory and CPUs, Transparent Data Encryption, and parallel index operations, this release is for you.
It is also an appropriate solution if you require only advanced business analytics, and not necessarily the
millions of transactions per second that this edition offers.
The Enterprise Edition is about performance and scalability. Although the feature set in the Enterprise
Edition may be more than the average company needs, the differences in performance between the
Standard and Enterprise editions can have a significant impact on whether their SQL Server is scalable
10
11:33am
Page 10
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
enough to accommodate quick growth within the organization. The Enterprise Edition fully optimizes
Read-ahead execution and table scans, which results in a noticeable performance improvement.
The difference in cost between the Standard Edition and the Enterprise Edition can be significant; especially to smaller organizations where budget constraints can limit their purchasing power. However,
be aware that some software may depend on certain features of the Enterprise Edition. A good example
of this is the Microsoft Office PerformancePoint Server 2007 Planning Server, which relies heavily on
proactive caching for Analysis Services cubes. This feature is only available in the Enterprise Edition of
SQL Server.
SQL Ser ver 2008 Architecture
It is the job of SQL Server to efficiently store and manage related data in a transaction-intensive environment. The actual theories and principles of a relational database are beyond the scope of this book,
and, hopefully, you already have some of that knowledge. What is pertinent to this book is the way SQL
Server manages the data and how it communicates with clients to expose the data. The following discussion describes the communication architecture utilized by SQL Server 2008, the services SQL Server 2008
offers, and the types of databases used by SQL Server. This section also introduces at a high level how
those databases are stored and accessed, but you can find a detailed description of the SQL Server 2008
storage architecture in Chapter 4.
SQL Server 2008 Communication
To adequately plan for a SQL Server database application, it is important to understand how SQL Server
2008 communicates with clients. As mentioned previously, SQL Server 2008 is more than just a relational
database server. Because the SQL Server 2008 platform offers several different data services, it also must
provide different ways of accessing that data.
SQL Server 2008 ships with the ability to communicate over different protocols. By default, SQL Server
will accept network connections via TCP/IP. The local Shared Memory protocol is also enabled by
default to allow local connections without having to incur the overhead of a network protocol. A
more complete description of the protocols that can be leveraged by SQL Server 2008 is provided in
Chapter 7.
In addition to the TCP/IP, Named Pipes, and Shared Memory protocols, the Virtual Interface Adapter
(VIA) protocol is available for VIA Storage Area Network (SAN) implementations.
With the exception of HTTP endpoints, SQL Server uses a communication format called Tabular Data
Stream (TDS). The TDS packets utilized by SQL Server are encapsulated in the appropriate protocol
packets for network communication.
The task of wrapping the TDS packets is the responsibility of the SQL Server Network Interface (SNI)
protocol layer. The SNI replaces the Server Net-Libraries and the Microsoft Data Access Components
(MDAC) that were used in SQL Server 2000. SQL Server creates separate TDS endpoints for each network
protocol.
Although TDS is the primary method for connecting to and manipulating data on a SQL Server, it is not
the only method available. In addition to TDS communication, SQL Server 2008 supports native Data
11
Page 11
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
Tier Web services (see Chapter 7). By utilizing SQL Server Web services, connections can be made to SQL
Server via any client application that supports HTTP and Simple Object Access Protocol (SOAP).
Supported Languages
SQL Server 2008 supports the following five different languages to enable data manipulation, data
retrieval, administrative functions, and database configuration operations:
❑
Transact-Structured Query Language (T-SQL) — This is Microsoft’s procedural language extension to the Structured Query Language (SQL) standard established by the American National
Standards Institute (ANSI). T-SQL is entry-level compliant with the ANSI-99 standard. T-SQL
is the primary and most common method for manipulating data. For more information about
T-SQL, consult Beginning T-SQL with Microsoft SQL Server 2005 and 2008 by Paul Turley and Dan
Wood (Wiley, 2008).
❑
Extensible Markup Language (XML) — This is fully supported in SQL Server 2008 as a data
type, as well as language extensions to XML that enable the retrieval and modification of data by
using XQuery syntax or native XML methods.
❑
Multidimensional Expressions (MDX) — This language is used to query against multidimensional objects in SQL Server 2008 Analysis Services.
❑
Data Mining Extensions (DMX) — This is an extension of Transact-SQL that enables the creation of queries against a data-mining model implemented in SQL Server 2008 Analysis Services.
❑
Extensible Markup Language for Analysis (XMLA) — This can be used to both discover metadata from an instance of SQL Server 2008 Analysis Services and to execute commands against an
instance of SSAS. XMLA commands are generally limited to the creation or modification of SSAS
objects. Actual retrieval of SSAS data is done with MDX queries.
SQL Server Programming Object Models
Most of the administrative activity that must be done on SQL Server 2008 can be done using the provided
tools, but sometimes it may be necessary to build custom administrative tools, or to be able to programmatically build and manipulate database objects. Three new object models have been created to support
this need:
12
❑
SQL Management Objects (SMOs) — SMOs enable developers to create custom applications
to manage and configure SQL Server 2008, SQL Server 2005, SQL Server 2000, or SQL Server 7.0
Database Engines. It is an extensive library that provides full support for virtually all aspects of
the relational store. The SMO library makes it possible to automate administrative tasks that an
administrator must perform through custom applications, or with command-line scripts using
the SMO scripter class.
❑
Replication Management Objects (RMOs) — RMOs can be used along with SMOs to implement and automate all replication activity, or to build custom replication applications.
❑
Analysis Management Objects (AMOs) — AMOs, like SMOs and RMOs, represent a complete
library of programming objects. AMOs enable the creation of custom applications or automation
of Analysis Server management.
❑
SQL Distributed Management Objects (DMOs) — SQL-DMO is a legacy set of management
objects that have been held over from SQL Server 2000. Although they are available in SQL
Server 2005 and SQL Server 2008, they have been deprecated in favor of SQL-SMO. Applications
that still use SQL-DMO should be upgraded to support SQL-SMO for SQL Server 2008.
11:33am
Page 12
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
SQL Server 2008 Services
SQL Server runs as a service. In fact, it runs as several services if all the different features of the product
are installed. It is important to know what service is responsible for what part of the application so that
each service can be configured correctly, and so that unneeded services can be disabled to reduce the
overhead on the server and reduce the surface area of SQL Server. These services are identified by their
executable names.
MSSQLServer (SQL Server)
The MSSQLServer service is the Database Engine. To connect and transact against a SQL Server 2008
database, the MSSQLServer service must be running. Most of the functionality and storage features of
the Database Engine are controlled by this service.
The MSSQLServer service can be configured to run as the local system or as a domain user. If installed
on Windows Server 2003 or Windows Server 2008, it can also be configured to run under the Network
System account.
SQLServerAgent (SQL Server Agent)
The SQLServerAgent service is responsible for the execution of scheduled jobs such as backups,
import/export jobs, and Integration Services packages. If any scheduled tasks require network or file
system access, the SQLServerAgent service’s credentials are typically used.
The SQLServerAgent service is dependent on the MSSQLServer service. During installation, the option
is given to configure both services with the same credentials. Although this is by no means required,
it is common practice. A frequent problem encountered by database administrators is when a job that
executes perfectly during a manual invocation fails when run by the agent. Often, the reason for the
failure is because the account that is used when testing the job manually is the logged-in administrator,
but when the job is executed by the agent, the account the agent is running under does not have adequate
permissions.
MSSQLServerADHelper100 (SQL Server Active Directory Helper)
Microsoft SQL Server 2008 has the ability to publish itself and its features in Active Directory. This can
make it easier for Active Directory–aware services and applications to find the necessary SQL components that they need. Typically, the MSSQLServer service and the SQLServerAgent service are configured
to run with a domain account that has local administrative rights on the server that SQL Server is installed
on. Although this configuration offers a great deal of flexibility to what the two services can do locally, it
doesn’t give them any permission to publish objects in Active Directory.
In order for the MSSQLServer service to register its respective instance of SQL Server, it must be either
running as the local system account (which significantly reduces the flexibility of the service) or be a
member of the domain admin group (which grants it way too much access, violating the principle of
least privilege).
To enable SQL Server to register itself in the domain, but not limit its functionality, the MSSQLServerADHelper service was created. The MSSQLServerADHelper service runs under the local system
account of the domain computer that SQL Server is installed on and is automatically granted the
right to add and remove objects from Active Directory. The MSSQLServerADHelper service only runs
when needed to access Active Directory and is started by the MSSQLServer service when required.
13
Page 13
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
Regardless of the number of installed instances, there is only one MSSQLServerADHelper service per
computer.
The version information ‘‘100’’ is used to denote that this service is associated with SQL Server 2008, or
SQL Server 10.0.
MSSQLServerOLAPService (SQL Server Analysis Services)
MSSQLServerOLAPService is the service that Analysis Services runs under. Analysis Services provides
the services and functionality to support all of SQL Server 2008’s OLAP needs, as well as the Data Mining
engine included with SQL Server 2008.
SQLBrowser (SQL Server Browser)
The SQLBrowser Service is used by SQL Server for named instance name resolution and server name
enumeration over TCP/IP and VIA networks.
The default instance of SQL Server is assigned the TCP Port 1433 by default to support client communication. However, because more than one application cannot share a port assignment, any named instances
are given a random port number when the service is started. This random port assignment makes it difficult for clients to connect to it, because the client applications don’t know what port the server is listening
on. To meet this need, the SQLBrowser Service was created.
On start-up, the SQLBrowser Service queries the registry to discover all the names and port numbers of
installed servers and reserves UDP Port 1434. It then listens on UDP Port 1434 for SQL Server Resolution
Protocol (SSRP) requests and responds to the requests with the list of instances and their respective port
assignments so that clients can connect without knowing the port number assignment. There are definite
security considerations to this arrangement, so it is very important that no unauthenticated traffic on UDP
Port 1434 be allowed on the network, because the service will respond to any request on that port. This
creates the potential of exposing more information about the server instances than some organizations
find acceptable.
If the SQLBrowser Service is disabled, it will be necessary to specify a static port number for all named
instances of the SQL Server Service and to configure all client applications that connect to those instances
with the appropriate connection information. For a full list of what features are affected by disabling the
SQLBrowser, consult SQL Server 2008 Books Online.
MSSQLFDLauncher (SQL Full-Text Filter Daemon Launcher)
The Microsoft Full-Text Daemon Launcher for SQL Server (MSSQLFDLauncher) is used to support
full-text indexing and full-text queries against text data stored in the database. The text data can be of
several different data types including char, nchar, varchar, nvarchar, text, and ntext. In addition,
full-text indexes can be created on binary formatted text such as Microsoft Word documents.
The chief advantage of the MSSQLFDLauncher service and associated engine is that it allows much more
flexible and powerful searches against text data than the Transact-SQL LIKE command, which is limited
to exact match searches. The MSSQLFDLauncher engine can perform exact match, proximity, linguistic,
and inflectional searches. It will also exponentially outperform comparative Transact-SQL LIKE searches
against large (millions of rows) tables. For a more complete discussion on both the Transact-SQL LIKE
command and Full-Text search, see Beginning T-SQL with Microsoft SQL Server 2005 and 2008.
14
11:33am
Page 14
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
MSDTSServer100 (SQL Server Integration Services)
The MSDTSServer service provides management and storage support for SSIS. Although this service is
not required to create, store, and execute SSIS packages, it does allow for the monitoring of SSIS package
execution and displaying of a hierarchical view of SSIS packages and folders that are stored in different
physical locations.
ReportingServicesServer (SQL Server Reporting Services)
The ReportingServicesServer service is the process in which Reporting Services runs. The service is accessible as a Web Service and provides for report rendering, creation, management, and deploying. For more
information on Reporting Services, see Professional Microsoft SQL Server 2008 Reporting Services.
SQLWriter (SQL Server VSS Writer)
The SQLWriter service allows for the volume backup of SQL Server data and log files while the SQL
Server service is still running. It does this through the Volume Shadow Copy Service (VSS). SQL Server
database backups are typically performed through SQL Server’s backup program or through third-party
applications that communicate with SQL Server’s backup program.
Normal file system backups of volumes containing SQL Server log or data files will typically fail to
properly back up those files, because as long as SQL Server is running, the files are open. The SQLWriter
service overcomes this limitation by allowing you to perform the backups of a snapshot copy of the files
with the VSS service. It is still recommended, however, to perform regular backups through SQL Server’s
backup program.
MSDTC (Distributed Transaction Coordinator)
The MSDTC service is used to manage transactions that span more than one instance of SQL Server or
an instance of SQL Server and another transaction-based system. It uses a protocol known as two-phased
commit (2 PC) to ensure that all transactions that span systems are committed on all participating systems.
SQL Ser ver 2008 Database Objects
SQL Server 2008 database objects exist within a defined scope and hierarchy. This hierarchy enables more
control over security permissions and organization of objects by similar function. SQL Server 2008 objects
are defined at the server, database, and schema levels.
Server
The server scope encompasses all the objects that exist on the instance of SQL Server, regardless of their
respective database or namespace. The database object resides within the server scope.
One of the more confusing terms when working with SQL Server 2008 is server. When you hear the term
server, you often think of that piece of hardware taking up space on a server rack in the server room. And
let’s not even get started on how virtualization mucks up the term. Where the confusion arises is that you
can install multiple instances of SQL Server on a single server (huh?).
What would probably be clearer is to say that the capability exists to install multiple instances of the
SQL Server 2008 Data Platform application on a single computer running a Windows operating system.
Although this might be more descriptive, it doesn’t make for very interesting marketing material.
15
Page 15
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
What is left is the fact that, when it comes to SQL Server 2008 and you read ‘‘server,’’ it is important to
check the context to make sure that it means an instance of SQL Server 2008 or the physical computer
that SQL Server is installed on.
When it comes to the server scope and SQL Server 2008 database objects, the term server actually refers
to the SQL Server 2008 instance. The default instance is actually SERVERNAME\MSSQLService. However, since it is the default instance, appending MSSQLService to the server name is unnecessary. For
example, we are using a server called AUGHTEIGHT that runs the Windows Server 2008 Operating
System while writing this book. The default instance of SQL Server is known simply as AUGHTEIGHT.
If you were to install a second instance, named SECONDINSTANCE, the SQL Server name would be
AUGHTEIGHT\SECONDINSTANCE. From a SQL Server point of view, each instance is considered a
separate ‘‘server.’’
Database
The database scope defines all the objects within a database catalog. Schemas exist in the database scope.
The ANSI synonym for database is catalog. When connecting to an instance of SQL Server 2008, it is generally desired to specify an Initial Catalog, or Initial Database. An instance of SQL Server 2008 can contain
many databases. It used to be common for a typical database application to be constrained within one
database that contained all the data objects required to provide the functionality for the application.
However, now it is not uncommon to see more and more applications requiring multiple databases to
manage different components of the application (this tends to increase the scalability of said application).
An example of this is SharePoint, which creates databases for managing the SharePoint environment
itself, as well as content databases for the various sites and site collections.
Schema
Each database can contain one or more schemas. A schema is a namespace for database objects. All data
objects in a SQL Server 2008 database reside in a specific schema.
SQL Server 2008 implements the ANSI schema object. A database schema is a defined namespace in which
database objects exist. It is also a fully configurable security scope. In previous releases of SQL Server,
the namespace was defined by the owner of an object, and it wasn’t uncommon to see everything in the
database in the dbo schema. In SQL Server 2008, the ownership of an object is separated from an object’s
namespace. An individual user may be granted ownership of a schema, but the underlying objects belong
to the schema itself. This adds greater flexibility and control to the management and securing of database
objects. Permissions can be granted to a schema, and those permissions will be inherited by all the objects
defined in the schema.
Object Names
Every object in a SQL Server 2008 database is identified by a four-part, fully qualified name. This fully
qualified name takes the form of server.database.schema.object. However, when referring to objects,
the fully qualified name can be abbreviated. By omitting the server name, SQL Server will assume the
instance the connection is currently connected to. Likewise, omitting the database name will cause SQL
Server to assume the existing connection’s database context.
16
11:33am
Page 16
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
Omitting the schema name will cause SQL Server to assume the namespace of the logged-in user. This
is where some confusion can be created. Unless explicitly assigned, new users are assigned the default
schema of dbo. (See Chapter 6 for user and login management information.) As a result, all references to
database objects not explicitly qualified will be resolved to the dbo schema.
For example, the user Fred logs in to the server AUGHTEIGHT, and his database context is set to
AdventureWorks2008. Because Fred was not assigned a user-defined schema, he exists in the default
dbo schema. Fred wants to retrieve the contents of the Person table, so he executes the following query:
SELECT * FROM Person;
Fred’s query will resolve to AUGHTEIGHT.AdventureWorks2008.dbo.Person. Unfortunately, that table
does not exist. The fully qualified name for the contact table is AUGHTEIGHT.AdventureWorks2008
.Person.Person. In order for Fred’s query to work, one of two things will have to happen. The query
will have to be rewritten to reference the appropriate schema scope, as in the following example:
SELECT * FROM Person.Person;
Or, Fred’s default schema can be changed to the Person schema so that his query will be properly
resolved with the following command:
USE AdventureWorks2008;
GO
ALTER USER Fred WITH DEFAULT_SCHEMA=Person;
GO
Now, take a look at a different scenario. The user Fred is created and assigned the default schema of
Production. Fred wants to retrieve the contents of a table called dbo.DatabaseLog so he executes the
following:
SELECT * FROM DatabaseLog;
SQL Server first resolves this query as AUGHTEIGHT.AdventureWorks2008.Person.DatabaseLog
because Fred’s default schema is Person and he did not explicitly tell SQL Server what schema
to work with. Because the DatabaseLog table does not exist in the Person schema, the initial
resolution fails, but SQL Server then falls back to the dbo schema and resolves the name as
AUGHTEIGHT.AdventureWorks2008.dbo.DatabaseLog. The resolution succeeds, and Fred is able to
retrieve the data he wanted.
SQL Server will always search the assigned schema first, then the dbo schema if the initial resolution fails.
Care must be taken when creating objects so that the proper namespace is referenced. It is completely
possible to create a table with the same name in two different schemas (e.g., a dbo.HourlyWage and a
HumanResources.HourlyWage). When this happens and an application is created to expose the contents
of the HourlyWage table, the possibilities for inconsistencies and confusion are endless. If the schema
is not referenced in the application’s query, some users will invariably get their results from the table
in the dbo schema, whereas others will end up getting results from the HumanResources version of the
table. As a best practice, all objects should be referenced by (at least) a two-part name to avoid this
confusion.
17
Page 17
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
SQL Ser ver 2008 Databases
There are two types of databases in SQL Server: system databases and user databases. The system databases
are used to store system-wide data and metadata. User databases are created by users (sometimes during the process of installing an application) who have the appropriate level of permissions to store
application data.
System Databases
The system databases are comprised of master, model, msdb, and tempdb databases, as well as the hidden
resource database. If the server is configured to be a replication distributor, there will also be at least one
system distribution database that is named during the replication configuration process.
The master Database
The master database is used to record all server-level objects in SQL Server 2008. This includes Server
Logon accounts, Linked Server definitions, and EndPoints. The master database also records information
about all the other databases on the server (such as their file locations and names). SQL Server 2008 does
not store system information in the master database but, rather, in the Resource database. However,
system information is logically presented as the SYS schema in the master database.
The model Database
The model database is a template database. Whenever a new database is created (including the system
database tempdb), a copy of the model database is created and renamed with the name of the database
being created. The advantage of this behavior is that objects can be placed in the model database prior
to the creation of any new database, and, when the database is created, the objects will appear in the
new database. For example, Transact-SQL does not contain a Trim function to truncate both leading
and trailing spaces from a string of characters. Transact-SQL offers an RTRIM function that truncates
trailing spaces and an LTRIM function that removes leading spaces. The code to successfully implement
a traditional trim operation thus becomes the following:
LTRIM(RTRIM(’character string’))
To make it easier to perform this task with the least amount of effort, a custom TRIM function can be
added to the model database with the following code:
USE Model
GO
CREATE FUNCTION dbo.Trim (@String varchar(MAX))
RETURNS varchar(MAX)
AS
BEGIN
SELECT @String = LTRIM(RTRIM(@String))
RETURN @String
END
After creating this function in the model database, it will be propagated to all databases created and can
be used with the following simplified code:
dbo.TRIM(’character string’)
18
11:33am
Page 18
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
Sure, it’s only a small savings, but the open and close parenthesis characters are often the source of
annoying syntax errors. By reducing the nested functions, the overall complexity of the function call is
also reduced.
Almost any database object can be added to the model database so that it will be available in subsequently created databases. This includes database users, roles, tables, stored procedures, functions, and
assemblies.
The msdb Database
The msdb database can be considered the SQL Server Agent’s database. That’s because the SQL Server
Agent uses the msdb database extensively for the storage of automated job definitions, job schedules,
operator definitions, and alert definitions. The SQL Server Agent is described in greater detail in
Chapter 8, but for now, just know that the Agent is responsible for almost all automated and scheduled
operations.
The SQL Server Agent is not the only service that makes extensive use of the msdb database. Service
Broker, Database Mail, and Reporting Services also use the msdb database for the storage of scheduling
information. In addition to automation and scheduling information, SQL Server Integration Services
(SSIS) can also use the msdb database for the storage of SSIS packages.
The tempdb Database
The tempdb database is used by SQL Server to store data — yes, you guessed it, temporarily. The tempdb
database is used extensively during SQL Server operations, so careful planning and evaluation of its size
and placement are critical to ensure efficient SQL Server database operations.
One of the primary functions of this database is to store temporary objects (such as temporary tables,
views, cursors, and table-valued variables) that are explicitly created by database programmers. In addition, the tempdb database stores work tables containing intermediate results of a query prior to a sort
operation or other data manipulation. For example, if you wrote a query that returned 100,000 rows and
you wanted the results sorted by a date value in the results, SQL Server could send the unsorted results to
a temporary work table, where it would perform the sorting operation and then return the sorted results
to you. It is also used extensively to support connection options such as SNAPSHOT ISOLATION or Multiple
Active Result Sets (MARS). If online index operations are performed, the tempdb database will hold the
index during the build or rebuild process.
Another important aspect to keep in mind about the tempdb database is that all database users have
access to it and have the ability to create and populate temporary objects. This access can potentially
create locking and size limitation issues on SQL Server, so it is important to monitor the tempdb database
just like any other database on SQL Server.
The resource Database
The last system database is the resource database. The resource database is a Read Only database that
contains all system objects used by an instance of SQL Server. The resource database is not accessible
during normal database operations. It is logically presented as the SYS schema in every database. It
contains no user data or metadata. Instead, it contains the structure and description of all system objects.
This design enables the fast application of service packs by replacing the existing resource database with
a new one. As an added bonus, to roll back a service pack installation, all you have to do is replace the
new resource database with the old one. This very elegant design replaces the older method of running
many scripts that progressively dropped and added system objects.
19
Page 19
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
User Databases
User databases are simply that — databases created by users. They are created to store data used by
data applications and are the primary purpose of having a database server. Unlike previous versions,
SQL Server 2008 does not ship with any sample databases. Instead, sample databases are available from
Microsoft’s Open Source CodePlex site (www.codeplex.com). There you can search for the three sample
databases that are available at the time of this writing: AdventureWorks2008, AdventureWorksLT2008,
and AdventureWorksDW2008.
The AdventureWorks2008 database is an OLTP database used by the fictitious Adventure Works Cycles
Company, which sells mountain bikes and mountain-biking-related merchandise.
The AdventureWorksLT2008 database is an OLTP database that is a subset of the larger
AdventureWorks2008 database. It was scaled down to help those who are new to relational
databases.
The AdventureWorksDW2008 database is an OLAP database used for data analysis of historical Adventure
Works Cycles data.
Distribution Databases
One or more distribution databases can be configured to support replication. Some SQL Server professionals describe the distribution databases as system databases, and yet others describe them as
user databases. I don’t think it makes much difference. What is important is what the database or
databases do.
A distribution database stores metadata and transactional history to support all types of replication on a SQL Server. Typically, one distribution database is created when configuring a SQL
Server as a replication Distributor. However, if needed, multiple distribution databases can be
configured.
A model distribution database is installed by default and is used in the creation of a distribution database
used in replication. It is installed in the same location as the rest of the system databases and is named
distmdl.mdf.
SQL Ser ver 2008 Database Storage
All system and user databases (including the resource database) are stored in files. There is always a
minimum of two files: one data file and one transaction log file. The default extension for data files is
.mdf, and the default for transaction log files is .ldf.
The default location for the system database files is <drive>:\Program Files\Microsoft SQL Server\
MSSQL.X\MSSQL\Data\, where <drive> is the installation drive and X is the instance number (MSSQL.1
for the first instance of the Database Engine). The following table lists the names and default locations for
system database files associated with the first instance of SQL Server:
20
11:33am
Page 20
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
System
Database
Physical Location
master
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\master.mdf
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\mastlog.ldf
model
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\model.mdf
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\modellog.ldf
msdb
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\msdbdata.mdf
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\msdblog.ldf
tempdb
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\tempdb.mdf
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Data\templog.ldf
resource
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Binn\Mssqlsystemresource.mdf
<install path>\MSSQL10.MSSQLSERVER\MSSQL\Binn\Mssqlsystemresource.ldf
When it comes to the system databases, the following guidance is given: Don’t mess with them. Your ability
to manipulate the system databases in SQL Server 2008 has been extremely limited by the developers at
Microsoft. Overall, this is a good thing. Generally speaking, the only thing you are permitted to do with
system databases is back them up or move them to faster, more reliable disk arrays if they prove to
be a performance bottleneck. The ability to modify the data contained in system tables through ad hoc
updates has been almost completely removed from SQL Server 2008. To modify the system catalog, the
server must be started in Single-User mode, and even then, activity is restricted and is not supported by
Microsoft.
Data Files and Filegroups
When a user database is created, it must contain at least one data file. This first data file is known as the
primary data file. The primary data file is a member of the default Primary filegroup. Every database has
one Primary filegroup when created, which consists of at least the primary data file. Additional data files
can also be added to the Primary filegroup. More filegroups can also be defined upon initial creation of
the database, or added after the database is created. Chapter 4 describes the storage architecture of files
in greater detail, and Chapter 5 explains the advantage of filegroups. For now, it is sufficient to know
that all of the data objects in a database (such as tables, views, indexes, and stored procedures) are stored
within the data files. Data files can be logically grouped to improve performance and allow for more
flexible maintenance (see Figure 1-1).
Log Files
Upon initial creation of a database, one transaction log must be defined. The transaction log is used to
record all modifications to the database to guarantee transactional consistency and recoverability.
Although it is often advantageous to create multiple data files and multiple filegroups, it is rarely
necessary to create more than one log file. This is because of how SQL Server accesses the files. Data
files can be accessed in parallel, enabling SQL Server to read and write to multiple files and filegroups
21
Page 21
Leiter c01.tex
V3 - 03/25/2009
Chapter 1: Introducing SQL Server 2008
simultaneously. Log files, on the other hand, are not accessed in this manner. Log files are serialized to
maintain transactional consistency. Each transaction is recorded serially in the log, in the sequence it was
executed. A second log file will not be accessed until the first log file is completely filled. You can find a
complete description of the transaction log and how it is accessed in Chapter 4.
MyDB
MyDB_Log.Idf
Primary Filegroup
Secondary Filegroup
MyDB_Data.mdf
MyDB_Data3.ndf
MyDB_Data2.ndf
MyDB_Data4.ndf
Figure 1-1: Data files and filegroups.
SQL Ser ver Security
Chapter 6 provides a thorough discussion of SQL Server 2008 security features. However, to select the
proper authentication model during installation, it is important to have a basic understanding of how
SQL Server controls user access.
SQL Server 2008 can be configured to work in either the Windows Authentication Mode or the SQL
Server and Windows Authentication Mode, which is frequently called Mixed Mode.
Windows Authentication Mode
In Windows Authentication Mode, only logins for valid Windows users are allowed to connect to SQL
Server. In this authentication mode, SQL Server ‘‘trusts’’ the Windows or Active Directory security subsystem to have validated the account credentials. No SQL Server accounts are allowed to connect. They
can be created, but they cannot be used for login access. This is the default behavior of a fresh installation
of SQL Server 2008.
SQL Server and Windows Authentication Mode
(Mixed Mode)
In SQL Server Mode and Windows Authentication Mode, or Mixed Mode, valid Windows accounts
and standard SQL Server logins are permitted to connect to the server. SQL Server logins are validated
by supplying a username and password. Windows accounts are still trusted by SQL Server. The chief
advantage of Mixed Mode is the ability of non-Windows accounts (such as UNIX) or Internet clients to
connect to SQL Server.
22
11:33am
Page 22
Leiter c01.tex
V3 - 03/25/2009
11:33am
Chapter 1: Introducing SQL Server 2008
Summar y
This chapter introduced the basic structure and purpose of SQL Server 2008, along with a brief explanation of the various features available in this release of Microsoft’s database application. Subsequent
chapters delve into the technologies and features exposed in this chapter so that the database administrator can better understand and implement each feature introduced.
In Chapter 2, you will learn how to plan and perform a SQL Server 2008 installation. Included in the
discussions are prerequisite hardware and software configurations, as well as service and security
considerations. A thorough installation plan will always reap enormous benefits when it comes to
post-installation modifications. Understanding what to install (and how to install it) is invaluable.
23
Page 23
Leiter c01.tex
V3 - 03/25/2009
11:33am
Page 24
Leiter c02.tex
V3 - 03/25/2009
11:37am
2
Installing SQL Ser ver 2008
Installing SQL Server 2008 is deceptively simple. I say deceptively because although SQL Server
includes several wizards and tools that make the installation process itself go smoothly, a good
database administrator will have devised a thorough plan for installing SQL Server and its requisite
components. This chapter will introduce you to the process of installing SQL Server, beginning with
an overview of the planning process. Although it would be impossible to document every possible
design decision for every possible scenario, the goal of this chapter is to help you understand the
installation process, some key design considerations, and the various components and options
available prior to and during installation.
SQL Ser ver Installation Planning
‘‘There is never enough time to do it right, but always enough time to do it twice.’’ ‘‘Measure twice,
cut once.’’ How many times have you heard these sayings? There are a number of these clichés that
point out that doing something right the first time means not having to do it over and over again. To
avoid having to do it twice (or more!), you need to create a thorough plan. Too often installations are
rushed and then must be uninstalled when technical issues arise. The questions that must be asked
range from collation settings and named instances to the separation of log and data files. Will SQL
Server be installed in a cluster? How about Storage Area Networks (SAN) or Network Attached
Storage (NAS)? And virtualization, won’t someone please think of the virtualization! Although the
Installation Wizards will ask you to provide answers to several questions about how you want SQL
Server installed, before you launch the Wizard you should know the why behind your answers.
In addition to the ‘‘how’’ and ‘‘why,’’ there are the ‘‘who,’’ ‘‘what,’’ and ‘‘when’’ questions that
must be answered to create an adequate plan.
❑
The ‘‘who’’ is most likely going to be the database administrator (DBA), but other individuals will need to be included in the deployment plan as well. In addition to getting
members of the IT department because there are network and storage considerations to
account for, other departments or individuals that are considered key stakeholders may
need to be involved in the process. Remember that SQL Server 2008 is an enterprise data
platform, and users who own or interact with the data that will be managed by SQL Server
will need to have their interests represented.
Page 25
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
❑
The ‘‘what’’ question can be a bit more complex. The first ‘‘what’’ is ‘‘What features will be
installed?’’ However, more ‘‘what’’ questions could include ‘‘What constitutes a successful
installation?’’ or ‘‘What resources are required?’’
❑
The ‘‘when’’ question is also imperative. ‘‘When will the installation be started and when will it
be complete?’’
It would be impossible to cover all the possible variations that could arise during a SQL Server installation, so this chapter covers only the essentials. Remember, when it comes to technology, the answer to
almost every question is, ‘‘It depends.’’ There are almost always ‘‘best practices,’’ but sometimes the best
practices are based on various ‘‘ivory tower’’ assumptions. We don’t all have 50 billion dollars, 20,000 IT
professionals, and unlimited access to hardware and software. Sometimes the ‘‘best practices’’ have to be
left behind in favor of practicality and budget.
For example, as a best practice, transaction logs should be placed on a RAID 1 array as opposed to any
striped array configuration because of how the transaction log is accessed by SQL Server. However, if
the only available fault-tolerant storage is a RAID 5 striped array, then by all means it should be used to
store and protect the log data. In many cases, the only storage available because of budget and hardware
constraints is a single RAID 5 array where both the transaction log and data files are hosted. In a large
enterprise solution, this would be completely unacceptable; but for a small-to-medium business implementation, it may be the only choice. The key point is that it is very important to know what the ‘‘best’’
solution is, but also keep in mind that compromises are often necessary to meet deadlines and budgetary
constraints.
Hardware Considerations
Minimum requirements are exactly that: minimum. SQL Server will run on a system with minimum
hardware, but the performance is not going to be stellar. Even the ‘‘recommended’’ hardware is to be
exceeded whenever practical. I tend to think of these as ‘‘minimum to install and start the services’’ and
‘‘minimum to run a production system,’’ respectively.
Upgrading almost any hardware object on a server hosting SQL Server 2008 will result in improved
performance, but all things being equal, increasing RAM often has the best impact on performance.
An underpowered processor or slow disk system will cause just as many performance problems as
insufficient RAM, but RAM limitations will often cause processor and disk issues to be exacerbated.
A common scenario for certification exams often presents a series of questions that involve allocating
different limited resources across different types of servers such as a file server, domain controller, and
database server. Often, you’re tasked with determining where to place the faster CPU, the better disk
array, and the new RAM. I’ve been an IT generalist for many years, so I know what the test designers are
after, but when I wear my DBA hat, I want to put everything into SQL Server.
This seems kind of self-serving, but based on my experience, SQL Server tends to be the core or underlying technology for a lot of the business applications. A company that I worked at for a number of years
relies on a single SQL Server for all financial data, logistics and materials tracking, SharePoint, and several other line-of-business applications. Without exception, these applications used SQL Server as a data
store. Optimizing the server running SQL Server would have an immediate positive impact on a majority
of the applications used for the key business activities, as well as many support applications.
26
11:37am
Page 26
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
There are four main subsystems that you need to optimize for SQL Server 2008 to perform optimally.
These include the Processor, Memory, Storage, and Network subsystems. Performance of these
subsystems will affect SQL Server in a variety of ways, and as part of the pre-installation process, you
should have an understanding of what your hardware needs are. One quick note about the network
subsystem is that it is often the one the DBA has the least control over, and yet sometimes has the most
impact, depending on the number of applications and users that are being supported. You should work
with your network administrators and engineers to plan a strategy for concurrent database access by
your users.
Processor Considerations
Microsoft sets the minimum processor requirements at 1 GHz Pentium III or a compatible processor for
32-bit installations of SQL Server, and 1.4 GHz for 64-bit systems. However, 2.0 GHz is considered the
recommended speed for both platforms. SQL Server uses the processor extensively during the compilation and execution of query plans. Your server can have an extraordinarily fast disk array and plenty of
RAM, but if it has an underpowered processor, it is all for naught. As the workload of the server increases
and more and more transactions are executed against it, the processor will have to schedule and handle
the multitude of query execution plans and programmatic manipulation of data.
Chapter 10 discusses the ways to monitor SQL Server to ensure that the CPU is not a bottleneck, but from
the outset, SQL Server should be given plenty of processor power. In addition, SQL Server is very adept
at using multiple processors to execute parallel operations, so adding a second processor will often pay
larger dividends than upgrading a single processor. However, if your license is per processor, the cost
may be prohibitive to add additional processors.
As of this writing, Microsoft considers multiple logical processors to be covered under a single processor
license. This would allow you to buy a quad-core CPU, essentially supplying SQL Server with up to
four CPUs for the cost of a single processor license. For example, if you wanted to buy a new server that
has two quad-core processors, you would be able to leverage all eight cores, but only have to buy two
processor licenses.
Memory Considerations
The minimum amount of RAM, according to Microsoft, is 512 MB. I personally find this minimum
requirement a bit on the ridiculous side. I wouldn’t set up a Windows server running any multi-user
application with only 512 MB of RAM, let alone a RAM-hungry application like SQL Server. Would
512 MB be sufficient for a desktop machine running SQL Server 2008 Developer Edition? Maybe, as long
as no serious load was put on the server.
That’s not to say that SQL Server wastes memory or that it consumes a bloated footprint. The simple fact
is that SQL Server likes memory — a lot. It attempts to place as much data as possible in RAM so that the
data is readily available for processing. It also tries to keep the data in RAM as long as possible.
SQL Server creates and maintains different memory pools for various database operations. For example,
there is a buffer cache that is used to store data pages retrieved from the disk; a procedure cache that is used
to store compiled stored procedures, triggers, functions, views, and query plans; and even a log cache for
transaction log operations.
27
Page 27
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Having sufficient RAM on hand allows SQL Server to minimize the amount of page swapping required
and enables the data to be pre-fetched for fast processing. If you want to keep SQL Server happy, feed
it RAM. What you will get in return is a hard-working database server that efficiently and effectively
utilizes that RAM to service your requests as fast as possible. Lack of sufficient RAM can also cause
degradation in performance of the storage subsystem, as more data gets paged to disk.
Microsoft recommends just over 2 GB of RAM for both the 32-bit and 64-bit editions. Although Microsoft
considers operating system overhead when publishing their recommended values, given the relatively
low cost of RAM, I typically recommend this above the operating system requirements. For example, if
Windows Server 2008 recommends 2 GB of RAM for the OS, I would recommend a total of 4 GB to help
optimize performance.
Storage Considerations
An often overlooked hardware aspect of many SQL Server installations is the disk subsystem. I have
personally witnessed deployments in which undertrained personnel installed the OS, SQL Server, and
all the database files on the system partition. Although this will work, it is less than ideal. The question
of how to best place the application and database files is answered with a definite ‘‘It depends.’’
If you’re not familiar with the different levels of RAID technology, let me offer a quick primer. RAID, first
of all, stands for ‘‘Redundant Array of Inexpensive Disks’’ (inexpensive being a relative term here). When
working with SQL Server, there are four types of RAID implementations that are commonly used:
❑
RAID 0 — RAID 0 offers no redundancy or fault tolerance, but instead helps improve performance by striping across multiple disks. RAID 0 also allows you to use the combined storage
capacity of both disks. RAID 1, also known as mirroring, provides fault tolerance by making
a bit-for-bit copy of your data on two disks. While this provides basic redundancy and can
improve Read performance (by having two separate disks available to read from), you might
suffer minor loss of Write performance, since the data will have to be written across both disks.
RAID 1 has 50 percent storage overhead.
❑
RAID 5 — RAID 5 is one of the more common implementation types of RAID, utilizing three or
more disks. RAID 5 is also called striping with parity, because as it stripes across multiple disks,
it writes a parity block on each stripe that allows the data to be rebuilt in case of a disk failure.
RAID 5 is considered a good option for most scenarios because it provides fault tolerance and
improved Read and Write performance and has a relatively low storage overhead. Because the
available capacity on a RAID 5 array is n – 1 (n being the total number of disks in the array),
the storage overhead decreases as the number of disks in the array increases.
❑
RAID 10 — RAID 10 (also sometimes known as RAID 1+0) is the cat’s pajamas of RAID, and is
considered the optimal design solution for SQL Server database files. RAID 10 requires a minimum of four disks and essentially stripes data across two mirrored sets. So let’s say, for example,
that you have four disks: a, b, c, and d. Disks a and b will be used to make one mirrored set, which
we’ll call ab, and disks c and d will be used to make the cd mirrored set. The two mirrored sets are
then part of a new striped set, so when data is written to the array, it is striped across ab and cd.
Now that you know a little bit more about the various RAID levels, it’s important to understand that
there are several factors that can have an impact on the decision regarding where to install everything.
How important is fault tolerance? How much money is the organization willing to spend on the database
solution? How much disk space will be needed? How busy is the existing disk system? An optimal
installation of SQL Server could look something like Figure 2-1.
28
11:37am
Page 28
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
RAID 10
DATA
RAID 1
OS
RAID 1
SQL
RAID 1
LOG
Figure 2-1: Optimal installation.
Notice that the application is installed on a separate set of spindles from the operating system. This
reduces contention for disk resources and makes the application more efficient. Notice use of the term
spindle. This is preferred to drive or disk because it leaves little room for interpretation. Physical disk
drives have one spindle, which is loosely analogous with the center of a spinning top. Granted, the
increase in capacity and general availability (as well as decreasing costs) of Solid State Drives, which
have no spinning platter, may eventually make the term spindle obsolete. For now, let’s agree to continue
to use that term. In the case of Figure 2-1, the two spindles that host the log file on a RAID 1 array will
actually look like a single drive to the operating system, when, in reality, there are two physical disks,
or spindles.
In addition to the application existing on a separate set of spindles, the data files and the log files are
on yet another set. The idea here is not to keep the hard disk industry in business, but to maximize
efficiency, fault tolerance, and recoverability. Placing the operating system, application, and database
all on the same spindle is basically putting all of your eggs in one basket. If the basket is dropped, you
will lose all of your eggs. Likewise, if the spindle fails, you will lose your operating system, application,
and databases. Your recovery time in this instance is tripled. Even if your server weren’t to suffer a
catastrophic failure, the amount of contention for resources on the disk subsystem could cause a severe
degradation in performance.
Separating the database files from the transaction logs files can also help improve recovery efforts. If the
database file is corrupted or damaged, the most recent backup can be used to recover it, and then
the existing transaction log can be used to recover all the transactions since the last backup. Likewise,
if the transaction log is lost, it can be re-created with minimal data loss from the database. If both data
29
Page 29
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
files and the log file are on the same spindle, a catastrophic failure of the spindle will result in all
data since the last backup being lost.
Backup and recovery strategies are covered in more detail in Chapter 9.
The separation of the different components of SQL Server is just part of the equation. When choosing a
disk system, it is also important to know what type of disk is best for each part of the database. Notice
in Figure 2-1 that the operating system is installed on a RAID 1 array. The same goes for the SQL Server
application and the database log file, while the data files are placed on a striped array. It is possible to
place all the SQL resources on one or more RAID 10 or RAID 5 arrays, and many organizations do just
that. However, when it comes to the transaction log, a RAID 1 configuration is more appropriate than a
RAID 5 one. A transaction log placed on a striped array will actually decrease the performance of SQL
Server. This is because of the inherent hit in Write performance on a RAID 5 array, and also because of the
way SQL Server writes serialized data to the log. Log files, by their nature, are mostly written to, which
means that often RAID 1 (or RAID 10, if you have the budget) is the best choice for performance. RAID 1
or RAID 10 is also better because of the sequential and serial nature of the transaction log as compared to
the parallel friendly nature of data files.
Each transaction is written to the transaction log before it is written to memory. This puts the transaction
log in the position to become a possible bottleneck. A fast array will help prevent the log from becoming
a performance liability.
SAN and NAS versus Local Disk Storage
Another decision to be made during a SQL Server installation is that of storage architecture. There are
many vendors in the marketplace with hundreds of possible configurations for sale. Many larger organizations have placed much of their corporate data on local and remote SANs. At the same time, other
organizations have chosen NAS, and still others (mostly smaller organizations) have chosen to place
all their data on local attached disk arrays. Although a complete discussion of these different technologies is beyond the scope of this book, a brief explanation is useful in describing the utilization of these
technologies in database implementations.
Storage Area Network (SAN)
SANs typically transmit Small Computer Systems Interface (SCSI) block commands over a network
(usually either Fibre Channel or iSCSI) in lieu of a SCSI connection for a direct-attached storage array.
This option is well-suited to SQL Server because the database application expects block access to data,
which is not easily supplied using NAS. Utilizing SAN software, multiple volumes can be created and
‘‘presented’’ to the servers, using the storage space on the SAN, as shown in Figure 2-2.
Network Attached Storage (NAS)
The NAS network interface is usually Gigabit Ethernet or Fast Ethernet, but the storage type is file-based
via traditional file sharing protocols. Volumes are not presented to the servers that utilize a NAS;
instead, files are accessed through Universal Naming Convention (UNC) shares, as shown in Figure 2-3.
File-based access degrades SQL Server performance considerably, which is why NAS storage should be
avoided. By default, databases cannot be created with a UNC location, but this behavior can be changed.
However, if the database is going to be used for any serious I/O scenarios, you will find that NAS will
not be able to provide an adequate response.
30
11:37am
Page 30
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
F:\
G:\
H:\
I:\
J:\
K:\
L:\
M:\
SAN Storage
SAN Controller
DB1
DB2
DB3
Figure 2-2: Storage Area Network.
DB1
\\NASServer\Share1
\\NASServer\Share2
\\NASServer\Share3
\\NASServer\Share4
DB2
NAS Storage
DB3
Figure 2-3: Network Attached Storage.
31
Page 31
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Local Attached Disk Array
There is a lot to be said for sharing storage resources among multiple servers on a high network, but some
organizations (for a variety of reasons) have chosen to dedicate local attached storage to their database
implementations (see Figure 2-4). In reality, the only differences between local attached disk arrays and
SANs are that the volumes created on the local array are only accessible to the server to which the array
is attached and that SAN controllers can optimize data transfer. Local arrays are typically connected via
a high-speed SCSI cable or Fiber Channel.
Figure 2-4: Local attached disk array.
Virtualization Considerations
SQL Server 2008 is the first version of SQL Server that is supported in virtual environments; however,
there are some limitations. Microsoft will officially only support installations of SQL Server in Hyper-V
environments on Windows Server 2008, and clustering of virtual machines is not supported. Because of
the continued improvement in virtualization technology, it is becoming a much more attractive option to
companies that want to either consolidate hardware or take advantage of some of the recovery and portability options available. It’s been my experience that the biggest bottleneck that occurs when running SQL
Server in a virtual machine is I/O performance. For this, I strongly recommend using SAN storage for
the database and transaction log files to avoid storing database information in a virtual hard drive file.
Software Prerequisites
In addition to the hardware dependencies mentioned above, there are a number of software dependencies that exist to support the various features of SQL Server 2008. The System Consistency Checker does a
very thorough job of identifying all the requirements and dependencies, and informing you if anything is
missing. For example, if a critical component is missing, the installer won’t proceed until that component
has been installed. If, however, you are running with less than recommended RAM, the SCC will give
you a warning, but allow you to proceed with the installation. It is up to the DBA to evaluate the warning
to ensure that it is acceptable to continue the installation.
Another critical dependency is the operating system. As you might expect, the IA86 and x64 editions
of SQL Server 2008 can only be installed if the operating system is using the same platform. Note that
32-bit versions of SQL can be installed on 64-bit operating systems, but may actually suffer a performance loss because it will need to run within the WOW64. The following table describes the different
operating systems required for each edition of SQL Server 2008. For a complete list of requirements, visit
http://technet.microsoft.com/en-us/library/ms143506.aspx.
32
11:37am
Page 32
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
Operating System
SQL Server Edition
Enterprise
Windows XP SP2 Pro
Standard
Workgroup
Web
Developer
Express
X
X
X
X
X
X
X
Windows XP Home
Edition SP2
Windows Server 2003
SP2 Web
X
Windows Server 2003
SP2 Standard
X
X
X
X
X
X
Windows Server 2003
SP2 Enterprise
X
X
X
X
X
X
Windows Server 2003
SP2 Datacenter
X
X
X
X
X
X
Windows Vista
Ultimate
X
X
X
X
X
Windows Vista
Enterprise
X
X
X
X
X
Windows Vista
Business
X
X
X
X
X
Windows Vista Home
Premium
X
X
X
Windows Vista Home
Basic
X
X
X
Windows Vista Starter
Edition
X
Windows Server 2008
Web
X
X
X
X
X
X
Windows Server 2008
Standard
X
X
X
X
X
X
Windows Server 2008
Enterprise
X
X
X
X
X
X
Windows Server 2008
Datacenter
X
X
X
X
X
X
Windows Small
Business Server 2003,
Standard Edition SP2
X
X
X
X
X
X
Windows Small
Business Server 2003,
Premium Edition SP2
X
X
X
X
X
X
33
Page 33
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
SQL Ser ver Installation Center
The SQL Server 2008 setup process itself is pretty straightforward. If Autorun is enabled (I usually turn
it off), the setup splash screen will launch as soon as you insert the media. If not, the installation can be
launched from the SETUP.EXE file located in the root folder of the installation media.
You may also note that there are three folders in the root folder of the SQL Server 2008 installation
media. Each folder contains the platform-specific setup files for the x86, x64, and IA64 platforms. When
you launch setup from the root folder, it runs a detection script to determine the platform of the current
system and launches the installer for that platform. If you have a specific need to install, for example, the
32-bit version on a 64-bit platform, the preferred method is to select the Options page of the SQL Server
Installation Center.
Before the setup application launches the SQL Server Installation Center, it checks for several dependencies that are critical to installing SQL Server. This includes an updated version of the Microsoft .NET
Framework (version 3.5 SP1), and in some cases, an update to the Windows Installer service may be
required as well. Be aware that if these components have not yet been installed, a reboot will be necessary
before SQL Server setup can continue.
Once the dependent components can be installed, the SQL Server Installation Center menu pops up. From
here, you can navigate through the different pages, to learn more about the planning and installation
process. You can choose to run the System Configuration Checker manually, but all of the tests are run
as part of the Installation Wizard for SQL Server 2008.
Setup Support Rules (for Setup Support Files)
Prior to installing the SQL Server setup support files, SQL Server checks a series of conditions to ensure
that the support files can be installed before the actual setup process begins. The six items shown in
Figure 2-5 and described in the following table are checked:
34
Component
Description
Minimum operating system
version
Checks whether the computer meets minimum operating
system version requirements.
Setup administrator
Checks whether the account running SQL Server Setup has
administrator rights on the computer.
Restart computer
Checks if a pending computer restart is required. A
pending restart can cause Setup to fail.
Windows Management
Instrumentation (WMI) service
Checks whether the WMI service is started and running on
the computer.
Consistency validation for SQL
Server registry keys
Checks if the SQL Server registry keys are consistent.
Long path names to files on SQL
Server installation media
Checks whether the SQL Server installation media is too
long.
11:37am
Page 34
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
Figure 2-5: Setup Support Rules results for setup files.
Once the initial validation tests have been completed and there are no errors that would halt the installation, the Registration Information screen appears and asks for your 25-character product key. After
entering the product key, you will be presented with the License Terms to review and accept.
Before proceeding with installation, you should understand some of the licensing constraints around
SQL Server 2008. Many organizations are not aware that the components of SQL Server are licensed as
a bundle, and when you purchase a server or processor license for SQL Server, you can install some or
all of those components on one machine, and one machine only. For example, if the Database Engine is
installed on one server and the Reporting Services engine is installed on a different server, a separate
license is required for each installation. This is a major area of confusion for many DBAs. Common sense
would say that a purchase of a SQL Server license that included the Database Engine, Reporting Services,
Integration Services, and Analysis Services would give an organization the right to spread these
services across as many servers as necessary, as long as only one instance of each service was used.
Common sense, in this instance, may get you into trouble with the licensing police. If you haven’t read
the licensing agreement, do so, or have your lawyer read it for you. The license agreement can also be
found in the Resources section of the SQL Server Installation Center.
After accepting the terms of the license agreement, you will be prompted to install the SQL Server
Setup files. These files are used during the installation process and are usually removed as part of the
post-install cleanup.
35
Page 35
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Setup Support Rules (for Installation)
Another set of validation tests must be performed to verify that the system meets the conditions
for installing SQL Server. The tested components are listed in the following table and shown in
Figure 2-6:
36
Component
Description
Fusion Active Template Library
(ATL)
Checks if a computer restart is required because of broken
fusion ATL. A pending restart can cause SQL Server Setup
to fail.
Unsupported SQL Server products
Checks whether SQL Server 7.0 or SQL Server 7.0 OLAP
Services is installed. SQL Server 2008 is not supported with
SQL Server 7.0.
Performance counter registry hive
consistency
Checks if the existing performance counter registry hive is
consistent.
Previous releases of SQL Server
2008 Business Intelligence
Development Studio
Checks for previous releases of SQL Server 2008 Business
Intelligence Development Studio.
Previous CTP installation
Checks whether there is an existing SQL Server 2008 CTP
installation.
Consistency validation for SQL
Server registry keys
Checks if the SQL Server registry keys are consistent.
Computer domain controller
Checks whether the computer is a domain controller.
Installing SQL Server 2008 on a domain controller is not
recommended.
Microsoft .NET Application
Security
Verifies that the computer is connected to the Internet.
When a Microsoft .NET application like Microsoft
Management Studio starts, there may be be a slight delay
while the .NET security check validates a certificate.
Edition WOW64 platform
Determines whether SQL Server Setup is supported on this
operating system platform.
Windows PowerShell
Checks whether Windows PowerShell is installed.
Windows PowerShell is a prerequisite of Microsoft SQL
Server 2008 Express with Advanced Services.
Windows Firewall
Checks whether the Windows Firewall is enabled. If the
Windows Firewall is enabled, a warning event will be
generated. This is to inform you that the SQL Server will not
automatically open the required firewall ports to enable
SQL connectivity. The Windows Firewall service must be
manually configured to allow incoming connections.
11:37am
Page 36
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
Figure 2-6: Setup Support Rules results for installation.
Feature Selection
The next step in the Installation Wizard is the Feature Selection screen (see Figure 2-7). This is where
you will choose what aspects of SQL Server you want to install. If you intend to follow along with the
examples in this book, it’s recommended that you install all features in your test environment. In a
production environment, you should install the features you intend to use, and no more. You can always
go back and install additional services and features, but for the sake of efficiency, if you’re not going to
be using Analysis Services, there’s no reason to install it. If you’ve installed an earlier version of SQL
Server, sample databases were often included with the installation media. In the case of SQL Server
2005, installation of the sample databases was disabled, but it was still a feature that you could enable
through the advanced installation options. With SQL Server 2008, the sample databases are not included
with the media and are available online at www.codeplex.com. More information on installing the sample
databases is covered later in this chapter.
Instance Configuration
After choosing what features of SQL Server are to be installed, the setup utility asks for instance information. You can install either a named instance or a default instance. The default instance takes on the name
of the machine where SQL Server is being installed. There can be only one default instance; however, SQL
Server 2008 Enterprise Edition supports installing up to 50 instances of SQL Server on a single machine.
37
Page 37
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
If there is a default instance, a maximum of 49 named instances can be configured. If no default instance
is installed, 50 named instances can be configured.
Figure 2-7: Feature Selection screen.
Named instances are referenced by the server name followed by the instance name. For example, the server
name used in the examples for this book is AughtEight. The default name of the SQL Server 2008 installation is the same as the server name. However, you could install a named instance on AughtEight called
Dagobah. To connect to the Dagobah instance of SQL Server, it must be referenced as AughtEight\Dagobah.
In addition to the name, any client accessing a named instance must use the SQL connection objects from
SQL Server 2000 or later. Legacy ODBC and old OLEDB drivers will be unable to enumerate a named
instance of SQL Server 2008.
The Instance Configuration screen also provides you with the opportunity to change the default location
for the SQL Server files. This sets the file location for the SQL binaries as well as the system databases.
Best practices recommend that you separate the instance folders from the OS drive.
Server Configuration
After the instance configuration is completed and the Disk Space Requirements have been verified, the
service accounts that SQL Server will use must be specified. Chapter 1 describes the various services
that SQL Server may need to run depending on what features were installed. When configuring the
security credentials for these services, you have a choice to make. Does the service require the ability to
authenticate and connect to external resources? If so, the local system account will not be appropriate.
38
11:37am
Page 38
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
Best-practice security guidelines recommend that the local system account not be used because it grants
full administrative access to the computer on which SQL Server is installed. This expands the attack
surface of the system by allowing a compromised SQL Server to be used to attack other components
on the system. Also, services running as the local system account will have no authenticated access to
resources that exist on other servers in your environment.
A very useful feature of SQL Server is the ability to use the SQL Server Agent’s scheduling options to
run unattended jobs. If the ability to schedule SQL Server jobs that require access to external resources is
desired, then at a minimum, the SQL Agent account will need to be configured to use a domain account
so that the respective account can be granted permissions to the remote resource.
The ability to configure each installed SQL Server service individually is provided (see Figure 2-8),
which is also a security best practice, but it does increase the administrative complexity of the
system.
Figure 2-8: Service account screen.
In addition to the security information for each individual service, each service can be configured for
automatic or manual startup during installation. By default, the SQL Agent Service is configured to start
manually, while other installed components will start automatically. In order for scheduled tasks and
jobs to execute, the SQL Agent Service must be running. It is usually a good practice to configure this
service to run automatically.
39
Page 39
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Additionally, the SQL Server Browser Service is disabled by default. The Browser Service is only needed
if you have multiple instances of SQL Server installed on the same machine. Although you cannot change
the account being used by the Browser Service or the Full-Text Daemon Filter Launcher, these can be
changed manually after SQL Server is installed.
Collation Settings
After setting the Authentication mode of SQL Server, you can configure the collation settings of SQL
Server 2008 by selecting the Collation tab in the Server Configuration window. The first question many
people have is, ‘‘What is collation?’’ The dictionary definition of collation is ‘‘assembling in proper numerical or logical sequence.’’ Collation settings have two significant effects on your database: the sorting of
your character-based data and the searching of your character-based data.
A different collation can be set for both the SQL Server and Analysis Services, but Analysis Services only
supports Windows collation, whereas SQL Server can support both Windows and SQL collation. SQL
collation support is included for backward compatibility, and it is recommended to configure the server
collation with Windows collation (despite the fact that SQL collation is configured as the default).
Choosing Windows collation by selecting the Collation Designator provides a greater level of control
and more choices when it comes to customizing the collation settings for the server. The collation setting
affects what data will be returned when searching on character data and in what order the data will be
returned. It also determines what characters will be supported.
The default collation for an installation is determined by the locale with which Windows was configured.
For example, the default collation the SQL Server installation application chooses when being installed on
a Windows server configured for the United States is SQL_Latin1_General_CP1_CI_AS. A brief definition
of this underscore-delimited name is definitely in order:
❑
SQL_Latin1_General_CP1 indicates that characters from the Latin Code Page One (CP1), which
is equivalent to the 1,252-character set, are supported. These characters provide support for the
storing, sorting, and searching of character data in any Latin-derived language. These languages
include Western European, English, and Latin American languages. However, it is important to
note that sort orders can be different among Latin-derived languages. For example, in German
the ö character comes before z, but in Swedish, the opposite is true (z comes before ö). Therefore,
small discrepancies can occur from language to language.
The number 1,252 represents the character set identifier as assigned by the International Organizations for Standardization (ISO).
❑
CI (Case Insensitive) indicates that the character data is to be sorted and searched in dictionary
order without regard to capitalization. As this setting infers, there is also a CS (Case Sensitive)
setting as well.
❑
AS (Accent Sensitive) indicates that the character data is to be sorted and searched in dictionary
order with preference to accent marks. As a result, a search for a German ‘‘spatlese’’ wine will
not return the correct spelling of this sweet late-harvest wine, which is spätlese if it is stored with
the umlauts. Accent sensitivity can be turned off by specifying AI (Accent Insensitive).
These are not the only character settings that can be set. Character data can be set to be stored with sensitivity to width with the designation of WS (Width Sensitive) or WI (Width Insensitive). Width sensitivity
applies to Unicode character data and differentiates between UTF-8 (8-Bit Unicode Text Format) and
40
11:37am
Page 40
Leiter
c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
UTF-16 (16-Bit Unicode Text Format). There is also a setting for Kana sensitivity: KS (Kana Sensitive)
and KI (Kana Insensitive). Kana sensitivity essentially controls the sorting and searching of Asian Unicode characters (Japanese, Chinese, etc.) that can represent the same words using different script. For
example, when Japanese kana characters Hiragana and Katakana are treated differently, it is called Kana
sensitive; when they are treated the same, it is Kana insensitive.
Character data can also be sorted by their binary value. Binary sorting and searching is actually faster
than dictionary sorting and searching, but is not as user-friendly. For example, the following script creates
a table with two columns. The first column is assigned a character data type with case-sensitive dictionary
collation. The second column is assigned a character data type with binary collation:
USE TempDB
CREATE TABLE MySortTable
(DictionarySort varchar(10) COLLATE Latin1_General_CS_AS NULL,
BinarySort varchar(10) COLLATE Latin1_General_BIN)
GO
Once the tables are created, you can populate both of them with the same six rows: Alpha, Bravo, Charlie
and alpha, bravo, charlie by executing the following command:
USE TempDB
INSERT MySortTable
VALUES (’Alpha’,’Alpha’)
INSERT MySortTable
VALUES (’Bravo’,’Bravo’)
INSERT MySortTable
VALUES (’Charlie’,’Charlie’)
INSERT MySortTable
VALUES (’alpha’,’alpha’)
INSERT MySortTable
VALUES (’bravo’,’bravo’)
INSERT MySortTable
VALUES (’charlie’,’charlie’)
GO
Now that the tables are created and populated, you can query them. Notice the different order of results
using an identical query:
SELECT DictionarySort
FROM MySortTable
ORDER BY DictionarySort ASC
DictionarySort
-------------alpha
Alpha
bravo
Bravo
charlie
Charlie
(6 row(s) affected)
SELECT BinarySort
41
Page 41
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
FROM MySortTable
ORDER BY BinarySort ASC
BinarySort
---------Alpha
Bravo
Charlie
alpha
bravo
charlie
(6 row(s) affected)
As you can see, server collation can have a profound effect on how your data is stored and retrieved, so
careful planning is essential when deciding on a server collation. Fortunately, collation can also be set at
the database and column level, so multiple collations are supportable.
As a word of caution, though, be careful when implementing incompatible
collations on a single server. Issues may arise when the server collation is set to a
collation that is not compatible with a database collation. This is because the tempdb
database is set to the default server collation. When temporary objects are created in
tempdb from a user database that uses an incompatible collation, errors can occur.
Database Engine Configuration
After you have configured the server options, the next stage in the installation process requires you to
set additional configuration properties on the Database Engine. It begins with the Account Provisioning
screen, which allows you to set the Authentication mode and define administrative users. Authentication
and security are covered in great detail in Chapter 6. However, a brief explanation is appropriate at this
point.
If the default ‘‘Windows Only’’ configuration is chosen, only connections that have been authenticated
by the local Windows security subsystem (or by the domain security subsystem) are allowed to be made
to SQL Server. In this scenario, SQL Server validates that the login exists and has been authenticated, but
no password verification takes place because SQL Server ‘‘trusts’’ that the login has been validated. A
frequent connection error that occurs on servers configured for ‘‘Windows Authentication mode’’ is one
that says simply that the login failed (see Figure 2-9).
Figure 2-9: Bad login or password error message.
This is admittedly a vague response to a login request and is not the most intuitive message in the world.
‘‘Login Failed because it is not a valid Windows account and the server is configured for Windows
42
11:37am
Page 42
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
authentication mode’’ or something a bit more informative would have been more useful. The message
can be even more cryptic, given that the respective SQL login may, in fact, exist. Being in ‘‘Windows
Authentication mode’’ does not prevent the database administrator from creating SQL Server login
accounts. However, any attempt to connect with a valid SQL Server login when the server is in ‘‘Windows
Authentication mode’’ will result in the vague ‘‘trusted SQL Server connection’’ error.
With ‘‘Mixed Mode,’’ SQL Server can authenticate Windows logins as well as logins that have been
created locally on the SQL Server. Local SQL Server logins are validated by username and password
verification. The username and an encrypted version of the password are stored in the master database.
When a SQL login connection is requested, the SQL Server security subsystem encrypts the provided
password, compares it to the stored password, and allows or refuses the connection based on the
credentials provided.
If you choose the ‘‘Mixed Mode’’ option, you will need to specify a password for the sa account. Not
setting one, or setting a weak one, would expose your SQL Server to any number of potentially disastrous
results.
Invalid credentials (either bad login name or bad password) result in the same ‘‘Login failed’’ message
(see Figure 2-9) when SQL Server is configured for ‘‘Mixed Mode’’ security.
Also on this screen you will need to provide at least one Administrator account. Often, you will want to
choose the ‘‘Add Current User’’ option (to give yourself rights to the SQL Server), but you may need
to include additional users or groups as well. Most common production environments will require you to
add a group that identifies all the SQL Server administrators, which can be added through this tool.
The Data Directories tab allows you to change the default locations for data files (which will also change
the default location for the system databases, user databases, the tempdb database, and the backup
directory).
The last tab in the Database Engine Configuration screen allows you to enable FILESTREAM options.
FILESTREAM is turned off by default, and if you don’t enable it from here, you can enable and configure
it using SQL Server Configuration Manager and SQL Server Management Studio. More information
about using FILESTREAM is in Chapter 5.
Analysis Services Configuration
As with the Database Engine, the Analysis Services Engine will require you to specify which users or
groups will have administrative control over the Analysis Services instance, as well as the data directories
for data, log, temp, and backup files. Note that Analysis Services does not use SQL-based logins. All
authentications are done through the Windows Authentication provider.
Reporting Services Configuration
If you are using SQL Server Reporting Services, you may want to specify how reports will be published.
As mentioned in Chapter 1, SQL Server Reporting Services no longer uses Internet Information Services
(IIS) for hosting access to the Reporting Services Web Service and the Reports virtual directory (both
of which are covered in more detail in Chapter 18). In your production environment, you should have
already decided whether reports will be published natively from SQL Server, or if they are going to be
published on a SharePoint Server. You have the option during installation to configure Reporting Services
to use the default ‘‘Native Mode’’ configuration or to use ‘‘SharePoint Integrated Mode.’’ There is also a
third option that allows you to install the files needed for the SSRS, but configuration will be done using
the Reporting Services Configuration tool after the installation has completed.
43
Page 43
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Error and Usage Reporting
Microsoft also provides an opt-in screen to allow you to send Windows and SQL error reports, as well
as feature usage data, to Microsoft. Personally, I see some value in this, as it helps Microsoft identify
problems or bugs. That being said, I enable this only on my test and development systems and never
in my production systems, unless there is a corporate policy that dictates otherwise. Microsoft Enterprise licensing customers can send error reports to a Corporate Error Reporting server that allows your
administrators to selectively choose which events get sent to Microsoft.
Installation Rules
Prior to finally installing the files for SQL Server, one last set of rules is checked. These rules validate
your setup configuration options to identify potential problems that would cause undesired behavior
or prevent SQL Server from installing. The following table lists the components that are checked before
installation begins:
44
Component
Description
Same architecture installation
Checks whether the installing feature(s) are the same CPU
architecture as the specified instance.
Cross language installation
Checks whether the setup language is the same as the language
of existing SQL Server features.
Existing clustered or
cluster-prepared instance
Checks if the selected instance name is already used
by an existing cluster-prepared or clustered instance on any
cluster node.
Reporting Services Catalog
Database File Existence
Checks whether the Reporting Services catalog database file
exists.
Reporting Services Catalog
Temporary Database File
Existence
Checks whether the Reporting Services catalog temporary
database file exists.
SQL Server 2005 Express tools
Checks whether SQL Server 2005 Express Tools are installed.
Operating System supported for
edition
Checks whether the SQL Server edition is supported on this
operating system.
FAT32 File System
Checks whether the specified drive is FAT32 file system
volume. Installing on a FAT32 file system is supported but not
recommended as it is less secure than the NTFS file system.
SQL Server 2000 Analysis
Services (64-bit) install action
Checks whether a default instance of SQL Server 2000 (64-bit)
Analysis Services is installed.
Instance name
Checks whether the specified instance name is already used
by an existing SQL Server instance.
Previous releases of Microsoft
Visual Studio 2008
Checks for previous releases of Microsoft Visual Studio 2008
11:37am
Page 44
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
Final Steps
After the Install Rules have been validated, a final summary screen appears that provides you with a list
of the services and features that will be installed. Clicking ‘‘Install’’ launches the SQL Server installation,
and an Installation Progress screen appears (see Figure 2-10). The Installation Progress screen gives
summary information about all the different features required by SQL Server and shows when each
individual feature is finished installing.
Figure 2-10: Installation Progress screen.
Installing to a Windows Cluster
The most difficult part about installing SQL Server to a cluster is configuring the Windows cluster, which
is beyond the scope of this book. It is important to note that planning and configuration of the cluster
must be done prior to running SQL Server Setup. There are several dependencies that must be in place,
such as clustering the Microsoft Distributed Transaction Coordinator (MS DTC). Once the Windows
cluster is installed and configured, the installation of SQL Server to the cluster has some very significant
differences from installing to a single server. One of the first things you will most likely notice is that
when the pre-installation rule validation process runs, it detects all nodes in the cluster and ensures
that they meet the requirements for a SQL Server install (see Figure 2-11).
Because you are installing a SQL Server failover cluster, the installation will be slightly different from
that previously described for a single server installation. After choosing to install the failover cluster, the
45
Page 45
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Instance Configuration screen appears. SQL Server 2008 supports multiple instances in a cluster, as well
as in stand-alone scenarios.
Figure 2-11: Ensuring that the requirements are met for the install.
Configuring the Virtual Server Name
The least-intuitive part of installing a SQL Server failover cluster is the naming configuration. When
the Windows cluster was originally installed, a virtual name was designated for the cluster. However,
a virtual name must also be specified for the SQL Server installation, and it cannot be the same as the
46
11:37am
Page 46
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
virtual name used for the cluster. For my test cluster, I installed Windows Server 2008 Enterprise Edition
on two Virtual PC images and configured the two servers as nodes in a Windows failover cluster. During
the SQL Server installation, the setup utility will prompt for the instance configuration information, at
which time you can supply both the SQL Server Network Name, which is the name of the SQL Server
cluster, and the instance name (Figure 2-12).
Figure 2-12: Instance Configuration screen.
If you choose a default instance, the name of the SQL Server will be whatever you provide
for the SQL Server Network Name. If you choose a named instance, the instance name will be
NetworkName\InstanceName.
After specifying the Network Name, a cluster resource group must be created. The resource group is
where SQL Server places all failover cluster resources. You will also need to specify the shared disk (or
disks) that will be used to store shared SQL Server data (Figure 2-13). Additionally, you will need to
designate an IP address that will be used as a listener for the SQL Server cluster.
The last cluster-specific option applies a cluster security policy for services that are installed as part of
the cluster. Windows Server 2003 and Windows XP only support the use of domain groups for clustered
services. This meant that the service accounts for each SQL Service installed as part of this cluster would
be added to the identified domain groups. Windows Vista and Windows Server 2008 include a new
feature that uses a Service SID rather than a group (Figure 2-14). This improves security by not requiring
the service account to run with unnecessary elevated privileges.
47
Page 47
Leiter c02.tex
Chapter 2: Installing SQL Server 2008
Figure 2-13: Cluster Resource Group screen.
Figure 2-14: Cluster Security Policy screen.
48
V3 - 03/25/2009
11:37am
Page 48
Leiter c02.tex
V3 - 03/25/2009
11:37am
Chapter 2: Installing SQL Server 2008
The Cluster Security Policy configuration screen is the last dialog that is different from a stand-alone
installation. The summary screen (Figure 2-15) is presented after the services screen, and then the
installation begins.
Figure 2-15: Cluster Installation Rules.
Once SQL Server is successfully installed, it can be controlled just like any other SQL Server instance.
The only difference is the ability of SQL Server to fail over to the second node automatically in the case
of fault tolerance, or manually for scheduled maintenance events.
Sample Databases
Because SQL Server no longer ships with sample databases, in order to follow along with
many of the examples in the book, you will need to download and manually install the sample databases from Mirosoft’s CodePlex site. There are three databases available that can be
found at www.codeplex.com/MSFTDBProdSamples. These include the AdventureWorks2008,
AdventureWorksLT2008, and AdventureWorksDW2008 databases. It is important to note that these
are not the same databases that shipped with SQL Server 2005. Although they may look similar on the
surface, they have a different schema, and they have been optimized for SQL Server 2008. Each of these
comes in a platform-specific version (x86, x64, ia64) and gives you several options for download types
(.zip and .msi). I prefer the MSI installer myself, as it makes it easy to download and deploy. There is
also an installer for some sample scripts that are used in conjunction with the databases.
In most cases, you’ll be using the AdventureWorks 2008 OLTP database, but the Analysis Services
chapter uses the AdventureWorks DW database.
49
Page 49
Leiter c02.tex
V3 - 03/25/2009
Chapter 2: Installing SQL Server 2008
Installation Review
Not every installation goes flawlessly, and not everything may behave as expected. After installing SQL
Server, it is important to review the installation to ‘‘inspect,’’ or ensure that what you expected to happen,
actually happened. Did the services get installed with the proper credentials? Are they configured to
auto-start? Are the program files and database files where they were expected to be? This may seem
to be a little overkill, but ‘‘An ounce of prevention is better than a pound of cure.’’
Summar y
Careful planning prior to the installation process prevents the need to uninstall and start over. It also
prevents a continuous struggle with an installation that is ‘‘not quite right.’’ In later chapters, the optimization process, disk and memory access, as well as disaster recovery are discussed in great detail, and
the connection to a well-designed infrastructure for installation will become increasingly evident. One
of the most important aspects of installing SQL Server is having an understanding of the effects of the
options you select. Too many times I’ve seen production environments where a junior administrator who
was given the install media and no direction installed every feature under the sun. This was wasteful and
unnecessary.
This chapter described physical storage options, which are a big part of any database configuration.
By placing SQL data files and log files on separate physical disks, you decrease the chances of a major
disaster and increase the speed of recovery. By placing SQL Server’s assets on separate controllers and
arrays, you also increase the performance of SQL Server by reducing resource conflicts and maximizing
database throughput. It’s always a balancing act to try to get the most out of your system performance
while staying within a reasonable budget.
When it comes to availability, understand that Microsoft worked very hard to make SQL Server
‘‘cluster-friendly.’’ It is fairly easy to configure a failover cluster, but remember that a full discussion of
the Windows cluster was not provided. Many resources are available in the Windows Help files, online
resources such as TechNet, and in print that cover the topic of clustering in great detail. It is strongly
recommended that you research them thoroughly prior to any SQL Server cluster installation.
Chapter 3 will introduce you to the tools used to administer, manage, monitor, and maintain SQL Server
2008. You will learn about a number of improvements that have been made to facilitate the administration
of SQL Server 2008.
50
11:37am
Page 50
Leiter c03.tex
V3 - 03/25/2009
11:39am
3
SQL Ser ver 2008 Tools
Several years ago, when I was beta testing SQL Server 2005, I was surprised to see familiar tools like
the Enterprise Manager, a Microsoft Management Console (MMC)-based interface, and the SQL
Query Analyzer done away with. In fact, with the exception of the SQL Server Profiler, pretty much
everything had been replaced with a new set of applications that were . . . well, different.
It’s been my experience that most database administrators (DBAs) typically fall into one of two distinct groups. The first group is made up of database administrators whose background is system
and network administration. The second group is made up of application and database developers
who have become responsible for the administration of a SQL Server infrastructure, be it a production system or a test-bed environment. DBAs that fell into the first category, myself included, often
responded with trepidation about the new SQL Server management tools, and with good reason.
Most of the new tools available were based on the Visual Studio interface. In fact, one of them was
indeed Visual Studio (although rebranded to sound less intimidating). What was Microsoft trying
to do — make us developers?
Yes. A database administrator must be about half system administrator and half developer in order
to be completely successful. Several years ago, when Microsoft announced its Microsoft Certified
Database Administrator (MCDBA) certification, it was no real surprise that the required exams
were both from the administrative side of database administration and the programming side.
Microsoft’s intent was clear. To be a database administrator worth his or her salt, it would be absolutely imperative to understand database design and database application development. This was
where Microsoft wanted DBAs to go, and they made sure we had the tools to get there. Ironically,
the current generation of certifications, the Microsoft Certified Information Technology Professional (MCITP), includes two distinct specializations for Database Administrators and for Database
Developers.
There is no doubt that Microsoft considers database administrators to be, at least marginally, developers. However, this does not mean that the tools are not intuitive and easy to use. In fact, after
having spent more than three years working with them, I can’t ever see myself going back to what
some of us jokingly referred to as Enterprise Mangler. The tools that you will use today to manage SQL Server 2008 (and supported previous versions) are more intuitive and easier to use. DBAs
will also be able to take advantage of functionality that developers have become used to, such as
source control, solution files that manage multiple related files, and a fully functional Integrated
Development Environment (IDE).
Page 51
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
If you’ve never worked with SQL before or haven’t managed SQL since SQL Server 2000, the new tools
may seem daunting. In reality, they are more streamlined, more efficient, and yet more powerful than
anything we’ve had before.
SQL Ser ver Management Studio
SQL Server Management Studio completely replaces Enterprise Manager and Query Analyzer from
SQL Server 2000 and earlier. It also replaces some of the functionality formerly found in other applications, such as SQL Analysis Manager. The bulk of work that I often do is performed through SQL Server
Management Studio, or SSMS.
On first glance, the SQL Server Management Studio interface looks a lot like the Visual Studio IDE. It
should, since it is, in actuality, a Visual Studio shell. The Visual Studio shell brings many very useful
tools and features to the creation and organization of database objects, as well as the full feature set of
the old tools.
When the SQL Server Management Studio is first launched, the default view is a great deal like the old
Enterprise Manager with a slight Query Analyzer influence (see Figure 3-1).
Figure 3-1: SQL Server Management Studio.
Because there are many different windows that can be viewed in the Management Studio, the management of screen real estate becomes critical. Most of the windows have the capability to either be pinned
open or configured to fly out when the mouse pointer is placed over the menu bar, or auto-hide when
the mouse cursor is placed elsewhere. If you are familiar with the Visual Studio Integrated Development
Environment (IDE), this will all be very familiar; if not, it may take a little while to get used to.
If you are unfamiliar with the Visual Studio interface, here’s a tip: Any window that supports the pinned
or unpinned option will have a pin at the top right of the window. When the window is pinned, the pin
52
11:39am
Page 52
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
will appear vertically oriented. When the window is unpinned, it will be horizontal (see Figure 3-2), and
the toolbar will auto-hide or fly out, depending on the mouse cursor location.
Pinned
Unpinned
Figure 3-2: Object Explorer with a
pinned and unpinned window.
As mentioned before, the Visual Studio interface has a bit of a learning curve, but once you get used
to it, it’s hard to imagine any interface that works as well. The biggest advantage of the interface is
that it’s heavily customizable. Everything from window placement to colors can be altered to suit your
personal management style. I used to drive my old manager (and cowriter), Dan, crazy by setting my
Query window to a black background with bright green text (yes, it was hideous). Being able to hide
and unhide windows with little effort offers a huge benefit. This conserves a great deal of screen real
estate without having to click several menus to expose the features you want. The expanding popularity
of Netbook computers with smaller screen sizes and limited resolution makes this a more and more
attractive feature for those of us who tend to administer from the road.
Tool Windows
SQL Server Management Studio offers many different tool windows that facilitate the development and
modification of database objects, as well as the effective management of SQL Server. The various views
are accessible from the View menu as well as the Standard Toolbar. Each window can be configured
as Dockable, which is the default, but can also be configured as a Tabbed Document or a Floating window. You can change the state of the window by clicking on the down arrow next to the pushpin in the
window’s title bar, or if the window is floating, by right-clicking on the title bar (Figure 3-3).
Figure 3-3: Window placement
options.
53
Page 53
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
A dockable window means that the window can be dragged and docked at almost any location in the
environment. If you don’t like the Object Explorer window on the left of the Studio, just drag it to the
right, top, or bottom, and dock it there. When dragging a tool window, a guide diamond will appear
in the center of the screen representing the dockable areas. Dragging the window over one of the area
representations (see Figure 3-4) will cause a shadow to appear in that area, indicating that the window
can be docked there by releasing the mouse button.
Figure 3-4: Dockable window.
Changing a windows property to Tabbed Document mode changes the window into a tab on the main
window. The Floating window option specifies that the tool window is not anchored anywhere and can
be moved around the main interface.
Object Explorer
The Object Explorer (see Figure 3-2) is more than just a way to explore the database objects on a server.
The Object Explorer is also the tool that will be used to initiate most database management tasks. It is
arranged in a standard tree view with different groups of objects nested in folders.
The Object Explorer’s functionality is exposed through the context menu. Right-clicking on any object
or folder within the Object Explorer exposes a list of context-sensitive options, from creating tables and
users to configuring replication and Database Snapshots. The context menu also presents the ability to
create scripts that manipulate. For example, right-clicking on a table exposes a context menu that allows
the user to either view or modify the table structure through the graphical interface, or create scripts to
perform actions against the table or its data (perhaps to be saved and executed later). This functionality
exists for virtually every object that is visible in the Object Explorer.
Another great feature of SQL Server Management Studio that is exposed through the Object Explorer
and other areas of the Studio interface is the ability to create scripts based on actions performed in the
graphical designers. For example, right-clicking on the table folder and choosing to create a new folder
launches a graphical interface where the table structure can be defined. Once the table design is complete,
54
11:39am
Page 54
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
you can either save the table (which creates it) or click the ‘‘Generate Change Script’’ button on the Table
Designer toolbar (which will write the appropriate T-SQL to complete the task). Using the ‘‘Generate
Change Script’’ option can be beneficial when creating objects in a test or development environment that
will also need to be created in a production environment.
Likewise, when working with other objects in Management Studio, a Script button will appear at the
top of the respective designer, which will cause the actions performed in the designer to be scripted to
a new Editor window. This feature is particularly useful when several different objects of the same type
are to be created. The first one can be designed in the designer, the script generated for it, and that script
modified to create the remaining objects. It can also be a good learning tool, by allowing inexperience
database administrators to learn the T-SQL equivalent of a task that is performed through the Graphical
User Interface (GUI).
Try It Out
Creating a Script
In the following example, you use the Object Explorer to create a script for a new database called
DVDCollection:
1.
In Object Explorer, right-click Databases. In the context menu that appears, click ‘‘New
Database.’’
2.
The New Database dialog appears (see Figure 3-5).
Figure 3-5: New Database dialog.
55
Page 55
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
3.
4.
5.
Enter DVDCollection for the name of the database.
Click on the Script button at the top of the New Database dialog.
The Script button causes the appropriate T-SQL code to be written to a new Query window.
Clicking the down arrow to the right of the Script button (Figure 3-5) gives you the option of
sending the script to a variety of locations.
6.
In the New Database dialog box, click Cancel. (Clicking OK will cause the database to be created.)
The script remains, but the database is not created unless the script is executed.
Code Editor
The Code Editor in SQL Server Management Studio provides the ability to open, edit, or create new
queries. The types of queries supported by the Editor are:
❑
Database Engine Queries — These are written in Transact-SQL (T-SQL) against a SQL Server
OLTP database.
❑
Analysis Services MDX Queries — These use the MultiDimensional eXpression (MDX) language.
MDX queries are used to retrieve information from multidimensional objects created in Analysis
Services.
❑
Analysis Services DMX Queries — These are created by using extensions to the Structured
Query Language (SQL) called Data Mining eXtensions (DMX). DMX queries are written to return
information from data-mining models created in SQL Server Analysis Services databases.
❑
Analysis Services XMLA Queries
❑
SQL Server Compact — As the name implies, these can perform Transact-SQL queries using a
SQL Server Compact Edition database file as a data source.
The Code Editor is essentially a word processor. It provides color coding of syntax, multiple query windows, and partial code execution when you highlight the desired code and click on the Execute button
or press [F5]. The SQL Server 2008 Books Online documentation will often refer to the Code Editor as the
Query Editor (its most common moniker), Text Editor, or simply the Editor, depending on what aspect of
SQL Server you are reading about.
The basic functionality that the Code Editor brings is the same for all the possible types of queries
it supports. However, more complete functionality is provided for specific languages. For example,
when creating MDX, DMX, or XMLA queries, the Code Editor provides basic IntelliSense functions
such as those found in Visual Studio. SQL Server 2008 also introduces, for the first time, IntelliSense for
Transact-SQL, which includes code completion (for object names) and error handling. For example, while
typing the following script, as soon as you type the H in HumanResources, a dropdown list appears with
the HumanResources schema selected. Pressing the period (.) key results in a list of objects that exist
within the HumanResources schema, from which you can use the arrow keys to highlight and select the
Employee table.
56
11:39am
Page 56
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
USE AdventureWorks2008
Select * from HumanResources.Employee
Where Gender = ‘M’;
GO
Additionally, if you mouse-over the column name, Gender, the Query Editor provides you with metadata
about the gender column, as shown in Figure 3-6.
Figure 3-6: IntelliSense displaying column information.
Right-clicking on the Code Editor window, when that window is associated with a Database Engine
query, results in a context menu that includes the ‘‘Design Query in Editor’’ option (see Figure 3-7). The
Query Designer is also available from the SQL Editor toolbar described later. The Query Designer can be
very helpful when writing queries against databases that are not familiar to the query writer.
Figure 3-7: Query window context
menu.
57
Page 57
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Solution Explorer
In the past, DBAs and database developers who had to keep track of saved queries that were used
together as part of a batch process, or required source control and versioning, often had to manage
multiple independent files manually. I don’t know how many times I’ve browsed a common file system
and found scattered .sql files stored here and there. SQL Server Management Studio takes full advantage
of Visual Studio’s solution system by providing the means of grouping various connection objects and
scripts into a single solution called a SQL Server Management Studio Solution. Each solution can have one
or more projects associated with it. For example, if you are developing several objects for a new application that includes both Database Engine and Analysis Engine objects, you can create a new solution that
links them all together by creating a new SQL Server Management Solution with one or more associated
Projects (see Figure 3-8).
Figure 3-8: Associating projects and solutions.
If no solution is currently open, the Management Studio will create a new one. As you can see in
Figure 3-8, there are three types of projects to choose from:
❑
SQL Server Script — These projects contain T-SQL Database Engine queries.
❑
Analysis Services Script — These projects contain MDX, DMX, and XMLA analysis queries.
❑
SQL Server Compact Edition Script — These projects contain SQL Server Compact queries, as
you might expect.
The solution is managed through a SQL Server Management Studio Solution file with an .ssmssln extension. The example shown in Figure 3-8 created a new solution folder called AdventureWorks Automation
that contains a project folder called AdventureWorks Data Integration. By default, the solution folder and
the first project folder will have the same name, so it is generally a good idea to change the name of the
58
11:39am
Page 58
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
solution. The ‘‘Create directory for solution’’ option can also be cleared and a solution folder specified. In
this way, only a project folder will be created in the specified directory. If a solution is already opened,
creating a new project can add the project to the solution, or be configured to create a whole new solution
and close the open one. Solutions can contain many projects. For example, a project called AdventureWorks
Data Preparation can be added to organize the files for the sales piece of the solution (see Figure 3-9).
AdventureWorks
Projects
Figure 3-9: Multiple projects.
Projects contain three folders:
❑
Connection Folders — These folders store objects that contain connection parameters for the
queries in the solution. For example, if you look at the AdventureWorks Data Preparation
project shown in Figure 3-9, you will note that there are two connection objects, one for the
AughtEight\Administrator account and another for a SQL account named ChrisL.
❑
Queries Folders — Each of the queries in the Queries folders of the project will use one of those
configured connection objects. The query will run in the context of the associated connection
object.
❑
Miscellaneous Folder — This folder can be used to store just about any other file that is pertinent to the project. This may be project documentation, XML files, or even the .NET assemblies
used to create managed-code procedures.
The solution folder contains two files:
❑
Solution File — One file is the solution file, which, in this case, is called
AdventureWorks Automation.ssmssln. This contains a list of all the projects in the solution
and their locations.
❑
SQL Solution Options File — The second file is the SQL Solution Options file,
AdventureWorks Automation.sqlsuo. The solution options file contains information about
the options that customize the development environment. This file is hidden by default.
The solution folder will contain a project folder for every project added to the solution. The project
folder contains all the project files, including the project definition file. The project definition
file, or SQL Server Management Studio SQL Project file, is an XML file with the .ssmssqlproj
59
Page 59
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
extension. In the previous AdventureWorks Data Integration project example, this file is called
AdventureWorks Data Integration.ssmssqlproj. The project definition file contains the connection
information, as well as metadata about the remaining files in the project.
Properties Window
The Properties window is linked to the Solution Explorer and simply displays the properties for the
currently selected item in the Solution Explorer window. Editable properties will be bolded.
Registered Servers
Multiple servers can be registered and managed with the Management Studio. Right-clicking on any
blank area in the Registered Servers window or on any server group name (see Figure 3-10) will expose
a context menu that allows for the addition of new server registrations. It also allows for the creation of
server groups. The Registered Servers window is not visible by default. To open it, use the View menu,
and select Registered Servers or press [Ctrl]+[Alt]+G.
Figure 3-10: Registered Servers
window.
If you have multiple servers in your organization, server groups can be very useful. For example, server
registrations can be segregated so that all the test and development servers are in one group and the production servers are in another, or servers could be grouped based on function or department. Instances of
the Database Engine, Analysis Services, Reporting Services, Integration Services, and SQL Server Compact can be registered in the Registered Servers window (Figure 3-10). Once registered, the Registered
Servers window provides the ability to manage the associated services or launch other SQL Server tools
associated with the respective instance.
A new feature of SQL Server 2008 includes the ability to use policy-based management, enforceable on multiple servers simultaneously through the use of Central Management servers. Central
Management servers can be registered in the Registered Servers window and can also have Server
Groups created to group together services with similar configuration requirements. Policy-based
administration can be used to apply policies to the Central Management server, the Server Group, or the
individual registered SQL Server. More information about Policy-Based administration is presented in
Chapter 8.
Bookmark Window
When working with very large scripts in the Code Editor, it is very useful to be able to mark a location
in the script. Bookmarks enable this functionality. The Bookmark window is made visible from the View
menu and is enabled when working with any SQL Server script type. Any number of bookmarks can
60
11:39am
Page 60
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Figure 3-11: Bookmark window.
be created and then renamed with an intuitive name that identifies the bookmark (see Figure 3-11). If
the script is part of a solution, the bookmarks are saved with the solution in the Solution Options file.
Bookmarks can be added to a line by pressing [Ctrl]+K twice. Navigating bookmarks is easy. In addition
to selecting the bookmarks in the Bookmark window, you can use the key combinations of [Ctrl]+K,
[Ctrl]+P and [Ctrl]+K, [Ctrl]+N to move to the previous and next bookmarks, respectively. You can also
organize your bookmarks into multiple folders for each project, which can make it easier to navigate
through bookmarks by function.
Toolbox
The Toolbox window (see Figure 3-12) consists of maintenance plan tasks that can be dragged and
dropped into maintenance plan subtasks using the Maintenance Plan Designer, which is described in
more detail in Chapter 8.
Figure 3-12: Toolbox
window.
61
Page 61
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Error List
The Error List can be handy when trying to troubleshoot a query, even simple ones like the example in
Figure 3-13, by providing descriptive information about the error, as well as line and position number in
the query text. As you can see, the three lines of code have generated four errors. You can now resolve
these errors before you execute your query.
Figure 3-13: Error List window.
Object Explorer Details
The Object Explorer Details window replaces the Summary View from SQL Server 2005. It is a great
deal like the List or Detail view in Windows Explorer; however, it also provides a very useful reporting
feature. This feature allows the rendering of various server and database reports. The report feature is
enabled when right-clicking on an object in the Object Explorer or in the Object Explorer Details window
that has reports associated with it, and selecting the Reports option from the context menu. The following
table contains a list of all the supported reports and where they can be found:
Report Object
Reports
Server
Server Dashboard
Configuration Changes History
Schema Changes History
Scheduler Health
Memory Consumption
Activity — All Blocking Transactions
Activity — All Cursors
Activity — Top Cursors
62
11:39am
Page 62
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Report Object
Reports
Activity — All Sessions
Activity — Top Sessions
Activity — Dormant Sessions
Activity — Top Connections
Top Transactions by Age
Top Transactions by Blocked Transactions Count
Top Transactions by Locks Count
Performance — Batch Execution Statistics
Performance — Object Execution Statistics
Performance — Top Queries by Average CPU Time
Performance — Top Queries by Average I/O
Performance — Top Queries by Total CPU Time
Performance — Top Queries by Total I/O
Service Broker Statistics
Transaction Log Shipping Status
Server.Database
Disk Usage
Disk Usage by Top Tables
Disk Usage by Table
Disk Usage by Partition
Backup and Restore Events
All Transactions
All Blocking Transactions
Top Transactions by Age
Top Transactions by Blocked Transactions Count
Top Transactions by Locks Count
Resource Locking Statistics by Objects
Object Execution Statistics
Database Consistency History
Index Usage Statistics
Index Physical Statistics
Continued
63
Page 63
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Report Object
Reports
Schema Changes History
User Statistics
Server.Database.Service Broker
Service Broker Statistics
Server.Database.Storage.Full Text Catalogs
Active Full Text Catalogs
Server.Security
Login Statistics
Login Failures
Resource Locking Statistics by Logins
Server.Management
Tasks
Number of Errors
Server.Management.Data Collection
Server Activity History
Disk Usage Summary
Query Statistics History
SQL Server Agent
Job Steps Execution History
Top Jobs
Web Browser
SQL Server Management Studio also includes the ability to launch a Web Browser window within
the context of the management studio. The browser uses the Internet Explorer renderer, if desired,
to minimize the number of open applications and to allow direct access to Internet content from
within the Management Studio application. The Web Browser window is made visible from the
View menu (or by pressing [Ctrl]+[Alt]+R). You can use the address bar at the top of the window
to enter a URL, or you can use the Web Browser Search button to take you to the MSDN home
page.
Although using a browser within Management Studio might seem unnecessary, it does offer some benefits. For example, it allows tabbed browsing of content or newsgroups that may be pertinent to the
current solution. You can search or ask questions without having to switch back and forth between Management Studio and Internet Explorer. Keep in mind that the Web Browser window is just an instance
of Internet Explorer embedded in Management Studio. The behavior of the Web Browser window is the
same as Internet Explorer, and the security configuration of Internet Explorer is in full effect in the Web
Browser window. However, because a separate executable is not launched, it may actually be more efficient from a resource perspective to launch the Web Browser within the context of Management Studio.
For example, on my test system, when I opened up a new instance of IE and browsed to www.msdn.com,
the process consumes about 13 MB of memory. Launching the Web Browser window in SSMS and clicking on the Web Search button in the toolbar increased the memory utilization for the SSMS process by
only 3 MB.
64
11:39am
Page 64
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Template Explorer
The Template Explorer (see Figure 3-14) contains hundreds of SQL Server, Analysis Server, and SQL
Compact scripts. Each script is grouped into folders based on their function. The template scripts can be
opened by being dragged onto an open Query window. If no Query window is open, the templates can
be opened by double-clicking with a mouse, using the Edit menu, or right-clicking on a context menu, all
of which cause a new Query window to open.
Figure 3-14: Template Explorer.
When using a template, you can modify the text directly in the Query Editor, or you can use the ‘‘Specify
Values for Template Parameters’’ option to replace the placeholders in the template (see Figure 3-15).
This dialog can be launched from the SQL Editor toolbar or through the Query menu.
Toolbars
SQL Server Management Studio includes 14 preconfigured toolbars that contain features from various
menus. Each toolbar can be displayed or hidden by using the View Toolbars menu (see Figure 3-16).
The existing toolbars can be customized to display only the buttons that are most often used, or you can
create a new toolbar that has only the commands you typically use.
65
Page 65
Leiter c03.tex
Chapter 3: SQL Server 2008 Tools
Figure 3-15: Parameter replacement.
Figure 3-16: Toolbars menu.
66
V3 - 03/25/2009
11:39am
Page 66
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Try It Out
Creating a Custom Toolbar
Create a new custom toolbar by completing the following steps:
1.
Select the Customize command on the View Toolbars menu. This will launch the Customize
window.
2.
On the Customize window, click on the New button (see Figure 3-17), give your toolbar a new
name (for this example, I just created one called My Toolbar), and click OK. Your new toolbar will
show up in the Toolbars list, as well as a floating toolbar on your screen.
Figure 3-17: Custom toolbar window.
3.
With your new toolbar highlighted, select the Commands tab on the Customize window. Two
panes are visible on the Commands tab: Categories and Commands. Each category contains commands specific to that category. For example, the File category contains commands such as Open
File, Save Project, and so on.
4.
Select the Edit Category, and drag several commands to the new custom toolbar created in Step
2 (see Figure 3-18). You can also right-click on a button on the toolbar to change some of the
options of that toolbar — for example, changing the name or button image used for that command. Once you have all the commands that you want on the new toolbar, you can drag it and
dock it in a desired location.
67
Page 67
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Figure 3-18: Custom edit toolbar.
Creating new toolbars or customizing existing ones can help you manage your screen real estate by
allowing you to create more useful and efficient toolbars.
Database Diagram Toolbar
The Database Diagram toolbar (see Figure 3-19) exposes a great deal of functionality for use on database
diagrams.
Figure 3-19: Database Diagram toolbar.
The toolbar is not used just for diagramming the database, but also for modifying or creating database
objects from within the diagram interface. The Database Diagram toolbar features are described in the
following table:
68
Feature
Purpose
New Table
Enables the creation of new tables from within the database diagram.
Add Table
Adds an existing table from the database to the diagram.
Add Related Tables
If a table in the database diagram is related to one or more additional tables
by a declarative Foreign Key constraint, clicking on the Add Related Tables
button will add those related tables to the diagram.
11:39am
Page 68
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Feature
Purpose
Delete Tables from
Database
Not only removes the table from the diagram, but deletes the table
and its contents as well. Use with caution.
Remove from Diagram
Removes the selected table from the diagram, but not the database.
Generate Change
Script
Any changes made to database objects in the diagram (such as the creation,
deletion, or modification of attributes) can be sent to a script.
If changes are made to underlying objects and the diagram is saved, a prompt is
shown asking to confirm changes to the underlying objects.
Set/Remove Primary
Key
Sets or removes the primary key assignment to the selected column.
New Text Annotation
Adds a textbox for annotation to the database diagram.
Table View
Enables the changing of table presentation in the diagram, including
a customized view to configure exactly which aspects of the table are displayed.
The default is Column Names.
Show Relationship
Labels
Displays or hides the name of the foreign key constraints.
View Page Breaks
Displays or hides page break lines to enable the organization of diagrams for
printing.
Recalculate Page
Breaks
Re-centers table objects onto as few pages as possible after being manually
arranged on the diagram.
Autosize Selected
Tables
Re-sizes the selected table so that all rows and columns are visible.
Arrange Selection
Arranges selected tables so they do not overlap and are viewable
in the diagram.
Arrange Tables
Arranges all tables so they do not overlap and are viewable in the diagram.
Zoom
Increases or decreases the zoom factor on the displayed diagram.
Relationships
Launches a dialog that displays existing foreign keys defined on a selected table
and enables the defining of additional foreign keys.
Manage Indexes and
Keys
Launches a dialog that displays existing primary and unique keys defined on a
selected table and enables the defining of additional keys.
Manage Fulltext
Indexes
Launches a dialog that displays existing full-text indexes on a selected table and
enables the defining of additional full-text indexes on full-text index-enabled
databases.
Manage XML Indexes
Launches a dialog that displays existing XML indexes on a selected table and
enables the defining of additional XML indexes.
Manage Check
Constraints
Launches a dialog that displays existing Check Constraints on a selected table and
enables the defining of additional Check Constraints.
Manage Spatial
Indexes
Launches a dialog that displays existing Spatial indexes on a selected table and
enables the defining of additional indexes on Spatial data types.
69
Page 69
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Debug Toolbar
The Debug toolbar, as shown in Figure 3-20, includes several tools useful when debugging projects in
SQL Server Management Studio that let you step through long queries to help identify potential problem
areas.
Figure 3-20: Debug toolbar.
The Debug toolbar’s commands are described in the following table:
Command
Purpose
Start Debugging
Begins debug mode and runs the code in the Query Editor against the debugger
until a breakpoint is encountered.
Break All
Sets the debugger to break all processes to which it is attached.
Stop Debugging
Exits Debug mode.
Show Next Statement
Moves the cursor to the next statement.
Step Into
Runs the next statement.
Step Over
Skips the statement immediately after the current one and executes the
statement after next.
Step Out
Steps out to the next highest calling level in the query structure.
Breakpoints
In Standard mode, this opens the Breakpoints window, which allows you to
view and manage Breakpoints in the current query. In Debug mode, this
provides a breakpoint menu that includes the ability to open the Locals, Call
Stack and Threads window.
Debug Location Toolbar
The Debug Location toolbar (Figure 3-21) displays thread and stack frame information about the current
command being executed in the Debug window.
Figure 3-21: Debug Location toolbar.
Help Toolbar
The Help toolbar (see Figure 3-22) provides a very easy and convenient mechanism for consulting online
help articles while using the Management Studio.
Figure 3-22: Help toolbar.
70
11:39am
Page 70
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
The Help toolbar’s commands are described in the following table:
Command
Purpose
Web Browser
Back/Web Browser
Forward
If the Web Browser window is opened in Management Studio, the Web
Browser Back and Forward commands can be used to move from a
viewed Web page to the previously viewed Web page, and vice versa.
Web Browser Stop
Stops the loading of a Web page in a Web Browser window.
Web Browser Refresh
Refreshes the current Web Browser window.
Web Browser Search
Launches the MSDN web site in a new Web Browser window.
Text Size
Changes of the size of text in the Web Browser window. Clicking this
repeatedly will cycle the font size from Smallest, Smaller, Medium,
Larger, and Largest.
How Do I
The ‘‘How Do I’’ command launches SQL Server Books Online and
loads up the How Do I section, which allows the user to navigate
through articles that explain how to perform a myriad of actions with
SQL Server 2008.
Search
Launches the search feature of SQL Server Books Online.
Index
Launches the SQL Server Books Online Index.
Contents
Launches the SQL Server Books Online Table of Contents.
Help Favorites
Launches SQL Server Books Online and opens the Help Favorites
window
for navigating any saved favorites.
Add to Help Favorites
Adds the currently viewed help page to the Help Favorites.
Save Search
Saves the current search in the SQL Server Books Online search page to
the Help Favorites.
Sync with Table of
Contents
If the SQL Server Books Online Table of Contents is visible, this button
will navigate to the location in the Table of Contents that the current
article window is opened to.
Ask a Question
Opens the Search Community Forums home page at the MSDN web
site. Here you can create a profile and ask questions of other SQL Server
professionals or answer other people’s questions.
Check Question Status
Once you have an MSDN Community Forum account, your questions
are associated with your account, so you can easily check back to see if
anyone has replied to your question.
Send Feedback
The Send Feedback command allows you to provide feedback to the
SQL Server product team about SQL Server 2008.
Query Designer Toolbar
The Query Designer toolbar (see Figure 3-23) is enabled when a table is opened for editing with Object
Explorer.
71
Page 71
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Figure 3-23: Query Designer toolbar.
To open a table for editing, follow these steps:
1.
2.
Right-click on the table you want to open in Object Explorer.
Click ‘‘Edit Top 200 Rows.’’
If the Query Designer was not visible, it will be when the table is opened. If it was visible, it will now be
enabled. Although opening a table in a test and development environment might be acceptable, opening
a table in this manner in a production environment is never recommended. Opening a table with the
Object Explorer dumps the data from the table in to an updatable scrollable cursor. What this means
is that while the table data is exposed in the results window, any change to the displayed data is also
made to the underlying data in the table. There is no confirmation message or warning. The data is just
modified. This can be very dangerous. Displaying the entire contents of the table can also consume a great
deal of server resources if the table is large. The default behavior of SQL Server Management Studio only
exposes the first 200 rows of a table for editing, but this can be changed through the Tools Options
menu. As a general rule, if the entire contents of a table need to be exposed for quick viewing, the best
way is to write a query with no filters, such as the following:
USE AdventureWorks2008
GO
SELECT * FROM Person.Person
This exposes the same information as opening the table, but does not populate an updatable cursor, so
the results are Read Only. If the data in that table needs to be updated, an update command is more
appropriate than modifying the data in an open table results window.
The Query Designer toolbar features are described in the following table:
72
Feature
Purpose
Show Diagram
Pane
Displays or hides the Diagram Pane, which can be used to add or remove
tables from the query, add derived tables, and configure table join criteria.
Show Criteria
Pane
Displays or hides the Criteria Pane, which can be used to alias column
names, establish sort orders, and configure filter criteria.
Show SQL Pane
Displays or hides the SQL Pane, which displays the resultant SQL syntax
from the Diagram Pane. The SQL syntax can also be manipulated in the
SQL Pane, resulting in changes to the Criteria and Diagram Panes.
Show Results
Pane
Displays or hides the results of the query if it has been executed.
Change Type
Allows changing the type of query from SELECT to INSERT, DELETE, or
UPDATE.
11:39am
Page 72
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Feature
Purpose
Execute SQL
Executes the query against the database.
Verify SQL
Syntax
Validates the syntax of the query, but does not execute it.
Add/Remove
Group By
Adds a GROUP BY expression and formats the query so that non-aggregated
columns in the SELECT list are present in the GROUP BY list.
Add Table
Adds an existing table to the Diagram Pane and SQL Pane.
Add New
Derived Table
Adds an empty table to the Diagram Pane and the shell syntax for creating
a derived table subquery to the SQL Pane.
Source Control Toolbar
The Source Control toolbar (see Figure 3-24) is enabled when working with scripts and a Source Control
plug-in has been configured such as Visual Source Safe 2005. The addition of source-control functionality to SQL Server projects is a great step forward in recognizing the need for a structured solution
environment in the development of database solutions.
Figure 3-24: Source Control toolbar.
The following example uses Visual Source Safe 2005 as the source-control tool, but there are other
source-control applications available that will interact with SQL Server Management Studio. A full
description of Visual Source Safe 2005 configuration and use is beyond the scope of this book, so it will
be limited to just the interaction with SQL Server Management Studio.
To configure Management Studio to use source control:
1.
Click File, and click Launch Microsoft Visual Source Safe. The Add Visual SourceSafe
Database Wizard will launch.
2.
Click Next on the Welcome screen. The Database Selection screen will appear, asking for the
location of an existing Source Safe database. If you or your organization has already configured a source-control database, select the ‘‘Connect to an existing database’’ option. If this is
a new installation, check the ‘‘Create a new database’’ option (see Figure 3-25).
3.
The next step is either to choose an existing source control share location or to create one.
After choosing to either use an existing share or to create a new one, the summary screen for
the Wizard will appear.
4.
Clicking Finish on the Wizard will launch the Visual SourceSafe Explorer. The Visual
SourceSafe Explorer can be used to create and manage project folders for both SQL Server
Management Studio and Visual Studio solutions.
In a previous example, I created a Management Studio solution called AdventureWorks Automation. Now
that Visual SourceSafe is configured for use with Management Studio, I can add the solution to the
73
Page 73
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
source-control database to control the modification of the included files and to provide structured version
control.
Figure 3-25: Source-control database selection.
Much of the functionality of the Source Control toolbar is only enabled if the current project has already
been added to the source-control database.
To add a solution to source control, right-click on the solution in Solution Explorer and select ‘‘Add
Solution to Source Control.’’ After logging in to source control, choose a location for the solution (see
Figure 3-26) and click OK.
Figure 3-26: Add solution to source control.
Now that the solution has been added to source control, the Source Control toolbar is fully enabled for
managing the solution.
74
11:39am
Page 74
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
The features available on the Source Control toolbar are described in the following table:
Feature
Purpose
Change Source
Control
Displays a dialog that enables the linking of new and existing items in the
Solution Explorer to a source-control database folder.
Get Latest
Version
Opens the latest version of the item or items selected in the Solution
Explorer.
Get
Returns a list of all versions of the selected item and allows the selection of
a particular version.
Check Out for
Edit
Opens the selected item for editing and marks its status in the
source-control database as ‘‘Open for Edit,’’ preventing other users from
editing it at the same time.
Check In
Saves changes and marks the selected item in the source-control database
as ‘‘Checked In’’ and allows editing by other users.
Undo Checkout
Discards any changes and marks the selected item in the source-control
database as ‘‘Checked In’’ and allows editing by other users.
View History
Displays the history of a project, which includes a list of everything done
to the project from creation to deletion.
Refresh Status
Queries the source-control database for the most recent status of all project
items.
Share
Allows for a single item to be shared in multiple projects. Changes made to
shared items are reflected in all the projects that use the item.
Compare
Compares an item to a previous version to expose the changes made.
Properties
Displays detailed status information on the selected item.
Source Control
Manager
Launches the associated source control application as identified in the
Management Studio options settings.
SQL Editor Toolbar
The SQL Editor toolbar (see Figure 3-27) becomes visible (or is enabled if already visible) when a new
SQL Query window is opened. It provides the most common features used by SQL programmers and
DBAs.
Figure 3-27: SQL Editor toolbar.
75
Page 75
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
The supported features available on the SQL Editor toolbar are described in the following table: }
76
Feature
Purpose
Connect
Queries can be written without being connected to a database, so when it
comes time to execute the query or validate its syntax against a database, the
Connect button displays a server connection dialog that enables the selection
of the applicable server and database.
Change Connection
Enables changing the connected server. A script can be created and tested on
a test and development server and then the connection changed to the
production server for execution.
Available Databases
Dropdown list box for selecting the database context for the query
Execute
Executes the SQL in the current window (or the highlighted portion
of code) against the selected database.
Debug
Opens the current query in the debugger.
Cancel Executing Query
Terminates the active query.
Parse
Checks the SQL in the current window for valid structure and syntax. It
does not check to ensure that referenced objects actually exist.
Display Estimated Execution
Plan
Displays a graphical execution plan for the current window. It does not
actually execute the query, but simply checks the metadata of the referenced
object and builds a query plan based on current information.
Query Options
Opens a dialog box that allows you to specify query-specific options, such as
maximum rows returned, deadlock priority, and ANSI settings. You can also
configure the output settings of the query from this dialog.
IntelliSense Enabled
Toggling this button allows you to enable or disable IntelliSense for this
query.
Include Actual Execution
Plan
A graphical query plan used during execution is returned along with the
results of the query.
Include Client Statistics
Client statistics including statistics about the query, network packets, and
the elapsed time of the query are returned, along with the query results.
Results to Text
Formats the results of any query executed in the Query Editor as text.
Results to Grid
Query results are returned in a grid. By default, grid results cannot exceed
65,535 characters.
Results to File
When a query is executed a Save Results window will appear, prompting for
a filename and location.
Comment Out Selected Lines
Adds inline comment marks to comment out the selected lines.
Uncomment Selected Lines
Removes inline comment marks.
Decrease Indent
Decreases the indent of selected text.
Increase Indent
Increases the indent of selected text.
Specify Values for Template
Parameters
Displays a dialog that enables the replacement of template
parameters with defined values.
11:39am
Page 76
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
SQL Server Analysis Services Editors Toolbar
The Analysis Services Editors toolbar (see Figure 3-28) also becomes visible (or is active if already visible)
when a new Analysis Services query is opened or created. The tools on this toolbar are a subset of the SQL
Editor tools, but contain only those tools applicable to Analysis Services queries (DMX, MDX, XMLA).
Figure 3-28: Analysis Services Editors toolbar.
SQL Server Compact Edition Editor Toolbar
The SQL Server Compact Edition Editor toolbar (see Figure 3-29) becomes visible (or enabled) when
a new SQL Compact Edition Query window is opened. The tools on the SQL Server Compact Edition
toolbar are a subset of the SQL Editor tools that are applicable for SQL Compact queries.
Figure 3-29: Compact Edition Editor toolbar.
Standard Toolbar
The Standard toolbar (see Figure 3-30) provides buttons to execute the most common actions such as
opening and saving files. It also provides buttons that will launch new queries and expose additional
tool windows.
Figure 3-30: Standard toolbar.
The commands available on the Standard toolbar are described in the following table:
Feature
Purpose
New Query
The New Query command launches a new Database Engine
Query window by default.
Database Engine Query
Opens a new Database Engine Query window.
Analysis Services MDX Query
Opens a new MDX Query window.
Analysis Services DMX Query
Opens a new DMX Query window.
Analysis Services XMLA Query
Opens a new XMLA Query window.
Continued
77
Page 77
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Feature
Purpose
SQL Server Compact Query
Opens a new SQL Server Compact query.
Open File
Opens a file.
Save
Saves the currently selected window, or in the case of a
Designer tool, saves the current object.
Print
Sends the selected window or pane to the printer.
Activity Monitor
Opens the SQL Server Activity Monitor.
Table Designer Toolbar
The Table Designer toolbar (see Figure 3-31) becomes visible (or enabled) when a new table is created
using Table Designer or an existing table is modified using Table Designer. Table Designer is launched
by right-clicking on the Table node in Object Explorer and choosing New Table from the context menu,
or by right-clicking on an existing table in the Table node of Object Explorer and choosing Design.
Figure 3-31: Table Designer
toolbar.
The following table describes the toolbar:
78
Feature
Purpose
Generate Change Script
Table creation or modification done with the Designer can be sent
to a Query window for later execution.
Set/Remove Primary Key
Sets the selected column of the table as the primary key column
or removes the key if it has already been set.
Relationships
Enables the creation of foreign key constraints.
Manage Indexes and Keys
Enables the creation of unique keys and indexes.
Manage Fulltext Index
Launches a dialog that enables the creation of full-text catalogs
and full-text indexes.
Manage XML Indexes
Launches a dialog that enables the creation and management of
Primary and Secondary indexes.
Manage Check Constraints
Launches a dialog that enables the creation and management of
check constraints.
Manage Spatial Indexes
Launches a dialog that enables the creation of Spatial Indexes for
the new Geometry and Geography data types.
11:39am
Page 78
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Text Editor Toolbar
The Text Editor toolbar (see Figure 3-32) offers additional shortcuts to those provided in the other
language-specific editors.
Figure 3-32: Text Editor toolbar.
The features are described in the following table:
Feature
Purpose
Display an Object Member List
When editing T-SQL, DMX, MDX, or XMLA scripts,
invokes an IntelliSense window that displays a list of
possible script members.
Display Parameter Info
Displays the parameter list for System Stored Procedures
and functions used with Analysis Services.
Display Quick Info
Displays declaration information for XML objects created
or referenced in an XMLA script.
Display Word Completion
Displays possible words to complete a variable,
command, or function call. If only one possible option
exists, it is implemented.
Decrease Indent
Decreases the indent of selected text.
Increase Indent
Increases the indent of selected text.
Comment Out Selected Lines
Adds inline comment marks to comment out the selected
lines.
Uncomment Selected Lines
Removes inline comment marks.
Toggle a Bookmark on the Current
Line
Adds or removes a bookmark to the current script at the
position of the cursor.
Move the Caret to the Previous
Bookmark
Moves the cursor to the previous set bookmark in the
current script project.
Move the Caret to the Next
Bookmark
Moves the cursor to the next set bookmark in the current
script project.
Move the Caret to the Previous
Bookmark in the Current Folder
Moves the cursor to the previous set bookmark in the
currently selected bookmark folder of the Bookmark
window.
Move the Caret to the Next
Bookmark in the Current Folder
Moves the cursor to the next set bookmark in the currently
selected bookmark folder of the Bookmark window.
Continued
79
Page 79
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Feature
Purpose
Move the Caret to the Previous
Bookmark in the Current Document
Moves the cursor to the previous set bookmark in the
current script window.
Move the Caret to the Next Bookmark in
the Current Document
Moves the cursor to the next set bookmark in the
current script window.
Clear All Bookmarks in All Files
Removes all configured bookmarks from the current
project.
View Designer Toolbar
The View Designer toolbar (see Figure 3-33) is almost exactly like the Query Designer toolbar, with the
exception of being limited to writing SELECT queries. In addition, queries written with the View Designer
are saved as views and not just query scripts. For information about the function of the buttons on the
View Designer toolbar, consult the table in the earlier section, ‘‘Query Designer Toolbar.’’
Figure 3-33: View Designer
toolbar.
XML Editor Toolbar
The XML Editor toolbar (see Figure 3-34) contains several shortcuts that are specific to managing XML
files. This is often used with XMLA scripts.
Figure 3-34: Text Editor toolbar.
The features of the Text Editor toolbar are described in the following table:
80
Feature
Purpose
Create Schema
Generates a schema file based on the structure of the current
XML file.
Reformat Selection
Applies formatting rules to selected text to ensure that the
hierarchy is properly displayed.
Format the Whole Document
Applies formatting rules to the entire XML document to ensure
that the hierarchy is properly displayed.
Show XSLT Output
Allows you to associate an XSLT style sheet with your XML
document to format the output.
11:39am
Page 80
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Feature
Purpose
Debug XSLT
Starts debugging for the XML and XSLT style sheet.
Cancel XSLT Output
Cancels the output, which can be helpful if the process is
taking too long to finish.
Display an Object Member List
When editing T-SQL, DMX, MDX, or XMLA scripts,
invokes an IntelliSense window that displays a list of
possible script members.
Display Parameter Info
Displays the parameter list for System Stored Procedures
and functions used with Analysis Services.
Display Quick Info
Displays declaration information for XML objects created
or referenced in an XMLA script.
Display Word Completion
Displays possible words to complete a variable,
command, or function call. If only one possible option
exists, it is implemented.
Decrease Indent
Decreases the indent of selected text.
Increase Indent
Increases the indent of selected text.
Comment Out Selected Lines
Adds inline comment marks to comment out the selected
lines.
Uncomment Selected Lines
Removes inline comment marks.
Toggle a Bookmark on the Current
Line
Adds or removes a bookmark to the current script at the
position of the cursor.
Move the Caret to the Previous
Bookmark
Moves the cursor to the previous set bookmark in the
current script project.
Move the Caret to the Next
Bookmark
Moves the cursor to the next set bookmark in the current
script project.
Move the Caret to the Previous
Bookmark in the Current Folder
Moves the cursor to the previous set bookmark in the
currently selected bookmark folder of the Bookmark
window.
Move the Caret to the Next
Bookmark in the Current Folder
Moves the cursor to the next set bookmark in the currently
selected bookmark folder of the Bookmark window.
Move the Caret to the Previous
Bookmark in the Current Document
Moves the cursor to the previous set bookmark in the
current script window.
Move the Caret to the Next
Bookmark in the Current Document
Moves the cursor to the next set bookmark in the current
script window.
Clear All Bookmarks in All Files
Removes all configured bookmarks from the current
project.
81
Page 81
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
SQL Server Management Studio Configuration
Management Studio’s look and feel can be customized through the Tools Options menu (see
Figure 3-35), which is accessed by selecting Tools on the main menu and clicking Options.
Figure 3-35: Options menu.
The Options dialog enables the customization of the Management Studio IDE. The configuration options
are divided into the following seven areas.
Environment
The Environment configuration section is broken down into four subareas:
❑
General — Start-up options and environment layout (such as tabbed windows versus MDI windows) and how the windows behave. Recent file history is also configured on this screen.
❑
Fonts and Colors — The fonts and colors used in the Text Editor are completely customizable in
this area. The colors and fonts used for items such as reserved words, stored procedures, comments, and background colors are just a small portion of what can be changed.
❑
Keyboard — For those database administrators who are used to Query Analyzer’s keyboard
shortcuts, this configuration area enables the setting of the keyboard shortcuts to the same ones
used in Query Analyzer. The keyboard configuration area also allows for the addition of custom
keyboard shortcuts.
❑
Help — The Help area enables the integration of Help into a Management Studio window or
launching Help externally. It also allows for customizing local and online help resources.
Text Editor
The Text Editor section enables the customization of the various Text Editors and is divided into the
following six subareas:
82
11:39am
Page 82
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
❑
File Extension — File extensions for all the possible script and configuration files can be configured in the File Extension area. Known file extensions such as .sql, .mdx, .dmx, and .xml are
not listed, but are automatically associated with their respective editors. They can be reassigned
with a ‘‘with encoding’’ option so that Management Studio will prompt for specific language
encoding every time an associated file type is opened. Custom file extensions can also be
added.
❑
All Languages — The All Languages area is divided into two parts, General and Tabs, and provides configuration settings for IntelliSense features, word-wrap, line numbers, and indentation
for all script languages.
❑
Plain Text — Configuration settings for plain-text documents not associated with a particular
scripting language.
❑
Transact-SQL — Configuration settings specific to T-SQL. There is also a separate tab here for
enabling and configuring IntelliSense for Transact-SQL queries.
❑
XML — Configuration settings for XML documents. These settings consist of the same settings
from the All Languages area, as well as XML-specific settings such as automatic formatting and
schema download settings.
❑
Editor Tab and Status Bar — Configuration settings for the status bar, which is displayed at the
bottom of the Query Editor window. You can choose the colors of the status bar, as well as what
information is included in the display.
Query Execution
The Query Execution section provides configuration options for how queries are executed, as well as
connection properties and time-out settings. The Query Execution section is divided into two primary
areas:
❑
SQL Server — The SQL Server area has configuration options that control the maximum row
count and the maximum amount of text or Unicode text that is returned to the Management Studio results window. This area also has options to specify a batch delimiter other than GO and to
specify Query Execution time-out settings. There are also Advanced and ANSI areas that provide for the configuration of specific connection level options described in the following table:
Option
Description
SET NOCOUNT
Suppresses the X number rows message from being
returned on the connection.
SET NOEXEC
Configures the Query Processor to only parse
and compile SQL batches, but not to execute them.
SET PARSEONLY
Configures the Query Processor to only check the validity
of SQL batches, but not to compile or execute them.
SET CONCAT_NULLS_YIELDS_NULL
Configures the Query Processor to return a NULL for any
string concatenated with a NULL. This setting is selected
by default.
Continued
83
Page 83
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Option
Description
SET ARITHABORT
Configures the Query Processor to terminate the query if an
arithmetic error, overflow, divide-by-zero, or a domain
error is encountered. This setting is enabled by default.
SET SHOWPLAN_TEXT
Configures the Query Processor to only return the query
plan in text format, but not to actually execute the query.
SET STATISTICS TIME
Configures the Query Processor to return the amount of
time spent in the parsing, compiling, and execution of a
script.
SET STATISTICS IO
Configures the Query Processor to return the amount of
scans, physical reads, logical reads, and read-ahead reads
required to execute a script.
SET TRANSACTION ISOLATION
LEVEL
Provides the option of configuring the isolation level of SQL
scripts. The default is READ COMMITTED.
SET DEADLOCK_PRIORITY
Configures the deadlock priority of SQL scripts to either
Normal or Low. The default is Normal.
SET LOCK TIMEOUT
Configures the time a connection will wait until terminating
a query that is being blocked by a lock. The default setting is
-1, which means forever.
SET QUERY_GOVERNOR_
COST_LIMIT
Configures the Query Processor to prevent any query from
executing that is calculated to take longer than the
configured limit. The default value is 0, which disables the
time limit.
Suppress provider message
headers
Configures the Query Processor to suppress messages
returned by data providers such as OLEDB or SQLClient.
This setting is enabled by default.
Disconnect after the query
executes
Disconnects the active Query window from the database
after execution.
SET ANSI_DEFAULTS
Sets all ANSI connection settings to On.
SET QUOTED IDENTIFIER
Configures the Query Processor to allow double quotes as
legitimate object delimiters. This setting is enabled by
default.
SET ANSI_NULL_DFLT_ON
Specifies that columns created in a CREATE TABLE or ALTER
TABLE statement default to allowing NULLS if
NOT NULL is not defined in the script. This setting is enabled
by default.
SET IMPLICIT_TRANSACTIONS
84
Configures the Query Processor to begin, but not commit a
transaction any time an UPDATE, INSERT, or DELETE
statement is executed outside an explicit transaction.
11:39am
Page 84
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Option
Description
SET CURSOR_CLOSE_
ON_COMMIT
When set to ON, causes any open cursor to be closed on a
COMMIT TRANSACTION statement or
ROLLBACK TRANSACTION statement not associated with
a save point.
SET ANSI_PADDING
When set to ON, causes trailing spaces to be added to any
fixed-length character string, or trailing zeros to be added to
fixed-length binary strings. Trailing spaces or trailing zeros
explicitly added to variable-length strings are not trimmed.
This setting is enabled by default.
SET ANSI_WARNINGS
When set to ON, causes a warning to be returned if any
aggregate function encounters a NULL or an arithmetic
function fails. This setting is enabled by default.
SET ANSI_NULLS
When set to ON, equality or inequality operations executed
against a NULL value will return an empty set. This setting is
enabled by default.
❑
Analysis Services — Configuration setting to control the execution time-out setting for Analysis
Server queries.
Query Results
The Query Results section provides configuration options for how query results are formatted. As with
the Query Execution options, this is also divided into two sections for the SQL Server Database Engine
and the Analysis Services Engine.
❑
SQL Server — The SQL Server section has configuration options to specify the default location
for query results: to a grid, as text, or to a file, as well as the default location for results sent to a
file. You can also enable the Windows default beep sound to play whenever a query batch completes. The ‘‘Results to Grid’’ settings are described in the following table:
Option
Description
Include the query in the
result text
The query executed is returned as part of the result. This
setting is off by default.
Include column headers when
copying or saving results.
Results copied to the clipboard or saved to a file include the
column header names. This setting is off by default.
Quote strings containing list
separators when saving
.csv results
When exporting to a .csv file format, quotes will be placed
around any column that contains a list separator, such as a
comma. This setting is off by default.
Discard results after
execution
Queries are executed, but results are immediately cleared from
the results window. This setting is off by default.
Continued
85
Page 85
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Option
Description
Display results in a separate
tab
Results are sent to a separate tab instead of a results window
beneath the query window. This setting is off by default. Note
that the new tab will not automatically have focus.
Switch to results tab after
the query executes
If the above option is enabled, the Query Results tab will
automatically have focus once the results are displayed.
Maximum Characters Retrieved
Grid results are limited to a specified number of characters. By
default, this limit is 65,535 characters for non-XML data and 2
MB for XML data.
The ‘‘Results to Text’’ settings are described in the following table:
Option
Description
Output format
The default text output format is column-aligned. Comma, tab,
space, and custom delimiters are available.
Include column headers in the
result set
Column headers are returned in the text results by default.
Include the query in the
result text
The query executed is returned as part of the result. This
setting is off by default.
Scroll as results are
received
The results window scrolls to expose the last set of rows
returned that will fit in the results window. This setting is on
by default.
Right align numeric values
This option is only available when column-aligned is selected
as the Output format. This setting is disabled by default.
Discard results after query
executes
Queries are executed, but results are immediately cleared from
the results window. This setting is off by default.
Display results in a separate
tab
Results are sent to a separate tab instead of a results window
beneath the query window. This setting is off by default.
Switch to results tab after
the query executes
If the above option is enabled, the results tab can be given
focus by enabling this option. This is off by default.
Maximum characters displayed
in each column
Configures the maximum length of any column returned in
text format. The default is 256 characters.
Multi-server Result settings include enabling or disabling adding the login name or server name to the
results, as well as merging the results from multiple servers into a single output.
86
11:39am
Page 86
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
❑
Analysis Services — Configuration settings for Analysis Services query results include showing
grids in separate tabs and playing the default Windows beep when the query completes. Both
settings are disabled by default.
SQL Server Object Explorer
The SQL Server Object Explorer options list contains two tabs, one for managing command settings and
another for handling scripting behavior. The command settings allow you to specify the number of rows
returned used by the menu items for the number of rows returned for the Select Top <n> Audit records,
Edit Top <n> Rows, and Select Top <n> Rows commands.
The configurable scripting options are identified in the following table:
Option
Description
Delimit Individual
Statements
Separate individual T-SQL statements by using the batch
separator. This is on by default.
Include descriptive
headers
Adds descriptive comments at the beginning of a script. This is
on by default.
Include VarDecimal
Enables the scripting of VarDecimal storage formats. This is off
by default.
Script change tracking
Enables including Change Tracking information. This is off by
default.
Script for server version
Specifies the version of SQL Server for which the script will be
generated. The default is SQL Server 2008, but SQL Server
2005 and SQL Server 2000 are supported.
Script full-text catalogs
Includes scripts for full-text catalogs. This is off by default.
Script USE <database>
Includes the database context in the scripts. This is on by
default.
Generate script for
dependent objects
Dependent objects will be scripted when this setting is
enabled. This is off by default.
Include IF NOT EXISTS
clause
This clause checks to see if an object with the same name
already exists. This is off by default.
Schema qualify object
names
Uses the two-part schema.object convention when including
object names in the script. This is on by default.
Script Data Compression
Options
This option includes data compression settings in the target
script if they exist in the source object. This is off by default.
Script extended properties
Extended properties of an object will also be scripted when
this option is enabled. This is on by default.
Script permissions
Permissions will be scripted when this option is turned on. It is
off by default.
Continued
87
Page 87
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
88
Option
Description
Convert user-defined data
types to base types
This will force user-defined data types to be converted to their
respective base types. This is off by default.
Generate SET ANSI PADDING
commands
This will enclose CREATE TABLE statements in SET ANSI
PADDING commands. This is on by default.
Include collation
Enables the inclusion of collation settings in column
definitions for tables or views. This is off by default.
Include IDENTITY property
This option will include IDENTITY seed and IDENTITY
increment definitions. This is on by default.
Schema qualify foreign key
references
This enables references to include schema qualifiers for foreign
key constraints. This is on by default.
Script bound defaults and
rules
This option will include sp_bindefault and sp_bindrule
binding stored procedure calls. This is off by default.
Script CHECK constraints
Include CHECK constraints. This is on by default.
Script defaults
Includes default values for columns. This is on by default.
Script file groups
Specifies the ON <filegroup> clause for table definitions. This
is on by default.
Script foreign keys
Include FOREIGN KEY constraints. This is on by default.
Script full-text indexes
Includes script for full-text indexes. This is off by default.
Script indexes
Includes script for clustered, non-clustered, and XML indexes.
This is off by default.
Script partition schemes
Table partitioning schemes are scripted when this option is
enabled. This is off by default.
Script primary keys
Includes script for PRIMARY KEY constraints. This is on by
default.
Script statistics
Includes script for user-defined statistics. This is off by default.
Script triggers
This will include scripts for triggers. This is off by default.
Script unique keys
This will include UNIQUE constraints in generated scripts. This
is on by default.
Script view columns
This option will declare view columns in view headers. This is
on by default.
ScriptDriIncludeSystemNames
When enabled, this option will include system-generated
constraint names to enforce declarative referential integrity
(DRI). This is off by default.
11:39am
Page 88
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Designers
The Designers section provides configuration options for the graphical designers used in Management
Studio. The Designers section is divided into three subareas:
❑
Table and Database Designers — The Table and Database Designers area allows for the configuration of specific designer behavior. The following table describes the Table options:
Option
Description
Override connection
string time-out value
for table designer
updates
Changes the default connection string time-out. When modifying the
structure of large tables, more time is often required than the default of
30 seconds. Enabling this option also enables a textbox for entering the
new time-out value.
Auto generate change
scripts
When this option is enabled, Management Studio will automatically
generate a change script and prompt for a location to save the file any
time designer modifications are saved. The applicable modifications are
executed, as well as a script being generated.
Warn on null primary
keys
A primary key placed on a column that allows NULLS will cause an
error when the option is enabled. If this option is not enabled, the
designer will automatically clear the Allow Nulls attribute from the
column designated as a primary key without raising an error.
Warn about difference
detection
When selected, Management Studio will raise a warning dialog if the
changes made conflict with changes made by any other user.
Warn about tables
affected
Management Studio will raise a warning and confirmation dialog if
changes to a table affect any other table in the database.
Prevent saving
changes that require
table re-creation
This will prevent a user from making a change that will require
re-creation of a table. This includes actions such as adding a new
column to the middle of a table, dropping a column, and changing the
data type of a column.
The following table describes the Diagram options:
Option
Description
Default table view
Used to select the default way tables are represented in the
database diagram tool. Possible views are:
Standard — Shows the table header, all column names, data types,
and the Allow Nulls setting.
Column Names — Shows the table header and column names.
Continued
89
Page 89
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Option
Description
Key — Shows the table header and the primary key columns.
Name Only — Shows only the table header with its name.
Custom — Allows you to choose which columns to view.
Launch add table dialog
on new diagram
When the Database Diagram Designer is opened, Management
Studio automatically prompts for the selection of existing tables
to be added to the diagram when this option is selected.
❑
Maintenance Plans — The Maintenance Plan Designer options determine the way new shapes
are added to the maintenance plan design area, including the precedence constraint and positioning of the new shape relative to an existing shape.
❑
Analysis Designers — The Analysis Designers options page provides options to set the connection and query time-out values for the Analysis Designers and the colors for the Data Mining
viewers.
Source Control
The Source Control configuration section allows for the integration of a source-control plug-in such as
Visual Source Safe 2005. The Source Control section is broken down into three different areas:
❑
Plug-In Selection — Here, the specific plug-in can be chosen (such as Visual Source Safe 2005, or
Visual Studio Team System).
❑
Environment — The Environment section allows for the configuration of the Source Control
Environment settings supported by the configured source-control plug-in. For Visual Source
Safe 2005, there are three preconfigured settings: Visual Source Safe, Independent Developer,
and Custom. These settings determine the automatic Check-In and Check-Out behavior of
source-control projects.
❑
Plug-in Settings — The Plug-in Settings section provides the ability to customize the
source-control actions (such as what to do with unchanged files that have been checked out and
how to manage file comparisons and timestamps).
The features available in the Source Control section are dependent on the source control application used.
Consult the documentation of the applicable program for more information.
Log File Viewer
The Log File Viewer (see Figure 3-36) is launched from within SQL Server Management Studio. To open
it, follow these steps:
1.
2.
3.
90
Expand the Management node in Object Explorer.
Expand SQL Server Logs.
Right-click on a log, and select ‘‘View SQL Server Log.’’
11:39am
Page 90
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Figure 3-36: Log File Viewer.
One of the benefits of the Log File Viewer is that it allows consolidation of practically all the logs the
DBAs are most interested in. SQL Server logs, SQL Agent logs, and Operating System logs can be opened
in the same window for easy correlation of system and SQL Server events.
When viewing multiple logs in the Log Viewer, filters can become useful in ensuring that only the information of interest is shown. For example, the filter settings allow the specification of a start date and an
end date. Filter settings can also be set to display only those events from a certain subsystem. Applying
the appropriate filters helps mitigate the problem of ‘‘Information Overload’’ when trying to sift through
thousands of log entries.
SQL Ser ver Business Intelligence
Development Studio
When SQL Server 2000 Reporting Services was released, Visual Studio was the only way for users to be
able to create and manage reports. However, many non-developers were scared off by an interface that
was unfamiliar to them. When SQL Server 2005 was released, Microsoft knew they had to respond to
user concerns and provide them with a new interface for not only managing reports, but one that could
be used for Analysis Services and Integration Services tasks, as well.
Thus, the SQL Server Business Intelligence Development Studio (BIDS) was born. Users could now feel
more confident that they had a tool made especially for their Business Intelligence (BI) needs.
91
Page 91
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
In all actuality, BIDS is, in fact, Visual Studio, and SQL Server 2008 includes Visual Studio 2008. Granted,
it’s not the full Visual Studio 2008, which includes the templates and compilers for Visual Basic, C#,
and ASP.NET, but many DBAs were surprised to find Visual Studio installed on their workstation after
installing the SQL Server tools. Regardless of whether you launch the Business Intelligence Development
Studio shortcut from the SQL Server 2008 folder or the Visual Studio 2008 shortcut from the Visual Studio
folder in your Start menu, they launch the exact same application. If the full Visual Studio suite has not
been installed, the only available project templates will be Business Intelligence projects. However, if the
full suite is installed, all the installed features and templates will be available.
A complete discussion of the Visual Studio IDE is beyond the scope of this book, but a very brief description is definitely in order.
Microsoft has divided Business Intelligence into three distinct pieces: ETL (Extract-Transform-Load),
Analysis, and Reporting. These three parts of the Business Intelligence package are implemented through
SQL Server Integration Services, SQL Server Analysis Services, and SQL Server Reporting Services. Correspondingly, BIDS provides Business Intelligence project templates that focus on these three areas. The
templates are available when creating a new project from BIDS (see Figure 3-37) by selecting File New
Project from the main BIDS menu.
Figure 3-37: Business Intelligence Studio.
Once a template is selected, the template loads with the appropriate tools for the project. The available
templates are briefly described in the following table:
92
11:39am
Page 92
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Template
Description
Analysis Services
Project
Analysis Services projects are used to create SQL Server 2008
Analysis Services databases that expose the objects and features of
Analysis Cubes used for complex data analysis.
Import Analysis
Services 2008 Database
The import project enables the creation of an Analysis Services
project from an existing SQL Server 2008 Analysis Services database.
It essentially reverse-engineers the project using an existing
database.
Integration Services
Connection Project
Integration Services projects are used to create robust
Extract-Transform-Load (ETL) solutions to enable the moving and
transforming of data. This project type uses a Wizard to generate an
ETL package.
Integration Services
Project
This project type uses the Integration Services Designer for creating
and managing ETL packages.
Report Server Project
Wizard
The Report Server Project Wizard offers the same functionality as the
Report Server Project, but starts the development of the project in a
step-by-step process that guides the user through the various tasks
required to create a report. Like many wizards, this one leaves the
project in a skeleton phase, which will require more detailed
finalization.
Report Model Project
Report Model projects are used to create and deploy SQL Server
Reporting Services 2008 report models, which can, in turn, be used
by end-users to create reports using Report Builder.
Report Server Project
Report Server projects are used to create and deploy enterprise
reports for both traditional (paper) and interactive reports.
SQL Ser ver Profiler
The SQL Server Profiler is an absolutely essential tool for both DBAs and developers alike. Profiler
provides the ability to monitor and record virtually every facet of SQL Server activity. It is actually a
graphical interface for SQL Trace, which is a collection of stored procedures and functions that are used
to monitor and record server activity. SQL Server Profiler can be launched from the Tools menu of SQL
Server Management Studio, or from the All Programs Microsoft SQL Server 2008 Performance Tools
menu.
SQL Server Trace
The Profiler can be used to create and view SQL Server Traces. When creating a new trace, the Profiler
will prompt you for the server on which you will be running the trace. Remember that the Profiler is just
93
Page 93
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
a graphical interface for SQL Trace, and what is occurring in the background is the execution of stored
procedures and functions on the server you connect to. If the server is very busy and is operating at the
edge of its capabilities, the additional load of running SQL Trace on it may well put it over the edge.
Profiler and SQL Trace procedures are discussed in greater detail in Chapter 10.
Trace Properties
When creating a new trace, the Trace Properties dialog is shown (see Figure 3-38). The Trace Properties
dialog includes two tabs: the General tab and the Events Selection tab. A third tab, Events Extraction
Settings, will be enabled if any XML SHOWPLAN event is selected in the Events Selection tab.
Figure 3-38: Trace Properties dialog.
General Tab
The General tab provides the ability to set the basic structure of the trace (such as the trace name, trace
template, saving options, and trace stop time). It also displays the provider name and type, because SQL
Server Profiler is not limited to the Data Engine. It can also be used to trace SQL Server Analysis Services.
❑
94
Use the Template — This dropdown list contains several pre-built trace templates. Each template is a pre-defined set of events and filters that provide for the monitoring of SQL Server for
particular purposes. These templates can be a good place to start when creating traces to monitor SQL Server. It is also possible to create your own templates, and it is strongly recommended
that you do so. The provided templates are fine, but you will undoubtedly want to collect different information from that which the templates provide. To avoid having to create the same
11:39am
Page 94
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
custom trace over and over again, create and save a template to capture the information you are
interested in.
❑
Save to File — Selecting this checkbox will display a dialog prompting for a file location to save
the trace data to. The filename defaults to the name assigned to the trace with the .trc extension. However, the name can be changed if desired. The default maximum file size for a trace
file is 5 MB, but it can be set to virtually any size. When the ‘‘Save to file’’ option is selected, two
additional options are enabled: the ‘‘Enable file rollover’’ option and the ‘‘Server processes trace
data’’ option.
❑
Enable File Rollover — This option causes a new file to be created every time the maximum file size is reached. Each file created is named the same as the original file with a
sequential number added to the end of the name. Each sequential file is linked to the preceding file, so that each file can be opened in sequence, or they can all be opened in a single
trace window.
❑
Server Processes Trace Data — This option causes the server that the traces are running
on to also process the trace information. By default, the Profiler application processes the
trace information. During high-stress operations, if the Profiler processes the data, it may
drop some events and even become unresponsive. If the server processes the trace data,
no events will be dropped. However, having the server process the trace data and run the
trace puts an additional load on the server, which can have a negative impact on server
performance.
❑
Save to Table — Trace data can also be saved to a table instead of a file by selecting the ‘‘Save
to table’’ option. This is very useful if the trace data is going to be analyzed by an external application that requires access to the data stored in a relational format. The down side is that large
traces will generate huge amounts of data that will be inserted into the storage table. This can
also cause server performance issues, but you can mitigate this by saving trace information to
a different server from your production system. If saving trace data to a table, the maximum
amount of rows to be stored can also be assigned.
❑
Enable Trace Stop Time — Traces can be started and configured to automatically stop at a
pre-defined time by enabling the ‘‘Enable trace stop time’’ option and assigning a stop time.
Events Selection Tab
The Events Selection tab provides the ability to choose what SQL Server events are to be traced (see
Figure 3-39). Events are grouped in 21 SQL Server event groups with a total of 170 distinct SQL Server
events, plus 10 user-definable events. There are also 11 Analysis Services Groups with 38 distinct events.
SQL Server Books Online has an excellent reference that describes each group and event. Search for the
titles of ‘‘SQL Server Event Class Reference’’ for SQL Server events and ‘‘Analysis Services Event Classes’’
for Analysis Services Events.
❑
Column Filters — Also in the Events Selection tab is the option to filter the events that are traced
(see Figure 3-40). The ability to filter the data is incredibly useful. For example, if you are troubleshooting a particular application, you can filter on just the events generated by the application
of interest and avoid having to sift through all the events generated by SQL Server and other
applications.
❑
Organize Columns — The Organize Columns button enables you to place the trace columns you
are most interested in so that they are easily seen when viewing the trace. Because a great deal of
95
Page 95
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
data can be returned, it may very well be that the column you are most interested in is off the
screen to the left. The Organize Columns button helps prevent this.
Figure 3-39: Events to be traced.
Figure 3-40: Filtering traced events.
Events Extraction Settings Tab
The Events Extraction Settings tab (see Figure 3-41) is enabled when one of the SHOWPLAN XML
events is chosen from the Performance event group. This tab is divided into two group boxes. The
96
11:39am
Page 96
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
first provides the ability to save SHOWPLAN information. All SHOWPLAN information can be saved to
a single file or multiple XML files that can be opened in SQL Server Management Studio. When
opened, they are displayed as graphical execution plans (which are described in detail in Chapter
10). The second group is used for saving graphical deadlock information. Because deadlocks are
automatically detected and killed by SQL Server, they are often hard to troubleshoot. SQL Server Profiler
provides the ability to trace deadlocks and graphically represent the sequence of events that led to the
deadlock.
Figure 3-41: Events Extraction Settings.
Chapter 10 describes how to use the SQL Server Profiler to gather pertinent SQL Server data and how to
use the profile traces to troubleshoot and optimize SQL Server performance.
Database Engine Tuning Advisor
The Database Engine Tuning Advisor (DTA) can analyze SQL Server scripts or SQL Server Profiler traces
to evaluate the effective use of indexes. It can also be used to get recommendations for building new
indexes or indexed views, or for creating physical table partitions.
Chapter 11 describes how to use the DTA to help optimize SQL Server databases, so this section is limited
to describing the tool and its features. When the DTA is started, it prompts for a server to connect to and
then automatically creates a new session. The session is displayed in two tabs: a General tab and a Tuning
Options tab.
97
Page 97
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
General Tab
The General tab (see Figure 3-42) is used to define the session name, the workload for analysis, and the
database(s) to tune.
Figure 3-42: DTA General tab.
Following are some options found under this tab:
98
❑
Session name — By default, the session name is the name of the logged-on user combined with
the current date and time, but it can (and should) be changed to a more descriptive name.
❑
Workload — The Workload section provides the ability to retrieve trace information from either
a file or a table. The table designated must have been previously created by a SQL Server Profiler
trace, and the table must be located on the same server the DTA is running on. The file can be a
SQL script, a Profiler trace (.trc) file, or a Profiler trace saved as XML.
❑
Database for workload analysis — This option sets the initial connection information for the
DTA.
❑
Select databases and tables to tune — In this section, you can designate the database or
databases to be tuned. Keep in mind that the more objects chosen to monitor, the bigger the
performance impact on the server being monitored. The DTA doesn’t actually re-run all the
activity from the trace, but it does retrieve a great deal of metadata about the objects contained
in the workload, along with any available statistics. This activity alone generates a lot of
server activity. Both SQL Server Profiler and DTA activity should be as specific as possible for
performance reasons because the more specific the monitoring is, the better the results will be.
11:39am
Page 98
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Another reason for being specific about choosing the right tables to tune is that if the DTA sees
no activity for a table that was selected for monitoring, it will recommend dropping any indexes
on that table not associated with a constraint.
Tuning Options Tab
The Tuning Options tab (see Figure 3-43) contains the controls used to configure how the DTA analyzes
the workload and what kind of recommendations it will return. At the bottom of the tab is a description
box that both describes the individual options and provides feedback for incompatible settings.
Figure 3-43: Tuning Options tab.
❑
Limit tuning time — Large workloads can take a very long time to fully analyze and can be very
expensive in CPU and Database Engine resources. Limiting the amount of time the DTA spends
analyzing the workload will cause it to return any recommendations generated with the amount
of workload it was able to analyze in the time allocated. For the best results, the DTA should be
allowed to run until it has completed; however, that may not always be possible on production
systems. Once analysis has started, it can be stopped by clicking the Stop Analysis button on the
DTA toolbar.
❑
Physical Design Structures (PDS) to use in database — This option group allows the configuration of the type of PDS recommendations the DTA will return. Options include returning
recommendations for the creation of all indexes and indexed views, indexes only, non-clustered
99
Page 99
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
indexes only, and indexed views only. There is also an option for the DTA to only evaluate the
effectiveness of current PDS structures, but not recommend the creation of additional structures.
Filtered indexes can also be included.
❑
Partitioning strategy to employ — This option group is used to configure the type of physical
table partitioning to employ: no partitioning, full partitioning, and aligned partitioning. Physical
partitioning is described in Chapter 4.
❑
Physical Design Structures (PDS) to keep in database — When the DTA analyzes workloads,
if it determines the PDS structure is not beneficial, it may recommend dropping the structure
from the database. This option group is used to configure what PDS structures the DTA will not
recommend dropping. The DTA can be configured to recommend dropping any non-beneficial
PDS structure, to keep indexes only, to not recommend dropping any PDS, to keep clustered
indexes only, and to keep any aligned partitioning structure.
❑
Advanced Options — The Advanced Options dialog is used to configure the maximum amount
of disk space to use for recommendations, the maximum number of table columns to include per
individual index, and online indexing recommendations.
SQL Ser ver Configuration Manager
The SQL Server Configuration Manager is a Microsoft Management Console (MMC) snap-in and is used
to manage all the services and protocols employed by an instance of SQL Server. It combines all the
functionality that had been in three separate applications — SQL Server 2000’s Service Manager, Client
Network Utility, and Server Network Utility. The Configuration Manager is divided into three nodes:
❑
SQL Server Services — The Services node offers the similar functionality as the Services applet
in the Administrative toolset. However, because it only shows SQL Server services, it is much
easier to both control and monitor the status of SQL Server services.
❑
SQL Server Network Configuration — The Network Configuration node displays and enables
the configuration of all the available server protocols. The protocols available for use with SQL
Server 2008 are Shared Memory, Named Pipes, TCP/IP, and Virtual Interface Adapter (VIA).
Protocols that are not in use should be disabled (or left disabled) to minimize the attack surface
of the SQL Server.
❑
SQL Native Client 10.0 Configuration — The SQL Native Client Configuration node displays
and enables the configuration of the client protocols used to connect to an instance of SQL Server
2008. The configurations only affect the computer that the Configuration Manager is running on.
In addition to protocol configuration, the Native Client Configuration node enables the configuration of server aliases.
Repor ting Ser vices Configuration Manager
SQL Server 2008 includes an updated Reporting Services Configuration Manager that is more streamlined
and easier to use than configuration tools from prior versions. Depending on which options you chose
during the installation of SQL Server Reporting Services (‘‘Native Mode,’’ ‘‘SharePoint Integrated mode,’’
or ‘‘I Will Configure Later’’ mode), SQL Server may already be configured and ready to deliver reports.
100
11:39am
Page 100
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
More information about Reporting Services can be found in Chapter 18. For a thorough discussion of
SQL Server 2008 Reporting Services, check out the book Professional Microsoft SQL Server 2008
Reporting Services by Paul Turley, Thiago Silva, Bryan C. Smith, and Ken Withee (Wiley, 2008).
Each has its own configuration areas, including the following:
❑
Report Server Status — Selecting the Server name will display the Service Status area, which
allows you to monitor the status and stop and start the Reporting Services service. Although this
area is called Server Status, it is really only the status of the Reporting Services service.
❑
Service Account — This area is used to configure the account under which the Reporting Service
runs. Best practices recommend using an Active Directory domain account with the minimum
permissions required to run SQL Server Reporting Services. If a domain account is not available, the Network Service account may be used. Local System and Local Service accounts will
not work very well, unless SQL Server and Reporting Services are installed on the same computer.
❑
Web Service URL — The Report Server Virtual Directory configuration area enables the viewing
or changing of the virtual directory on the SQL Server that hosts the Reporting Services Web Service. Unlike prior versions of Reporting Services, the Web Service does not use IIS. The default
virtual directory name is ReportServer.
❑
Database — The Database area is used to create or configure SQL Server 2008 Report Server
databases. The Report Server databases provide storage of report definitions, report connections, and intermediately rendered reports. The database can be configured in either Native or
SharePoint Integrated mode. If you wish to switch database modes, you will have to create a
new database with the correct target mode. You can also configure the credentials that are used
by the Report Server to connect to the Report Server database. By default, the Service Account
for the Reporting Services engine is used.
❑
Report Manager URL — This area is where the virtual directory for the administrative interface, Report Manager, is viewed or configured. This is the Virtual Directory that users will access
when creating or managing reports.
❑
E-mail Settings — The SMTP Server settings are very straightforward and simple. However,
using the Reporting Services Configuration tool, you can only specify the SMTP server to use
and the sender’s address. Additional configuration to the e-mail settings must be done manually
by editing the Report Server configuration file.
❑
Execution Account — The Execution Account is used when a report needs resources that are not
locally available (such as a graphic stored on a remote server). It can also be used to connect to
resources that do not require credentials. Configuration of an Execution Account is optional, but
may be necessary when accessing shared resources.
❑
Encryption Keys — During the installation of Reporting Services, the installation program automatically generates a symmetric key that is used to encrypt security credentials stored in the
Report Server database. To preserve access to this encrypted information, it is critical to back
up and restore the key during certain Report Server maintenance procedures. For example, if the
database is moved to a different server or the service accounts are changed, the key will have to
be restored to preserve access to the encrypted information. The Encryption Keys configuration
area provides an easy-to-use graphical interface to back up and restore the keys. It also provides
the ability to replace the existing encryption key with a newer one, as well as delete all encrypted
101
Page 101
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
content, in which case, all the stored security credentials would have to be re-entered. In the past,
this functionality was provided only through the RSKEYMGMT command-line utility, which is still
available.
❑
Scale-out Deployment — SQL Server Reporting Services 2008 provides the ability to scale-out
Web Service and report access by allowing multiple Reporting Services instances to share a common Report Server database. Scaling-out provides fault tolerance (for front-end services), as well
as being able to handle more concurrent connections and specific report execution loads. SSRS
is not ‘‘Cluster Aware,’’ but can leverage Network Load Balancing (NLB) for Web Services and
clustering of the database through a Fault Tolerant Cluster.
Command-Line Tools
SQL Server 2008 comes with plenty of great graphical tools to accomplish almost everything you could
ever need to do, but there also comes a time when a simple command-line tool is the best tool for the
job. While there are a few command-line tools out there, this section will look at the more prominent
ones, which have historically been SQLCMD (and previously OSQL) and BCP, as well as introduce you
to Microsoft’s newest, and arguably most powerful, command-line utility, PowerShell.
SQLCMD
The SQLCMD utility replaces OSQL as the utility used to execute Transact-SQL statements, Stored Procedures, and SQL script files from the command prompt. OSQL is still available for backward compatibility,
but SQLCMD is a more full-featured tool. SQLCMD uses OLE DB to connect to SQL Server and execute
Transact-SQL batches.
The SQLCMD utility includes the ability to use variables, connect to servers dynamically, query server
information, and pass error information back to the calling environment. Access to the Dedicated Administrator Connection (DAC) is also provided by the SQLCMD utility. The DAC is a special diagnostic
connection that can be used by the DBA to connect to a SQL Server server when all other connection
types fail to diagnose and correct server problems.
SQLCMD supports several arguments that change the way it behaves and connects to an instance of SQL
Server. An abbreviated list is included in the following table. For a complete list of the argument options,
consult SQL Server Books Online under the topic ‘‘SQLCMD Utility.’’ Unlike other command-line utilities, SQLCMD command-line arguments are case-sensitive.
102
Argument
Description
-S
Specifies the SQL Server Instance name for SQLCMD to connect to.
-U
Specifies a username to use when connecting with a SQL Server login.
-P
Specifies the password to use when connecting with a SQL Server login.
-E
Configures SQLCMD to use a trusted connection.
-i
Specifies the Transact-SQL script input file to run.
-o
Specifies the output text file to return the results of a SQLCMD execution.
11:39am
Page 102
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Argument
Description
-v
Specifies the parameter(s) to pass to a SQLCMD script execution.
-Q
Performs a query passed as a command-line parameter and exits.
-A
Designates the SQLCMD connection as a DAC
The SQLCMD utility is typically used to execute saved Transact-SQL scripts in batch processes. This
functionality is further enhanced by the ability of SQLCMD to accept scripting parameters. The following
code is an example of a SQLCMD script that accepts a parameter called DBName to back up a designated
database to a file named DatabasenameDB-Month-Day-Year.BAK to the C:\SQLBackups folder:
DECLARE @BackupDest AS varchar(255)
SET @BackupDest = ‘C:\SQLBackups\’
+ ‘$(DBName)’
+ ‘DB-’
+ DATENAME(m,GETDATE())
+ ‘-’
+ DATENAME(dd,GETDATE())
+ ‘-’
+ DATENAME(yy,GETDATE())
+ ‘.BAK’
BACKUP DATABASE $(DBName)
TO DISK = @BackupDest
If the preceding script is saved to a file called BackupDBs.SQL in the C:\SQLBackups folder, it could be
executed to back up the Master database on a server called AughtEight using Windows authentication
with the following command line:
SQLCMD –E –S AughtEight –i C:\SQLBackups\BackupDBs.SQL –v DBName="Master"
SQL Server Management Studio makes the creation of SQLCMD scripts even easier with its SQLCMD
mode. The BackupDBs.SQL script can be written and tested with Management Studio by selecting SQLCMD mode in the Query menu. However, to fully test it in the Query Editor, the following command
must be inserted in the beginning of the script:
:SETVAR DBName "Master"
The SETVAR command can also be used in the execution of SQLCMD from the command line, but it
usually makes more sense to use the –v variable argument.
Multiple variables can be set with the SETVAR command, as well as passed in to a SQLCMD script with
the –v argument. The following example shows how to use multiple SETVAR commands:
USE AdventureWorks2008
GO
:SETVAR ColumnName "LastName"
:SETVAR TableName "Person.Person"
SELECT $(ColumnName)
FROM $(TableName)
103
Page 103
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
If the preceding example is saved to a file called GetContacts.SQL with the SETVAR commands omitted, it
would look like the following example:
USE AdventureWorks2008
GO
SELECT $(ColumnName)
FROM $(TableName)
This script could be executed with the SQLCMD utility using the following command line:
SQLCMD –E –S AughtEight –i C:\GetContacts.SQL –v ColumnName="LastName"
TableName = "Person.Person"
Dedicated Administrator Connection (DAC)
SQLCMD is particularly useful for creating batch scripting jobs for administrative purposes. However,
as an emergency utility to diagnose and hopefully correct server problems, it has no peer. With the –A
argument, the SQLCMD utilizes an exclusive connection to SQL Server. If no other connection is possible,
the SQLCMD –A command is the last and best hope for diagnosing server problems and preventing
data loss. By default, only local DACs are allowed because the DAC components only listen on the
loopback connection. However, remote DACs can be enabled using the sp_configure stored procedure
by changing the remote admin connections option to true, as the following code illustrates:
sp_configure ‘remote admin connections’, 1
RECONFIGURE
Bulk Copy Program (BCP)
The BCP utility is mainly used to import flat-file data into a SQL Server table, export a table out to a flat
file, or export the results of a Transact-SQL query to a flat file. In addition, it can be used to create format
files that are used in the import and export operations.
The syntax of the BCP utility is as follows:
usage: bcp {dbtable | query} {in | out | queryout | format} datafile
[-m maxerrors] [-f formatfile] [-e errfile] [-F firstrow] [-L lastrow]
[-b batchsize] [-n native type] [-c character type] [-w wide character type]
[-N keep non-text native] [-V file format version] [-q quoted identifier]
[-C code page specifier] [-t field terminator] [-r row terminator] [-i inputfile]
[-o outfile] [-a packetsize] [-S server name] [-U username] [-P password]
[-T trusted connection] [-v version] [-R regional enable] [-k keep null values]
[-E keep identity values] [-h "load hints"] [-x generate xml format file]
BCP format files can be created in two separate formats: XML and non-XML. These files can then be
referenced in the import and export of data. The BCP is well-documented in Books Online, but the
following examples show the most common usage of BCP.
Non-XML Format File Example
This example shows how to begin an interactive BCP session to create a non-XML format file based on an
existing table. The BCP utility will prompt for a column data type, a prefix length, and a field delimiter.
104
11:39am
Page 104
Leiter c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
It is usually best to accept the defaults provided for the data type and the prefix length because these
values are determined by the table being referenced in the BCP command. The delimiter value can be
any character, but defaults to ‘‘None.’’
The following command uses BCP to create a format file based on the CreditCard table in the
AdventureWorks2008 database and Sales schema of the local default instance of SQL Server:
BCP AdventureWorks2008.Sales.CreditCard format nul -T -f C:\BCP\CreditCard.fmt
It is often better to provide the –S switch and specify the server name. The format argument tells BCP
that the desired output is a format file. The absence of an –x switch specifies that the output file is not
XML. The nul argument sends a NULL as the username, because the –T switch was used indicating that
BCP should use a Windows trusted connection. If –T is not used, the –U username switch is required
followed by the –P password switch. If nul is not used, BCP will fail with the error that a username was
not provided.
The result of the preceding command, accepting the defaults for the field data type and prefix length, but
entering a comma as the field delimiter, is as follows:
10.0
6
1
SQLINT
2
SQLNCHAR
3
SQLNCHAR
4
SQLTINYINT
5
SQLSMALLINT
6
SQLDATETIME
0
2
2
0
0
0
4
100
50
1
2
8
","
","
","
","
","
","
1
2
3
4
5
6
CreditCardID
CardType
CardNumber
ExpMonth
ExpYear
ModifiedDate
""
SQL_Latin1_General_CP1_CI_AS
SQL_Latin1_General_CP1_CI_AS
""
""
""
The 10.0 at the top of the results designates the version of BCP. ‘‘10.0’’ is SQL Server 2008, and ‘‘9.0’’
would be SQL Server 2005. The number 6 under the 10.0 specifies how many columns are in the file.
Following the column number is the SQL Server data type of the column, followed by the number of
bytes needed by the prefix length. The prefix length of a column depends on the maximum number
of bytes, whether the column supports NULLs, and the storage type.
If the BCP command is supplied a data format argument (-c or –n), it will output a format file with all
columns mapped to the supplied format without any interaction.
XML Format File Example
This example shows how to use the BCP command to generate an XML format file:
BCP AdventureWorks2008.Sales.CreditCard format nul –x -T –f C:\BCP\CreditCard.xml
As you can see, the syntax is identical, except that the -x switch is used to specify an XML output. The
result is as follows:
<?xml version="1.0"?>
<BCPFORMAT xmlns=http://schemas.microsoft.com/sqlserver/2004/bulkload/format
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<RECORD>
<FIELD ID="1" xsi:type="NativeFixed" LENGTH="4"/>
<FIELD ID="2" xsi:type="NCharPrefix" PREFIX_LENGTH="2" MAX_LENGTH="100"
105
Page 105
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
COLLATION="SQL_Latin1_General_CP1_CI_AS"/>
<FIELD ID="3" xsi:type="NCharPrefix" PREFIX_LENGTH="2" MAX_LENGTH="50"
COLLATION="SQL_Latin1_General_CP1_CI_AS"/>
<FIELD ID="4" xsi:type="NativeFixed" LENGTH="1"/>
<FIELD ID="5" xsi:type="NativeFixed" LENGTH="2"/>
<FIELD ID="6" xsi:type="NativeFixed" LENGTH="8"/>
</RECORD>
<ROW>
<COLUMN SOURCE="1" NAME="CreditCardID" xsi:type="SQLINT"/>
<COLUMN SOURCE="2" NAME="CardType" xsi:type="SQLNVARCHAR"/>
<COLUMN SOURCE="3" NAME="CardNumber" xsi:type="SQLNVARCHAR"/>
<COLUMN SOURCE="4" NAME="ExpMonth" xsi:type="SQLTINYINT"/>
<COLUMN SOURCE="5" NAME="ExpYear" xsi:type="SQLSMALLINT"/>
<COLUMN SOURCE="6" NAME="ModifiedDate" xsi:type="SQLDATETIME"/>
</ROW>
</BCPFORMAT>
Export a Table to a Flat-File Example
Once the format file is created, it can be used to control data export and import operations. To export data
to a delimited flat file using the XML format file created in the preceding example, execute the following
code:
BCP AdventureWorks2008.Sales.CreditCard OUT C:\BCP\CreditCard.dat -T
-f C:\BCP\CreditCard.XML
Import Flat-File Example with a Format File
To test a BCP import, first create a copy of the CreditCard table with the following script:
USE AdventureWorks2008
GO
SELECT * INTO Sales.CreditCard2
FROM Sales.CreditCard
TRUNCATE TABLE Sales.CreditCard2
Once the destination table exists, the flat file and XML format file can be used to import the data to the
new CreditCard2 table with the following code:
BCP AdventureWorks2008.Sales.CreditCard2 IN C:\BCP\CreditCard.dat -T
-f C:\BCP\CreditCard.xml
PowerShell
PowerShell is a new command-line shell designed for Systems Administrators. PowerShell is both an
interactive console and a scripting interface that can be used to automate many common administrative
tasks. A complete explanation of PowerShell is beyond the scope of this book, but this section will provide
a summary of how PowerShell can be used for SQL Server Administration.
PowerShell is designed around the Microsoft .NET Common Language Runtime (CLR) and the .NET
Framework. It exposes .NET objects through a series of cmdlets, which are single-feature commands that
interact with objects. Cmdlets are formatted using a verb–noun structure, separated by a hyphen, such as
106
11:39am
Page 106
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Get-Process, which returns a list of the current running processes. Another benefit of PowerShell is that
cmdlets can be piped into one another; for example, you might invoke one command to retrieve information and then use a pipe character ( | ) on the same line to invoke another command that performs an
action or controls formatting and output of the results of the first command. You can pipe several commands as a single function. PowerShell can be installed on Windows XP SP2, Windows Vista, Windows
Server 2003, and comes installed in Windows Server 2008.
SQL Server 2008 supports PowerShell for SQL Administration, and, in fact, if it’s not already installed on
the system, the SQL Server installer will install it for you. SQL Server administrators can use PowerShell
to administer any SQL Server running SQL Server 2008, SQL Server 2005, and even SQL Server 2000 SP4,
although functionality will be limited.
SQL Server 2008 also includes a limited-functionality shell known as sqlps. The sqlps utility is designed to
expose access to SQL Server objects and cmdlets automatically, but it is configured to run with a Restricted
execution policy, which prevents PowerShell scripts from running. This can be changed, if necessary.
It may be preferred to access SQL Server objects from a standard PowerShell environment, in which case,
you can create a PowerShell console that includes the snap-ins for SQL Server. The following example
shows you how to create a new PowerShell console named MySQLPS.psc1 with the SQL Server snap-ins,
to a new folder called PSConsoles. In this case, PowerShell is being invoked from the Run command in
the Start Menu.
Windows PowerShell
Copyright (C) 2006 Microsoft Corporation. All rights reserved.
PS C:\Users\Administrator> md C:\PSConsoles
Directory: Microsoft.PowerShell.Core\FileSystem::C:\
Mode
---d----
PS
PS
PS
PS
LastWriteTime
------------9/23/2008
9:33 AM
Length Name
------ ---PSConsoles
C:\Users\Administrator> cd c:\PSConsoles
C:\PSConsoles> add-pssnapin SqlServerProviderSnapin100
C:\PSConsoles> add-pssnapin SqlServerCmdletSnapin100
C:\PSConsoles> Export-Console -Path MySQLPS.psc1
Now that you’ve created the new console, you can double-click on the file in Windows Explorer, or you
can manually invoke the console using the following command from the Run command:
powershell.exe -psconsolefile C:\PSConsoles\MySQLPS.psc1
So what can you do with PowerShell? Quite a bit, actually. The Object Explorer includes the ability to
launch PowerShell using the right-click context menu. The PowerShell console invoked is location-aware,
meaning that when you right-click the HumanResources.Employee table in the AdventureWorks2008
database and choose Start PowerShell from the menu, it will start sqlps using that object as the current
path.
107
Page 107
Leiter c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
PS SQLSERVER:\SQL\AUGHTEIGHT\DEFAULT\Databases\AdventureWorks20
08\Tables\HumanResources.Employee>
Try It Out
Output Data using PowerShell
In this exercise, you will use PowerShell to invoke a SQLCMD function.
1.
2.
In Object Explorer, navigate to Server Databases AdventureWorks2008.
Right-click on the AdventureWorks 2008 database, and select Start PowerShell (Figure 3-44).
Figure 3-44: Start PowerShell.
3.
Type the following commands into the PowerShell shell:
md C:\OutFiles
invoke-SQLCMD "Select TOP 10 * from HumanResources.Employee" |
ConvertTo-html | Out-file C:\OutFiles\Top10Emps.html
4.
108
Navigate to C:\OutFiles, and double-click on the Top10Emps.html file. In IE, you should see the
HTML-formatted output shown in Figure 3-45.
11:39am
Page 108
Leiter
c03.tex
V3 - 03/25/2009
11:39am
Chapter 3: SQL Server 2008 Tools
Figure 3-45 HTML formatted output.
At this point, you’ve barely scratched the surface of what PowerShell can do, but because the entire set
of SQL Management Objects (SMO) is exposed to PowerShell, administration of your SQL Server and its
databases can be made much easier by automating and scripting many common processes.
Summar y
This Chapter described the primary tools that are used by DBAs. Some of the less-frequently used tools
were covered briefly, as they are not often used by the DBA, but instead by an application or Business
Intelligence developer. By this point, you should have a good understanding of the tools available to you
in your role as a DBA and how to customize those tools to meet your needs.
The most prominent of these tools is, of course, SQL Server Management Studio. SQL Server Management Studio for SQL Server 2008 includes many new and compelling features, such as IntelliSense for
T-SQL, PowerShell integration, and expanded toolsets. However, DBAs should also be familiar with
Business Intelligence Development Studio (BIDS) and SQL Server Configuration Manager.
109
Page 109
Leiter
c03.tex
V3 - 03/25/2009
Chapter 3: SQL Server 2008 Tools
Throughout this book, you will be using the tools described in this Chapter to build and manage SQL
Server 2008 databases. Having a solid understanding of the tools available will make it easier to perform
these tasks.
Chapter 4 describes how SQL Server stores its data physically and logically. It describes the physical
architecture of data and log files, as well as how SQL Server manages these files. Since Disk I/O is often
the slowest part of any SQL environment, understanding how SQL Server stores and accesses data will
be the key to maintaining a solid infrastructure.
110
11:39am
Page 110
Leiter
c04.tex
V3 - 03/25/2009
11:44am
4
SQL Ser ver 2008 Storage
Architecture
I had just spent the better part of the day describing the storage architecture to a group of about
30 new database administrators when one of them approached me while the class was on break
and asked me pointedly, ‘‘Why do I need to know this stuff? I mean, who cares how SQL Server
stores data as long as it does it?’’ They were valid questions. After all, I have no idea how the fuel
injection system on my car works, but I drive it anyway. The key difference is that when my car
needs service, I take it to a mechanic. If your database doesn’t work, who are you going to take it
to? Understanding the mechanics of the SQL Server storage will help you make informed decisions
on where the data is stored, how the data is indexed, and how to troubleshoot an ailing database.
For years, SQL Server database administrators have grown accustomed to having unrestricted
access to system objects. This ability gave the DBA incredible power for both good and for evil.
For example, a database administrator could turn on ad hoc updates to the system tables and then
modify any value, including password hashes. This ability was certainly useful for correcting some
system errors; more damage was just as likely, however.
In the past, Microsoft strongly recommended that system objects not be accessed directly, while
sometimes offering solutions to database problems that required directly updating system tables.
With the release of SQL Server 2005 and continuing with SQL Server 2008, this apparent contradiction came to an end. Unless Microsoft (or a mysterious third party) releases some hidden secret
handshake that unlocks system objects to modification, they are completely inaccessible for updates
by the DBA. Even Read Only access to the actual system tables has been restricted and can only be
accomplished through the Dedicated Administrator Connection (DAC), and even that allowance
is made with the disclaimer ‘‘Access to system base tables by using DAC is designed only for Microsoft
personnel, and it is not a supported customer scenario.’’
To Microsoft’s credit, they certainly did their homework. They researched the primary reasons
that DBAs performed ad hoc updates to system tables and provided mechanisms to perform those
actions in a controlled manner without compromising the integrity of the system catalog.
In this chapter, you learn how SQL Server 2008 stores and organizes data. This knowledge will be
very helpful in any effort to optimize and tune SQL Server, as well as troubleshoot performance
issues.
Page 111
Leiter c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
The Resource Database
A big reason for the locking away of the system objects is because they all have a common source now
called the resource database. The resource database is the physical repository for all system objects and
is inaccessible during normal operations of SQL Server. Although the system objects are physically stored
in the resource database, they are logically presented as the sys schema in each database. Microsoft
strongly recommends that the resource database be left alone, but it can be accessed if SQL Server is
started in single-user mode. Even this access, however, is Read Only, as is access to any objects in the
sys schema. Any attempt to modify a system object will result in an error, even if ad hoc updates to
the system catalog are enabled.
Persisting all the system objects in the resource database allows for rapid deployment of service packs
and upgrades to SQL Server 2008. When installing a service pack, the process is simply one of replacing
the resource database with a new version and executing whatever modifications are required to the
operating system objects. This dramatically reduces the amount of time it takes to update SQL Server.
Even though the resource database isn’t accessible during normal SQL Server operations, information
about the database can be retrieved using system functions and global variables. The following code
returns the build number of the resource database:
SELECT SERVERPROPERTY(’ResourceVersion’)
To return the date and time the resource database was last updated, the following code can be executed:
SELECT SERVERPROPERTY(’ResourceLastUpdateDateTime’)
The sys Schema
As previously mentioned, the system objects stored in the resource database logically appear in the sys
schema of each database. The sys schema contains views that can be utilized by the DBA to retrieve
information about the objects in a database. Most (but not all) of the information the DBA typically needs
access to is available through the use of system functions and stored procedures that return metadata
from the system objects. Sometimes, however, it is beneficial to retrieve the metadata directly from the
system objects. The views in the sys schema are provided for this reason.
If you have ever used SQL Server 2000 system tables, you will find that almost all of the old system table
names have been preserved, but now are persisted as views. However, these views are only provided
for backward compatibility. They do not expose any SQL Server 2008–specific metadata. Any future
operations should be based on the new SQL Server 2008 system views. The views created to replace the
functionality of the old system tables are known as backward compatibility views, and Microsoft’s official
word is that these views will be removed in a future release.
A word of caution is needed here. As a general rule, any scripts or applications created to consume
system metadata directly from system objects should be built with the knowledge that they may not
work in future releases of SQL Server. There is nothing really new about this. Microsoft has cautioned
against formalizing processes that directly access system objects for years and has warned that the system
objects could be altered by future upgrades and service packs. What this means is that as a rule, dynamic
management views and system functions, which are discussed next, along with system stored procedures
should be used.
112
11:44am
Page 112
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
Dynamic Management Views and Functions
In addition to the traditional system objects that can be used to view system metadata, new dynamic
views and functions in the sys schema expose some very useful information about SQL Server processes and database activity. The dynamic views and functions are grouped into the following functional
categories:
❑
Common Language Runtime Related Dynamic Management Views
❑
I/O Related Dynamic Management Views and Functions
❑
Database Mirroring Related Dynamic Management Views
❑
Query Notifications Related Dynamic Management Views
❑
Database Related Dynamic Management Views
❑
Replication Related Dynamic Management Views
❑
Execution Related Dynamic Management Views and Functions
❑
Service Broker Related Dynamic Management Views
❑
Full-Text Search Related Dynamic Management Views
❑
SQL Server Operating System Related Dynamic Management Views
❑
Index Related Dynamic Management Views and Functions
❑
Transaction Related Dynamic Management Views and Functions
❑
Change Data Capture Related Dynamic Management Views
❑
Resource Governor Dynamic Management Views
❑
SQL Server Extended Events Dynamic Management Views
❑
Security Related Dynamic Management Views
❑
Object Related Dynamic Management Views and Functions
Many of the dynamic views and functions replace SQL Server 2000 system-stored procedures and
Database Consistency Checker (DBCC) commands. Most of the old stored procedures and DBCC commands still exist, but they are provided only for backward compatibility and do not expose new SQL
Server 2008 objects and processes. The new views and functions provide much more detailed information
and return relational result sets that can be used with ease in custom monitoring applications.
In later chapters, many (but by no means all) of the views and functions are used and explained in the
context of describing database maintenance and monitoring tasks. For a complete description of each
system view and function, check out SQL Server Books Online under the topic ‘‘Dynamic Management
Views and Functions.’’
SQL Ser ver Database Physical Structure
SQL Server stores all of its data in files. These files are divided up into substructures that SQL Server
manages to maintain the integrity, structure, and logical organization of the data contained within them.
Although this book is meant to be a beginner’s guide to SQL Server 2008 database administration, it is still
very important for the new DBA to understand such advanced topics as physical database architecture.
Knowing how SQL Server stores and maintains data will give you a better understanding of how changes
to the data affect performance and will allow you to more effectively diagnose database problems.
113
Page 113
Leiter c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
Physical Storage Data Types
Before getting started on the physical storage of data, it is important to have a good understanding
about the types of data that SQL Server stores. SQL Server 2008 Books Online groups data types into the
following seven functional groups:
❑
Exact numerics
❑
Approximate numerics
❑
Date and time
❑
Character strings
❑
Unicode character strings
❑
Binary strings
❑
Other data types
Although the functional grouping of data types makes perfect sense when looking at data types from
a usability viewpoint, what is relevant to this discussion is how the data is stored. SQL Server data
types can essentially be grouped into three storage type groups: fixed-length data types, variable-length
data types, and large object data types. In certain circumstances, large object data types can also act like
variable-length data types, which are explained later. The data types described in this section are only
data types that can be assigned table column data types for the physical storage of the associated data.
This precludes the cursor and table data types that are described later in this chapter.
Fixed-Length Data Types
Fixed-length data types are exactly that — fixed. The amount of space used to store them in memory or
on disk does not change. Following is a list of fixed-length data types:
❑
bit — The bit is an integer data type that supports a value of 0 or 1. Contrary to what its name
implies, the bit data type actually consumes a byte of space for 8 or less bit data types used.
❑
tinyint — The tinyint data type uses 1 byte of storage space to store an unsigned integer value
between 0 and 255.
❑
smallint — The smallint data type uses 2 bytes of storage space to store a signed integer
between –32,768 and 32,767.
❑
int — The int data type uses 4 bytes of storage space to store a signed integer between
–2,147,483,648 and 2,147,483,647.
❑
bigint — The bigint data type uses 8 bytes of storage space to store a signed integer between
–9,223,372,036,854,775,808 and 9,223,372,036,854,775,807.
❑
114
decimal and numeric — The decimal and numeric data types are functionally identical. For
clarity, you should typically use decimal, because it is more descriptive of the data it is used
to store. The decimal data type can be set to consume different fixed amounts of storage space
based on how it is used. When using the decimal data type, you have the option of specifying the precision (p) and scale (s) of the data to be stored. This is expressed by decimal(p,s).
The precision and scale are specified with positive integer values between 0 and 38. However,
the scale value must be less than or equal to the precision value, and can only be specified if a
11:44am
Page 114
Leiter c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
precision value is specified. Storage space is dependent on the value of precision, as described in
the following table:
Precision
Storage Bytes
1–9
5
10–19
9
20–28
13
29–38
17
❑
smallmoney — The smallmoney data type stores monetary values between –214,748.3648 and
214,748.3647. The smallmoney data type is accurate to a ten-thousandth of whatever currency
unit is being stored and consumes 4 bytes of space.
❑
money — The money data type stores monetary values between –922,337,203,685,477.5808 and
922,337,203,685,477.5807. The money data type is accurate to a ten-thousandth of whatever currency unit is being stored and consumes 8 bytes of space.
❑
real — The real data type is a floating-point number, so its value is approximate. The values
supported by real are negative numbers between –3.40E+38 and –1.18E-38, 0, and positive
numbers between 1.18E-38 and 3.40E+38. The real data type consumes 4 bytes of space.
❑
float — The float data type is a floating-point number, so its value is also approximate. The
range of values supported by float and the resultant storage space required is dependent on the
specified precision of the float. The precision is expressed as float(n), where n is the number of
bits used to store the mantissa of the number in scientific notation. Allowable precision values
are between 1 and 53. Precision values from 1 to 24 require 4 bytes of storage space, and precision values of 25 to 53 require 8 bytes of storage space. With the default precision of 53, the range
of values supported by float is negative numbers between –1.79E+308 and –2.23E-308, 0, and
positive numbers between 2.23E-308 and 1.79E+308.
❑
smalldatetime — The smalldatetime data type is used to store dates and times between January 1, 1900 and June 6, 2079. It is accurate to the minute and consumes 4 bytes of space. Internally, SQL Server stores smalldatetime data as a pair of 2-byte integers. The first 2 bytes are
used to store the number of days since January 1, 1900, and the second 2 bytes are used to store
the number of minutes since midnight.
❑
datetime — The datetime data type is used to store dates and times between January 1, 1753
and December 31, 9999. It is accurate to 3.33 milliseconds and consumes 8 bytes of space. Internally SQL Server stores datetime data as a pair of 4-byte integers. The first 4 bytes are used to
store the number of days since January 1, 1753, and the second 4 bytes are used to store the number of milliseconds (rounded to 3.33) since midnight.
❑
datetime2 — The datetime2 data type is an extension of the datetime data type with support
of a wider range of dates and more accuracy. It can be used to store dates and times between
January 1, 0001 and December 31, 9999 and is accurate to up to 100 nanoseconds. Similar to the
decimal and numeric data types, it is declared with an optional precision. The precision specifies
115
Page 115
Leiter
c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
the storage of fractional seconds with the default precision being seven decimal places, or 100
nanoseconds. It consumes 6 bytes of space for precisions 3 or less, 7 bytes for precisions 4 and 5,
and 8 bytes for precisions 6 and 7.
❑
datetimeoffset — The datetimeoffset data type is used to store dates and times between
January 1, 0001 and December 31, 9999 along with an offset from UTC (Coordinated Universal
Time) ranging from 14 hours before UTC to 14 hours after UTC. Like the datetime2 data type, it
is accurate to 100 nanoseconds and uses the optional precision specification.
❑
date — The date data type is used to store date values only between January 1, 0001 and December 31, 9999. It is accurate to 1 day and consumes 3 bytes of space. Internally, SQL Server stores
date data as a 3-byte integer that is used to store the number of days since January 1, 0001.
❑
time — The time data type is used to store time values only between 00:00:00.0000000 and
23:59:59.9999999. It is accurate to 100 nanoseconds. Similar to the decimal and numeric data
types, it is declared with an optional precision. The precision specifies the storage of fractional
seconds with the default precision being seven decimal places, or 100 nanoseconds. It consumes
3 bytes of space for precisions less than 3; 4 bytes for precisions 3 and 4; and 5 bytes for
precisions 5, 6, and 7.
❑
char — The char data type is used to store a fixed amount of non-Unicode data between 1 and
8,000 characters, and is expressed as char(n), where n is the number of characters to store. Each
character requires 1 byte of storage space.
❑
nchar — The nchar data type is used to store a fixed amount of Unicode data between 1 and
4,000 characters, and is expressed as nchar(n), where n is the number of characters to store. Each
character requires 2 bytes of storage space. Unicode types are appropriate if multiple languages
must be supported.
❑
binary — The binary data type is used to store a fixed amount of binary data between 1 and
8,000 bytes, and is expressed as binary(n), where n is the number of binary bytes to store.
❑
rowversion or timestamp — rowversion is the data-type synonym for timestamp and consumes
8 bytes of storage space. rowversion should be specified instead of timestamp whenever possible, because it more accurately reflects the true nature of the data type. The timestamp data
type has nothing to do with time. It is actually an 8-byte binary string that is used to define a
versioning value to a row. When a timestamp or its synonym rowversion is specified as a table
column’s data type, every insert or update to that table will cause a new value to be generated
by SQL Server and placed in the appropriate field.
❑
uniqueidentifier — The uniqueidentifier data type is stored as a 16-byte binary string
represented by 32 hexadecimal characters. uniqueidentifiers can be generated by SQL Server
with the NEWID() function, or existing uniqueidentifiers can be inserted and stored in a
uniqueidentifer column.
Variable-Length and Large Object Data Types
Variable-length data types are used when the exact amount of space required by data cannot be predicted
(such as a column that holds a last name of a person). The varchar, nvarchar, and varbinary data types
fall into this category.
However, when the (MAX) option is specified for the length of the character or binary string, these variable data types can be treated as Large Object data types. The primary difference is in how the data
is stored. Large Object data is stored outside the data row in separate physical structures by default,
whereas variable-length data is stored in the data row.
116
11:44am
Page 116
Leiter c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
This is explained in the following descriptions:
❑
varchar — The varchar data type is used to store a variable amount of non-Unicode data
between 1 and 8,000 characters, and is expressed as varchar(n), where n is the maximum
number of characters to store. Each character requires 1 byte of storage space. The actual storage
space used by a varchar is the value of n plus 2 bytes. The varchar data type also supports
an optional (MAX) length specification. When using varchar(MAX), the maximum amount of
characters supported is 2,147,483,647, consuming up to 2 GB of storage space. When the (MAX)
option is specified, SQL Server will store the varchar data in the data row, unless the amount
of data exceeds 8,000 bytes or doing so would exceed the maximum row size of 8,060 bytes. In
these cases, SQL Server will move the varchar data out of the row and into a separate Large
Object storage space (see the section ‘‘Data Pages’’ later in this chapter).
❑
nvarchar — The nvarchar data type is identical to the varchar data type, except that it is used
to store Unicode data. Each Unicode character requires 2 bytes of storage, resulting in the maximum number of characters supported being 1,073,741,824.
❑
varbinary — The varbinary data type is also very similar to the varchar data type, except that
it is used to store binary data and not character data. Other than that, the storage and use of the
(MAX) option works the same as the (MAX) option described above.
❑
text — The text data type is a Large Object data type and is very similar to the varchar(MAX)
data type in that it can also be used to store up to 2 GB of character data. The primary difference
is that text data is stored out of the data row by default, and the text data type cannot be passed
as a parameter in SQL Server functions, stored procedures, or triggers.
❑
ntext — The ntext data type is identical to the text data type, except that it is used to store
Unicode data. As a result, the 2 GB of Unicode character data represents only 1,073,741,824
characters.
❑
image — The image data type is a Large Object data type and is very similar to the
varbinary(MAX) data type. It can also be used to store up to 2 GB of binary data but is
always stored outside the data row in separate Large Object data pages.
❑
XML — The XML data type is a Large Object type that is used to store XML (Extensible Markup
Language) in its native format. Up to 2 GB of XML data can be stored per data row.
❑
sql_variant — A sql_variant data type can be used in objects when the actual data type of a
value is unknown. The sql_variant data type can be used to store almost any value that consumes less than 8,000 bytes. The type of data that is incompatible with the sql_variant type is
text, ntext, image, timestamp, cursor, varchar(MAX), and nvarchar(MAX).
CLR Data Types
SQL Server 2008 includes three different CLR-based data types. The first is hierarchyid, which is used
to manage hierarchical data in a table structure. The other two are new spatial data types that are used to
represent information about the physical location and shape of geometric objects, such as country boundaries, roads, lakes, and the like. SQL Server 2008’s spatial data types conform to the Open Geospatial
Consortium (OGC) Simple Features for SQL Specification version 1.1.0.
❑
hierarchyid — The hierarchyid data type is used to create tables with a hierarchical struc-
ture or to reference the hierarchical structure of data in another location. The amount of storage
required depends on the number of records and the number of hierarchies in the rows. To store a
hierarchical number for an organization with 100,000 employees divided into seven levels would
117
Page 117
Leiter c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
require 5 bytes. The more rows divided into more hierarchies, the more storage space that is
required. The data type is limited to 892 bytes.
❑
geometry — This type represents data in a Euclidean (flat) coordinate system.
❑
geography — The geography data type (geodetic) stores ellipsoidal (round-earth) data, such as
GPS latitude and longitude coordinates.
In-Row Data
By utilizing the ‘large value types out of row’ table option, the DBA can specify that all of the
varchar(MAX), nvarchar(MAX), and varbinary(MAX) data is treated as Large Object data and is stored
outside the row in separate Large Object data pages. The option can be set to ‘ON’ or ‘OFF’, as shown
here:
sp_tableoption ‘tablename’, ‘large value types out of row’, ‘ON’
sp_tableoption ‘tablename’, ‘large value types out of row’, ‘OFF’
Likewise, if the DBA wants to keep text or ntext data in the row unless it exceeds a specified size, the
table option ‘text in row’ can be specified. This option allows the DBA to specify a range of data to keep
in the row. The supported range is from 24 to 7,000 bytes. Instead of specifying a limit, the word ON can
be passed, resulting in a default value of 256 bytes. To turn the option off, the word OFF is passed:
sp_tableoption ‘tablename’, ‘text in row’, ‘number of bytes’
sp_tableoption ‘tablename’, ‘text in row’, ‘ON’
sp_tableoption ‘tablename’, ‘text in row’, ‘OFF’
FILESTREAM Data
A new enhancement added to SQL Server 2008 is the ability to store unstructured data, such as text documents, images, and videos, outside the database but linked to the row in which the column is defined.
FILESTREAM integrates the Database Engine with the NT File System by storing varbinary(MAX)
binary large object (BLOB) data as files on the file system instead of on separate Large Object data pages
within the data file of the database. Transact-SQL statements can insert, update, query, and back up
FILESTREAM data.
In order to use FILESTREAM, the database needs a filegroup that is designated as a FILESTREAM storage
area. The following example shows how to add a FILESTREAM filegroup to the AdventureWorks2008
database:
USE Master
GO
ALTER DATABASE AdventureWorks2008
ADD FILEGROUP MyFilestreamGroup2
CONTAINS FILESTREAM
GO
ALTER DATABASE AdventureWorks2008
118
11:44am
Page 118
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
ADD FILE (NAME = N’FileStreamData’
,FILENAME = N’D:\SQLData\FileStreamData’)
TO FILEGROUP MyFilestreamGroup
GO
Once the new filegroup is added to the database, tables can be added or modified to store the table’s
binary Large Object data in the file system as a Database Engine–managed object. The following example
shows how to create a table that uses the FILESTREAM storage:
USE AdventureWorks2008
GO
CREATE TABLE MyLargeData
(DocumentIdentifier uniqueidentifier ROWGUIDCOL NOT NULL UNIQUE
,DocumentFile VARBINARY(MAX) FILESTREAM NULL)
GO
Keep in mind that a table with FILESTREAM-enabled storage must have a non-NULL unique ROWGUID
column. To add a FILESTREAM column to an existing column, you must ensure that the table has a
ROWGUID column or you must add one.
Other Data Types
As previously noted, SQL Server 2008 has two data types that are not used to store data physically on
the disk by being part of a table or index definition. The following data types are used in programming
objects to manipulate data:
❑
table — The table data type is used to store a set of rows in memory. It is primarily used with
Table-Valued Functions but can be used in any programming object to return an organized result
set that has most of the properties of an actual table. A table variable can be declared and instantiated with a set of columns, a specified primary key, check constraints, and a default constraint.
❑
cursor — Transact-SQL performs best with sets of data, but occasionally it is necessary to
manipulate data one row at a time. The cursor data type is used for this type of requirement. A
cursor holds a complete set of rows from a query and can then be manipulated to return single
rows at a time. For a complete discussion of cursors and their uses, check out the book Beginning
T-SQL with Microsoft SQL Server 2005 and 2008 by Paul Turley and Dan Wood (Wiley, 2008).
SQL Server Database Files
SQL Server stores data in data files and transactional records in transaction log files. These files, when
grouped together under a logical database name, are the database. A SQL Server database can have many
data files and multiple transaction log files, although one transaction log file is usually sufficient.
When a database is first created, it will have one primary data file with the default file extension of .mdf.
It can also optionally have secondary data files with the default extension of .ndf. These data files can be
grouped together in a logical grouping called a filegroup, which is explained in Chapter 5. The database
will also have, at a minimum, one transaction log file with the default extension of .ldf. The file extensions
119
Page 119
Leiter
c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
for SQL Server databases are not enforced, so you can use anything you want, but the default extensions
are typically used because they readily identify the file’s purpose. The following sections are limited
to a description of the physical storage structure of the data and transaction log files. For a complete
description of the database creation process and how files are created and used, see Chapter 5.
Data Files
The database master data file (.mdf), or primary data file, and any secondary data files (.ndf) that are part
of the database have identical structures. Both files are used to store data, as well as all the metadata that
allows SQL Server to efficiently find, read, modify, and add data to the database. All the data from tables
and indexes and the metadata that describes that data is organized in storage objects called extents and
pages.
Extents
An extent is a SQL Server file storage structure that is 64 KB in size. Extents are comprised of eight contiguous 8-KB pages. There are two types of extents: mixed extents and uniform extents. Mixed extents
contain pages from more than one object. For example, a mixed extent might contain data pages from
Table A, an index page from indexes on Table B, and still more data pages from Table C. Because there are
eight pages in an extent, it is possible for eight different objects to share an extent. Uniform extents contain
eight contiguous pages that belong to the same object. The differences are illustrated in Figure 4-1.
Contact
Contact
Customer
CreditCard
Store
Store
SalesPerson
SalesPerson
ContactID
ContactID
CustomerID
CreditCardID
CustomerID
CustomerID
SalesPersonID
SalesPersonID
NameStyle
NameStyle
TerritoryID
CardType
Name
Name
TerritoryID
TerritoryID
Title
Title
AccountNumber
CardNumber
SalesPersonID
SalesPersonID
SalesQuota
SalesQuota
FirstName
FirstName
CustomerType
ExpMonth
Demographics
Demographics
Bonus
Bonus
MiddleName
MiddleName
rowguid
ExpYear
rowguid
rowguid
CommissionPct
CommissionPct
LastName
LastName
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
SalesYTD
SalesYTD
CreditCard
CreditCard
Mixed Extent
CreditCard
CreditCard
CreditCard
CreditCard
CreditCard
CreditCard
CreditCardID
CreditCardID
CreditCardID
CreditCardID
CreditCardID
CreditCardID
CreditCardID
CreditCardID
CardType
CardType
CardType
CardType
CardType
CardType
CardType
CardType
CardNumber
CardNumber
CardNumber
CardNumber
CardNumber
CardNumber
CardNumber
CardNumber
ExpMonth
ExpMonth
ExpMonth
ExpMonth
ExpMonth
ExpMonth
ExpMonth
ExpMonth
ExpYear
ExpYear
ExpYear
ExpYear
ExpYear
ExpYear
ExpYear
ExpYear
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
ModifiedDate
Uniform Extent
Figure 4-1: Mixed extents and uniform extents.
When data is retrieved or written to disk during database operations, the extent is the basic structure for
data retrieval. SQL Server always allocates space in 64-KB increments. This maps very nicely to the way
data is organized in memory and on an NT File System (NTFS) formatted partition. As previously noted,
however, SQL Server can store pages from different objects in a single extent to maximize the efficiency
of the storage process.
120
11:44am
Page 120
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
Pages
All data and metadata in a SQL Server 2008 database are stored in pages. Unlike extents, pages always
store data from the same object. This includes rows from tables, rows from indexes, and Large Object
data. Pages are 8 KB in size and are organized on 64-KB extents, which are made up of eight contiguous
8-KB pages. Every page has a 96-byte header that contains information about the page, such as the page
number, the type of data stored on the page, the amount of free space available on the page, and what
object owns the page. SQL Server contains several different types of pages that are used both to store
data and to manage data.
Data Pages
Data pages contain data rows from tables. These rows cannot span pages. Because of the page header and
row offset information, the maximum row size is limited to 8,060 bytes. Row sizes are determined by the
number of columns in the row and the data type defined on each column. To maximize performance,
table and index rows should be kept as narrow as possible. For example, if a single table row were 4,100
bytes in width, only one row could be stored on each data page, leaving almost 4,000 bytes of unusable
space. Resulting reads from a table with this structure would require 8 KB of data retrieval for only 4,100
bytes of data. This is obviously very inefficient. Physical data page structure is illustrated in Figure 4-2.
Page Header
(96 Bytes)
Row 1
Row 2
Row 3
Row 4
Free
Space
Row Offsets
1 2 3 4
Figure 4-2: Physical storage
structure.
Each row-offset block consumes 2 bytes of space for every row stored on a page. Rows from tables are
physically arranged differently than their logical definition in order to optimize storage space. When a
row is stored on a data page, the row is identified with a 4-byte header, which uniquely identifies the
row on the page, followed by the fixed-length data columns, a Null block, a variable block, and then all
the variable data columns at the end of the physical row, as shown in Figure 4-3.
The Null block contains a 2-byte block that indicates how many columns in the row can contain nulls,
followed by a bitmap that indicates whether the nullable column is null. The size of the null bitmap is
121
Page 121
Leiter
c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
equal to 1 bit per column, rounded up to the nearest byte. One to eight nullable columns require a 1-byte
bitmap. Nine to 16 columns require a 2-byte bitmap, and so on.
Row
Header
(4 Bytes)
Fixed Data
Null
Block
Variable
Block
Variable Data
Figure 4-3: Header identifying a row.
The variable block, like the Null block, contains 2 bytes that indicate how many variable-length columns
are present, followed by a bitmap that indicates what the maximum length of each variable column is.
Unlike the Null block, the variable block bitmap contains 2 bytes per column that point to the end of each
variable-length column, so that all the variable data can be stored contiguously at the end of the row. If
no columns are defined as variable length, the variable block is omitted.
Index Pages
Index pages contain rows from indexes. They have the same structure and limitations as data pages.
Text/Image Pages
When a column is defined with a Large Object data type, SQL Server places a 16-byte pointer in the actual
data row and places the Large Object data on separate data pages. This data includes those defined as
text, ntext, image, varchar(MAX), nvarchar(MAX), varbinary(MAX), and XML.
Global Allocation Map (GAM) and Secondary Global Allocation Map (SGAM) Pages
The GAM and SGAM pages are allocation pages that manage extents on a file-by-file basis. The second
page of every data file is a GAM page, and the third page of every data file is a SGAM page. SQL Server
will add additional GAM and SGAM pages as necessary, because each GAM and SGAM page can track
only 63,904 extents. The GAM and SGAM pages form a bitmap that indicates whether an extent is a
uniform or mixed extent. The GAM and SGAM bitmap also indicates whether the extent is full, empty,
or has free data pages.
Page Free Space (PFS) Pages
PFS pages record the status of each page, whether or not a page has been allocated, and the amount of
free space on each page.
Index Allocation Map (IAM) Pages
The IAM page contains information about the extents that a table or index uses. The IAM page contains
the location of the eight initial pages of an object, and a bitmap representing the extents that are in use for
that object. Every IAM page can track up to 512,000 data pages. SQL Server uses the IAM and PFS pages
to find and allocate new pages for data.
122
11:44am
Page 122
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
Bulk Changed Map (BCM) Pages
The Bulk Changed Map pages contain the location of extents that were modified by bulk operations
since the last transaction log backup. Bulk operations include UPDATETEXT, WRITETEXT, SELECT INTO,
BULK INSERT, and image operations. BCM pages are used primarily for transaction log backup operations when the database is in BULK-LOGGED recovery mode (see Chapter 9 for a full explanation of the
BULK-LOGGED recovery mode).
Differential Changed Map (DCM) Pages
The Differential Changed Map pages contain the identifier of any extent that has been modified since the
last database backup. The DCM pages are used when performing Differential backups.
Transaction Log
The purpose of the transaction log is to maintain a physical record of all transactions that have occurred
on a SQL Server database during a specific interval. The specific interval depends on the database
recovery mode.
In the default database configuration, the transaction log keeps a record of all database modifications and
is never cleared unless it is backed up or explicitly truncated by a database administrator.
The transaction log is a binary file. It is not simply a traditional log file that can be opened and viewed
with a log viewer or Notepad, so its contents are not readily available to the database administrator.
There are a couple of third-party products that can be used by the database administrator to open and
view the contents of the transaction log. These products can be used to audit database modifications and
also can be used to create scripts that will reverse the effects of an unwanted transaction.
The transaction log is maintained on disk as one or more physical files. In most cases, one transaction
log file is sufficient, because any additional log files will not be used until the first is completely full and
has reached its maximum size. Internally, the physical transaction log file is divided into multiple virtual
logs. The number and size of the virtual log files that a physical file or files are divided into are configured
dynamically by SQL Server and are not configurable. When SQL Server configures the transaction log
internal structure, it tries to keep the number of virtual logs small.
To help SQL Server maintain a smaller number of virtual logs, the initial size of the transaction log should
be set to accommodate all expected transactions that may occur between transaction log backups. If the
log is configured to auto-grow, the growth increments should be fairly large to avoid small repetitive
growths that will cause the creation of multiple small virtual logs.
Transactions
All data modifications occur within a transaction and are recorded in the transaction log. A transaction is
a single unit of data operations that can be controlled so that either all the modifications in a transaction
occur, or none occur. SQL Server has three ways of executing transactions: Implicit Transactions, Explicit
Transactions, and Auto-Commit Transactions. Implicit and Auto-Commit Transactions are mutually
exclusive.
123
Page 123
Leiter
c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
Auto-Commit
By default SQL Server connections use Auto-Commit Transactions. Any INSERT, UPDATE, or DELETE statement executed alone or in a batch will automatically be applied to the database. An example of this type
of activity is as follows:
UPDATE CheckingAccount
SET Balance = Balance + 500
WHERE AccountID = ‘123456789-CK’
UPDATE SavingsAccount
SET Balance = Balance - 500
WHERE AccountID = ‘123456789-SV’
Both of the updates in this example are transactions. In Auto-Commit mode, they will be applied to the
database independently of each other. If the first update succeeds, but the second fails, the bank will have
lost $500.00, and there will be no way to roll back the changes. Likewise, if the first update fails and the
second succeeds, you will be out $500.00, and the bank will have gained $500.00. To avoid data problems
resulting from errors involving dependent data changes, transactions should be used.
Implicit
The ANSI standard for the Structured Query Language specifies that no modifications should be made to
data unless explicitly committed. SQL Server supports this specification through a connection property
called IMPLICIT_TRANSACTIONS. When IMPLICIT_TRANSACTIONS is set to ON, any data modification will
implicitly begin a transaction, but will not close the transaction. The transaction will remain open until it
is explicitly committed or rolled back. An example of this is as follows:
SET IMPLICIT_TRANSACTIONS ON
BEGIN TRY
UPDATE CheckingAccount
SET Balance = Balance + 500
WHERE AccountID = ‘123456789-CK’
UPDATE SavingsAccount
SET Balance = Balance - 500
WHERE AccountID = ‘123456789-SV’
COMMIT TRANSACTION
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION
RAISERROR(’Account Transfer Failed’, 14,1)
END CATCH
In this example, if any error occurs during data modification, the CATCH block will be called to roll back
the transaction. If no errors occur, the transaction will be committed. In Auto-Commit mode this same
124
11:44am
Page 124
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
logic would not work, because there was no implicit or explicit transaction to commit or roll back. Turning on IMPLICIT_TRANSACTIONS turns off Auto-Commit.
Explicit
An explicit transaction requires a BEGIN TRANSACTION to begin the transaction and an explicit
COMMIT TRANSACTION or ROLLBACK TRANSACTION to close the transaction, as shown in the following
example:
BEGIN TRY
BEGIN TRANSACTION
UPDATE CheckingAccount
SET Balance = Balance + 500
WHERE AccountID = ‘123456789-CK’
UPDATE SavingsAccount
SET Balance = Balance - 500
WHERE AccountID = ‘123456789-SV’
COMMIT TRANSACTION
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION
RAISERROR(’Account Transfer Failed’, 14,1)
END CATCH
In this example, like the implicit transaction example before it, any error can be used to immediately roll
back the transaction, ensuring data integrity.
Much of the documentation available on SQL Server states that a transaction is a ‘‘single unit of work that
must accomplish entirely, or not at all.’’ However, even if the data modifications are placed in a transaction, this does not guarantee that the transaction will accomplish entirely. Without the TRY and CATCH
blocks, an implicit or explicit transaction will work just like the Auto-Commit example. Any successful
modifications will be made to the database, and any failed ones will not. Proper error handling is critical
to managing transactions.
Recording Transactions
Now that you know what a transaction is, take a look at how SQL Server records them on the disk.
Data modifications are never made directly to the database data file. When a modification is sent by an
application, SQL Server finds the data page that contains the data, or, in the case of an insert, a page with
enough space in it to accommodate the data in the buffer cache. If the page is not located in the cache,
SQL Server will read the page from disk and place it in the buffer cache and then modify it there. At the
same time, SQL Server records the data modification on disk in the transaction log. When the page was
initially read into the buffer cache, it was a ‘‘clean’’ page. Once the page was modified by the transaction,
the page became ‘‘dirty.’’
125
Page 125
Leiter
c04.tex
V3 - 03/25/2009
Chapter 4: SQL Server 2008 Storage Architecture
SQL Server periodically issues an event called a CHECKPOINT. When a CHECKPOINT is issued, all dirty
pages in the buffer cache are written to the data file on disk. The purpose of checkpoints is to reduce
the amount of dirty data stored in the cache to minimize the amount of time required for SQL Server to
recover from a failure. Consider the following sequence of events:
BEGIN TRANSACTION 1
UPDATE ...
INSERT ...
UPDATE ...
COMMIT TRANSACTION 1
BEGIN TRANSACTION 2
INSERT ...
UPDATE ...
***CHECKPOINT***
BEGIN TRANSACTION 3
DELETE ...
UPDATE ...
COMMIT TRANSACTION 3
BEGIN TRANSACTION 4
UPDATE ...
***Server Power failure***
When SQL Server restarts after the power failure, it will read the transaction log to find the last
CHECKPOINT issued. Everything from the last CHECKPOINT to the beginning of the log has been safely
written to the disk. However, the only record of data modifications after the CHECKPOINT is in the
transaction log. Because Transaction 3 was successfully committed, the calling application was notified
of its success and should expect to see all the modifications that were submitted. In light of this, SQL
Server will roll the entire Transaction 3 forward and commit the changes to disk. Transaction 2, on the
other hand, was never successfully committed, even though the first two modifications were written to
disk by the CHECKPOINT. SQL Server will use the information in the transaction log to undo, or roll back,
the modifications. Transaction 4 was also never successfully committed, but neither was it written to the
disk. Transaction 4 data modifications will essentially be deleted from the transaction log.
Transaction Log Physical Characteristics
The transaction log is implemented as a serialized, sequential, rotary write-back log. As data modifications are written to the log, they are given a Log Sequence Number (LSN). Because the transaction log is
used to record more and more transactions, it will eventually fill up. If the transaction log has been set
up to auto-grow (see Chapter 5), SQL Server will allocate additional file space to accommodate storage
of transaction records. This behavior will continue until the transaction log’s maximum size has been
reached, or the disk that contains the transaction log fills up. If the transaction log becomes completely
full, no data modifications will be allowed on the database.
To keep the transaction log from becoming completely full, it is necessary to periodically remove old
transactions from the log. The preferred method of clearing the log is by backing up the transaction
log (see Chapter 7). By default, once the transaction log has been successfully backed up, SQL Server
will clear the inactive portion of the transaction log. The inactive portion of the transaction log is from
the LSN of the oldest open transaction to the earliest LSN in the transaction log. This clearing of the
126
11:44am
Page 126
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Chapter 4: SQL Server 2008 Storage Architecture
transaction log does not reduce the size of the transaction log, but it does free up space in the log for
additional transaction records.
The inactive portion of the transaction log can also be manually cleared, but this is strongly discouraged
because doing so deletes all records of data modifications since the last database backup.
As previously noted, the transaction log is a rotary file. Once the end of the physical log is reached, SQL
Server will loop back and continue writing the current logical log at the beginning of the physical log, as
shown in Figure 4-4.
Free space due to truncation
End of
Logical Log
Last Checkpoint
Start of
Logical Log
Figure 4-4: Looping back and continuing to write the current
logical log.
Summar y
This chapter examined how SQL Server physically stores data and transaction records on disk. Although
this information may seem a bit esoteric in nature, it will become increasingly valuable as your SQL
Server skills advance and you encounter more complex troubleshooting and optimization issues that
require a deep understanding of how SQL Server stores and retrieves data. Keep in mind that this
chapter just scratched the surface when it comes to the deep inner workings of the Database Engine.
For a complete discussion of the Database Engine internals, consult SQL Server 2008 Books Online.
The database is the heart of SQL Server, and Chapter 5 exposes and describes all the parts and pieces that
SQL Server uses to manage, modify, and organize the data stored within it. This includes everything from
the tables used to store the data to the programming objects used to modify the data, and everything in
between.
127
Page 127
Leiter
c04.tex
V3 - 03/25/2009
11:44am
Page 128
Leiter
c05.tex
V3 - 03/25/2009
11:47am
5
SQL Ser ver 2008
Databases
The database is the heart of SQL Server 2008, handling everything from storing user information for
later retrieval to acting as a temporary storage area for SQL Server operations. Previous chapters
discussed the SQL Server installation process and the internal structure of all the files that make
up a SQL Server 2008 database. This chapter delves into creating user databases and the various
options that can be configured on them.
System Databases
As mentioned in Chapter 1, when SQL Server 2008 is installed, five system databases are created to
store system information and support database operations. Four of the system databases (master,
model, msdb, and tempdb) are visible during normal database operations, but the fifth (the resource
database, as described in Chapter 4) is not. Distribution databases can also be created if the SQL
Server instance is configured as a distributor for SQL Server Replication.
User Databases
User databases are those databases that are created by any server login that possesses the appropriate
permissions. In past versions of SQL Server, you had the option to install the AdventureWorks2008
sample databases that were briefly described in Chapter 1, but this ability has since been
removed from the product. You can download the AdventureWorks2008 sample database and
code samples from the ‘‘Microsoft SQL Server Community Projects and Samples’’ located at
www.codeplex.com/sqlserversamples.
Database Planning
One of the key responsibilities of the database administrator is the management of database
creation. All too often, a company will purchase an application from a vendor that requires a SQL
Server back-end without fully planning the data tier support. Many times, the vendor will be more
than happy to come out, install the SQL Server instance, and create the necessary databases to
Page 129
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
support the application. In other cases, the application vendor will create setup programs that install
and configure the database automatically. I have seen many of these installations, and, with just a few
exceptions, the configuration of the supporting databases was either inefficient or flat-out wrong.
This is not to say that the application developers from software vendor companies don’t know what
they’re doing. The problem is much more complex. First, it is almost impossible to accurately predict the
hardware platform, database usage, and the amount of data stored for every installation of a database
application combination, so default values are almost always wrong. Second, and this comes from a lot
of experience, many application developers have no idea how SQL Server really works. They think of it
only as a place to stick data. The idea of leveraging the power of the data tier or optimizing the data tier
doesn’t occur to very many application developers.
Database administrators should worry about how and why a database is performing the way it is. The
best time to start managing a database is before it is created. Whether a data application is developed
internally or purchased from a software vendor, it is imperative that the database administrator be intimately involved in the planning and creation of the supporting database. With that in mind, here’s a
closer look at the database creation process and the configuration options available during database
creation.
Capacity Planning
One of the first things that must be determined when planning a new database is how much disk space
will be required to support the database. The idea is to both ensure that there is sufficient disk space
available for data expansion and to reduce the amount of data and log file growths that are performed to
accommodate the data expansion to improve database efficiency.
If the database is being built to support an application purchased from a vendor, the capacity planning
for the database should be very easy. However, the simplicity depends on the software vendor providing
detailed documentation. The documentation must describe the average size of the database after periodic
intervals where a defined number of users and transactions were supported. If the documentation is
provided, you will have a good idea of what to expect from the database and can configure it accordingly.
If the vendor did not provide the information, your job as a database administrator becomes a bit more
complicated, and you may just have to guess. However, it must be an educated guess using as much
information as you are able to collect. The difficulty is often in the fact that you may not know how the
vendor is storing and retrieving data, so the database must be monitored for growth trends to adequately
predict the amount of storage space.
If the database is being designed and built internally, there are established techniques for determining
how big the data files will need to be. These techniques work because you know how much data is added
for every transaction, whereas in a vendor-provided database, that information may not be available.
One such technique that I am sure you will encounter is calculating a database size requirement by
calculating table sizes. It looks like this:
1.
2.
3.
130
Add up the total number of bytes used by the fixed-length columns in the table.
Average the total number of bytes used by the variable-length columns in the table.
Add the number from Step 1 to the number calculated in Step 2.
11:47am
Page 130
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
4.
Divide 8,060 (the maximum amount of data bytes in a page) by the number calculated in
Step 3, and round down to the nearest whole number. This is the number of rows that will
fit on a single page. Remember that rows cannot span pages, which is why you round down.
5.
Divide the total number of expected rows by the number of rows per page calculated in Step
4. This is the total number of data pages expected to support the table.
6.
Multiply the number calculated in Step 5 by 8,192 (the size of the data page). This is the total
number of bytes required for the table.
7.
Repeat the process for every table in the database.
Sounds like fun, doesn’t it? Here’s a tip: Don’t do it. The results from this algorithm are misleading at best.
The calculation doesn’t take into account variables that affect storage space, such as whether or not compression is enabled, the number of indexes, the fill-factor used on the indexes, and data fragmentation,
just to name a few. So, why did I even bother to explain the process? Because it does give insight into size
considerations and because, as I mentioned earlier, you will most likely encounter this technique, and I
wanted to make sure you knew its limitations.
There is a more realistic method of determining how big to make a data file. The idea is to take the
database prototype (the test or development version of the database) and fill it with an appropriate
amount of test data. After the test database has been populated, check the size of the data file on disk,
and then multiply it by 1.5. The resulting file size should be sufficient to accommodate the initial data
load of the new database with some room to spare. This technique is by no means perfect, but it is a great
deal easier than the first technique, and typically much more accurate.
Once the database is put into production, it will become extremely important to monitor the size of
the database files in order to analyze growth trends. I prefer to configure alerts that fire off when the
database grows to 75 percent full. This will allow you to increase the size of files when necessary, but
also to increase them in sufficient percentages so that the increases are seldom executed.
Planning the size of the transaction log file is much more complicated. To accurately plan the log size,
you will need to know how big the average transaction is that will be executed on the database, as well
as how often the transactions will take place and what the physical structure of the tables being modified is. For example, an insert executed on a table stored in a heap with a row size of 800 bytes and
a non-clustered index on an integer column will increase the amount of data in the transaction log by
approximately 820 bytes. This is because the new row is recorded in the transaction log along with the
new index row. The size of the transaction log is also dependent on the recovery model of the database
and how often the database transaction log is backed up. Recovery models are introduced later in this
chapter. A complete description of indexes can be found in Chapter 6. Transaction log backups and their
effect on the transaction log are described in Chapter 9.
Creating Databases
Databases are usually created either by writing and executing Transact-SQL code or through the graphical user interface. In either case, the only required information during the database creation process is
the name of the new database, so the following code will create a database called SampleDB:
CREATE DATABASE SampleDB
131
Page 131
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Executing this Transact-SQL will cause SQL Server to create a single data file and one transaction log file
in the default location for files specified during the SQL Server 2008 installation process. For a typical
installation of a default instance of SQL Server 2008, this code, when executed, will create the following
file system objects:
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\
MSSQL\DATA\SampleDB.mdf
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\
MSSQL\DATA\SampleDB_log.ldf
The first file is the database data file, and the second file is the database transaction log file. Although this
default behavior is very convenient, it is usually better not to take advantage of it because all databases
are not created equal, besides the fact that the system partition is hardly the recommended destination
for data and log files. The database creation process allows for the specification of data file(s), transaction
log file(s), and database options.
Getting Started
Before creating a database, it is important to understand all the available settings and options that are
available. This section explains the process of creating a database with the graphical user interface and
examines each configuration setting and option, as well as how it affects the database creation process.
Once you have gone through the entire process, I’ll show you how to turn all the work into a script
that can be run again and again by specifying different values for the database name, filenames, and file
locations.
Creating a New Database
Creating a database graphically with SQL Server Management Studio is very easy and intuitive. The first
step is to open SQL Server Management Studio from the Start menu and connect to the Database Engine
of your SQL Server.
Right-click on the Databases node, and click New Database. The New Database screen appears, as shown
in Figure 5-1.
In the ‘‘Database name’’ field, enter the name of the new database. When specifying a database name,
keep in mind that it can be a maximum of 128 characters long. SQL Server Books Online also states
that a database name must start with a letter or underscore, and then subsequent characters can be
a combination of letters, numbers, and some special characters, but this requirement is not enforced.
However, data applications may be unable to make the connection to a database if the name does not
conform to accepted standards, so it is a very good idea not to deviate from them. As a best practice,
database names should be as descriptive as possible, but also kept as short as possible. Embedded spaces
in object names are also problematic, because they can cause unexpected problems when the database is
accessed programmatically.
The ‘‘Owner’’ field should typically specify SA, which is the built-in SQL Server System Administrator
account. When creating a new database in the graphical user interface, this field will default to the value
of <default>, which is the login account that is performing the database creation. The owner of the
132
11:47am
Page 132
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
database gains complete control of the database. Database ownership can be modified by using the
ALTER AUTHORIZATION T-SQL statement and specifying any valid login as shown in the following example:
ALTER AUTHORIZATION ON DATABASE::SampleDB TO SA
GO
Figure 5-1: New Database screen.
There are two different ways to retrieve information about databases (such as who the owner is). The
sp_helpdb stored procedure can be used to retrieve information about all databases or a specific database
and is a lot easier to use for a quick look. For all databases, the stored procedure is executed with no
parameters. For a specific database, the name of the database is passed to the stored procedure, as demonstrated in the following example:
USE Master
GO
EXEC sp_helpdb AdventureWorks2008
The results of the stored procedure when executed alone and with a database name are shown in
Figures 5-2 and 5-3, respectively.
133
Page 133
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Figure 5-2: sp_helpdb results without a database name.
Figure 5-3: sp_helpdb results with a database name.
Another way to view database information is by using catalog views, which were introduced in SQL
Server 2005. They offer more information than their stored procedure counterparts and allow the use of
standard T-SQL commands such as WHERE and GROUP BY. The following T-SQL statement shows how to
take the sys.databases catalog view and join it with the sys.server_principals catalog view to see basic
information about all the databases on the server (see Figure 5-4):
SELECT db.name AS database_name,
sp.name AS owner,
db.create_date,
db.compatibility_level,
db.recovery_model_desc
FROM sys.databases db INNER JOIN sys.server_principals sp
ON db.owner_sid = sp.sid
To avoid any potential issues, the database owner should almost always be SA. See Chapter 6 for more
information about the SA account.
Full-text indexing allows for the use of more flexible string-matching queries than Transact-SQL allows.
The full-text engine has been moved into the SQL Server 2008 process in this release, allowing better
optimization of mixed queries and performance of the index itself.
134
11:47am
Page 134
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-4: Using catalog views to retrieve database information.
Database Files
In the ‘‘Database files’’ section of the New Database dialog, notice that the Logical Name of the first
data file as well as the Logical Name for the first log file have been given names automatically. The first
data file is named the same as the database, and the log file is given the name of the database with _log
appended to the end. The logical names are used to refer to the files programmatically in T-SQL script.
Multiple files can be specified during the creation process, and each one could have its own configuration
settings (such as initial size and growth behavior).
Click on the Add button at the bottom of the New Database dialog. A new row for an additional file
is added to the ‘‘Database files’’ section. The new file defaults to the file type of Rows Data but can be
changed to either Log or FILESTREAM Data by selecting it from the dropdown list. Once the database is
created, the type of the file cannot be changed.
For this example, leave the file type as Rows Data. Type in a Logical Name for the new data file and then
in the Filegroup column, click on the dropdown list, and choose <new filegroup>. The New Filegroup
dialog displays, as shown in Figure 5-5.
Figure 5-5: New Filegroup dialog.
Filegroups
Databases are created on files that are organized in filegroups. Filegroups are a logical grouping of data files
that hold all data and database objects defined for the database. The data is striped across all files within
the filegroup using a proportional fill strategy. This allows all data files to become full at the same time.
135
Page 135
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
The only required filegroup is the one called Primary. The Primary filegroup is made up of the primary
data file and any additional user-defined data files. The purpose of the primary data file is to store all
system references for the database including pointers to objects defined in the resource database. The
Primary filegroup contains all object definitions for user-defined objects if it is left as the default filegroup
as well as all system-created objects. In addition to the Primary filegroup, more user-defined filegroups
can be created as needed.
One of the biggest advantages of using user-defined filegroups boils down to one word: control. With
user-defined filegroups, the database administrator has complete control over what data is stored in what
location. Without user-defined filegroups, all data is stored in the Primary filegroup, so the flexibility
and scalability of the database are reduced dramatically. Although this may be perfectly acceptable for
smaller databases, once the database grows to a large size, it will become increasingly unacceptable to
have all the user and system data grouped into the same filegroup.
I wish I could tell you exactly when it becomes necessary to segregate data, but like almost all questions
in technology, the answer is, ‘‘It depends.’’ It depends on the hardware the SQL Server is running on
and how the database is being accessed; there is no hard-and-fast rule. For more information about data
segregation and the use of filegroups, check out Professional Microsoft SQL Server 2008 Administration by
Brian Knight, Ketan Patel, Wayne Snyder, Ross LoForte, and Steven Wort (Wiley, 2008).
Type in a name for the new filegroup, select the Default checkbox, and click OK. This sets the new
user-defined filegroup as the default so that all user-created objects will be placed in this filegroup. This
essentially segregates system data from user data and allows for more control of the database structure.
One nice feature of using filegroups is the ability to mark all data contained within that filegroup as Read
Only. This can be done by selecting the ‘‘Read-only’’ checkbox on the New Filegroup dialog. This can be
very advantageous when organizing the different objects in a database. The objects that change can be
placed in an updatable filegroup, whereas those that never (or seldom) change can be placed in a Read
Only filegroup. This segregation of objects can reduce the amount of data required to be backed up and
restored, which is a useful option with very large databases.
Maintenance or Performance?
Should filegroups be implemented to optimize performance or to optimize maintenance tasks? Why
not both? Filegroups provide the ability to improve both the performance and the maintainability of a
database by separating data across multiple physical files in groups of tables.
The maintenance advantage comes from the ability to back up and restore individual files and filegroups
as opposed to backing up entire databases. (File and filegroup backups are described in Chapter 9.) This
ability is useful with very large databases separated into multiple filegroups, and even more useful when
some of the filegroups are marked as Read Only. This segregation of Read Write data and Ready Only
data enables the database administrator to back up only the data that is subject to modification, which
can minimize backup and restore time of large databases. This ability, however, does not come without a
cost. File and filegroup backup strategies can become quite complex. The complexity of the maintenance
plans can quickly outweigh the flexibility that is gained.
Performance advantages that are delivered with filegroups are primarily divided into three areas: The
first is parallel Read and Write operations that are made possible by separating the data files across
multiple physical devices. However, the same performance gain can be achieved in a single filegroup
with many physical files in it. The second is the ability to move non-clustered indexes and Large Object
136
11:47am
Page 136
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
data off the filegroup reserved for the regular data space. Separating non-clustered indexes from the
data enables the Database Engine to seek row locations from the index and retrieve the rows from the
tables simultaneously using separate threads. Separating infrequently accessed Large Object data from
transaction-intensive relational data can improve scan performance in some instances. The third (and
most significant) advantage that filegroups enable is the ability to physically partition large tables across
multiple filegroups. (Table and index partitioning is described later in this chapter.)
When it comes to performance, filegroups will only offer a small increase in performance to most
databases, with the exception of very large databases that can fully exploit physical table partitioning.
The best way to improve disk access to data is to implement a robust Redundant Array of Inexpensive
Disks (RAID) environment. The primary reasons for using filegroups for most database administrators
are the control it offers in the storage of the data and the ability to segregate system and user data, which
equates to maintenance concerns.
File Size
In the ‘‘Initial Size (MB)’’ column (see Figure 5-1), a value should be assigned based on how big the file
is expected to be within the first few weeks (and maybe even months) of operation. When looking for a
house and planning a large family, it would be inadvisable to buy a one-bedroom house and then have
to remodel it every time a new child is born. It makes much more sense to buy a large house that would
accommodate the family, including future children. The same goes for database files. If a file is expected
to hold 1 GB of data within the first few months of its existence, it only makes sense to allocate 1 GB of
space to that file. As a best practice, file size modifications should be kept to a minimum. Allocate enough
contiguous disk space to accommodate all the expected data plus a percentage of space for growth.
Autogrowth
Click the ellipsis button on the right of the Autogrowth column (see Figure 5-1) for the Primary data
file. The Change Autogrowth dialog displays, as shown in Figure 5-6. The Change Autogrowth dialog
enables the configuration of the maximum size and file growth setting for each individual file. Ensure
that the ‘‘Enable Autogrowth’’ checkbox is checked. Clearing this checkbox sets the filegrowth property
to zero. For this example, we will use the defaults in the Change Autogrowth dialog box.
Figure 5-6: Change Autogrowth dialog.
File growth can be set at a fixed allocation size or a percentage of the existing file size. As a best practice,
the Autogrowth option should be set to a sufficiently large enough increment to minimize the number of
137
Page 137
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
file-growths required to accommodate data growth. Growing files in small increments results in physical
fragmentation of the files, which is detrimental to both data and log file performance.
The size of both data and log files can be restricted, allowing one more way to control the sizing of the
files. This can be done by selecting the ‘‘Restricted File Growth (MB)’’ option button and specifying a
maximum size. This size cannot be exceeded by automatic or manual file-growth operations. It is generally a best practice to set a maximum file size to safeguard against any errant process that may attempt to
insert millions of rows (instead of just a few) and also to maintain control of database growth. One thing
to keep in mind is that if the database reaches the maximum size, all data modification transactions will
fail. If this occurs, the maximum size property can be changed and additional space allocated. The size
selected should be the maximum amount of data expected for that file in a determined period of time.
This operation should be performed on every file in the database.
Path
To change the path where data and log files are located, either click on the ellipses button on the right
of the Path column in the New Database dialog for each data file and select a destination folder for
each individual file, or simply type in the correct path in the Path column. When placing files, keep in
mind that data files and log files should never be on the same physical disk; doing so puts the data
at high risk of loss caused by disk or controller failure. See Chapter 3 for more information on file
placement.
Now that all the general settings of your new database are complete, it is time to configure the database
options.
Database Options
Click Options in the ‘‘Select a page’’ section in the upper-left of the New Database dialog, as shown in
Figure 5-7. The Options window displays, enabling the setting of several database options.
Collation
Click the Collation dropdown list and review the different collation settings that are available, but leave
the setting set to <server default>.
As noted in Chapter 2, an instance of SQL Server is assigned a default server collation that determines
what characters are supported on the server by default and how those characters are searched and sorted.
Collation settings can also be assigned to the database as well. As a result, just because a SQL Server
instance has been configured to use the Latin character set doesn’t mean that a database built to support
Korean characters cannot be created on the same instance. However, also as previously described, collation incompatibilities in the tempdb database may occur if the database collation settings are different
from the SQL Server instance collation settings.
Recovery Model
Click the ‘‘Recovery model’’ dropdown list and review the available choices. The available models that
can be set are Full, Bulk-Logged, and Simple. If the Model database has not been set otherwise, the default
recovery model for new databases is Full. Recovery models are explained in complete detail in Chapter
9, so for now an abbreviated explanation will suffice.
138
11:47am
Page 138
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-7: Enabling database options.
For all intents and purposes, there are really only two recovery models, Full and Simple. The
Bulk-Logged model is meant only as an accessory to the Full recovery model for use during bulk
operations. This is because in the Full recovery model, all modifications to the database are fully logged.
Although this recovery model offers the greatest level of protection from data loss, it comes at a cost.
Because all modifications to a database are fully logged, the transaction log can grow very rapidly to large
sizes during certain operations (such as bulk loading of data or table index maintenance operations). The
Bulk-Logged recovery model is also known as minimal logging and was developed so that the database
could be temporarily set to Bulk-Logged during those operations that could cause the transaction log to
rapidly swell and then be set back to Full recovery once those operations were complete.
In the Simple recovery model, the transaction log is cleared of all inactive content every time a checkpoint
is issued. Checkpoints were described in Chapter 4. The repercussion of the Simple recovery model is that
the transaction log cannot be backed up or used for database restore operations. The transaction log is
only used for transactional consistency, but no long-term storage of transactional history is maintained.
Compatibility Level
Click the ‘‘Compatibility level’’ dropdown list and review the possible choices. Unless you have specific
reasons to change the compatibility level, it should be set to SQL Server 2008 (100). The Compatibility
139
Page 139
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
level option changes the behavior of some database operations and is only necessary if an instance of
SQL Server 2008 is sharing database responsibilities with a previous release of SQL Server. SQL Server
2008 only allows for the selection of compatibility levels of 80, 90, and 100, which, as the dropdown list
indicates, correlates to SQL Server 2000, SQL Server 2005, and SQL Server 2008, respectively. In previous
versions, you were able to programmatically change the compatibility level by using the System Stored
Procedure sp_dbcmptlevel. This System Stored Procedure has been officially deprecated and has been
replaced with an addition to the ALTER DATABASE Transact-SQL command. The following code will set
the compatibility level of the AdventureWorks2008 database to SQL 2000:
ALTER DATABASE AdventureWorks2008
SET COMPATIBILITY_LEVEL = 80
For a complete discussion of all the differences between compatibility levels, there is an excellent description in SQL Server 2008 Books Online under the topic ‘‘ALTER DATABASE Compatibility Level
(Transact-SQL).’’ Databases upgraded from SQL Server 2000 or 2005 are configured for a compatibility
mode respective to their original version. For example, a SQL Server 2000 database upgraded to SQL
Server 2008 will have a compatibility level of 80.
Other Options
By default, the ‘‘Other options’’ section of the New Database screen organizes the options categorically. For purposes of this discussion, we will sort the options alphabetically. For this exercise, leave all
the options in their default configurations. Each one is described in the following sections. Some of the
database options are also connection options. Where this is the case, the commands to set the database
option and the connection-level options are both shown. It’s important to know that connection-level
options, if specified, will override database-level options. When they are not specified, the database
option will be in effect.
Click the alphabetical sort button, which can be identified by an A and a Z with a vertical arrow pointing
down. The available options are now listed alphabetically, as shown in Figure 5-7.
ANSI NULL Default
The ‘‘ANSI NULL Default’’ setting specifies whether or not the default for columns added to a table
during a CREATE TABLE or ALTER TABLE operation is to allow nulls. When the ‘‘ANSI NULL Default’’
setting is set to False, columns added will not allow nulls unless explicitly specified to do so. When
connecting to SQL Server with SQL Server Management Studio, the connection setting for new queries
defaults to the setting ANSI NULLS ON, which overrides the database setting. To set it at the connection
level or database level, the following commands are used:
--Connection Settings
SET ANSI_NULL_DFLT_ON OFF --ANSI NULL Default False
SET ANSI_NULL_DFLT_ON ON --ANSI NULL Default True
--Database Options
ALTER DATABASE AdventureWorks2008 SET ANSI_NULL_DEFAULT OFF
ALTER DATABASE AdventureWorks2008 SET ANSI_NULL_DEFAULT ON
ANSI NULLS Enabled
The ‘‘ANSI NULLS Enabled’’ setting controls the behavior of comparisons to NULL values. When set to
True, any comparison to a NULL value results in an unknown. When set to False, comparisons to NULL
140
11:47am
Page 140
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
will return True if the values are null. To set it at the connection level or database level, the following
commands are used:
--Connection Settings
SET ANSI_NULLS OFF
SET ANSI_NULLS ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET ANSI_NULLS OFF
ALTER DATABASE AdventureWorks2008 SET ANSI_NULLS ON
The ‘‘ANSI NULLS’’ option is deprecated as of this version of SQL Server. In a future version of SQL
Server, the option will be set to ON and will not be allowed to be changed. If an application attempts
to set the value to OFF, an error will be thrown. It is recommended that you avoid using it in all new
development work and make arrangements to update any applications that currently use it.
ANSI Padding Enabled
When set to True, ‘‘ANSI Padding Enabled’’ dictates that trailing spaces for character data and trailing
zeros for binary data are appended to the end of character and binary columns that are of fixed length.
Character and binary columns that are of variable length are not padded, but trailing spaces or trailing
zeros are not trimmed either. When set to False, character and binary columns that are of fixed length
and set to NOT NULL behave the same as when ‘‘ANSI Padding Enabled’’ is True. However, nullable
character and binary columns that are of fixed length are not padded, and any trailing spaces or trailing
zeros are trimmed. Variable-length columns behave the same as nullable fixed-length columns when
‘‘ANSI Padding Enabled’’ is False. To set it at the connection level or database level, the following
commands are used:
--Connection Settings
SET ANSI_PADDING OFF
SET ANSI_PADDING ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET ANSI_PADDING OFF
ALTER DATABASE AdventureWorks2008 SET ANSI_PADDING ON
The ‘‘ANSI Padding’’ option is deprecated as of this version of SQL Server. In a future version of SQL
Server, the option will be set to ON and will not be allowed to be changed. If an application attempts
to set the value to OFF, an error will be thrown. It is recommended that you avoid using it in all new
development work and make arrangements to update any applications that currently use it.
ANSI Warnings Enabled
When ‘‘ANSI Warnings Enabled’’ is set to True, warnings will be raised by the Database Engine whenever an aggregate function encounters a null. When set to False, no warnings are raised. To set it at the
connection level or database level, the following commands are used:
--Connection Settings
SET ANSI_WARNINGS OFF
SET ANSI_WARNINGS ON
--Database Options
141
Page 141
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
ALTER DATABASE AdventureWorks2008 SET ANSI_WARNINGS OFF
ALTER DATABASE AdventureWorks2008 SET ANSI_WARNINGS ON
Arithmetic Abort Enabled
Any statement or transaction that encounters an arithmetic overflow or divide-by-zero error will terminate when ‘‘Arithmetic Abort Enabled’’ is set to True. When set to False, a warning is raised, but the
statement or transaction will not be terminated. In order for this option to have the desired effect, the
‘‘ANSI Warnings’’ options must also be set to False. To set it at the connection level or database level,
the following commands are used:
--Connection Settings
SET ARITHABORT OFF
SET ARITHABORT ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET ARITHABORT OFF
ALTER DATABASE AdventureWorks2008 SET ARITHABORT ON
Auto Close
When a database is first accessed, SQL Server opens and locks all files that are associated with the
database. When ‘‘Auto Close’’ is True, the database will be closed, releasing all file locks, when the
last user connected to it closes the connection. This setting is OFF by default because the act of opening
and closing the database on a server platform is unnecessary and produces unneeded overhead. The
exception to this rule is SQL Server Express Edition, because SQL Express is designed to run on a desktop system where resources are more restricted and an open database consumes resources. If no user is
connected, those resources can be returned to the system. To set it at the database level, the following
commands are used:
ALTER DATABASE AdventureWorks2008 SET AUTO_CLOSE OFF
ALTER DATABASE AdventureWorks2008 SET AUTO_CLOSE ON
Auto Create Statistics
When ‘‘Auto Create Statistics’’ is set to True, the Database Engine will generate statistics for columns
without indexes that are missing statistics and when those columns are referenced in a WHERE clause, or
the ON clause of a JOIN operation. Statistics are used by the Database Engine to determine the selectivity
and distribution of data in a column. If set to False, it will be up to the database administrator to create
statistics manually wherever needed. To set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET AUTO_CREATE_STATISTICS OFF
ALTER DATABASE AdventureWorks2008 SET AUTO_CREATE_STATISTICS ON
Auto Shrink
When ‘‘Auto Shrink’’ is set to True, the Database Engine will periodically examine the total size of all
database files and compare it to the amount of data being stored. If there is more than 25 percent total
free space remaining, the Database Engine will perform file-shrink operations on database files to reduce
the total free space to 25 percent. This option is set to False by default, except for SQL Express Edition,
142
11:47am
Page 142
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
and, apart from the rare instance that a database will increasingly get smaller, it should be left set to
False. To set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET AUTO_SHRINK OFF
ALTER DATABASE AdventureWorks2008 SET AUTO_SHRINK ON
Auto Update Statistics
When ‘‘Auto Update Statistics’’ is set to True, the Database Engine will automatically update statistical
information on columns to maintain the most efficient query plans possible. This typically takes place
when a query is executed and the Query Processor discovers the out-of-date statistics. If set to False, it
will be up to the database administrator to manually keep column statistics up to date. To set it at the
database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET AUTO_UPDATE_STATISTICS OFF
ALTER DATABASE AdventureWorks2008 SET AUTO_UPDATE_STATISTICS ON
Auto Update Statistics Asynchronously
When ‘‘Auto Update Statistics Asynchronously’’ is set to True, statistics that are discovered to be
out-of-date during queries will be updated, but the query that was being executed when the discovery
was made will not wait for the new statistics. Subsequent queries will take advantage of the new
statistics. When set to False, query compilation will not occur until after the statistics are updated. To
set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET AUTO_UPDATE_STATISTICS_ASYNC OFF
ALTER DATABASE AdventureWorks2008 SET AUTO_UPDATE_STATISTICS_ASYNC ON
Broker Enabled
When ‘‘Broker Enabled’’ is set to True, the database is configured for participation in a Service Broker
messaging system. When this is enabled in a new database, a new Service Broker identifier is created
and persisted in the database. If Service Broker is disabled and then re-enabled, the original identifier
will be used. For more information on Service Broker, see Chapter 19. To set it at the database level, the
following commands are used:
ALTER DATABASE AdventureWorks2008 SET DISABLE_BROKER
ALTER DATABASE AdventureWorks2008 SET ENABLE_BROKER
Close Cursor on Commit Enabled
When ‘‘Close Cursor on Commit Enabled’’ is set to True, cursors contained in a transaction will be closed
after the transaction has been committed or rolled back. When this setting is False, cursors will remain
open when the transaction is committed. However, rolling back a transaction will close any cursors
except those defined as INSENSITIVE or STATIC when set to False. To set it at the connection level or
database level, the following commands are used:
--Connection Settings
SET CURSOR_CLOSE_ON_COMMIT OFF
SET CURSOR_CLOSE_ON_COMMIT ON
--Database Options
143
Page 143
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
ALTER DATABASE AdventureWorks2008 SET CURSOR_CLOSE_ON_COMMIT OFF
ALTER DATABASE AdventureWorks2008 SET CURSOR_CLOSE_ON_COMMIT ON
Concatenate Null Yields Null
When a character string is concatenated with a NULL, it will return NULL when the ‘‘Concatenate Null
Yields Null’’ setting is True. When set to False, a character string concatenated with a NULL will
return the character string. To set it at the connection level or database level, the following commands
are used:
--Connection Settings
SET CONCAT_NULL_YIELDS_NULL OFF
SET CONCAT_NULL_YIELDS_NULL ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET CONCAT_NULL_YIELDS_NULL OFF
ALTER DATABASE AdventureWorks2008 SET CONCAT_NULL_YIELDS_NULL ON
The ‘‘Concatenate Null Yields Null’’ option is deprecated as of this version of SQL Server. In a future
version of SQL Server, the option will be set to ON and will not be allowed to be changed. If an application attempts to set the value to OFF, an error will be thrown. It is recommended that you avoid using
it in all new development work and make arrangements to update any applications that currently use it.
Cross-database Ownership Chaining Enabled
The ‘‘Cross-database Ownership Chaining Enabled’’ option is not settable in the Options dialog and only
indicates what the value is set to. When set to True, it indicates that the database can participate in a
cross-database ownership chain. This option is only recognized if the server level option is turned off. To
set it at the server level or database level, the following commands are used:
--Server Options
sp_configure ‘cross db ownership chaining’, 0 -- OFF
sp_configure ‘cross db ownership chaining’, 1 –- ON
RECONFIGURE
--Database Options
ALTER DATABASE AdventureWorks2008 SET DB_CHAINING OFF
ALTER DATABASE AdventureWorks2008 SET DB_CHAINING ON
Database Read-Only
The ‘‘Database Read-Only’’ option specifies that no modifications are allowed to the database when set
to True. Exclusive access to the database is required to set this option, except for the Master database. To
set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET READ_ONLY
ALTER DATABASE AdventureWorks2008 SET READ_WRITE
Database State
The ‘‘Database State’’ option is not configurable in the graphical interface, and, for the most part, is not
directly configurable at all. The exception is the ONLINE, OFFLINE, and EMERGENCY states. The ‘‘Database
144
11:47am
Page 144
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
State’’ will indicate different values based on what is occurring on the database. The following table
describes the various states the database can be in:
State
Description
ONLINE
The database is online and available. This will show up as the NORMAL
state.
OFFLINE
The database is unavailable. Databases are set offline by executing the
command ALTER DATABASE <DBName> SET OFFLINE. This can be done if the
database administrator wants to move a database file from one location
to another. In this case, the database would be set OFFLINE, then the
ALTER DATABASE <DBName> MODIFY FILE command would be executed,
followed by changing the database back to ONLINE.
RESTORING
One or more files are being restored. The database is unavailable.
RECOVERING
The database is being recovered. Except in the case of database
mirroring, this is a transient state that occurs during the automatic or
manual recovery process. The database is unavailable.
RECOVERY
PENDING
A database will be in this state if SQL Server encounters a
resource-related error during recovery. The database will be unavailable
until the database administrator resolves the resource error and allows
the recovery process to be completed.
SUSPECT
One or more database files have been marked as suspect because of a
data access or Read error. This may occur if a TORN PAGE has been
detected during database Read operations. If a database has been marked
as SUSPECT, the database is unavailable until the error has been resolved.
EMERGENCY
The database will be in this state when the database administrator has set
the status to EMERGENCY. In this state, the database is in single-user mode
and may be repaired or restored. If the database has been marked as
SUSPECT, this is the first step in correcting the problem, short of a
database restore. Only members of the sysadmin fixed server role can set
a database to the EMERGENCY state.
Date Correlation Optimization Enabled
When the ‘‘Date Correlation Optimization Enabled’’ option is set to True, it indicates that the Database
Engine will maintain date statistics between two tables with datetime columns joined by a foreign key
constraint to optimize queries between those two tables where the datetime field is a filter. To set it at
the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET DATE_CORRELATION_OPTIMIZATION OFF
ALTER DATABASE AdventureWorks2008 SET DATE_CORRELATION_OPTIMIZATION ON
Default Cursor
Unlike local and global variables whose scope is based on connections, cursors are always local to the
connection in which they are declared. When the ‘‘Default Cursor’’ option is set to Global, it specifies
145
Page 145
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
that a declared cursor can be referenced by any batch, stored procedure, or trigger executing on the
same connection. If set to Local, the cursor can only be referenced inside the batch, stored procedure,
or trigger in which the cursor was declared. To set it at the database level, the following commands
are used:
ALTER DATABASE AdventureWorks2008 SET CURSOR_DEFAULT LOCAL
ALTER DATABASE AdventureWorks2008 SET CURSOR_DEFAULT GLOBAL
Encryption Enabled
When the ‘‘Encryption Enabled’’ option is set to True, all data and log files will be encrypted. If a database
encryption key has not yet been created, trying to set this option will result in an error. See Chapter 6
for more information on ‘‘Transparent Data Encryption.’’ To set it at the database level, the following
commands are used:
ALTER DATABASE AdventureWorks2008 SET ENCRYPTION OFF
ALTER DATABASE AdventureWorks2008 SET ENCRYPTION ON
Honor Broker Priority
The ‘‘Honor Broker Priority’’ option is not configurable in SQL Server Management Studio and must be
changed through T-SQL script. When this option is turned on, SQL Server will honor priority levels for
Service Broker messages. For more information on Service Broker and message priority, see Chapter 19.
To set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET HONOR_BROKER_PRIORITY OFF
ALTER DATABASE AdventureWorks2008 SET HONOR_BROKER_PRIORITY ON
Numeric Round-Abort
When the ‘‘Numeric Round-Abort’’ option is set to True, it means that any numeric rounding that occurs
will generate an error. For example, if ‘‘Numeric Round-Abort’’ is set to True, the following code will
generate an error:
DECLARE @Num1 AS decimal(4,3)
SET @Num1 = 7.00004 / 2.84747
SELECT @Num1 AS Answer
RESULTS:
-----------------------------------------------------------------Msg 8115, Level 16, State 7, Line 2
Arithmetic overflow error converting numeric to data type numeric.
The error is caused because the decimal variable was declared with a scale of 3. Remember that the
scale specifies how many digits are supported to the right of the decimal place. To perform this calculation, SQL Server must round the number. If ‘‘Numeric Round-Abort’’ is set to False, this code will
succeed:
DECLARE @Num1 AS decimal(4,3)
SET @Num1 = 7.00004 / 2.84747
146
11:47am
Page 146
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
SELECT @Num1 AS Answer
RESULTS:
-----------------------------------------------------------------Answer
-------2.458
To set it at the connection level or database level, the following commands are used:
--Connection Settings
SET NUMERIC_ROUNDABORT OFF
SET NUMERIC_ROUNDABORT ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET NUMERIC_ROUNDABORT OFF
ALTER DATABASE AdventureWorks2008 SET NUMERIC_ROUNDABORT ON
Page Verify
The ‘‘Page Verify’’ option enables the database administrator to set different options for page Write
verification. The available options are Checksum, Torn_Page_Detection, and None. As far as performance
goes, the best option is None. However, with None set, pages corrupted during disk Write operations (or
by some other disk anomaly after the page is written to disk) will not be discovered.
With the Checksum option, SQL Server will calculate a checksum value and store it in the page header.
This checksum value is very much like the Cyclic Redundancy Check (CRC) values created when files
are written to disk by the operating system. When a data page is read from the disk, SQL Server will
re-calculate the checksum and compare it to the one stored in the page header. If the values match, the
page is good. If the values do not match, the page is considered corrupted, an error 823 will be raised,
and the database status is changed from ONLINE to SUSPECT.
In a typical configuration, only 512 bytes of data are written to the disk with each pass of the disk under
a Write head. Therefore, it takes 16 passes to write an 8-KB page. The Torn_Page_Detection option configures SQL Server to write an error bit in the page header at the end of every Write cycle. If the error
bit is absent when the page is later read, an error 823 is raised, and the database status is changed from
ONLINE to SUSPECT.
When SQL Server raises an 823 error, a record will be added to the suspect_pages table in the msdb
database. The record includes the database the error occurred in, the page ID, file ID, and various other
pieces of information that will be helpful to restore the page from a backup. This table will be updated
when the page is restored, but the records will not be removed. It is the database administrator’s job to
remove any records that are marked as restored or repaired.
Choosing an appropriate Page Verify setting depends on the degree of acceptable risk and CPU utilization. As mentioned earlier, the best option for performance is setting ‘‘Page Verify’’ to None, but this
setting exposes your database to the risk of undetected data corruption. The Checksum option offers
the best protection from undetected corruption because any modification to the data on disk during
or after data Write operations will be detected by the checksum verification. However, the Checksum
147
Page 147
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
option costs the most CPU cycles. The Torn_Page_Detection option is a lower-cost method of detecting
corrupted pages, but it will only detect page corruption that occurs during the Write operation. The recommended setting is Checksum because of its high degree of data integrity verification. To set it at the
database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET PAGE_VERIFY NONE
ALTER DATABASE AdventureWorks2008 SET PAGE_VERIFY TORN_PAGE_DETECTION
ALTER DATABASE AdventureWorks2008 SET PAGE_VERIFY CHECKSUM
Parameterization
‘‘Parameterization’’ is a very interesting but advanced option that was introduced in SQL Server 2005.
By default, the Database Engine auto-parameterizes some queries so the query plans that are created
and compiled can be reused even when different values are defined in the WHERE clause. For example,
consider this code:
USE AdventureWorks2008
GO
SELECT * FROM Person.Person
WHERE LastName = N’Smith’
If you type this code in a Query window and then click on the ‘‘Display Estimated Execution’’ button on
the SQL Editor toolbar, you will find that the Database Engine compiles the query with the search criteria
of LastName = N‘Smith’ (see Figure 5-8) when the ‘‘Parameterization’’ option is set to Simple. This is
because SQL Server decides which queries to parameterize and which ones not to when Simple is set. For
this particular query, it determines that it is not worth the extra cost.
Figure 5-8: Simple parameterization.
When the option is set to Force, SQL Server will parameterize all queries that can be parameterized,
and the same query will result in a parameterized query plan instead (see Figure 5-9). Forcing
auto-parameterization can improve performance in some instances, but careful monitoring should be
done to ensure that it doesn’t have a negative impact on performance.
148
11:47am
Page 148
Leiter c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-9: Forced parameterization.
To set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET PARAMETERIZATION SIMPLE
ALTER DATABASE AdventureWorks2008 SET PARAMETERIZATION FORCED
Quoted Identifiers Enabled
By default, SQL Server uses square brackets (‘‘[ ]’’) to delimit objects. Delimiting objects is only required
if the object name contains an embedded space or a reserved word. The ANSI standard delimiter is the
double quotation marks. The following examples show how to create and reference an object with an
embedded space with both square brackets and double quotation marks.
Following is an example for the ANSI double quote delimiter:
USE AdventureWorks2008
GO
CREATE TABLE "Sales.USA Customers"
( AcctNumber int IDENTITY(1,1) NOT NULL
, "Last Name" varchar(75) NOT NULL
, "First Name" varchar(75) NOT NULL)
SELECT AcctNumber, "Last Name", "First Name"
FROM "Sales.USA Customers"
Following is an example of the default square bracket delimiter:
USE AdventureWorks2008
GO
CREATE TABLE [Sales.USA Customers]
( AcctNumber int IDENTITY(1,1) NOT NULL
, [Last Name] varchar(75) NOT NULL
149
Page 149
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
, [First Name] varchar(75) NOT NULL)
SELECT AcctNumber, [Last Name], [First Name]
FROM [Sales.USA Customers]
When the ‘‘Quoted Identifiers’’ option is True, both square brackets and double quotation marks are
accepted. If the ‘‘Quoted Identifiers’’ option is set to False, only square bracket delimiters will be
accepted. To set this option at the connection level or database level, the following commands are used:
--Connection Settings
SET QUOTED_IDENTIFIER OFF
SET QUOTED_IDENTIFIER ON
--Database Options
ALTER DATABASE AdventureWorks2008 SET QUOTED_IDENTIFIER OFF
ALTER DATABASE AdventureWorks2008 SET QUOTED_IDENTIFIER ON
On a completely editorial note, I personally believe that embedded spaces in object names are wrong and
should never be used. They typically introduce nothing but problems to your database and application
design for the negligible benefit of a natural language name.
Recursive Triggers Enabled
Recursive triggers are considered an advanced programming technique that allows the same trigger to
fire more than once, in sequence, in the same transaction. When set to False, this action is not allowed
and is the default configuration. Generally it is a good idea to leave this set to False. Recursive logic is
difficult at best to debug and can lead to many headaches. Almost all of the time, recursive logic can be
rewritten as non-recursive logic. To set it at the database level, the following commands are used:
ALTER DATABASE AdventureWorks2008 SET RECURSIVE_TRIGGERS OFF
ALTER DATABASE AdventureWorks2008 SET RECURSIVE_TRIGGERS ON
Restrict Access
The ‘‘Restrict Access’’ option enables the database administrator to restrict access to a database
to a defined set of logins. The default value of this option is MULTI_USER, which allows multiple
non-privileged users to access the database. Two other options exist to restrict access: SINGLE_USER and
RESTRICTED_USER.
When the SINGLE_USER ‘‘Restrict Access’’ option is set, only one user account is allowed access to the
database at a time.
If the RESTRICTED_USER ‘‘Restrict Access’’ option is set, only members of the db_owner, dbcreator, or
sysadmin roles can connect to the database. To set it at the database level, the following commands are
used:
ALTER DATABASE AdventureWorks2008 SET MULTI_USER
ALTER DATABASE AdventureWorks2008 SET RESTRICTED_USER
ALTER DATABASE AdventureWorks2008 SET SINGLE_USER
Service Broker Identifier
The ‘‘Service Broker Identifier’’ option is not configurable in SQL Server Management Studio and cannot
be set directly. The Service Broker Identifier is created the first time the database is enabled to use Service
150
11:47am
Page 150
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Broker and is used to uniquely identify the database in a messaging infrastructure. See Chapter 19 for
more information on Service Broker.
Trustworthy
The ‘‘Trustworthy’’ setting cannot be set through SQL Server Management Studio. The ‘‘Trustworthy’’
option indicates whether or not the instance of SQL Server trusts the database to access external or network resources. If this is set to False, database programming components created with managed code,
or database components that need to execute within the context of a highly privileged user, are not
allowed access to any resource external to the database. When one of those two situations is required,
the ‘‘Trustworthy’’ option can be set to True. To set it at the database level, the following commands
are used:
ALTER DATABASE AdventureWorks2008 SET TRUSTWORTHY OFF
ALTER DATABASE AdventureWorks2008 SET TRUSTWORTHY ON
VarDecimal Storage Format Enabled
The ‘‘VarDecimal Storage Format Enabled’’ feature was first introduced in Service Pack 2 for SQL Server
2005 and is now deprecated in SQL Server 2008. Row and Page Compression, new features of SQL Server
2008, replace this functionality and are discussed later in the chapter. For SQL Server 2008, it is turned on
and cannot be turned off.
Generating Database Creation Scripts
Now that you have gone through all the steps and options of creating a database, let’s take a look at how
you can script this process so that you don’t have to go through it again.
At the top of the New Database dialog is a button called Script, as shown in Figure 5-10.
Figure 5-10: Script button.
Click the down arrow to the right of Script, and it will expose the scripting options available. If you have
followed along with the last few pages, then clicking any of the Script Action options will generate a
script that will duplicate all the settings you specified in the graphical interface. This script can then be
used to create new databases with the same options simply by changing the logical and physical names of
the database and associated files. The Script Action options are also great for exploring the actual syntax
151
Page 151
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
for creating or modifying database objects. Almost every configuration screen for creating or modifying
database objects includes the Script Action option.
Another option for reusing scripts is to replace the actual names of objects and files with variables. Then
all you have to do is update the variable values and execute the script. The only tricky part in creating
Data Definition Language (DDL) scripts is having to use dynamic SQL because variables can’t be used
directly in a DDL script. The following example demonstrates how to use dynamic SQL to create a new
database with a user-defined filegroup marked as the default:
DECLARE @DatabaseName AS nvarchar(255)
DECLARE @FileGroupName AS nvarchar(255)
SET @DatabaseName = N’SlateGravel’
SET @FileGroupName = N’UserData’
EXECUTE (
’CREATE DATABASE ‘ + @DatabaseName +
’ ON PRIMARY
( NAME = ‘’’ + @DatabaseName + ‘’’
, FILENAME = ‘’S:\SQLDataFiles\’ + @DatabaseName + ‘_data.mdf"
, SIZE = 20MB
, MAXSIZE = 100MB
, FILEGROWTH = 30%)
, FILEGROUP UserData
( NAME = ‘’’ + @FileGroupName + ‘’’
, FILENAME = ‘’S:\SQLDataFiles\’ + @DatabaseName + ‘_data.ndf’’
, SIZE = 2048KB , FILEGROWTH = 20%)
LOG ON
( NAME = ‘" + @DatabaseName + ‘_log’’
, FILENAME = ‘’T:\SQLLogFiles\’ + @DatabaseName + ‘_log.ldf’’
, SIZE = 100MB
, FILEGROWTH = 20%);
ALTER DATABASE ‘ + @DatabaseName +
’ MODIFY FILEGROUP ‘ + @FileGroupName + ‘ DEFAULT’)
This script assumes the presence of an ‘‘S’’ drive, ‘‘T’’ drive, a SQLDataFiles folder, and a SQLLogFiles
folder. To run it in your environment, you may have to change the drive letter assignments and folder
names.
Schemas
SQL Server 2008 implements the database schema as defined in the ANSI standard. Almost every object
in SQL Server 2008 exists within a defined schema. A schema is simply a way to organize your database
objects and assign permissions to the objects it contains. The schema itself can be owned by any database
principal including database roles and application roles while containing many objects owned by various users. Within the schema, objects cannot have duplicate names. However, objects can have the
same name if they exist in different schemas. For example, if a table called Inventory is created in the
schema Sales on the server AughtEight, its name becomes AughtEight.Sales.Inventory. An additional table called Inventory can still be created in the Marketing schema, and its name would be
AughtEight.Marketing.Inventory. Although this is possible, it is not a good idea, in my opinion, as
it can lead to confusion for anybody new to the database and may produce unexpected results from
queries later on. Where schemas really become powerful is in the ability to form a security scope that can
152
11:47am
Page 152
Leiter c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
be used by the database administrator to control access to all objects within the schema. This is covered
in detail in Chapter 6.
In SQL Server 2008, a database principal is assigned ownership of a schema, and that schema owns the
constituent objects such as tables, views, stored procedures, and functions. If a user who owns a schema
needs to be deleted, ownership of that schema will have to be assigned to a different user first. The easiest
solution is to have the dbo user own all the schemas. The dbo user is a built-in user that is mapped to any
member of the fixed server role sysadmin. The dbo user always exists and cannot be dropped, so it is a
perfect candidate for schema ownership. For more information about the dbo user, fixed server roles, and
SQL Server 2008 security, see Chapter 6.
Schemas and Name Resolution
Because schemas are just containers for objects, it is important to set the context of object references when
calling on database objects in SQL Server 2008. Every user is assigned a default schema. When he or she
logs in to a SQL Server and calls on database objects, this default schema will play a distinct role in how
the objects must be referenced.
For example, assume that a user named FredF is created in the AdventureWorks2008 database and
assigned the default schema of Sales. If FredF logs in and executes the query SELECT * FROM CreditCard,
the CreditCard table will be resolved to AdventureWorks2008.Sales.CreditCard because Fred’s default
schema is Sales. The Sales.CreditCard table exists, and so the contents of the CreditCard table will be
returned.
If FredF executes the query SELECT * FROM Person, the table Person will be resolved to
AdventureWorks2008.Sales.Person, a table that does not exist. Because SQL Server is unable to
find the Person table in FredF’s default schema, it will default to the dbo schema and look for the
AdventureWorks2008.dbo.Person table, again with no success. SQL Server will then return the error:
"Invalid object name".
Schema Creation
To create a schema, the only required information is the name of the schema. The ownership of the
schema defaults to the user who runs the creation script, but any valid database user can be specified as
the owner. The simplest approach is to designate dbo as the owner of the schema, but there are situations
in which it may be desirable to designate a regular user as the owner. The syntax and an example of the
CREATE SCHEMA statement are as follows:
CREATE SCHEMA Schema_Name [ AUTHORIZATION owner ]
USE AdventureWorks2008
GO
CREATE SCHEMA Operations AUTHORIZATION dbo
Any schema-scoped statements that follow the CREATE SCHEMA statement will fall into the scope of the
schema just created, as the following example illustrates:
USE AdventureWorks2008
GO
CREATE SCHEMA Operations AUTHORIZATION dbo
CREATE TABLE DeliveryDriver
153
Page 153
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
(DriverID int IDENTITY NOT NULL
,LName varchar(75) NOT NULL
,FName varchar(75) NOT NULL)
GRANT SELECT ON DeliveryDriver TO FredF
Even though the schema was not specified in the CREATE TABLE statement, this script places the
DeliveryDriver table into the Operations schema. Even the GRANT SELECT statement succeeds,
although the schema was not designated in the statement it defaulted to the Operations schema,
because the CREATE SCHEMA statement set the scope of the schema for all remaining statements in the
batch. If the script is changed slightly so that the GRANT SELECT statement is in a different batch, the
GRANT SELECT will fail.
CREATE SCHEMA Operations AUTHORIZATION dbo
CREATE TABLE DeliveryDriver
(DriverID int IDENTITY NOT NULL
,LName varchar(75) NOT NULL
,FName varchar(75) NOT NULL)
GO
GRANT SELECT ON DeliveryDriver TO FredF
-------------------------------------------------------------------------Msg 15151, Level 16, State 1, Line 1
Cannot find the object ‘DeliveryDriver’, because it does not exist or you do
not have permission.
The GO keyword placed the GRANT SELECT statement outside the batch that created the schema, and thus
the execution context reverted to that of the user executing the script. As a best practice, the schema of an
object should always be specified to avoid any unexpected results.
CREATE SCHEMA Operations AUTHORIZATION dbo
CREATE TABLE Operations.DeliveryDriver
(DriverID int IDENTITY NOT NULL
,LName varchar(75) NOT NULL
,FName varchar(75) NOT NULL)
GRANT SELECT ON Operations.DeliveryDriver TO FredF
Remember that schema scope resolution always starts at the user’s default schema and will revert to the
dbo schema if a referenced object is not scope-qualified.
Schema Maintenance
As a precaution if you attempt to drop a schema that contains objects, an error will be generated as shown
in the following example:
DROP SCHEMA Operations
-------------------------------------------------------------------------Msg 3729, Level 16, State 1, Line 1
154
11:47am
Page 154
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Cannot drop schema ‘Operations’ because it is being referenced by object
’DeliveryDriver’.
If the object in the schema is still required, it can be transferred to a different schema with the
ALTER SCHEMA statement:
ALTER SCHEMA Production TRANSFER Operations.DeliveryDriver
This example alters the schema Production by moving the table DeliveryDriver from the Operations
schema to the Production schema. Because that was the last object in the schema, it can now be dropped.
Be advised, however, that transferring an object from one schema to another clears any permissions set
on the object.
A user who owns a schema cannot be dropped from the database, which is one of the reasons why
you may decide to have the dbo user own all schemas. To change the ownership of a schema, the
AUTHORIZATION property of the schema is altered. The following example changes the ownership of
the Operations schema to FredF:
ALTER AUTHORIZATION ON SCHEMA::Operations TO FredF
Tables
SQL Server 2008, like all relational database management systems, stores data in objects called tables. As
mentioned in Chapter 1, it is assumed in this book that you are at least familiar with relational database
concepts, so I won’t spend much time explaining what a table is or how to create them. What is pertinent
to the SQL Server 2008 database administrator is how to maintain and secure tables to optimize the
performance and security of the database. Security is discussed in detail in Chapter 6, so for this chapter,
the discussion is limited to the maintenance of data tables, but first a little background information is
required.
Table Collation
As discussed earlier in this chapter, when creating a database, collation support can be configured that is
different from that of the server. This is also true for table columns that contain character data. Each column can be defined with a different collation setting. For example, the AdventureWorks Cycles company
wants to enable customers from all over the world to browse and search the product catalog in their own
languages. To enable this functionality, a GlobalProductDescription table is built with the following
script:
USE AdventureWorks2008
GO
CREATE TABLE Production.GlobalProductDescription(
ProductDescriptionID int IDENTITY(1,1) NOT NULL,
EnglishDescription nvarchar(400) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
FrenchDescription nvarchar(400) COLLATE French_CI_AS NULL,
ChineseDescription nvarchar(400) COLLATE Chinese_PRC_CI_AI NULL,
ArabicDescription nvarchar(400) COLLATE Arabic_CI_AS NULL,
HebrewDescription nvarchar(400) COLLATE Hebrew_CI_AS NULL,
ThaiDescription nvarchar(400) COLLATE Thai_CI_AS NULL,
ModifiedDate datetime NOT NULL)
155
Page 155
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Each column is now sorted and searchable using the native language collation settings as defined in
the business requirement. Now, don’t let me mislead you. SQL Server definitely is not some kind of
universal translator. SQL Server just provides the framework for storing multiple languages. You will
have to arrange for the proper translation of the descriptions and place them in the appropriate columns,
and handle any collation incompatibilities that arise because of tempdb’s collation. For more information
on collation, see Chapter 2.
Table Architecture
As discussed in Chapter 4, SQL Server uses 8-KB data pages to store information. All data within a table
is stored within these data pages, but how the data on the pages is organized will differ depending on
how you create the table and what you do with it after creation. By default, all data will be stored in an
unorganized manner formally called a heap. SQL Server makes no attempt to keep the data organized or
sorted in any way and maintains no links between the pages. The following code creates a table that is
stored in such a way:
CREATE TABLE Employee(
EmployeeId int IDENTITY,
FirstName nvarchar(25) NOT NULL,
MiddleName nvarchar(25) NULL,
LastName nvarchar(25) NOT NULL,
HireDate smalldatetime
)
Although this arrangement works great for adding data to a table, it is less than an optimum solution
when trying to find a particular row or set of rows in a table. Think of a library. If you managed a library
that put all the books on shelves as they came in with no regard to genre, author, or title, it would take
very little effort to shelve the books as they came in. However, when it came time to find a particular
book, you would be forced to scan through all the shelves looking for the one book you wanted. This is
exactly how SQL Server works when it is looking for a record in a heap. Later on in the chapter, we will
take a look at indexes and see how they can help with this problem, but first, let’s look at how breaking
up the table into smaller chunks can help.
Partitioning Tables
SQL Server physically stores all data pages in logical units called partitions. Unless specifically separated,
tables are stored in a single partition defined on a single filegroup. However, SQL Server provides the
ability to separate large tables into smaller manageable units by horizontally partitioning the tables across
multiple files managed by filegroup definitions.
The Table Partitioning feature is available only in the Enterprise and Developer editions of SQL Server
2008.
For example, a transaction table with millions of rows can be physically partitioned so that all the transactions for the current year are separated from those for previous years. This way, only a subset of the
table will need to be scanned to select, insert, or update current-year transactions.
To illustrate the advantages of physical table partitioning and demonstrate how to implement them,
you must first build a table that is a candidate for partitioning. Using the following script, create the
dbo.Transactions table that will hold your test data. The Transaction table has the same basic structure
as the Production.TransactionHistory and Production.TransactionHistoryArchive tables.
156
11:47am
Page 156
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
USE AdventureWorks2008
GO
CREATE TABLE dbo.Transactions(
TransactionID int NOT NULL,
ProductID int NOT NULL,
ReferenceOrderID int NOT NULL,
ReferenceOrderLineID int NOT NULL,
TransactionDate datetime NOT NULL,
TransactionType nchar(1) NOT NULL,
Quantity int NOT NULL,
ActualCost money NOT NULL,
ModifiedDate datetime NOT NULL)
To populate the new Transactions table, insert all the rows from the TransactionHistory and
TransactionHistoryArchive tables by using a UNION operator:
USE AdventureWorks2008
GO
INSERT dbo.Transactions
SELECT * FROM Production.TransactionHistory
UNION ALL
SELECT * FROM Production.TransactionHistoryArchive
Now that you have a nice-size table to work with, run a query against it to see the performance before
partitioning. The table contains a total of 202,696 rows. Of the transaction rows in the table, 12,711 took
place in 2001, 38,300 in 2002, 81,086 in 2003, and 70,599 took place in 2004.
--Pre Partition Statistics
USE AdventureWorks2008
GO
DBCC DROPCLEANBUFFERS
SET STATISTICS IO ON
DECLARE @BeginDate AS datetime, @EndDate AS datetime
SET @BeginDate = ‘2002-01-01’
SET @EndDate = ‘2002-12-31’
SELECT SUM(Quantity) AS TotalQuantity, SUM(ActualCost) AS TotalCost
FROM dbo.Transactions
WHERE TransactionDate BETWEEN @BeginDate AND @EndDate
The script uses the DBCC DROPCLEANBUFFERS command to clear all pages from the buffer cache. This will
allow us to see how many physical Reads are required to bring all needed data into memory. It also turns
on statistic reporting with the SET STATISTICS IO ON option and then queries the dbo.Transactions table
to return the total sales amount and total quantity of products sold in 2002.
The results of the query are as follows:
TotalQuantity TotalCost
------------- --------------------1472494
16427929.3028
(1 row(s) affected)
Table ‘Transactions’. Scan count 1, logical reads 1408, physical reads 26, readahead reads 1407, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
157
Page 157
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
In order to see the results as shown above, you must have the results of the query displayed as text. You
can do this by pressing [Ctrl]+T prior to running the query. To switch back to grid view, press [Ctrl]+D
and re-run the query.
As you can see, to satisfy the query, SQL Server had to scan the table. To find the 38,300 rows that met
the criteria of the WHERE clause, SQL Server had to scan through 202,696 rows. This scan resulted in 1,408
logical reads.
Now, let’s see what happens when you physically divide the table into multiple files by partitioning the
table so that all the transactions are divided by year.
In a perfect world, you would know that you wanted to physically partition a table before you ever
populated it with data, but perfect worlds are rare. In this case, you have decided to physically partition
the Transactions table after it has been built. Since the data is stored in a heap, you are forced to create a
new partitioned table and move the data to it, and then drop the original table. (I will show you a much
easier way to accomplish this later in the chapter.)
The first step in partitioning the table is to create the filegroups that will hold the data files to be used to
store the partitions of the table. Remember from the previous discussion on filegroups that tables cannot
be assigned to a particular file, only to a filegroup. In this example, each filegroup will contain only one
file. This is by no means a requirement. Partitions can be defined to exist on a single file or multiple
files.
The following script adds four new filegroups with one file per filegroup to contain the partitioned transaction table. As the names suggest, you will be partitioning the Transactions table
by date:
USE MASTER
GO
ALTER DATABASE AdventureWorks2008
ADD FILEGROUP FGPre2002
GO
ALTER DATABASE AdventureWorks2008
ADD FILE
( NAME = ‘AworksPre2002’
, FILENAME = ‘E:\SQLData\AworksPre2002.ndf’
, SIZE = 20MB
, FILEGROWTH = 20% )
TO FILEGROUP FGPre2002
GO
ALTER DATABASE AdventureWorks2008
ADD FILEGROUP FG2002
GO
ALTER DATABASE AdventureWorks2008
ADD FILE
( NAME = ‘Aworks2002’
, FILENAME = ‘E:\SQLData\Aworks2002.ndf’
, SIZE = 20MB
, FILEGROWTH = 20% )
TO FILEGROUP FG2002
GO
ALTER DATABASE AdventureWorks2008
158
11:47am
Page 158
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
ADD FILEGROUP FG2003
GO
ALTER DATABASE AdventureWorks2008
ADD FILE
( NAME = ‘Aworks2003’
, FILENAME = ‘E:\SQLData\Aworks2003.ndf’
, SIZE = 20MB
, FILEGROWTH = 20% )
TO FILEGROUP FG2003
GO
ALTER DATABASE AdventureWorks2008
ADD FILEGROUP FG2004AndAfter
GO
ALTER DATABASE AdventureWorks2008
ADD FILE
( NAME = ‘Aworks2004AndAfter’
, FILENAME = ‘E:\SQLData\Aworks2004AndAfter.ndf’
, SIZE = 20MB
, FILEGROWTH = 20% )
TO FILEGROUP FG2004AndAfter
GO
This script assumes the presence of an ‘‘E’’ drive and a SQLData folder. To run it in your environment,
you may have to change the drive letter assignment.
The next step in partitioning the Transactions table is to create a partition function. Partition functions
determine the boundaries for each partition. You must specify what data type the function will work
with during creation. All data types are valid with the exception of alias data types, CLR types, or any of
the following: text, ntext, image, xml, timestamp, varchar(max), nvarchar(max), or varbinary(max).
For example, the partition function will specify what the ranges of values are (as in 1 through 100,000,
100,001 through 1,000,000, etc.). Keep in mind that when specifying a partitioning function, you can only
partition on a single value.
In this example, all data is partitioned by date in order to group together the data in accordance to the
most frequent queries run against the table. Run the following script to create a partition function that
partitions a table into four groups of dated records. The first group is from NULL to 12/31/2001. The
second group is from 1/1/2002 to 12/31/2002. The third group is from 1/1/2003 to 12/31/2003, and the
last group is from 1/1/2004 to INFINITY.
CREATE PARTITION FUNCTION YearFunction (datetime)
AS RANGE RIGHT FOR VALUES (’1/1/2002’,’1/1/2003’,’1/1/2004’)
When creating a partition function, the option RANGE RIGHT or RANGE LEFT can be used. This is used to
determine which partition the row will be stored in if the value the table is partitioned on is equal to the
boundary value. For example, if you use RANGE LEFT and the value is equal to the boundary value, then
the row would be stored in the partition to the left of the boundary. If you were to use the RANGE RIGHT
partition function created in the previous script and insert a transaction into your table with a transaction
date of 1/1/2003, then the record would be placed into the third group.
Once the function is created to define the boundaries used for partitioning, a partition scheme must be
created. A partition scheme is used to determine where the partitions are physically stored. When defining
159
Page 159
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
the partition scheme, you must specify the same number of filegroups as partitions that are defined by the
partition function. Run the following script to create a partition scheme that maps the partitions created
by the YearFunction to the filegroups that you created earlier:
CREATE PARTITION SCHEME YearScheme
AS PARTITION YearFunction
TO (FGPre2002, FG2002, FG2003, FG2004AndAfter)
If you wanted to partition the table but store all of the partitions on the same filegroup, you have two
choices: You could repeat the filegroup name for each partition or use the ALL TO option with a single
filegroup, for example, ALL TO ([PRIMARY]).
You can also specify one additional filegroup following the last one. This filegroup is marked as the
‘‘next’’ filegroup to be used if another partition is created.
All that is left to do now is to create the actual partitioned table and move the data from the original
Transactions table into it:
USE AdventureWorks2008
GO
CREATE TABLE dbo.PartitionedTransactions(
TransactionID int NOT NULL,
ProductID int NOT NULL,
ReferenceOrderID int NOT NULL,
ReferenceOrderLineID int NOT NULL,
TransactionDate datetime NOT NULL,
TransactionType nchar(1) NOT NULL,
Quantity int NOT NULL,
ActualCost money NOT NULL,
ModifiedDate datetime NOT NULL)
ON YearScheme(TransactionDate)
GO
INSERT INTO dbo.PartitionedTransactions
SELECT * FROM dbo.Transactions
When creating partition functions and partition schemes, remember that they can be used to partition
as many tables as needed. The YearFunction and YearScheme can be used to partition any table in the
AdventureWorks2008 database that has a datetime column in it.
To see if you have improved the performance of your query, run the same query that you ran before on
the Transactions table:
--Post Partition Statistics
DBCC DROPCLEANBUFFERS
SET STATISTICS IO ON
SELECT SUM(Quantity) AS TotalQuantity, SUM(ActualCost) AS TotalCost
FROM dbo.PartitionedTransactions
WHERE TransactionDate BETWEEN ‘1-1-2002’ AND ‘12-31-2002’
The results of the query are as follows:
TotalQuantity TotalCost
160
11:47am
Page 160
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
------------- --------------------1472494
16427929.3028
(1 row(s) affected)
Table ‘PartitionedTransactions’. Scan count 1, logical reads 266, physical reads 5,
read-ahead reads 259, lob logical reads 0, lob physical reads 0, lob read-ahead
reads 0.
Now that the table is physically partitioned, the logical Reads required to retrieve the results have gone
from 1,408 to 266. The decrease in I/O cost will also cause a decrease in CPU cost, resulting in a much
more efficient query. Keep in mind that the savings in performance are on a table with only 202,696 rows.
Imagine the savings if the table contained 10 years of data comprising millions of rows and the partitions
were defined on each year. The savings when querying a specific year would be much more dramatic.
Although creating partitioned tables was available in SQL Server 2005, the only way to do it was with
code. I don’t have a problem with writing scripts every once and awhile, but if I can use the GUI to write it
for me, I am all over it. SQL Server Management Studio now has the ability to not only create partitioned
tables, but also to generate the script for it so that you could run it on any server. Another benefit is that it
could perform the operation in place so that you don’t have to worry about creating a new table and moving the data into it. Let’s walk through the process of partitioning the Production.TransactionHistory
table in the AdventureWorks2008 database.
If you were following along with the last section, you will need to drop the table, partition function, and
partition scheme in order to do the next section. The following script will accomplish this for you:
IF
EXISTS (SELECT * FROM sys.tables WHERE object_id =
OBJECT_ID(’dbo.PartitionedTransactions’))
DROP TABLE dbo.PartitionedTransactions
IF
EXISTS
(SELECT * FROM sys.partition_schemes WHERE Name = ‘YearScheme’)
DROP PARTITION SCHEME YearScheme
IF
EXISTS
(SELECT * FROM sys.partition_functions WHERE Name = ‘YearFunction’)
DROP PARTITION FUNCTION YearFunction
To partition a table from SQL Server Management Studio, right-click on the table you wish to partition,
select Storage, and then ‘‘Create Partition,’’ as shown in Figure 5-11.
Figure 5-11: Creating a partition using Management Studio.
Use the ‘‘Select Partitioning Column’’ page to identify the column upon which the table will be partitioned (see Figure 5-12). As mentioned earlier, only certain data types are valid for the partitioning
column, and the Wizard will only show you columns that are of valid types. In this case, we are going to
choose the TransactionDate column.
161
Page 161
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Figure 5-12: Select a Partitioning Column page.
After clicking Next, you will need to choose the partitioning function that you would like to use (see
Figure 5-13). If you choose to use an existing function, you will only be able to choose a function that
can be used with the column that you selected in the previous page. If there are no partition functions
defined in the database for the data type of your selected column, then you will be have to create a new
one. Type a name for the new partition function, and click Next.
Now a partitioning scheme needs to be selected for the table (see Figure 5-14). If there is a partition
scheme available that has the correct number of filegroups defined for the choosen funtion then it can be
reused; otherwise, a new one will need to be created. Click Next to continue.
The Map Partitions page (see Figure 5-15) is used to define the boundaries of the partition function
and the mapping between the partitions and filegroups. If the partition column is a date, datetime,
smalldatetime, datetime2, or datetimeoffset, then the ‘‘Set boundaries’’ button will be enabled. This
allows a very quick way of defining the boundary points for the partition function by specifying the Start
Date, End Date, and the Date Range. You can create partitions that are broken up by Day, Month, Quarter,
Half-Year, or Year. Once the partitions are defined, they need to be mapped to the desired filegroups. The
filegroups must already exist and cannot be created at this point. When defining the mapping, the last
one will not map to a boundary point. The filegroup is not marked as the next filegroup but the filegroup
that the last partition is placed in. See Figure 5-16 for the completed dialog box.
You now have the option to create a script that will partition the table, do the partitioning immediately,
or schedule it for later execution (see Figure 5-17).
162
11:47am
Page 162
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-13: Select a Partition Function page.
Figure 5-14: Select a Partition Scheme page.
163
Page 163
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Figure 5-15: Map Partitions page.
Figure 5-16: Set Boundaries dialog.
Data Compression
SQL Server 2008 introduces the ability to compress data in tables, indexes, or partitions. This can save I/O
requests since more data on each page equals fewer pages to read into memory. Additionally, because
more data is stored on each data page, more data can be stored in the same amount of memory. The
combination of lower I/O and having more data in memory usually translates to increased performance.
Data compression is enabled using one of two different modes: row compression or page compression.
Row Compression
Row compression is a descendent of the vardecimal storage format introduced in SQL Server 2005 SP2.
Prior to the vardecimal storage format, decimals were stored in a fixed amount of space. The amount of
space that the decimal used was based on the scale defined for the column and took anywhere between
5 and 17 bytes. This often contributed to a lot of wasted space depending on the value. For example, if
164
11:47am
Page 164
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
you define a column as a decimal (15, 15), it would take 9 bytes of storage regardless of the value. With
vardecimal storage format enabled, only the absolute required space to represent the number is used.
This has been extended to all fixed length data types in SQL Server 2008.
Figure 5-17: Select an Output Option page.
Now that we have seen how SQL Server stores its data in tables and how we could improve performance by partitioning the data, let’s look at another way to improve the performance of retrieving
data — indexes.
Indexes
As noted previously, SQL Server tables are stored as heaps by default. In order for SQL Server to retrieve
any record from a heap, it must perform a full table scan; in other words, it must examine every record
to determine if it should be returned. As you are probably already thinking, this is an extremely inefficient way to retrieve data. Heaps work very well for storing data and are very efficient in handling new
records, but they are not so great when it comes to finding specific data in a table. This is where indexes
come in. SQL Server supports two basic types of indexes: clustered and non-clustered. Although there is
support for other index types such as XML and spatial indexes, which are discussed later in this chapter,
they are quite different from the regular relational indexes that will be used to locate the majority of the
data in database tables.
The key difference between clustered and non-clustered indexes is in the leaf level of the index. In
non-clustered indexes, the leaf level contains pointers to the data, whereas in a clustered index, the leaf
level of the index contains the actual data.
165
Page 165
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Clustered Indexes
All data that belongs to a table can be stored in either a heap or a clustered index. Heaps and clustered
indexes are thus mutually exclusive. As I mentioned earlier, a heap is an unorganized collection of table
rows, whereas a clustered index is a collection of organized table rows.
The white pages of the phone book are a perfect example of a clustered index. All the rows of the white
pages are clustered on the combination of last name and first name. When scanning the white pages
looking for a phone number, you are scanning both the index and the data. When the indexed value is
found, so is the rest of the pertinent data.
This is also true of SQL Server clustered indexes. Clustered indexes can be created to sort the data by
a particular attribute, or column, of the row. Going back to the library example, libraries organize most
of the books in a clustered index based on genre and/or topic, and then break that organization down
further by author. The clustered key must be unique within the index (this is to support non-clustered
indexes, as you will see shortly), but you do not have to mark the column as unique in order to create the
index. When clustered indexes are created on columns that are not marked as being unique, SQL Server
generates a hidden column that holds a 4-byte internal number called a uniqueifier to uniquely identify
duplicate clustered index keys. The leaf level of a clustered index is the actual data row, not just a pointer
to the data.
Non-Clustered Indexes
Non-clustered indexes are more like the indexes in the back of a book. When the indexed value is found,
you do not have the actual data row but a pointer that specifies the location of the actual data row. The
type of pointer that is included in the leaf level pages will depend on whether the non-clustered index is
built on top of a heap or a clustered index.
Non-Clustered Indexes on Heaps
When a non-clustered index is built on a table organized as a heap, the indexed column or columns are
sorted along with a pointer to the physical location of the data. The pointer is made up of the file ID, page
ID, and slot number that the data is located in. For example, if the data is the 20th record on page 84,593
in the first file, then the SQL would use 1:84593:20 for the value of the pointer. This allows SQL Server to
access the data quickly after finding it in the index.
For example, let’s go back to the library analogy. If the physical location of every book that came into this
unorganized library were recorded in an index as it was placed on the shelf, that index could be referenced to find the location of a book instead of scanning all the shelves. The downside of this technique
is that similar records (or, in the library analogy, similar books) could be located in completely different
places. For example, searching for books on SQL Server 2008 could return several books, each one located
at the opposite end of the library. Retrieving the books may take more effort than would be required if
all the SQL Server books were clustered together. In a simple one-column index built on a heap table, the
index itself is a great deal like a two-column table. The first column records the indexed value, and the
second column records the physical location of the row in which the indexed value can be found.
Non-Clustered Indexes on Clustered Indexes
When a non-clustered index is built on a clustered index, the pointer value in the index is the clustered
index key value for that row. Once the indexed value is located, SQL Server uses the clustered key to
navigate the clustered index to retrieve all required columns.
166
11:47am
Page 166
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
For example, in the phone book analogy, you learned that the white pages of the phone book are just like
a clustered index in SQL Server. I live in a small town southeast of Seattle, and my phone book contains
an interesting additional index just after the white pages. I call them the ‘‘slightly off-white pages.’’
These off-white pages contain every published phone number in town listed in sorted order, along with
the last name and first name of the phone number’s holder. This is a perfect example of a non-clustered
index built on a clustered index. The phone number can be used to discover the last name–first name
combination, and then the last name–first name combination can be used to find the address, if it is listed.
Whether to create a clustered index or leave the records in a heap is a design decision that is typically driven by how the data is accessed. When data from a table is primarily accessed by a predictable
attribute or column, then it may be useful to cluster the rows of the table on that specific column. However, if the column is based on a large data type, creating a clustered index on it will be costly as far as
storage and index maintenance.
Included Columns
The functionality of non-clustered indexes can be improved by adding non-key values to the leaf nodes
of the index. This allows the index to cover more queries, reducing the number of times the clustered
index needs to be traversed in order to retrieve additional values.
For example, imagine we have a table called Contacts that has a clustered index defined on the
ContactId column and a non-clustered index defined on the LastName column. The non-clustered
index leaf nodes will contain the index value and the clustered key. When a query that requires the
ContactId, FirstName, and LastName column is executed using the LastName as a predicate, the
non-clustered index on LastName will be used to locate the records but will only contain two of the
required columns, LastName and ContactId. SQL Server would then have to make a trip to the clustered
index to retrieve the value for the FirstName for each record found. Repeated trips to the clustered index
can be eliminated by designing the index as a covered index.
Typically, a covered index is an index that contains all data needed to satisfy the query. One approach
used by DBAs is to create a non-clustered index on both the LastName and FirstName columns. This
would place the values to both the LastName and FirstName columns (since these are the index keys) and
the ContactId in the leaf nodes. If a query only needing these three columns is executed, a trip to the
clustered index would not be necessary. This approach is fine except the index size could grow quickly
since all columns that participate in the index are included on all levels of the index. Also, the index needs
to be sorted on both columns, which could cause performance problems trying to keep it this way during
updates.
Included columns allow us to increase query coverage without incurring the overhead of composite index
keys. Columns that are marked as ‘‘included’’ in the index only appear in the leaf nodes of the index and
are not considered in the ordering of the rows. To include columns in the leaf nodes, you use the INCLUDE
option of the CREATE INDEX command. The following command creates an index on the LastName column
and includes the FirstName column of the Person.Person table in AdventureWorks2008:
CREATE NONCLUSTERED INDEX IX_Person_LastName
ON Person.Person(LastName)
INCLUDE(FirstName)
Filtered Indexes
A filtered index is simply an optimized non-clustered index. It allows the creation of an index over a
subset of the data keeping the index structure smaller, resulting in a decrease of the amount of time
167
Page 167
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
required to build the index and reducing index maintenance costs. Filtered indexes are particularly
useful for indexes on columns that contain a high percentage of NULL values or columns that contain
ranges of data such as dollar amounts. To create a filtered index, simply include a WHERE clause with
the CREATE INDEX statement. The following code creates an index over all products that cost more than
$800.00.
CREATE NONCLUSTERED INDEX IX_ListPrice_Product
ON Production.Product(ListPrice)
WHERE ListPrice > 800.00;
Hierarchal Indexes
As discussed in Chapter 4, HierarchyId is one of the new data types introduced in SQL Server 2008. To
aid in the retrieval of hierarchal data, indexes can be built on columns of this type using two different
approaches: breadth-first or depth-first.
Breadth-First Indexes
Breadth-first indexes keep all the records that are within the same level grouped together. This allows SQL
Server to very quickly respond to queries where all records have a common parent. For example, all
records for employees who report to the IT Manager would be grouped together. The following code
creates a breadth-first index on the employee table:
-- Breadth-First
IF EXISTS (SELECT * FROM sys.indexes
WHERE Name = ‘IX_Employee_OrganizationLevel_OrganizationNode’)
DROP INDEX IX_Employee_OrganizationLevel_OrganizationNode
ON HumanResources.Employee
CREATE NONCLUSTERED INDEX IX_Employee_OrganizationLevel_OrganizationNode
ON HumanResources.Employee
(
OrganizationLevel,
OrganizationNode
)
Depth-First Indexes
Depth-first indexes keep all the records for a chain grouped together. This allows SQL Server to quickly
answer queries that are looking for a hierarchy. For example, say we need the record for Peter and all the
people that Peter reports to, up to the CEO.
To create a depth-first index, all you need to do is create an index on the HierarchyId column.
The following code creates a depth-first index on the employee table:
-- Depth-First
IF EXISTS (SELECT * FROM sys.indexes WHERE Name = ‘IX_Employee_OrganizationNode’)
DROP INDEX IX_Employee_OrganizationNode ON HumanResources.Employee
CREATE NONCLUSTERED INDEX IX_Employee_OrganizationNode
ON HumanResources.Employee
168
11:47am
Page 168
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
(
OrganizationNode
)
Spatial Indexes
SQL Server 2008 includes support for spatial data through two new CLR data types: geometry and
geography. The geometry data type is designed for planer (flat earth) space, while the geography data
type is used for geodetic (round earth) space. For more information on these data types, see Chapter 4.
A common operation on spatial data is to find all records that intersect with a given area. For example,
we need to find all stores that are within a 50-mile radius of a specific location and then sort them based
on distance. Finding the intersection of regions is an expensive operation especially on complex data
regions. If all the regions that have no chance of intersecting with the given region could be eliminated,
then the cost of finding the valid records could be substantially reduced. This is where spatial indexes
help.
The creation of a spatial index goes through two phases: decomposition and tessellation. During the
decomposition phase, SQL Server breaks down a finite area into a grid structure (think ‘‘Excel worksheet’’).
Each cell of the grid is then mapped onto another grid structure, forming a more detailed level. This
process continues until four levels are created. The grid in each level can be configured to be a 4 × 4,
8 × 8, or 16 × 16 cell grid. As you can see, the number of cells can grow very quickly. For example, if you
were to have a 16 × 16 cell grid in each level, you would end up with approximately 4 billion cells.
During the tessellation phase, each spatial value in the table is mapped onto each of the resulting grid
levels. SQL Server evaluates the cells that the value ‘‘touches’’ and records them into the actual spatial
index. The spatial index can then be used to locate objects in space relative to other objects that are also
stored in the index.
Many spatial indexes can be built on a single spatial data column, each covering an independent area of
space. Since a flat plane continues infinitely in all directions, when using the geometry (flat earth) data
type, a finite space must be specified by using the BOUNDING_BOX option. For example, we may only want
to index storage-location data for stores within the state of Washington. Conceptually, it is very similar to
a filtered index in that we are only indexing a subset of the data, but instead of providing a WHERE clause
to limit the records indexed, we provide a bounding rectangle.
XML Indexes
Another type of index supported in SQL Server 2008 is the XML index. SQL Server 2005 introduced the
ability to store native XML in tables, and with that comes the ability to build indexes on that XML to help
locate and retrieve specific data within the XML text. XML data is stored as a Binary Large Object (BLOB)
in the SQL Server database. To search for specific elements, attributes, or values in the XML document,
SQL Server must first open the BLOB and then shred its contents. The act of shredding is what SQL
Server does to create a collection of XML objects that it can then navigate. It essentially extracts the XML
data structure and stores it in temporary relational structures.
XML indexes, like their relational counterparts, come with some overhead, but XML index overhead is
more significant than regular indexes. For this reason, XML indexes should be reserved for columns in
which the XML data is seldom modified.
169
Page 169
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
It is typically much more efficient to have the database applications store and retrieve complete XML
documents, rather than inserting and modifying parts and pieces of the document, which results in
shredding. However, there are business cases that call for just this type of functionality, so the ability to
create XML indexes was included to avoid the necessity of shredding complete documents.
XML indexes are essentially pre-shredded sections of the XML data linked to the primary key of the table.
There are four types of XML indexes: The first XML index must be a primary XML index. In addition to
the primary index, three secondary indexes can be created that build on the primary. Each additional
index type will improve XML query performance for certain types of queries, but will also adversely
affect XML data modification.
Primary XML Indexes
The primary XML index really isn’t built on the XML column itself but, rather, is a clustered index that
is built on an internal table that is created during the index creation process. This internal table is known
as the node table. The node table is directly linked to the clustered index of the table where the XML
index is being created. To create an XML index, the table with the XML column must have a clustered
index on its primary key. The node table is used to support the primary XML index but is not directly
accessible, although information about it can be exposed using system views. The primary XML index
stores a relational representation of the XML field and assists the Query Optimizer in creating efficient
query plans to extract data from an XML field. An example of the syntax to create a primary XML index
is as follows:
USE AdventureWorks2008
GO
CREATE PRIMARY XML INDEX XML_IX_Illustration
ON Production.Illustration (Diagram)
Primary XML indexes can also be graphically created in Management Studio. To create a new set of XML
indexes, first create a table to use. To create a copy of the Person.Person table that contains an XML
column, execute the following code, which creates the MyContact table and then creates a clustered index
on the primary key, which is required to create XML indexes:
USE AdventureWorks2008
GO
SELECT * INTO dbo.MyPerson FROM Person.Person
GO
ALTER TABLE dbo.MyPerson
ADD CONSTRAINT PK_MyPerson_BusinessEntityId
PRIMARY KEY CLUSTERED (BusinessEntityId)
Now that you have a table to play with, expand the AdventureWorks2008 database in Object Explorer,
expand Tables, and then expand the dbo.MyPerson table.
You may have to refresh the Tables node to get the MyPerson table to appear.
Right-click on the MyPerson table and click Design. The table structure will appear to the right of the
Object Explorer, and the Table Designer toolbar will appear.
Click on the AdditionalContactInfo column, and then click on the ‘‘Manage XML Indexes’’ button on
the Table Designer toolbar (see Figure 5-18). If the Table Designer toolbar is not visible, select it on the
View Toolbars menu.
170
11:47am
Page 170
Leiter c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-18: ‘‘Manage XML Indexes’’
button.
On the XML Indexes dialog (see Figure 5-19), click Add and then change the name of the new primary
XML index to PXML_MyPerson_AdditionalContactInfo, and give it a short description such as ‘‘Primary
XML Index.’’
Figure 5-19: XML Indexes configuration.
Notice that the ‘‘Is Primary’’ property is set to Yes and cannot be changed. This is because this is the first
XML index, and the first XML index created on an XML column must be a primary XML index.
Primary XML indexes can also be created through the New Index dialog by right-clicking on the Indexes
node under the Table node in Object Explorer, clicking ‘‘New Index,’’ and then choosing ‘‘Primary XML’’
from the list in the ‘‘Index type’’ dropdown box, as shown in Figure 5-20. However, secondary indexes
cannot be created this way.
Secondary XML PATH Indexes
XML PATH indexes can improve the performance of XML queries that specify path expressions against the
XML column. For example, if you use queries that check for the existence of an XQuery expression such
as /Invoice/LineItem[@ProductID="9834"], then a PATH secondary index may improve performance.
PATH secondary indexes (like all other secondary XML indexes) are built on the nodes provided by the
primary XML index. An example of the syntax to create a secondary PATH index is as follows:
USE AdventureWorks2008
GO
CREATE XML INDEX IXML_MyPerson_AdditionalContactInfo_Path
ON dbo.MyPerson(AdditionalContactInfo)
171
Page 171
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
USING XML INDEX PXML_MyPerson_AdditionalContactInfo
FOR PATH
Figure 5-20: New Index dialog.
Creating secondary indexes graphically is the same as creating the primary index, except that the secondary index type can now be chosen from the Secondary Type dropdown list. To create a Secondary
XML index, click on the Add button again on the XML Indexes configuration window. Now that a Primary XML index has been added, the next index type defaults to Secondary, the Is Primary property is
set to No, and a new Secondary Type dropdown list appears (see Figure 5-21).
To commit the changes to the table and actually create the indexes, the table must be saved after closing
the XML Indexes configuration window.
Secondary XML VALUE Indexes
XML VALUE indexes are designed to support XML queries where the path is not fully specified, or
where a value is being searched by a wildcard. For example, if you are trying to retrieve all LineItem
nodes that are for Product Id 9834 regardless of which invoice it belongs to using the XQuery such as
172
11:47am
Page 172
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
//LineItem[@ProductID="9834"], then a VALUE index may improve performance. An example of the
syntax for creating a secondary VALUE index is as follows:
CREATE XML INDEX IXML_MyPerson_AdditionalContactInfo_Value
ON dbo.MyPerson(AdditionalContactInfo)
USING XML INDEX PXML_MyPerson_AdditionalContactInfo
FOR VALUE
Figure 5-21: Secondary XML Indexes configuration.
Secondary XML PROPERTY Indexes
XML PROPERTY indexes are used to optimize queries that retrieve the value of nodes specifying
full paths to the nodes. For example, if you are trying to return the Product ID for the first LineItem
node in the document using an XQuery such as (/Invoice/LineItem/@ProductID)[1], then a PROPERTY
index may improve performance. An example of the syntax for creating a secondary PROPERTY index is
as follows:
CREATE XML INDEX IXML_MyPerson_AdditionalContactInfo_Property
ON dbo.MyPerson(AdditionalContactInfo)
USING XML INDEX PXML_MyPerson_AdditionalContactInfo
FOR PROPERTY
Maintaining Tables
Now that you have a better idea of how the data is organized in tables and explored ways to optimize
retrieving the data, we need to look at maintaining this environment. Table maintenance can be classified
into two basic categories:
❑
The maintenance of indexes
❑
The creation and maintenance of index statistics
173
Page 173
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Index Fragmentation
One of the leading causes of poor query performance is poorly maintained indexes. As indexes are
updated, they can become fragmented. This occurs because indexes are a collection of contiguous, sorted
data. To maintain the sorted order of indexes, SQL Server must split full data pages to make room for
more data.
For example, extent 72 (see Figure 5-22) contains a clustered index defined on the LastName column of
the fictitious Slate.Employee table. Each data page in the extent is completely full.
The code in the following example is shown for illustration purposes only and is not intended to be
executed.
Extent 72
Page 110
Desai
Desalvo
Dewer
D'Hers
Diaz
Dickmann
Dickson
Dievendorff
Page 111
Dillon
Dixon
Dobney
Dockter
Dodd
Dominguez
Donovan
Earls
Page 112
Eaton
Ecoffey
Edwards
Eldridge
Ellerbrock
Elliott
Elson
Emanuel
Page 113
Faeber
Ferrier
Fine
Finley
Flood
Flores
Fluegel
Focht
Page 114
Friske
Frum
Fuentes Espino
Fulton
Funk
Gaffney
Gage
Gallagher
Page 115
Galos
Galvin
Ganio
Gao
Garcia
Garden
Garza
Gash
Page 116
Gates
Gee
Gehring
Geist
German
Getzinger
Giakoumakis
Gibbens
Page 117
Groth
Gubbels
Guo
Gupta
Gustafson
Gutierrez
Guzik
Haemon
Figure 5-22: Full data pages.
The following batch is executed to insert a new row in to the Slate.Employee table:
INSERT Slate.Employee
(LastName, FirstName, Title, EmailAddress, Phone, ModifiedDate)
VALUES
(’Flintstone’,’Fred’,’Mr.’,’[email protected]’,’123-456-7890’,GETDATE())
An immediate page split occurs. This is because there is no room on the data page for a new record. To
maintain the order of the rows, SQL Server splits Page 113 and moves approximately 50 percent of the
rows to a new unallocated data page (see Figure 5-23).
As a result of this page split, when SQL Server reads the data pages to retrieve the contents of the
Slate.Employee table, it will have to switch from Extent 72 to Extent 119, and then back to Extent 72
again to continue the scanning of rows. After many more employees are added, additional page splits
will occur. These page splits cause index fragmentation. The fragmentation of the indexes will eventually cause SQL Server to perform an excessive number of Reads to retrieve data, resulting in poor query
performance.
To check for fragmentation on all the indexes of a table or specific indexes, the dynamic management
function sys.dm_db_index_physical_stats is used. This function returns a great deal of information about the indexes on a table, including the amount of data on each data page, the amount of
fragmentation at the leaf and non-leaf levels of the indexes, and the average size of records in an
index.
174
11:47am
Page 174
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
When querying this table-value function, I am most interested in the fragmentation level and the average
percentage that each page is full. The fragmentation level will let me know which indexes need to be
rebuilt, and the average percentage that each page is full tells me how soon I can expect more page splits
to occur. To query the sys.dm_db_index_physical_stats dynamic management view, the following
syntax can be used:
SELECT {* | column list} FROM
sys.dm_db_index_physical_stats
({database_id | NULL}
,{object_id | NULL}
,{index_id | NULL}
,{partition_number | NULL
,{mode | NULL | DEFAULT}
Extent 72
Page 110
Desai
Desalvo
Dewer
D'Hers
Diaz
Dickmann
Dickson
Dievendorff
Page 111
Dillon
Dixon
Dobney
Dockter
Dodd
Dominguez
Donovan
Earls
Page 112
Eaton
Ecoffey
Edwards
Eldridge
Ellerbrock
Elliott
Elson
Emanuel
Page 113
Faeber
Ferrier
Fine
Finley
Page 114
Friske
Frum
Fuentes Espino
Fulton
Funk
Gaffney
Gage
Gallagher
Page 115
Galos
Galvin
Ganio
Gao
Garcia
Garden
Garza
Gash
Page 116
Gates
Gee
Gehring
Geist
German
Getzinger
Giakoumakis
Gibbens
Page 117
Groth
Gubbels
Guo
Gupta
Gustafson
Gutierrez
Guzik
Haemon
Page ...
Page ...
Page ...
Page ...
Page ...
Page ...
Page ...
Page 495
Yukish
Yvkoff
Zabokritski
Zare
Zeman
Zeng
Zhang
Zhao
Page 496
Flintstone
Flood
Flores
Fluegel
Focht
Page 497
Page 498
Page 499
Page 500
Page 501
Extent 73-118
Page ...
Extent 119
Page 494
Yee
Yonekura
Yong
Young
Youtsey
Yu
Yuan
Yuhasz
Figure 5-23: Splitting Page 113.
As the syntax indicates, the sys.dm_db_index_physical_stats function requires five parameters to be
passed to it when retrieving index information. The following table describes the parameters:
175
Page 175
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Parameter
Description
database_id
The integer ID value assigned by SQL Server to the database. If this is
unknown, the output of the DB_ID() function can be passed. For example,
the value DB_ID(AdventureWorks2008) can be provided in lieu of the integer. If NULL is passed, the information for all indexes in all databases will
be returned. If NULL is specified, you must also specify NULL for object_id,
index_id, and partition_number.
object_id
The integer ID value for the table hosting the indexes to be examined. If the
object_id value is unknown, the output of the OBJECT_ID() function can
be passed. For example, the value OBJECT_ID(’Person.Person’) can be provided. If NULL is passed, the information for all tables will be returned. If NULL
is provided for object_id, you must also specify NULL for the index_id and
partition_number.
index_id
The integer value of the index on the table. If NULL is passed, the information
for all indexes will be returned. If NULL is provided as the value, you must also
specify NULL for partition_number. Finding the value of index_id requires
querying the sys.indexes catalog view. For example, finding the name and
index_id for all the indexes on the Person.Person table would require the following query:
USE AdventureWorks2008
GO
SELECT name, index_id
FROM sys.indexes
WHERE object_id = OBJECT_ID(’Person.Person’)
partition_
number
If the index is partitioned then this is the integer value for the partition. Indexes
that are not partitioned have a partition number of 1. Because partitions can be
stored on separate physical files, their fragmentation can be different on each
partition. If NULL is provided as the value for partition_number, all partitions
will be returned. To discover the partition_numbers for an index, the following query can be used:
USE AdventureWorks2008
GO
SELECT *
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID(’Person.Person’)
mode
Mode specifies what level of index analysis is performed and has only three
valid options: LIMITED, SAMPLED, or DETAILED, with LIMITED being the default.
The LIMITED mode is the fastest, but it only scans the index pages above the
leaf level, which makes it the least accurate.
The SAMPLED mode samples only 1 percent of the data pages to return the analysis information. If there are fewer than 10,000 pages, SQL Server will use
DETAILED instead.
The DETAILED mode scans all pages.
176
11:47am
Page 176
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
To practice examining and maintaining indexes, run the following command to create the MyPersons
table that is used in the next few examples:
USE AdventureWorks2008
GO
SELECT BusinessEntityId, LastName, FirstName, Title, ModifiedDate
INTO dbo.MyPersons
FROM Person.Person
CREATE CLUSTERED INDEX IX_MyPersons_LastName ON dbo.MyPersons(LastName)
To query the sys.dm_db_index_physical_stats view to return all the possible data in relation to the
MyPersons table, the following query can be used:
DECLARE @dbID smallint, @objectID int
SET @DbID = DB_ID(’AdventureWorks2008’)
SET @ObjectID = OBJECT_ID(’dbo.MyPersons’)
SELECT *
FROM sys.dm_db_index_physical_stats(@DbID, @ObjectID, NULL, NULL , ‘DETAILED’)
However, running this query returns more information than is generally needed. Because I am more
particularly interested in just the fragmentation of the leaf level of the index and the fill percentage of
the data pages, I can limit the amount of data returned. The reason that I am less concerned about the
non-leaf level is that the non-leaf level is typically very small. It can, indeed, get very fragmented, but
the fragmentation of the non-leaf level of the index does not have anywhere near as much impact on
performance as leaf-level fragmentation.
To reduce the information returned by the sys.dm_db_index_physical_stats query, it can be limited to
just the columns of interest and the leaf level of the index, as follows:
DECLARE @dbID smallint, @objectID int
SET @DbID = DB_ID(’AdventureWorks2008’)
SET @ObjectID = OBJECT_ID(’dbo.MyPersons’)
SELECT index_id, avg_fragmentation_in_percent, avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(@DbID, @ObjectID, NULL, NULL , ‘DETAILED’)
WHERE index_level = 0
Results:
index_id
avg_fragmentation_in_percent
avg_page_space_used_in_percent
----------------------------------1
0
-----------------------------98.9983815171732
This query only returns the fragmentation level and page space used for the leaf level of all the indexes,
which is where the worst fragmentation (as far as performance is concerned) will occur.
The precise definition of fragmentation as a measurement is the percentage of pages where the next
physical page is not the next logical page, as shown in Figure 5-24.
177
Page 177
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Extent 72
Page 110
Desai
Desalvo
Dewer
D'Hers
Diaz
Page 111
Dickmann
Dickson
Dievendorff
Dillon
Dixon
Page 112
Dobney
Dockter
Dodd
Dominguez
Donovan
Page 113
Earls
Eaton
Ecoffey
Edwards
Eldridge
Page 114
Ellerbrock
Elliott
Elson
Emanuel
Faeber
Page 115
Ferrier
Fine
Finley
Flood
Flores
Page 116
Fluegel
Focht
Friske
Frum
Fuentes
Page 117
Fulton
Funk
Gaffney
Gage
Gallagher
Figure 5-24: Impact of filling the data pages.
The MyPersons table contains 19,972 rows. Now, insert some more records in the MyPersons table. The
following script inserts 3,994 additional records, which constitutes a 20 percent increase in rows:
INSERT dbo.MyPersons
(BusinessEntityId, LastName, FirstName, Title, ModifiedDate)
SELECT BusinessEntityId, LastName, FirstName, Title, ModifiedDate
FROM Person.Person WHERE BusinessEntityId % 5 = 4
Querying the sys.dm_db_index_physical_stats dynamic management view now returns some very
interesting data:
DECLARE @dbID smallint, @objectID int
SET @DbID = DB_ID(’AdventureWorks2008’)
SET @ObjectID = OBJECT_ID(’dbo.MyPersons’)
SELECT index_id, avg_fragmentation_in_percent, avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(@DbID, @ObjectID, NULL, NULL , ‘DETAILED’)
WHERE index_level = 0
RESULTS:
-----------------------------------------------------------------------------index_id
avg_fragmentation_in_percent
avg_page_space_used_in_percent
---------------------------------------------------------------1
97.8571428571428
59.4185322461082
Because of the additional rows that have been added to the MyPersons table, almost 97 percent of the
time when SQL Server was reading the data pages, the next physical page was not the next logical page.
In addition to the fragmentation, the data pages are now only 59 percent full.
The combination of the fragmented indexes and the partially filled data pages causes SQL Server
to read 274 logical extents, when only about 40 logical extent Reads should have been required.
This information is available through a deprecated Database Console Command (DBCC) command
called DBCC SHOWCONTIG. DBCC SHOWCONTIG will be removed in a future release of SQL Server,
but for now, see what it tells you about the MyPersons table:
USE AdventureWorks2008
GO
178
11:47am
Page 178
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
DBCC SHOWCONTIG(’dbo.MyPersons’)
RESULTS:
------------------------------------------------------------------------------ Pages Scanned................................: 280
- Extents Scanned..............................: 38
- Extent Switches..............................: 274
- Avg. Pages per Extent........................: 7.4
- Scan Density [Best Count:Actual Count].......: 12.73% [35:275]
- Logical Scan Fragmentation ..................: 97.86%
- Extent Scan Fragmentation ...................: 13.16%
- Avg. Bytes Free per Page.....................: 3284.7
- Avg. Page Density (full).....................: 59.42%
Although historically, DBCC has been known to stand for Database Consistency Checker, many
DBCC commands now go beyond just checking database consistency. For this reason, DBCC can also be
used to as an acronym for Database Console Command.
The DBCC SHOWCONTIG command shows you that SQL Server scanned 38 extents to retrieve all the data in
the MyPersons table, but to scan those 38 extents, it had to switch between them 274 times!
It has already been established that SQL Server uses indexes to quickly find rows in data pages for
reading, updating, or deleting. However, if all you ever did was insert data in tables, you would not
need an index. The general rule is that indexes help Read performance and hurt insert performance.
Here is an analogy and a confession.
I am a home-improvement organizational slob. I am just incapable of putting things back where they
belong. As a result, when I am finished with a particular home project, I invariably grab all the tools I
have used and throw them on my workbench. Putting stuff away never takes me very long. However, as
I start the next project, I invariably spend a huge amount of time just trying to find my hammer. Out of
desperation, I sometimes just go buy another one. The home-improvement stores love me. If I just spent
the extra time required to put things back where they belong, I could save time and money.
The same goes for databases. Planning and building indexes take time and effort; so does maintaining the
indexes once they are built. However, even the most insert- and update-intensive database can usually be
found to perform five Reads for every Write. That means that maintaining indexes at peak performance
is going to pay off fivefold. With that firmly in mind, take a look at how to mitigate index fragmentation
and correct it once it has occurred.
Mitigating Fragmentation with Fill-Factor
To mitigate fragmentation caused by page splits, the database administrator can design or rebuild the
indexes so that data pages are not completely filled. This option is called the fill-factor. When building or
rebuilding the index, a fill-factor percentage can be specified. If an index page is only filled 90 percent of
the way, it will take more inserts to the index to cause page splits and thus longer for fragmentation to
occur. With the previous example, take a look at what impact filling the data pages to 90 percent would
have (see Figure 5-24).
As you can see, now that the data pages are not completely full, adding additional contacts will not cause
the pages to split as quickly. The fill-factor is only effective when the indexes are built or rebuilt. After a
few inserts, the indexes will again fill and page splits will occur. However, the page splits will not occur
immediately, and the amount of time between index rebuilds can be lengthened.
179
Page 179
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Only filling the index pages partially does have its drawbacks, as you knew it would. First, because the
pages are not completely full, the amount of disk space needed to store the index will increase. Also,
since there is less data on each page, the number of reads required to retrieve the data will increase. As
a result, there is a definite point of decreasing returns when setting a fill-factor. I personally believe that
the fill-factor of indexes should rarely be less than 90 percent. On heavily updated and queried tables,
this percentage might go as low as 85 percent, but keep in mind that at an 85 percent fill-factor, SQL
Server will have to perform 15 percent more Reads than is strictly required to retrieve the records at a
100 percent fill-factor. As a result, a 10 percent fragmentation level may have about the same effect as a
90 percent fill-factor.
Removing Fragmentation
There are three ways to remove fragmentation: The indexes can be dropped and re-created, rebuilt
in place, or reorganized. Each method has its advantages and disadvantages. The drop and re-create
option is used with the CREATE INDEX command. The rebuild and reorganize options are used with the
ALTER INDEX command. Let’s take a look at how to use each of these approaches.
Create Index with Drop Existing
The main advantage of dropping and re-creating an index is that almost everything about the index can
be changed. For example, the columns that the index is defined on can be changed, the FILLFACTOR of the
index can be modified, or the index can be changed from a non-clustered index to a clustered index as
long as a clustered index does not already exist. However, when using the DROP_EXISTING option with
the CREATE INDEX command, a specific index must be specified. When using the rebuild or reorganize
options of the ALTER INDEX command, all the indexes on a table can be processed at once.
Rebuilding an index with the DROP_EXISTING option removes index fragmentation by rebuilding all the
index pages in indexed order. It also compacts the index pages so that empty space created by page splits
is filled. Both the leaf level and the non-leaf level of the indexes are rebuilt.
The following is an example of the syntax for dropping and re-creating an index with the CREATE INDEX
command:
CREATE UNIQUE CLUSTERED INDEX PK_Address_AddressID
ON Person.Address(AddressID)
WITH (FILLFACTOR = 90, DROP_EXISTING = ON)
Rebuilding Indexes
When an index is rebuilt using the ALTER INDEX command, SQL Server actually drops and re-creates the
index much like the CREATE INDEX command. The difference is that the columns of the existing index cannot be changed, nor can the type of index. However, the FILLFACTOR can be modified. It is also possible
to execute the command only once and have it rebuild all the indexes on that table.
Another very useful feature is the ONLINE option. If ONLINE is on, SQL Server will not place any long-term
locks on the table being indexed, resulting in a much lower impact on user performance. In order to do
this, SQL Server leverages the tempdb database for index creation and maintenance. Indexes are created
or rebuilt in the tempdb database and then moved to the appropriate database. This decreases the impact
on users in the database, but it can cause unanticipated growth of the tempdb database. The ONLINE index
option is only available with the Enterprise and Developer editions of SQL Server.
Like the DROP_EXISTING option, the REBUILD option of ALTER INDEX rebuilds both the leaf and non-leaf
levels of the index.
180
11:47am
Page 180
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
The following is an example of rebuilding an individual index and then all the indexes on a table with a
FILLFACTOR of 90 percent and the ONLINE option on:
USE AdventureWorks2008
GO
ALTER INDEX AK_Product_ProductNumber ON Person.Product
REBUILD WITH (FILLFACTOR=90,ONLINE=ON)
USE AdventureWorks2008
GO
ALTER INDEX ALL ON Person.Product
REBUILD WITH (FILLFACTOR=90,ONLINE=ON)
Reorganizing Indexes
Reorganizing indexes consumes the least amount of system resources, but doesn’t do as thorough a job
as an index rebuild. When SQL Server reorganizes an index, it rearranges and compacts the data pages
so that their logical order matches their physical order. Index reorganization only affects the leaf level of
the index and is always performed online.
The guideline on when to perform index reorganization versus when to perform a rebuild is the 30 percent fragmentation level. If the level of fragmentation is less than or equal to 30 percent, a reorganization
will take less time than an index rebuild and consume much fewer system resources. If the fragmentation
is greater than 30 percent, index reorganization will most likely take longer than a rebuild, but it will still
consume fewer resources.
In general, if the indexes are rebuilt periodically with an appropriate FILLFACTOR, the need for index
reorganization between those periods is reduced. However, intervals of high transaction activity may
necessitate an intervening reorganization to prevent fragmentation from exceeding 30 percent and potentially causing performance issues.
Statistics
Statistics are used by SQL Server to find the most efficient means of retrieving data from database tables
by storing information about the selectivity of data in a column, as well as the distribution of data in a
column. They can be created manually and automatically. Chapter 10 describes statistics in greater detail.
Enforcing Data Integrity
As mentioned in previous chapters, the assumption of this book is that you are at least marginally familiar with database theory, so I will not expound on the purpose of constraints to maintain data integrity.
Instead, what is covered in this section is how to create these constraints, as well as other database objects
that are used to maintain the integrity and consistency of data.
Primary Key Constraints
A table can have one and only one primary key constraint. This value is the one that is used to uniquely
identify every row in the table. A primary key constraint can be defined on either a single column or
a combination of columns if it takes more than one column to uniquely identify each row. It is critical
181
Page 181
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
that you understand how SQL Server enforces uniqueness of the key values specified in a primary key
definition. It does so by creating a unique index on the column or columns participating in the key.
It would be very inefficient to try to enforce uniqueness without sorting the data. The problem with
SQL Server in this respect is that it defaults to a unique clustered index if a clustered index does not
already exist. Decisions on which column or columns participate in a primary key and which ones define
the physical structuring of the table’s data are completely different. It should not be assumed that the
primary key should also be the table’s cluster key. Remember that all the table’s non-clustered indexes
will include the clustered index key as the pointer back to the data row. If the primary key length is large,
using a clustered index to support the primary key could prove to be very detrimental to non-clustered
index storage and retrieval.
Primary keys can be created by selecting the column or columns in the Table Designer window and
then clicking on the ‘‘Set Primary Key’’ button on the Table Designer toolbar, or by using Transact-SQL
in a CREATE TABLE or ALTER TABLE command. The following are examples of setting a primary key
on tables during and after creation.
When using the CREATE TABLE statement, you can either define the constraint as part of the column
definition or at the end of all the column definitions as part of the table definition. The first example
shows how to create the primary key as part of the column definition of the CREATE TABLE command:
USE AdventureWorks2008
GO
CREATE TABLE dbo.CreditCards(
CreditCardID int IDENTITY(1,1) NOT NULL
CONSTRAINT PK_CreditCardID PRIMARY KEY NONCLUSTERED (CreditCardID),
CardType nvarchar(50) NOT NULL,
CardNumber nvarchar(25) NOT NULL,
ExpMonth tinyint NOT NULL,
ExpYear smallint NOT NULL,
ModifiedDate datetime NOT NULL)
This next example also creates a primary key constraint in the CREATE TABLE command, but does so as
part of the table definition at the end of all the column definitions:
CREATE TABLE dbo.CreditCards(
CreditCardID int IDENTITY(1,1) NOT NULL,
CardType nvarchar(50) NOT NULL,
CardNumber nvarchar(25) NOT NULL,
ExpMonth tinyint NOT NULL,
ExpYear smallint NOT NULL,
ModifiedDate datetime NOT NULL,
CONSTRAINT PK_CreditCardID PRIMARY KEY NONCLUSTERED (CreditCardID))
In both cases, the CONSTRAINT keyword and name for the constraint are optional. If the name is omitted, SQL Server will assign a system-generated name. I recommend that you provide a name for all
constraints since this is what will be displayed within SQL Server Management Studio and in any error
message generated by SQL Server, and a friendlier name could prove to be helpful. The name that you
choose must be unique within the scheme that contains the table.
182
11:47am
Page 182
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
The last example shows how to add a primary key constraint to an already existing table by using the
ALTER TABLE command:
ALTER TABLE dbo.CreditCards
ADD CONSTRAINT PK_CreditCardID PRIMARY KEY NONCLUSTERED (CreditCardID)
In addition, remember that if the NONCLUSTERED keyword is omitted, SQL Server will create a clustered
index to enforce the key if one is not already defined. Be sure this is what was intended as it is a common
mistake.
Unique Constraints
Whereas only one primary key constraint is allowed on a table, many unique constraints can be specified.
For example, a delivery company that employs drivers may want to record information about its drivers
in a table like the following example:
CREATE TABLE dbo.Driver(
DriverID int IDENTITY(1,1) NOT NULL
CONSTRAINT PK_DriverId PRIMARY KEY CLUSTERED,
LastName varchar(75) NOT NULL,
FirstName varchar(75) NOT NULL,
MiddleInitial varchar(3) NULL,
SocSecNum char(9) NOT NULL,
LicenseNum varchar(25) NOT NULL)
In this example, the employer would probably want to ensure that both the Social Security number and
the driver’s license number were unique in addition to the primary key. You may be thinking, ‘‘Why
don’t we just use the Social Security number or driver’s license number as the primary key?’’ There are
many reasons why these columns are not good candidates for a primary key.
When it comes to the Social Security number, security can be a big issue. Because most primary keys
are used as foreign keys, the Social Security number would be duplicated in several places. Given the
sensitivity placed on private information, this would become a management nightmare. Another reason
applies to both the Social Security number and the driver’s license number. Because both these numbers
are not numbers at all, but rather strings of characters, they are not the best values to use to enforce
referential integrity, because the join criteria would be large instead of a more efficient integer value.
One other thing to think about is whether the values are unique after all. Social Security numbers can be
reused, and you may end up with problems. This usually only occurs if you plan to keep your data for a
very long time, but it does happen.
To create a unique constraint, you have two choices: Create a unique index or create a unique constraint
on the table. A unique index behaves like a unique constraint, and SQL Server will create a unique
index to enforce the unique constraint. It is almost a case of ‘‘What comes first: the chicken or the egg?’’
However, there is a difference — albeit a small one. If you create a unique constraint, the only way to
drop the unique index is to remove the constraint. You will not be able to use the DROP INDEX command.
To create unique indexes or constraints graphically, first open the table for modification by right-clicking
on the table name and clicking Design.
183
Page 183
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
On the Table Designer toolbar, click on the ‘‘Manage Indexes and Keys’’ button (see Figure 5-25).
Figure 5-25: ‘‘Manage Indexes and Keys’’
button.
On the Indexes/Keys dialog (see Figure 5-26), click Add and then specify the properties of the new index
or key. Notice in the Type property that either Index or Unique Key can be chosen. If the ‘‘Is Unique’’
property is set to True, then either Index or Unique Key will have the same effect.
Figure 5-26: Indexes/Keys dialog.
To enforce uniqueness on the LicenseNum column, one of the following commands can be used as they
will both have the same outcome:
ALTER TABLE dbo.Driver
ADD CONSTRAINT UX_LicenseNum UNIQUE NONCLUSTERED(LicenseNum)
CREATE UNIQUE NONCLUSTERED INDEX UX_LicenseNum
ON dbo.Driver(LicenseNum)
184
11:47am
Page 184
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Foreign Key Constraints
Foreign key constraints are created to guarantee referential integrity between tables. To create a foreign
key constraint on a table, the column or columns defined in the foreign key must map to a column or
columns in a primary key table, where the columns are designated as either the primary key or have a
unique constraint (both unique constraints and unique indexes qualify).
The following examples are based on the dbo.Driver table created earlier and the dbo.DriverRecord
table, which can be created with the following script:
CREATE TABLE dbo.DriverRecord(
RecordID int IDENTITY (1,1) NOT NULL PRIMARY KEY NONCLUSTERED,
DriverID int,
InfractionID int NOT NULL,
RecordDate datetime NOT NULL)
To create a foreign key constraint with the graphical tools, expand the DriverRecord table in Object
Explorer. Right-click on the Keys node and click ‘‘New Foreign Key.’’ The Foreign Key Relationships
dialog will display (see Figure 5-27).
Figure 5-27: Foreign Key Relationships dialog.
Click the ellipses to the right of the ‘‘Tables And Columns Specification’’ property to select the primary
key and foreign key columns.
In the resulting Tables and Columns dialog (see Figure 5-28), choose Driver as the primary key table and
DriverID as the column in both the Primary key and Foreign key tables as shown in Figure 5-28. Once
you close the Wizard and the Table Designer page, you should be able to see the newly created foreign
key under the Keys folder in the tree view. If you don’t, right click the DriverRecord table and select
Refresh.
185
Page 185
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Figure 5-28: Tables and Columns dialog.
Foreign Key Constraint Options
Foreign key constraints have several advanced options that change the way they behave during creation
and after creation that are described in the following sections. These options can be set in the General and
Table Designer sections of the Foreign Key Relationships dialog, or through Transact-SQL. Examples of
the code necessary to create foreign keys and set their options are given with each description.
The following examples all use the same constraint name. To execute the examples in succession, it will
be necessary to drop the existing constraint prior to re-creating it. Constraints can be deleted using
SQL Server Managements Studio’s Object Explorer or by executing the script ALTER TABLE dbo.
DriverRecord DROP CONSTRAINT FK_DriverRecord_Driver.
WITH CHECK
WITH CHECK is the default setting when adding a foreign key constraint. This setting specifies that any
existing data in the foreign key table should be validated to conform to the constraint:
ALTER TABLE dbo.DriverRecord WITH CHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
WITH NOCHECK
The WITH NOCHECK setting specifies that existing data is not validated to conform to the new constraint.
This option can make the creation process more efficient when you know that all existing data already
conforms to the constraint, but it is important to keep in mind that any non-conforming records will
be ignored during the creation. However, during subsequent updates to the non-conforming row, the
constraint will be enforced, resulting in an error.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
186
11:47am
Page 186
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Cascading Constraints
Foreign keys prevent the updating or deletion of parent values (primary or unique values) by default.
However, there are times when this is not desirable. SQL Server provides the option of specifying what
action is taken on the child records if a parent record is deleted or updated.
ON DELETE NO ACTION and ON UPDATE NO ACTION are the default settings for foreign keys. These settings
specify that any attempt to delete a row or update a key referenced by foreign keys in existing rows in
other tables will fail.
In addition to the default NO ACTION setting, the options CASCADE, SET NULL, and SET DEFAULT are possible,
which allow for deletions or updates of key values to cascade in a defined manner to the tables defined
to have foreign key relationships.
ON DELETE CASCADE
This option specifies that all child records will be deleted when the parent row is deleted. If the child
record also has child records, the foreign key options on those tables will be enforced and either cascade
or fail.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON DELETE CASCADE
ON UPDATE CASCADE
When a parent key is updated, the update will cascade to any child records that reference the parent
keys.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON UPDATE CASCADE
ON DELETE SET NULL
With this setting, any child record’s foreign key will be set to NULL if the parent row is deleted. The foreign
key column must allow nulls for this option to work.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON DELETE SET NULL
ON UPDATE SET NULL
Any child record’s foreign key will be set to NULL if the corresponding parent key is updated. The foreign
key column must allow nulls for this option to work.
187
Page 187
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON UPDATE SET NULL
ON DELETE SET DEFAULT
When a parent record is deleted, the corresponding child key value will be set to the value specified by
any DEFAULT constraint defined on that column. If no DEFAULT constraint exists, the value will be set to
NULL as long as the foreign key column is nullable. The value specified in the DEFAULT constraint must
have a corresponding row in the parent table.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON DELETE SET DEFAULT
ON UPDATE SET DEFAULT
When a parent key value is updated, any corresponding child records will be updated to the value
specified in the DEFAULT constraint defined on the foreign key column. Like the previous option, the
default value must exist in the parent table. If there is no DEFAULT defined and the foreign key column is
nullable, the child value will be set to NULL.
ALTER TABLE dbo.DriverRecord WITH NOCHECK
ADD CONSTRAINT FK_DriverRecord_Driver FOREIGN KEY (DriverID)
REFERENCES dbo.Driver (DriverID)
ON UPDATE SET DEFAULT
The various cascade settings can be combined and mixed. For example, the cascade option for a DELETE
can be set to CASCADE, but NO ACTION for an UPDATE.
Check Constraints
Check constraints are used to ensure that the data in a field conforms to a defined expression. The check
constraints can be created graphically by following these steps on the dbo.Driver table that was created
earlier:
1.
2.
Expand the dbo.Driver table in Object Explorer.
3.
In the Check Constraints dialog (see Figure 5-29), change the name of the constraint to
CK_DriverSocialSecurityNumber in the Identity section and change the description to
Enforce numeric values for SSN’s.
4.
Edit the expression for the constraint by typing in the following expression:
Right-click on the Constraints node and click ‘‘New Constraint.’’ This will launch the Check
Constraints dialog.
(SocSecNum LIKE ‘[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]’)
This expression ensures that any Social Security numbers added to the table will be nine contiguous
integers with no dashes. Validating a Social Security number (SSN) is far more complicated than this
188
11:47am
Page 188
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
makes it out to be. For example, the first three numbers of an SSN range only between 001 and 772, but
this would become very messy using a simple LIKE operator.
Notice that as you are working within either the Foreign Key Constraint or Check Constraint dialog
boxes (see Figure 5-29), there are no OK or Cancel buttons. If you open the dialog, a constraint
is automatically added for you, so if you decided not to add the constraint, you would actually
have to delete it before closing the dialog. Here is the Transact-SQL command to create the same
constraint:
ALTER TABLE dbo.Driver ADD CONSTRAINT
CK_DriverSocialSecurityNumber
CHECK (SocSecNum LIKE ‘[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]’)
GO
Figure 5-29: Check Constraints dialog.
Default Constraints
Default constraints specify a value to be inserted in a table if no value is specified during an insert.
They can be applied to a table when it is created or added afterwards. To create a default constraint
with the graphical tools, first select the column you want to apply the default to, and then specify
a default value or binding in the Column Properties window of the Table Designer, as shown in
Figure 5-30.
Bindings are links to a Database Default or Rule and are discussed later in the chapter.
For this example, specify the string ‘000000000’ as the default value for the SocSecNum column.
The Transact-SQL command for accomplishing this same task is as follows:
ALTER TABLE dbo.Driver ADD CONSTRAINT
DF_Driver_SocSecNum DEFAULT ‘000000000’ FOR SocSecNum
GO
189
Page 189
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Figure 5-30: Creating a default constraint.
Database Diagrams
Once the database and its objects have been created, it is often convenient to be able to create entity
relationship diagrams that are linked to the underlying structures. That way, any changes that must
be made (especially the creation of foreign key constraints) can be made and applied to the database
in a convenient graphical environment. The database diagram feature in SQL Server Management
Studio provides this functionality. The database diagram feature, however, is not a replacement for
full-fledged database design tools. It is more often used in the test and development phase of database
deployment.
The database diagram feature is accessed in Object Explorer of SQL Server Management Studio in the
individual database node. Before you can create your first database diagram, you will need to install the
diagram support objects. This can be done by right-clicking on the Database Diagrams node and selecting
‘‘Install Diagram Support.’’ If you don’t do this, then the first time you try to create a database diagram,
an informational message will display notifying you that ‘‘One or more support objects’’ are missing,
and asking whether or not you want to install them. Either installing the support objects or selecting
Yes will cause SQL Server to create a system-owned table called dbo.sysdiagrams that will contain the
definitions of all diagrams created.
The following steps will guide you through the creation and modification of a database diagram:
1.
190
Expand the Databases node and then the AdventureWorks2008 database node. Right-click on
the Database Diagrams node in AdventureWorks2008 and click ‘‘New Database Diagram.’’
The Database Diagram pane will appear, as well as an Add Table dialog that alphabetically
lists all the user tables in the database.
11:47am
Page 190
Leiter c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
2.
Select the Address(Person) table. Click Add to add the Person.Address table to the diagram and then click Close on the Add Table dialog. (You can also double-click on the table
in the list to add it to the diagram.)
3.
Right-click on the Address(Person) table and then click ‘‘Add Related Tables.’’ This causes
all tables that have a defined relationship to the Person.Address table to be added to the
diagram. This feature comes in handy when you are unfamiliar with the structure of the
database.
Notice that all the tables are just piled on top of each other in the diagram. You can manually reorder
them, or just right-click on an empty space on the diagram and click ‘‘Arrange Tables.’’ SQL Server
arranges the tables neatly on the diagram pane so that the tables and their relationships are easily viewed.
Because there is limited space in the diagram, you can create multiple diagrams that divide the database
into functional areas, or you can display page breaks on the diagram and divide a large diagram into
many pages. To display page breaks, right-click on an empty space on the diagram and click ‘‘View Page
Breaks.’’
Right-clicking on any table provides the option of changing the way the table is displayed on the diagram, deleting the table from the database, removing the table from the diagram, as well as several table
modification options normally available from the Table Designer toolbar.
Views
SQL Server 2008 views are simply saved queries that are named and can be managed independently of the
tables they reference. They are very much like the tables they reference, except that they are, by default,
logical objects and not physical objects. The one exception to this is when a unique clustered index is
created on a view, causing the view to be ‘‘materialized.’’ Views are typically created to abstract complex
database design, to simplify permissions by granting access to one view instead of multiple tables, and
to arrange data for export to other data stores.
The creation of views and other programming objects is unfortunately beyond the scope of this book.
For more information on how to create views and why to create views, check out Beginning T-SQL with
Microsoft SQL Server 2005 and 2008 by Paul Turley and Dan Wood (Wiley, 2008). For information about
securing views take a look at Chapter 6.
System Views
System views, as noted in Chapter 4, are the database administrator’s view of system objects. There are
too many system views to describe here, and most are documented in SQL Server 2008 Books Online.
System views can be divided into four categories:
❑
Information Schema Views — Information Schema views are pre-defined views that belong to
a special schema known as INFORMATION_SCHEMA. SQL Server 2008 implements the ISO standard
definition for the INFORMATION_SCHEMA and provides a consistent view of SQL Server metadata
that is generally stable from one release to another.
❑
Catalog Views — Catalog views are another method for retrieving metadata from SQL Server.
Because the catalog views represent the most general interface into metadata about SQL Server,
191
Page 191
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
it is recommended that you use these over the Information Schema views. They provide a
great deal of useful information that can be used in the troubleshooting and maintenance of
SQL Server 2008. If using them in permanent scripts, be sure to specify the columns by name.
Microsoft reserves the right to add additional columns to the end of the catalog views, which
could break existing code. In fact, this occurred in select catalog views between SQL Server 2005
and SQL Server 2008.
❑
Dynamic Management Views — Dynamic Management views return server state information
that can be used to monitor SQL Server processes, diagnose problems, and tune performance.
They are briefly described in Chapter 4.
❑
Compatibility Catalog Views — Because the system tables from SQL Server 2000 are no longer
available, SQL Server 2008 provides many views that carry the same name as the previous system tables. These views return only the features of SQL Server 2008 that are compatible with SQL
Server 2000 and are provided strictly for use with objects and scripts designed on SQL Server
2000. Future development work should use the new catalog views that return SQL Server 2008
specific information since these will be removed in a future release.
Synonyms
Synonyms are a means to give a name to a SQL Server schema-scoped database object that can be
used by database applications instead of its defined two-part, three-part, or four-part names. For
example, a database application that references a table on another server would typically need to use a
four-part name. Defining a synonym essentially presents an alias that maps directly to the table without
having to fully qualify the table. The following code will create a synonym called Products in the
AdventureWorks2008 database that references the dbo.DimProduct table in the AdventureWorksDW2008
database:
USE AdventureWorks2008
GO
CREATE SYNONYM dbo.Products
FOR AdventureWorksDW2008.dbo.DimProduct
GO
Now that you have a new synonym, open a new Query window and type in the following code:
USE AdventureWorks2008
GO
SELECT ProductKey, EnglishProductName, StandardCost
FROM dbo.Products
Notice that the query returns 606 rows from the AdventureWorksDW database without having to qualify
the object name, like the following example:
USE AdventureWorks2008
GO
SELECT ProductKey, EnglishProductName, StandardCost
FROM AdventureWorksDW2008.dbo.DimProduct
Synonyms can reference views, tables, stored procedures, and functions on any database, or a linked
server to simplify the application data access.
192
11:47am
Page 192
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Programming Objects
As previously noted, the creation and logic behind programming objects are beyond the scope of this
book, but the purpose of the objects and their basic use is pertinent. The database administrator needs to
understand how programming objects can affect the behavior of the database. The most important aspect
is typically security, which is addressed in Chapter 6.
Stored Procedures
A stored procedure is a named collection of Transact-SQL or managed code that is stored on the server
in a database. SQL Server stored procedures are very similar to procedures from other programming
languages in that they are used to encapsulate repetitive tasks. They support user-declared variables,
conditional execution, and many other programming features.
Stored procedures can be written in traditional Transact-SQL or in any .NET managed language such
as C# or VB.NET. Chapter 14 discusses the advantages of using managed code to create complex stored
procedures that would push the limits of Transact-SQL.
The major purpose of stored procedures is to encapsulate business functionality and create reusable
application logic. Because the stored procedures are stored on the server, changes to the business logic
can be accomplished in a single location.
Stored procedures also provide controlled modification of data in the database. Giving users permission
to modify data in database tables is typically a very bad idea. Instead, stored procedures can be created
that perform only the modifications that are required by the application. Users can then be given the
permission to execute the stored procedure to perform the required data modification.
User-created stored procedures can be more efficient than ad hoc Transact-SQL, and much more secure.
They also drastically reduce the number of network packets needed to query and modify databases and
are compiled and cached for long periods of time for efficient reuse.
In addition to user-created stored procedures, SQL Server provides literally hundreds of System Stored
Procedures. These System Stored procedures are used to retrieve system information, as well as make
changes to the underlying system objects. They range from simple stored procedures that return a list
of all the logged-in users, to complex stored procedures that create database maintenance jobs. Some of
these stored procedures are covered in later chapters as they apply to the topic at hand.
Functions
SQL Server 2008 provides support for three types of user-defined functions: scalar functions, table-valued
functions, and aggregate functions. SQL Server functions are very similar to functions in other programming languages. They accept parameters, perform some action based on the input parameters, and return
a value. Table-value functions always return a table data type. Scalar and aggregate functions can return
any data type except text, ntext, and image.
User-defined functions can be created with Transact-SQL or managed code with the exception of aggregate
functions, which are always created in managed code. User-defined functions offer many of the same
benefits as stored procedures as far as efficiency and security are concerned. One area in which they
differ is that functions are not allowed to execute any code that modifies the state of the database, whereas
stored procedures can.
193
Page 193
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
System functions are separated into categories in Object Explorer of SQL Server Management Studio. Some
functions are used to manipulate user data (such as aggregate and string functions), whereas others are
used to retrieve system information (such as security and metadata functions).
Triggers
Triggers are stored Transact-SQL or managed-code objects that are executed because of some other action
within the system and cannot be executed directly. Two types of triggers exist in SQL Server 2008: DML
and DDL triggers.
DML Triggers
Data Manipulation Language (DML) triggers are executed as a result of a DML command (INSERT, UPDATE,
DELETE) being executed. There are two types of DML triggers in SQL Server 2008: After triggers and
‘‘Instead Of’’ triggers.
After Triggers
Traditional triggers are known as After triggers because they execute ‘‘after’’ the DML statement is executed on the table with the defined trigger. The code in the trigger is implicitly part of the transaction that
caused the trigger to execute. Any ROLLBACK command in the body of the trigger will cause the trigger
and the associated transaction to be rolled back.
‘‘Instead Of’’ Triggers
‘‘Instead Of’’ triggers are so named because the commands in the trigger are executed ‘‘instead of’’ the
actual transaction that caused the trigger to be executed. ‘‘Instead Of’’ triggers were created primarily as
a method of sending updates to tables referenced in views containing a UNION operator, because these
views cannot be directly updated. For information about ‘‘Instead Of’’ triggers and these partitioned
views, check out Beginning T-SQL with Microsoft SQL Server 2005 and 2008 by Paul Turley and Dan Wood
(Wiley, 2008).
DDL Triggers
Data Definition Language (DDL) triggers are executed as a result of a DDL command (CREATE, DROP, ALTER)
being executed and can be scoped at either the database or server scope. DDL triggers provide the ability
to audit or prevent database and server modifications.
The following example demonstrates how to create a database-level DDL trigger to audit modifications
made to the database.
First, you create a table to record all the DDL events that occur on the database. Do this by running the
following script:
USE AdventureWorks2008
GO
CREATE TABLE AuditLog (
EventID
int IDENTITY(1,1) NOT NULL,
LoginName varchar(75) NOT NULL,
EventTime datetime NOT NULL,
DDLEvent
varchar(100) NULL,
194
11:47am
Page 194
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Eventdata
xml NOT NULL)
GO
Next, create a trigger that will execute whenever any DDL level event is executed. This trigger uses a
system function called EVENTDATA that returns an XML resultset containing all the information about the
DDL event. The trigger uses XQUERY commands to shred the XML data into a relational resultset to be
inserted into the audit table.
USE AdventureWorks2008
GO
CREATE TRIGGER DatabaseAudit
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
AS
DECLARE @data XML = EVENTDATA()
INSERT AuditLog(LoginName, EventTime,DDLEvent,EventData)
VALUES
(SYSTEM_USER
,GETDATE()
,@data.value(’(/EVENT_INSTANCE/TSQLCommand)[1]’, ‘nvarchar(2000)’)
,@data)
RETURN
GO
Now, test the trigger by creating and dropping a table called TriggerTest and then querying the audit
table to see if you captured the information you wanted:
USE AdventureWorks2008
GO
CREATE TABLE TriggerTest (
Column1 int
,Column2 int)
DROP TABLE TriggerTest
SELECT * FROM AuditLog
You should get two rows that look similar to Figure 5-31 (of course, your LoginName and EventTime will
vary).
Figure 5-31: DDL Trigger Audit results.
To ensure that this trigger does not interfere with other exercises later in the book, you may want to drop
it by executing the following command:
DROP TRIGGER DatabaseAudit ON DATABASE
195
Page 195
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Assemblies
Assemblies are files that contain database programming objects and are created using Visual Studio. They
can include stored procedures, functions, triggers, aggregates, and data types written in any managed
language such as C# or Visual Basic.NET. They are directly accessible in the Database Engine through the
integration of the Common Language Runtime (CLR). Using managed code offers a significant advantage
over traditional Transact-SQL programming in certain situations such as those that require intensive and
recursive mathematical operations or complex string manipulation. Chapter 14 describes CLR objects
and integration in more detail.
As inferred in Chapter 14, there is a definite tension between database administrators and developers. Often, this tension is exacerbated by the database administrator’s lack of programming skills. With
the integration of the CLR and the Database Engine, it is more important than ever that the database
administrators understand programming and communicate with the developers who interact with their
systems.
CLR assemblies can be imported into the database with Visual Studio, Transact-SQL, or with SQL Server
Management Studio. This discussion focuses on just Transact-SQL and SQL Server Management Studio.
In order for you to follow along with me here, you will need a file to upload. Later in Chapter 14 we will
cover the creation of this file, but for now, just use your imagination.
To add a new assembly using SQL Server Management Studio, expand Databases, expand
AdventureWorks2008, expand Programmability, right-click Assemblies, and click ‘‘New Assembly.’’
In the New Assembly dialog (see Figure 5-32), browse to the assembly, specify an owner for the assembly,
and set the permissions for the assembly.
The permission set defines how much access the assembly is given to perform the contained actions.
‘‘Safe’’ limits the assembly to the current database and connection. ‘‘External Access’’ enables the assembly to interact with the operating system, network, and file system. ‘‘Unrestricted’’ allows the assembly
all the privileges of External Access, as well as the ability to make calls to unmanaged code. Assembly
permission sets are discussed in more detail in Chapters 6 and 14.
Now that the assembly has been added to the database, a stored procedure, function, trigger, type, or
aggregate can be added to the database that links to the assembly. (For this exact process, check out
Chapter 14.)
Types
Types are a collection of system data types, user-defined data types, user-defined table types, and
user-defined types, as well as any XML schema collections used in the database. System data types were
covered in Chapter 4, so let’s look at the remaining types.
User-Defined Data Types
User-defined data types are aliases for system types. These aliases exist only within the database they are
created in. User-defined data types are most often used to provide an intuitive data type name and
maintain data type consistency across different tables.
196
11:47am
Page 196
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
Figure 5-32: New Assembly dialog.
For example, if I were to ask five different database developers to create a table that stores information
about an individual, I would most likely get five different solutions. The table will probably contain
columns for the individual’s last name, first name, address, and phone number, but chances are that the
five different database developers would provide at least three differing data types to store any one of
the fields specified. For example, one developer may use a varchar(13) to represent a phone number,
thinking that phone numbers would be represented as (111)111-1111. Another developer may decide to
think globally and provide for international codes as well, and specify a phone number of varchar(25).
To avoid possible type conflicts later, you can specify that user-defined data types be used.
To create a user-defined data type graphically, expand Databases in Object Explorer, expand
AdventureWorks2008, expand Programmability, expand Types, right-click ‘‘User-defined data types,’’
and click ‘‘New User-defined data type.’’
Figure 5-33 illustrates the creation of a ZipCode data type in the dbo schema that is based on the system
type char(5). User-defined data types can also be bound to database defaults and rules by specifying
them in the appropriate textboxes. Defaults and rules are described later in this chapter.
There are a few drawbacks of user-defined data types. For one, they are not transparent to database
applications. For example, an application programmer would not be able to instantiate a variable in the
197
Page 197
Leiter c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
application layer that used the ZipCode data type. The programmer would have to know that the base
type was a char(5). In addition to the application-layer visibility, user-defined data types only exist in
the database in which they are created. For example, a ZipCode data type in the AdventureWorks2008
database may not be the same as a ZipCode data type in the AdventureWorksDW2008 database. Also, once
created, it cannot be altered. In other words, if later you wanted to change the ZipCode data type to be
a char(9) to hold zip+4, you would have to drop and re-create it. Unfortunately, in order to drop it, it
can’t be used anywhere.
Figure 5-33: Creation of a ZipCode data type.
User-Defined Table Types
SQL Server 2008 provides the ability to create user-defined types that represent table definitions. You
could use user-defined table types to declare variables or as parameters for stored procedures and functions, making it far easier to work with sets of information. To create a user-defined table type, you
use the CREATE TYPE statement providing the definition for the table. The following code creates a table
structure that is used to represent a set of customers and then uses it as an input parameter to a stored
procedure:
CREATE TYPE Customers AS TABLE
( CustomerName varchar (50),
198
11:47am
Page 198
Leiter
c05.tex
V3 - 03/25/2009
11:47am
Chapter 5: SQL Server 2008 Databases
CreditLimit decimal,
Address varchar(50),
PhoneNumber varchar(10) );
GO
DECLARE @customers Customers
INSERT INTO @customers(CustomerName, CreditLimit, Address, PhoneNumber)
VALUES (’’, 2300.00, ‘’, ‘’),
(’’, 2300.00, ‘’, ‘’),
(’’, 2300.00, ‘’, ‘’)
GO
EXEC usp_AddCustomers @customers
GO
The preceding code is for demonstration purposes only and will not function since there is no stored
procedure called usp_AddCustomers in the AdventureWorks database.
User-Defined Types
User-defined types (UDTs) are very similar to user-defined data types, except that they are created using
managed code and defined in an assembly that is imported into a SQL Server database. UDTs can be
very complex and can define custom data types that have no parallel system type. For example, a UDT
could be created to define a true Social Security number data type that really was stored as a number,
but didn’t truncate leading zeros. Also, we would be able to take advantage of regular expressions in the
managed code to validate the Social Security number much more easily and be more accurate.
The other advantage of UDTs is that they are visible from the application layer as well. Because they are
defined in an assembly, that assembly can be referenced in a database application so that parameters
could be instantiated using the native UDT. But user-defined types are not perfect, and they can be troublesome when it comes to cross-database applications because the UDT is database-specific. However, if
the same assembly is referenced in the creation of the UDT in each database, this limitation is reduced. As
previously noted, Chapter 14 contains more information about CLR assemblies and the database objects
that can be created with them, including UDTs.
Defaults
Instead of creating a default constraint on a column in a table, a stand-alone default can be created at the
database level and then bound to any table column in the database. Defaults have been marked for deprecation, and it is recommended that you do not use them in any new development work. They are found
in the Programmability node of databases in Object Explorer, but must be created with Transact-SQL.
The following example demonstrates how to create a default Social Security number and then bind it to
the SocSecNum column on the dbo.Driver table:
USE AdventureWorks2008
GO
IF EXISTS(SELECT * FROM sys.default_constraints WHERE name = ‘DF_Driver_SocSecNum’)
ALTER TABLE dbo.Driver DROP CONSTRAINT DF_Driver_SocSecNum
CREATE DEFAULT dfltSocSecNum AS ‘000000000’
GO
sp_bindefault ‘dfltSocSecNum’, ‘dbo.Driver.SocSecNum’
199
Page 199
Leiter
c05.tex
V3 - 03/25/2009
Chapter 5: SQL Server 2008 Databases
Rules
Rules, like defaults, have been deprecated. A rule is like a check constraint. However, it is created once
at the database level and then bound to any column that matches the data type specified. The following
example demonstrates how to create a rule that enforces numeric data on a character-based column and
then how to bind that rule to the SocSecNum column:
USE AdventureWorks2008
GO
CREATE RULE AllNumRule AS
@value LIKE ‘[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]’
GO
sp_bindrule ‘AllNumRule’,’dbo.Driver.SocSecNum’
Summar y
This chapter has covered a great deal of information, and we have barely scratched the surface. An entire
book could be written on just the SQL Server database and all the features it includes; however, this is
not that book. The purpose of this chapter was to expose you to many of the objects that can be found
in a SQL Server database and how to create and manage them. Future chapters dive into various other
areas of SQL Server 2008 from the database administrator’s perspective.
In Chapter 6, you will look at how to secure a SQL Server 2008 server, database, and all the associated
objects that comprise SQL Server. Many new features (such as SQL Server certificates, credentials, and
encryption) are described in detail, and it also covers the core security features so that you can ensure
your server is as secure as it possibly can be.
200
11:47am
Page 200
Leiter
c06.tex
V3 - 03/25/2009
11:54am
6
SQL Ser ver 2008 Security
Security is often one of the most challenging aspects of designing and managing a database system.
As a DBA, you want your servers to be as secure as possible without having to invest an inordinate
amount of money or sacrifice user functionality. Unfortunately, many administrators and application developers are often skeptical about the benefits of security, believing that they are somehow
immune to the myriad of threats that are out there. In reality, as long as users have access to data,
there is a risk of a security breach. So what do you do? Take the SQL Server offline, put it in a locked
room that only you have access to, and require that all database requests be processed manually
through you?
Security isn’t about guaranteeing a completely attack-proof system. It’s about mitigating and
responding to risk. It’s about ensuring that you take the necessary steps to minimize the scope
of the attack. Remember that simply giving users access to the database through the network will
introduce an element of risk. This chapter takes a look at SQL Security from the outside in. You
will learn about the different types of accounts and principals that are available. You will see how
to control access to database objects, and how to encrypt and protect your data. This chapter also
includes some guidelines for providing a secure solution for deploying and managing your SQL
Server.
Because SQL Server 2008 is designed to work with Windows Server 2008, some of the examples
in this chapter may behave a little differently in other operating systems, such as Windows Vista,
Windows XP, or Windows Server 2003. All examples in this chapter use Windows Server 2008 as
the baseline. Also, many of the examples used in this chapter refer to the server AughtEight, which
I configured in Chapter 2. Remember to replace AughtEight with your own server name.
SQL Ser ver Authentication Modes
Microsoft SQL Server 2008 offers two options for authenticating users. The default mode is Windows
Authentication mode, which offers a high level of security by using the operating system’s authentication mechanism to authenticate credentials that will need access to the server. The other, SQL Server
and Windows Authentication mode, offers the ability to allow both Windows-based and SQL-based
authentications. For this reason, it is also sometimes referred to as Mixed mode. Although Windows
Authentication mode typically provides better security than SQL Server and Windows Authentication mode, the design of your application may require SQL-based logins.
Page 201
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Windows Authentication mode allows you to use existing accounts stored in the local computer’s Security Accounts Manager (SAM) database, or, if the server is a member of an Active Directory domain,
accounts in the Microsoft Windows Active Directory database. The benefits of using the Windows
Authentication mode include reducing the administrative overhead for your SQL or database administrators by allowing them to use accounts that already exist and the ability to use stronger authentication
protocols, such as Kerberos or Windows NT LAN Manager (NTLM).
In Windows Authentication mode, SQL does not store or need to access password information for
authentication. The Windows Authentication Provider will be responsible for validating the authenticity
of the user.
Mixed mode authentication allows you to create logins that are unique to the SQL Server and do not
have a corresponding Windows or Active Directory account. This can be helpful for applications that
require users who are not part of your enterprise to be able to authenticate and gain access to securable objects in your database. When SQL logins are used, the SQL Server stores username and password information in the master database, and the SQL Server is responsible for authenticating these
credentials.
When deciding on the authentication method, it is important to identify how users will be connecting to
the database. If the SQL Server and your database users are all members of the same Active Directory
forest, or even different forests that share a trust, using Windows Authentication can simplify the process
of creating and managing logins. However, if your SQL Server is not in an Active Directory domain or
your database users are not internal to your organization, consider the use of SQL-based logins to create
a clear distinction between security contexts.
In Chapter 2, you learned how to install Microsoft SQL Server 2008, and you selected which authentication mode to use. If you wish to change the authentication mode after the installation, be aware that this
will require you to restart the SQL Server service.
Changing the Authentication Mode from Management
Studio
To change the authentication mode from Management Studio, follow these steps:
1.
2.
3.
4.
5.
Launch SQL Server Management Studio.
In Object Explorer, select your server.
Right-click on your server and select Properties.
Under the ‘‘Select a page’’ pane, select Security.
Under the heading ‘‘Server authentication,’’ select or review the appropriate authentication
mode (Figure 6-1).
Using the xp_instance_regwrite Extended Stored
Procedure
You can also change the authentication mode using the xp_instance_regwrite extended stored
procedure, as long as you have administrative permissions on the local server. The following
202
11:54am
Page 202
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
example shows you how to change the authentication mode to SQL Server and Windows Authentication mode:
USE master
EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’,
N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 2
Figure 6-1: Server Properties screen.
You can also change the authentication mode to Windows Authentication mode by changing the DWORD
value to 1, as shown in this example:
USE master
EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’,
N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 1
During the installation of SQL Server, the sa account is disabled by default. If you are changing the
authentication mode from Windows Authentication mode to SQL Server and Windows Authentication
mode, the account remains disabled with the password you specified during the Installation Wizard. I
recommend against using the sa account in a production environment, especially when multiple people
have administrative access to the SQL Server because of the lack of accountability. When multiple people
can log in as the sa account, you lose the ability to associate an auditable action with a specific person.
203
Page 203
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Principals
The term principal is used to describe individuals, groups, and processes that will interact with the SQL
Server. The resources available to a principal are dependent on where the principal resides. Microsoft
SQL Server supports several different types of principals defined at three different levels: the Windows
level, the SQL Server level, and the database level. Each type of principal is identified here, and the way
they are used. To prepare for some of the exercises in this chapter, you will want to create some local
Windows accounts as follows:
1.
2.
From the Start Menu, right-click My Computer and select Manage.
In the Server Manager window, expand Configuration, then ‘‘Local Users and Groups’’ (see
Figure 6-2).
Figure 6-2: Server Management screen.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
204
Right-click on the Users folder and select ‘‘New User.’’
In the User Name box, enter Bob.
In the Password and Confirm Password boxes, enter [email protected]
Clear the check next to the ‘‘User must change password and next login’’ box.
Click Create.
In the User Name box, enter CarolStreet.
In the Password and Confirm Password boxes, enter [email protected]
Clear the check next to the ‘‘User must change password and next login’’ box.
Click Create.
In the User Name box, enter Alice.
In the Password and Confirm Password boxes, enter [email protected]
Clear the check next to the ‘‘User must change password and next login’’ box.
Click Create.
Click Close.
11:54am
Page 204
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
17.
18.
19.
20.
21.
Right-click on the Groups folder and select ‘‘New Group.’’
In the Group Name Box, enter G NorthWest Sales.
Click Create.
Click Close.
Close the Server Manager window.
Logins
Microsoft SQL Server 2008 offers two kinds of logins for authentication. Windows logins are associated
with user or group accounts stored in the Active Directory or the local Security Accounts Manager (SAM)
database. SQL logins are used to represent an individual or entity that does not have a Windows account
and, therefore, must rely on the SQL Server for storage and management of account information.
Windows logins, whether they represent an individual or a group, are bound by the password policy of
either the domain or the SAM in which the account exists. When a login is created for a Windows user or
group, no password information is stored in the SQL Server. The password for a Windows login is stored
as NULL, but even if this field is populated with a value, the value is ignored. Windows logins are also
authenticated prior to connecting to the SQL Server. This means that Active Directory or the operating
system will have already verified the principal’s identity.
When a Windows login is created for a group, all members of that group have the ability to authenticate
against the SQL Server without having to create separate logins for each user.
SQL Server logins, however, must authenticate against the SQL Server. This makes the SQL Server
responsible for verifying the user’s identity. SQL stores the login and a hash of the login’s password
information in the master database. It is important that passwords for SQL logins adhere to security best
practices, such as enabling complexity requirements, prohibiting non-expiring passwords, and requiring
that passwords be changed regularly. In fact, options in Microsoft SQL Server 2008 allow you to enforce
requirements for password complexity and expiration for SQL logins based on your Windows or Active
Directory policies. Complex passwords are typically defined as having a combination of at least three of
the following four criteria:
❑
Uppercase alpha characters
❑
Lowercase alpha characters
❑
Non-negative integers (0–9)
❑
Special characters ($, %, *, &)
If the SQL Server is a member of an Active Directory domain, the password policy is usually defined in
a Group Policy object linked to the domain. For SQL logins, or logins based on a local Windows account,
this may be superseded by a Group Policy object linked to an Organizational Unit. If the SQL Server is
not a member of an Active Directory domain, the password policy is defined in the Local Group Policy
object or the Local Security Policy (which is a subset of the local GPO).
Unlike previous versions of SQL, SQL Server 2008 does not automatically create logins for the
[BUILTIN\Administrators] group, which would allow anyone with local administrative rights on the
server to log in to the SQL Server. Instead, administrators must be added during the user-provisioning
step in the Installation Wizard (see Chapter 2), or added to the sysadmin role (discussed later in the
chapter) after installation. A SQL login, sa, is also created. The sa account has full administrative access
205
Page 205
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
to all SQL functions. During installation, you are prompted to specify a password for the sa account.
Regardless of whether you install SQL Server using Windows Authentication mode or Mixed mode, the
sa account is disabled and remains disabled until you choose to enable the account.
Another new feature in SQL Server 2008 is the ability to create a SQL Server login that is mapped to a
certificate or asymmetric key through the GUI. SQL Server 2005 had allowed this mapping to be created
only through T-SQL. This mapping must be specified during login creation, and the certificate or asymmetric key must be created before the login can be mapped to it. Creation and management of certificates
and symmetric keys are covered later in this chapter.
Creating Logins in Management Studio
To create logins from Management Studio, follow these steps:
1.
2.
3.
4.
From Object Explorer, expand your server.
Expand the Security folder.
Right-click Logins and select ‘‘New Login.’’
In the Login–New dialog box (see Figure 6-3), either type the Login name you want to add
or click the Search button to browse for a Windows account.
Figure 6-3: New login dialog box.
206
11:54am
Page 206
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
5.
6.
If you are creating a SQL Login, select the ‘‘SQL Server authentication’’ radio button.
7.
You may also want to change the user’s default database and language.
Also, when you select ‘‘SQL Server authentication,’’ you can choose not to enforce the password policies.
Try It Out
Creating a New Login for Alice
To create a new login for Alice, follow these steps:
1.
2.
3.
4.
5.
6.
7.
From Object Explorer, expand your server.
Expand the Security folder.
Right-click Logins and select ‘‘New Login.’’
In the New Login dialog box, click Search.
In the ‘‘Select User or Group’’ dialog box, type Alice and click OK.
Select AdventureWorks2008 as the default database.
Click OK.
Creating Logins Using T-SQL
Alternatively, you can use the CREATE LOGIN statement. CREATE LOGIN allows you to create either Windows or SQL logins. This statement is designed to replace two stored procedures that were used in
previous versions of SQL, sp_grantlogin and sp_addlogin. Both of these stored procedures are still
available in SQL Server 2008, primarily for backward compatibility, but they have been deprecated and
may be removed in a future version of SQL. Use the following format for the CREATE LOGIN statement:
CREATE LOGIN [name] {WITH <options> | FROM <source>}
The following tables show the options available with this statement:
Option
Description
PASSWORD =
‘password’
Creates a new password for SQL logins. If this value is already
hashed, use the HASHED option. Passwords are case-sensitive. See the
‘‘Best Practices’’ section in this chapter for more information on
password guidelines.
HASHED
When a password is created for a SQL login, the password is stored
in the database using a one-way hashing algorithm. This provides
several benefits. Because the password is not stored in plain text, it
cannot be read by simply querying a system view. Because the
hashing process is one-way, the password cannot be extrapolated
from the hash value. This also secures the password in transmission,
because the SQL Authentication process will send the hashed value
of the password, not the actual plain-text password.
Continued
207
Page 207
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Option
Description
MUST_CHANGE
Requires the user to change his or her password at the next login. This
is valid for SQL logins only. CHECK_POLICY and CHECK_EXPIRATION
must be set to ON for this to work.
CREDENTIAL =
credential_name
Maps an existing credential to a login. Credentials are discussed later
in this chapter.
SID = sid
Allows you to manually specify a SID (Security Identifier) for a new
user. If this value is left blank, the SID will be automatically generated.
DEFAULT_DATABASE =
database
Assigns the default database for the login. If not specified, the master
database will be assumed. This should be configured to a user
database for most business users.
DEFAULT_LANGUAGE =
language
Assigns the default language for the login. If not specified, the default
language of the server at the time the login was created will be used.
This will not change if the server’s default language is changed.
CHECK_POLICY =
{ ON | OFF }
This statement allows you to enforce your Windows-based password
policies to SQL logins. This is ON by default.
CHECK_EXPIRATION =
{ ON | OFF }
A complement to the CHECK_POLICY option, this allows your
Windows-based password expiration policy to also apply to SQL
logins. If CHECK_POLICY is ON, then this will default to ON. Otherwise,
the default value is OFF.
Sources
Description
WINDOWS
Identifies that a login will be created based on an existing Windows
user or group.
CERTIFICATE certname
Associates a pre-existing certificate with a login. Certificates are
discussed later in this chapter.
ASYMMETRIC KEY
asym_key_name
Associates a pre-existing asymmetric key with a login. Symmetric and
Asymmetric keys are discussed later in this chapter.
SQL Server will automatically hash a password before storing it in the database. Be careful about using
the HASHED option unless you are sure that the password you are supplying has already been hashed by
SQL Server. For example, if you type the following statement:
CREATE LOGIN Bill WITH PASSWORD = ‘[email protected]’ HASHED
SQL will assume that [email protected] is a hash of another value. So, when Alice tries to log in with [email protected],
the authentication will fail. You can use the loginproperty function to obtain the hashed value of an
existing user’s password, as shown in the following example:
SELECT LOGINPROPERTY(’bill’, ‘passwordhash’)
208
11:54am
Page 208
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Managing Logins
SQL Server Management Studio includes several property sheets to configure logins, which are
addressed later in this chapter. In addition to the General property sheet, you should also be familiar
with the Status page, which allows you to enable or disable the login, unlock the login, and specifically
grant or deny access to connect to this SQL Server.
From the General property sheet, you can change the following attributes:
❑
Password
❑
Password Policy
❑
Password Expiration
❑
Force the user to change the password at the next login
❑
Default Database
❑
Default Language
Logins can also be managed using the ALTER LOGIN statement. In addition to many of the options listed
previously for the CREATE LOGIN statement, the ALTER LOGIN statement uses the following format:
ALTER LOGIN name {<status> | WITH <options>}
The following table shows the additional options available with this statement:
Option
Description
Status {Enable | Disable}
Enables or disables the login as needed.
OLD_PASSWORD =
‘oldpassword’
Specifies the current password when changing the password for
the login. The HASHED keyword cannot be used when specifying
an old password.
NAME = login_name
Allows you to rename a login. If renaming a Windows-based
login, the SID of the Windows object must match the SID for the
login in SQL Server. SQL Server–based logins must not contain a
backslash (\) character.
NO CREDENTIAL
Removes the mapping between the login and a server credential.
UNLOCK
A SQL Server login may become locked out after too many
invalid password attempts. If that occurs, this option can remove
the lock.
ADD CREDENTIAL
Associates an Extensible Key Management (EKM) provider
credential to the login. EKM is covered later in this chapter.
DROP CREDENTIAL
Removes an associated Extensible Key Management (EKM)
provider credential from the login. EKM is covered later in this
chapter.
209
Page 209
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Using CREATE LOGIN
To create a new login in Transact-SQL, use the CREATE LOGIN statement. The following example creates a
new login for a user account named Bob on the AughtEight server:
CREATE LOGIN [AughtEight\Bob] from Windows;
GO
To create a new login for a Windows group, use the following example:
CREATE LOGIN [AughtEight\G NorthWest Sales] from Windows;
GO
To create a new SQL Server login for Carol, use the following syntax:
CREATE LOGIN Carol
WITH PASSWORD = ‘Th1sI$|\/|[email protected]’;
GO
To change Carol’s password to use the all-lowercase newpassword, use the following command:
ALTER LOGIN Carol WITH PASSWORD = ‘newpassword’,
CHECK_POLICY=OFF;
GO
To remove an existing login, use the DROP LOGIN statement. For example, if you want to remove Bob’s
login (remember, Bob has a Windows-based login), use the following:
DROP LOGIN [AughtEight\Bob];
GO
For More Information
For backward compatibility, Microsoft SQL Server 2008 supports the stored procedures for managing
logins listed in the following table. Because these stored procedures have been deprecated, you should
use the CREATE LOGIN and ALTER LOGIN statements.
Stored Procedure
Description
sp_grantlogin:
Creates a new Windows-based login.
sp_revokelogin:
Removes a Windows-based login.
sp_addlogin:
Creates a new SQL Server login.
sp_droplogin:
Removes a SQL Server–based login.
Credentials
Microsoft SQL Server 2008 also includes a feature for mapping SQL Server logins to external Windows accounts. This can be extremely useful if you need to allow SQL Server logins to interact with
210
11:54am
Page 210
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
the resources outside the scope of the SQL Server itself (such as a linked server or a local file system).
They can also be used with assemblies that are configured for EXTERNAL_ACCESS permissions.
Credentials can be configured as a one-to-one mapping or a many-to-one mapping, allowing multiple
SQL Server logins to use one shared Windows account for external access. In SQL Server 2008, logins can
now be associated with multiple credentials, whereas SQL Server 2005 only allows a login to be mapped
to a single credential. Credentials can also be configured to use an EKM provider
Creating a New Credential
When creating a new credential, follow these steps:
1.
2.
3.
In Object Explorer, expand your server.
Expand the Security folder.
Right-click Credentials and select ‘‘New Credential’’ (see Figure 6-4).
Figure 6-4: New Credential properties screen.
4.
5.
Type a name for the credential.
In the Identity section, either type the name of a Windows account or click the ‘‘ . . . ’’ button
to browse for an account.
211
Page 211
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
6.
7.
8.
9.
10.
Enter the password for the account.
Re-enter the password to confirm.
Enable Use Encryption Provider (if desired).
Select a valid External Key Management provider (if the above option is selected).
Click OK.
Using Transact-SQL
You can use the CREATE CREDENTIAL statement as an alternative means to create a new SQL credential
object. The syntax is as follows:
CREATE CREDENTIAL name WITH IDENTITY = ‘identity_name’ [, SECRET = ‘secret’]
[FOR CRYPTOGRAPHIC_PROVIDER provider_name]
Likewise, the ALTER CREDENTIAL statement can be used to alter the name of the credential, the identity
it’s associated with, and the password. Once the credential is no longer needed, it can be removed with
the DROP CREDENTIAL command, as follows:
DROP CREDENTIAL name
Try It Out
Create a New Credential for a Windows Account
Earlier in the chapter, you created a Windows account named CarolStreet with a password of [email protected]
You will now create a new credential named StreetCred for that user. When running the following
script, replace AughtEight with your own server name:
USE master
CREATE CREDENTIAL StreetCred
WITH IDENTITY = ‘AughtEight\CarolStreet’,
SECRET = ‘[email protected]’;
GO
You can then associate Carol’s SQL Server login with the StreetCred credential:
ALTER LOGIN Carol WITH CREDENTIAL = StreetCred;
GO
Server Roles
Microsoft SQL Server 2008 defines eight server-level roles that are available to simplify management (and
the delegation of management) for SQL logins. These are often referred to as fixed server roles because
membership is the only thing you can change about these roles. The fixed server roles are designed
to allow you to automatically assign a common set of permissions to a login, based on the purpose of
the role.
Additionally, SQL Server 2008 also includes a public server role. In addition to customizing the member
list of the public server role, you can also define protocol-specific permissions for Tabular Data Stream
212
11:54am
Page 212
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
(TDS) endpoints. These endpoints are covered in more detail in Chapter 7. By default, all logins are
members of the public server role.
Using Fixed Server Roles
The following table shows the fixed server roles in the order they appear on the server:
Role
Description
sysadmin
Members have full administrative access to the SQL Server and can
perform any action. Users and groups added through the User
Provisioning function of SQL Server setup are added to this group.
serveradmin
Members of this role can change server-wide configurations and
shut down the server.
securityadmin
Members can manage SQL logins, including changing and resetting
passwords as needed, as well as managing GRANT, REVOKE, and DENY
permissions at the server and database levels.
dbcreator
Members can create, drop, alter, and restore any database for the
server.
diskadmin
Members can manage disk files for the server and all databases.
processadmin
Members can manage and terminate processes on the SQL Server.
setupadmin
Members can add and remove linked servers.
bulkadmin
Members of this role can execute the BULK INSERT statement for any
database on the server.
To add a login to a fixed server role, use the sp_addsrvrolemember stored procedure. The stored procedure uses the following format:
sp_addsrvrolemember [ @loginame= ] ‘login’ , [ @rolename = ] ‘role’
Simply provide the login name and the role name. To add Ted to the securityadmin role, use the following command:
USE master
CREATE LOGIN Ted WITH PASSWORD = ‘[email protected]’;
GO
EXEC sp_addsrvrolemember ‘Ted’, ‘securityadmin’;
GO
Use sp_dropsrvrolemember to remove a login from a fixed server role. The syntax is similar to the
sp_addsrvrolemember stored procedure, as shown in the following example:
USE master
EXEC sp_dropsrvrolemember ‘Ted’, ‘securityadmin’;
GO
213
Page 213
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
For More Information
You can query the Security Catalog Views to find out more information about principals at the server
scope. The following table shows views that identify server-level principals:
View
Description
sys.server_principals
Returns information about all server-level principals.
sys.sql_logins
Returns information about SQL Server logins.
sys.server_role_members
Returns the role ID and member ID for each member of
a server role.
sys.credentials
Returns a list of all credentials configured on the SQL
Server.
sys.server_principal_
credentials
Returns a list containing the principal_id and
credential_id for each principal mapped to a
credential.
Database Users
Database users are another component of the security model employed by Microsoft SQL Server 2008.
Users are granted access to securable database objects, either directly or through membership in one or
more database roles. Users are also associated with ownership of objects such as tables, views, and stored
procedures.
When a login is created, unless it is a member of a fixed server role with administrative privileges to
all databases, that login has no explicit permissions within the various databases attached to the server.
When this happens, the login is associated with the guest database user and inherits the permissions of
that user account.
When managing database users in SQL Server Management Studio, you have several options from which
to select. On the General property sheet (see Figure 6-5), you will be able to specify a name for the user
and associate the user with an existing login. Note that the username does not have to match the login
name. For ease of administration, it is best practice to try to use a consistent naming convention, but
it is not required. Also, note that there are radio buttons that show whether the user is mapped to a
login, a certificate, a key, or without any association. Through the Graphical User Interface (GUI), you
can only create a user mapped to a login. In the next section, you see how to create users with other
mappings.
Other options you can configure from the General page include specifying the user’s default schema,
schemas owned by this user (if any), and to which database roles the user belongs. In the Securables page,
you can list all the securable objects the user has permissions to and what permissions they have. Finally,
you have the Extended Properties page, which allows you to designate or view additional metadata
information about this user.
214
11:54am
Page 214
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Figure 6-5: Database User–New General property page.
Try It Out
Create a New User and Default Schema
For this example, you will create a new database user in the AdventureWorks2008 database for Carol and
set her default schema to the Sales schema.
1.
2.
3.
4.
5.
6.
7.
8.
In Object Explorer, expand Databases.
Expand AdventureWorks2008 (see Figure 6-6).
Expand Security.
Right-click Users and select ‘‘New User.’’
Type Carol in the User Name box.
Type Carol in the ‘‘Login name’’ box, or select her login using the ‘‘...’’ button.
Type Sales in the ‘‘Default schema’’ box.
Click OK.
215
Page 215
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Figure 6-6: New database user.
Now that Carol has a database user account in the AdventureWorks2008 database, she has inherited the permissions granted to the public database role. Database roles and permissions are
covered later in this chapter.
CREATE USER
The CREATE USER statement can also be used for creating new database users. CREATE USER offers more
options over how the user is created than the GUI allows. For example, you can create a user based on
an existing certificate or key, or even create a user who is not associated with a login. Although reasons
for implementing these types of users will be limited, they can have access to database objects without
being associated with a specific login. They can be used to access resources that have specific security
requirements. For example, a stored procedure might contain the EXECUTE AS clause, in which case, the
stored procedure runs as the user associated with a particular certificate, or asymmetric key. The caveat,
though, is that these users are valid only in the database in which they were created. If they attempt to
access resources in another database, they will access the other database as guest. If the guest user is
disabled in the other database, then they will be denied access.
Each database has two users created by default. The dbo user (also known as the database owner) has
all rights and privileges to perform any operation in the database. Members of the fixed server role,
sysadmin, as well as the sa account, are mapped to dbo. Any object created by a sysadmin is automatically
owned by dbo. The dbo user is also the owner of the default schema, also called dbo. The dbo user cannot
be deleted.
216
11:54am
Page 216
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
The guest account is also present in every database, but is disabled by default. The guest account is commonly used when a person has login access to the SQL Server, but no explicit user access to a database.
If the database has a guest account and it is enabled, then the login will connect to that database with
guest access. guest is a member of the public role and has all of the permissions assigned to that role,
but can be granted explicit permissions to securables as well.
You may also notice two other ‘‘users,’’ sys and INFORMATION_SCHEMA. Although they are not users in the
conventional sense, they do own objects in the database, primarily for storing and retrieving metadata.
These users are not mapped to any login and are disabled by default.
The following is the syntax and options for the CREATE USER statement:
CREATE USER name [{{FOR | FROM} source | WITHOUT LOGIN]
[WITH DEFAULT_SCHEMA = schema_name]
The following tables explain the options that are available:
Source Options
Description
Login login_name
This option specifies the login name to associate with this user.
If this value is not present, SQL Server assumes that the user
you are trying to create is using the same name as an existing
login. If there is not a login with the same name as the user, the
operation will fail.
CERTIFICATE cert_name
This option allows you to create a user associated with a
certificate, rather than with a login. The certificate must
already exist in this database for the operation to succeed.
Certificates are discussed later in this chapter.
ASYMMETRIC KEY key_name
This option allows you to create a user associated with an
asymmetric key, rather than with a login. The asymmetric key
must already exist in the database. Keys are discussed later in
this chapter.
Other Options
Description
WITHOUT LOGIN
This option allows you to designate that the user is created
without any association to a login, or other objects such as
asymmetric keys or certificates.
WITH DEFAULT_SCHEMA =
schema
This option lets you specify the schema in which the user will
operate. The benefit to users is that whenever they create or
access an object within their default schema, they can use the
object name by itself. The users may still be able to access
objects in other schemas, permission allowing, by using the
schema.object naming convention.
217
Page 217
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Try It Out
Create a New User
Take a look at the CREATE USER statement in action. In an earlier example, you created a new SQL Server
login called Carol and an associated user in the AdventureWorks2008 database. If you wanted to create
a user for Carol in the tempdb database, you could execute the following statement:
USE tempdb;
CREATE USER Carol;
GO
That’s all there is to creating a new user.
Look at another example. If you executed the DROP LOGIN [AughtEight\Bob] statement earlier, you’ll
need to re-create his login. In this example, you’ll create a database user named BillyBob who will be
mapped to Bob’s login, and set BillyBob’s default schema to the Sales schema:
USE master;
CREATE LOGIN [AughtEight\Bob] FROM WINDOWS;
USE AdventureWorks2008;
CREATE USER BillyBob FOR LOGIN [AughtEight\Bob]
WITH DEFAULT_SCHEMA = sales;
The last example shows creating a new user from an existing certificate. Certificates are covered later in
this chapter, but for this example, create the certificate first, and then create the user:
USE AdventureWorks2008;
CREATE CERTIFICATE SalesCert
ENCRYPTION BY PASSWORD = ‘[email protected]’
WITH SUBJECT = ‘Sales Schema Certificate’,
EXPIRY_DATE = ‘12/31/2010’;
GO
CREATE USER SalesSecurity FOR CERTIFICATE SalesCert;
GO
You can also use the ALTER USER statement to make changes to a user account. This is another example
where Transact-SQL gives you greater flexibility than Management Studio. ALTER SCHEMA lets you modify
both the name property and the DEFAULT_SCHEMA property. If you wish to change the Windows or SQL
login that the account is associated with, you can use the LOGIN = option, as well. Be aware that the LOGIN
option can only be used to associate a user to a login that is the same type as the one it was originally
created as. This will not work for users created as certificate or keys. These options are illustrated in the
following examples:
USE AdventureWorks2008
ALTER USER SalesSecurity
WITH NAME = SalesSchemaSecurity;
GO
USE AdventureWorks2008
ALTER USER BillyBob
WITH DEFAULT_SCHEMA = Production;
GO
--Create a new login
218
11:54am
Page 218
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
USE master
CREATE LOGIN TempCarol WITH PASSWORD = ‘MyPassword’,
CHECK_POLICY = OFF;
GO
USE tempdb
ALTER USER Carol WITH Login = TempCarol;
GO
Finally, once a user has outlived its usefulness, use the DROP USER statement to remove it from the
database. The DROP USER statement is straightforward, as seen in the following example:
USE AdventureWorks2008
DROP USER BillyBob;
GO
Older versions of SQL explicitly tied an object owner into the naming context of the object. For example,
if a user named BillyBob created a table called Orders, the table would be called BillyBob.Orders. SQL
Server 2008 allows you to separate an object’s schema from its owner. This helps to minimize orphaned
objects when a user is dropped by keeping those objects part of a schema that may be owned by a role
or a Windows group. Although it was easier to manage objects that were all owned by dbo, as seen in
previous versions, using schemas helps provide a more logical, hierarchical security design.
Fixed Database Roles
Every SQL database has a list of fixed database roles that allow you to delegate permissions to users as
necessary. As with the fixed server roles, membership is the only thing you can change about these roles.
It is important to know how and when to use these roles.
The following table shows the fixed database roles:
Role
Description
db_accessadmin
This role can add or remove access for Windows logins, Windows
groups, and SQL Server logins.
db_backupoperator
This role has the right to back up the database.
db_datareader
Members of this role can read data from all user tables.
db_datawriter
Members of this role can write data to all user tables.
db_ddladmin
This role can execute data definition language (DDL) statements for
any object in the database.
db_denydatareader
This role is explicitly excluded from being able to read from any user
table with the database.
db_denydatawriter
This role is explicitly excluded from being able to write to any table
in the database.
Continued
219
Page 219
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Role
Description
db_owner
Members of this role can perform any activity within the database.
This role can also drop the database from the server. The dbo user is
automatically a member of this role.
db_securityadmin
This role can manage permissions and role membership within the
database.
public
Membership in the public role is automatic. Permissions that apply
to the public role apply to everyone who accesses the database.
Note that the fixed database roles include db_denydatareader and db_denydatawriter. These roles
explicitly deny Read or Write access to user tables in the database and should be used sparingly. Deny
permissions are authoritative and cannot be overridden.
User-defined database roles offer greater control over managing permissions and access to resources
within a database. Frequently, when using a role-based security model, you may find that built-in principals (such as groups in Windows or roles in SQL) offer either too much access or not enough. In this
case, you can create user-defined roles that allow you to control access to securable objects for an entire
collection of users at once. Database roles are very similar in concept to Windows groups. You can create
a database role to identify a group of users, all of whom need access to a common set of resources, or you
can use roles to identify the permissions being granted to a securable in the database. Regardless of the
purpose of your role, its function should be clearly identified by the name of the role.
Creating a New User-Defined Database Role in Management Studio
In the New Role dialog box, you are prompted to provide a name for the role, as well as identify an
owner for the role. The owner of the role can modify it at any time. You can also select existing schemas
that will be owned by this role and add users as members to this role. In addition to the General property
sheet, you also have the Securables page and the Extended Properties page, which you can use to assign
permissions or set additional attributes, respectively.
In this example, you can create a new database role called ProductionRole and then add Carol as a
member:
1.
2.
3.
4.
5.
6.
7.
8.
220
In Object Explorer, expand Databases.
Expand AdventureWorks2008 and then expand Security.
Expand Roles and then expand Database Roles.
Right-click ‘‘Database Roles’’ and select ‘‘New Database Role.’’
In the ‘‘Role name’’ box, type ProductionRole (see Figure 6-7).
Under the list of members of this role (which should be empty), click Add.
Enter Carol in the window and click ‘‘Check Names.’’ This should resolve her name.
Click OK.
In the Database Role–New window, click OK.
11:54am
Page 220
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Figure 6-7: Database Role–New properties screen.
CREATE ROLE
CREATE ROLE is the Transact-SQL equivalent for creating a new user-defined database role. When using
the CREATE ROLE statement as shown here, you can also specify the owner of the role. Note that if you
are assigning a user as the owner of a role, you must have the IMPERSONATE permission, and if you’re
assigning another role as the owner, you must either be a member of that role or have ALTER permission on the role. The following statement creates a role called SalesStaff, designating Carol as
the owner:
USE AdventureWorks2008
CREATE ROLE SalesStaff
AUTHORIZATION Carol;
GO
The ALTER ROLE statement is fairly limited, allowing you to change only the name of the role:
USE AdventureWorks2008
ALTER ROLE SalesStaff
WITH NAME = SalesStaffRole;
GO
221
Page 221
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
DROP ROLE rolename will let you remove a role from the database once it is no longer needed:
USE AdventureWorks2008
DROP ROLE SalesStaffRole;
GO
As with fixed server roles, database roles (both fixed and user-defined) can have users added to them
either through SQL Server Management Studio or through a stored procedure. The stored procedure for
database roles is sp_addrolemember. Unlike the stored procedures for adding and dropping members
from server roles, sp_addrolemember and sp_droprolemember identify the role as the first variable and
the user as the second.
The following example adds the database user Carol to the db_datareader role:
USE AdventureWorks2008
EXEC sp_addrolemember ‘db_datareader’, ‘Carol’;
GO
To remove Carol from the db_datareader role, use the following stored procedure:
USE AdventureWorks2008
EXEC sp_droprolemember ‘db_datareader’, ‘Carol’;
GO
Application Roles
Another type of role that can be used to help secure the database environment is the application role.
Application roles are quite different from standard role types. They do not have members, and they
can (and should) be configured to authenticate with a password. Application roles are typically used
when database access must be the same for all users who run a particular application. Rather than
depending on the individual user to have the appropriate access for the application to work properly, the
application can instantiate the application role without prompting the user to provide a username and
password.
You can create a new application role from the Application Roles folder within SQL Server Management
Studio. The dialog box for creating a new application role is very similar to the standard database role
dialog, with the exception of the password field and the lack of a members list.
Try It Out
Create an Application Role
In this example, you create a new application role named PurchasingOrderEntry, with a password of
POEpass1:
1.
2.
3.
4.
5.
222
In Object Explorer, expand Databases.
Expand AdventureWorks2008 and then expand Security.
Expand Roles and then expand Application Roles.
Right-click ‘‘Application Roles’’ and select ‘‘New Application Role.’’
Type PurchasingOrderEntry for the Role name (see Figure 6-8).
11:54am
Page 222
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Figure 6-8: Application Role–New properties screen.
6.
7.
8.
Set the Default schema to ‘‘Purchasing.’’
Enter POEpass1 in the Password and ‘‘Confirm password’’ boxes.
Click OK.
In the next section, you see how to instantiate that role.
Using CREATE APPLICATION ROLE
The CREATE APPLICATION ROLE does what the name suggests. When using this statement, specify the
name of the application role, a password for the application role, and, optionally, a default schema for
the application role. The following example creates an application role named SalesApp:
USE AdventureWorks2008
CREATE APPLICATION ROLE SalesApp
WITH PASSWORD = ‘[email protected]’,
DEFAULT_SCHEMA = Sales;
GO
223
Page 223
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
To use an application role, you can execute the sp_setapprole stored procedure. This can be called from
an application, or you can test it from your Query window. The stored procedure includes options to
activate the application role by providing an encrypted password, creating a cookie, and setting information in the cookie. The following command activates the SalesApp application role and then returns the
username:
USE AdventureWorks2008
GO
DECLARE @cookie varbinary(8000);
EXEC sp_setapprole ‘SalesApp’, ‘[email protected]’
, @fCreateCookie = true, @cookie = @cookie OUTPUT;
GO
SELECT USER_NAME();
Once you’ve executed the preceding script, all activity performed from that connection operates under
the application role. When the connection is closed, the application role session ends.
With the ALTER APPLICATION ROLE statement, you can change the name of the application role, the password, and the default schema. The following example changes the SalesApp role name to OrderEntry
and sets a new password:
USE AdventureWorks2008
ALTER APPLICATION ROLE SalesApp
WITH NAME = OrderEntry,
PASSWORD = ‘[email protected]’;
GO
If you intend to run the ALTER APPLICATION ROLE script listed previously, ensure that you don’t do it
while connected as that application role. Opening a new Query window under your own credentials will
prevent errors.
DROP APPLICATION ROLE rolename will remove an application role from the database. Ensure that you
do not have any applications still using the application role; otherwise, the application will be unable to
connect to the database. For example:
USE AdventureWorks2008
DROP APPLICATION ROLE OrderEntry;
GO
For More Information
The following Security Catalog Views can be used to identify which principals exist in your database,
and their role membership:
224
View
Description
sys.database_principals
Returns information about all database-level principals.
sys.database_role_members
Returns the ID of each database role and its members.
11:54am
Page 224
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
For backward compatibility, Microsoft SQL Server 2008 supports the following stored procedures. Keep
in mind that these stored procedures are considered ‘‘legacy’’ tools and may disappear in a future update
or release of SQL Server.
Stored Procedure
Description
sp_adduser
Creates a new database user.
sp_grantdbaccess
Creates a new database user.
sp_dropuser
Removes a database user.
sp_revokedbaccess
Removes a database user.
sp_addrole
Creates a new user-defined database role.
sp_droprole
Removes a user-defined database role.
sp_addapprole
Creates a new application role.
sp_approlepassword
Changes the password for an application role.
sp_dropapprole
Removes an application role from the database.
Permissions
A well-implemented security solution answers three questions about security access. Who are you?
What can you do? And what have you done? The Kerberos security protocol, which was developed at
MIT, is designed to answer these questions through the processes of Authentication (who are you?),
Authorization (what can you do?), and Auditing (what have you done?). In an Active Directory forest,
SQL Server uses Microsoft’s implementation of the Kerberos protocol (named after the three-headed dog
who guarded the entrance to Hades), for the Authentication of logins that are associated with Active
Directory accounts. Permissions, or Authorizations, are managed from within SQL Server itself and may
be configured on server or database objects.
A typical statement to define the permissions on an object or resource will be structured to define a
permission state, an action, the object to which the permission and action will apply, and the security
principal to whom the permission and action will apply on the defined object. Put simply, it will look
like the following:
PermissionState Action ON Object TO Principal
or
GRANT SELECT ON Person.EmailAddress TO Carol
To begin with, you should understand there are essentially three permission states that exist: GRANT,
GRANT_W_GRANT, and DENY. In addition, when a principal does not have an explicit permission
225
Page 225
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
defined, the permission is considered ‘‘revoked.’’ The following table shows the different permission
states:
Permission
Description
GRANT
This state means that you have been given the right to perform this
action or interact with this resource based on what the actual
permission is.
GRANT_W_GRANT
Not only can you perform this action, but you also have the right to
give others the ability to perform this action.
DENY
You cannot perform this action. This is also known as an ‘‘explicit
deny’’ because nothing will allow you to perform this action.
REVOKE
This is not really a permission state as much as it is the absence of a
permission state. Revoked permissions will not show up in a
sysprotects table or sys.sysprotects view, and are considered an
‘‘implicit deny.’’ The idea is that if you haven’t been granted this
permission, either directly or indirectly, such as through
membership in a role with that permission, it is safe to assume that
you shouldn’t be doing that. Therefore, you will not be doing that.
To control permission states, you can use Object Explorer or Transact-SQL. The three commands that you
can use to control permission states are GRANT, REVOKE, and DENY, which are described in the following
table:
226
Command
Description
GRANT
This command allows you to grant the right to perform an action or
interact with an object in a specific way. The GRANT statement includes
the WITH GRANT OPTION statement, which also allows the grantee the
ability to become a grantor of this permission. Note that
WITH GRANT OPTION follows the TO Principal portion of the command.
REVOKE
This command removes any explicit permission granted to the grantee,
either grant or deny. Revoked permissions will remove the ability to
perform that task. Remember that if the user is a member of another
role, he or she may still have the ability to perform the action, unless an
explicit deny is specified.
DENY
This command creates an entry that will prevent the user from
performing the action. Denied permissions cannot be overridden by
grant permissions. For example, if a user specifically had deny insert
permission on a table, but belonged to a role that was given
grant insert permission on that same table, the user’s deny permission
would win.
11:54am
Page 226
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
The following table shows a general list of the actions you can grant, deny, or revoke, and the types of
objects on which you can grant them. A short description is provided for each:
Action
Description
SELECT
Controls the ability to retrieve data.
INSERT
UPDATE
DELETE
EXECUTE
ALTER
REFERENCES
Controls the ability to add a new row to a table
or view.
Controls the ability to change data rows in a
table or view.
Controls the ability to remove data rows from a
table or view.
Controls the ability to launch programmability
objects.
Controls the ability to change all the properties
of an object except ownership. ALTER ANY can
also be used when assigning permissions to all
objects of a specific type at the server scope.
Allows a user to write to an object (using an
INSERT or UPDATE statement) that contains a
foreign key reference without having SELECT
permissions on the underlying object.
Securable
❑
Synonyms
❑
Table-valued functions
❑
Tables and columns
❑
Views and columns
❑
Synonyms
❑
Tables and columns
❑
Views and columns
❑
Synonyms
❑
Tables and columns
❑
Views and columns
❑
Synonyms
❑
Tables and columns
❑
Views and columns
❑
Procedures
❑
Scalar and aggregate functions
❑
Synonyms
❑
Procedures
❑
Scalar and aggregate functions
❑
Service Broker queues
❑
Tables
❑
Table-valued functions
❑
Views
❑
Scalar and aggregate functions
❑
Service Broker queues
❑
Tables and columns
❑
Table-valued functions
❑
Views and columns
Continued
227
Page 227
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Action
Description
VIEW
DEFINITION
Controls the ability to return metadata
information about objects.
Securable
❑
Procedures
❑
Service Broker queues
❑
Scalar and aggregate functions
❑
Synonyms
❑
Tables
❑
Table-valued functions
❑
Views
VIEW CHANGE
TRACKING
Allows the user to view Change Tracking
information for objects on which it is
enabled.
❑
Tables
❑
Schemas
TAKE
OWNERSHIP
Controls the ability to take ownership of an
object. Object owners can change
permissions of the object.
❑
Procedures
❑
Scalar and aggregate functions
❑
Synonyms
❑
Tables
❑
Table-valued functions
❑
Views
❑
Procedures
❑
Scalar and aggregate functions
❑
Service Broker queues
❑
Tables
❑
Table-valued functions
❑
Views
CONTROL
RECEIVE
Controls the ability to have full control of an
object. This is similar to the ALTER
permission but includes TAKE OWNERSHIP.
Controls the ability to retrieve one or more
messages from a queue.
Service Broker queues
Now that you understand the permissions and permission states, take a look at the specific permissions
available. SQL Server 2008 uses a hierarchical security model that allows you to specify permissions that
can be granted at the server, database, schema, or object levels. You can also assign permissions within
tables and views for selected columns.
The next section identifies the scopes in which the different securable objects reside and how you can use
them to control access to your data. Best practices recommend using a role-based administrative model to
simplify the process of creating a secure environment, not only for your databases and database servers,
but also for all of your operations.
228
11:54am
Page 228
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
There are two key strategies you should use when securing your database servers:
❑
The first strategy you should use when granting permissions is known as the principle of least
privilege. This strategy mandates that you give your users appropriate permissions to do their
jobs, and nothing more. By keeping such tight constraints on your database environment, you
can offer a solution that minimizes the attack surface of your servers while maintaining operational functionality.
❑
The second key strategy is defense in depth. A good security implementation will provide security
at all layers of a database application. This might include using IPSec or SSL for communications
between clients and servers, strong password encryption on your authentication servers, and
configuring column-level permissions within a table or view.
When evaluating the different securable objects within SQL Server, you should have a good understanding of where and how permissions apply and how you can use some of the native features of the
hierarchical model to your advantage. Permission applied to a specific class of objects at a higher level in
the hierarchy allows for permission inheritance. For example, if you want Ted to be able to update any
row on every table within the Sales schema, you could simply use the following command:
USE AdventureWorks2008
--First, create the user
CREATE USER Ted WITH DEFAULT_SCHEMA = Sales;
-- Next, Grant Ted update permissions on the Sales Schema
GRANT UPDATE ON SCHEMA :: Sales to Ted;
GO
Alternatively, if you wanted Ted to have the ability to update any object in the database, you could use
the following:
Use AdventureWorks2008
GRANT UPDATE TO Ted;
GO
Take a quick look at the different levels in your security hierarchy. Figure 6-9 outlines the different levels
of security you need to manage. In the Windows scope, you create and manage Windows and Active
Directory security principals (like users and groups) and manage the files and services needed by the
SQL Server and the behavior of the server itself. In the server scope, you manage logins, endpoints, and
databases. In the database scope, you work with users, keys, certificates, roles, assemblies, and other
database objects. Also in this scope are schemas, which aren’t really objects as much as they are object
containers. Finally, within the schema scope, you have data types, XML schema collections, and objects.
These objects include your tables, views, stored procedures, and more.
Server Permissions
Server control permissions can be managed by simply specifying the permission and the login the permission will be assigned to. For example, to grant permissions to create databases to the login Ted, you
could use the following statement:
USE master
GRANT CREATE ANY DATABASE TO Ted;
GO
229
Page 229
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Windows Scope
Server Scope
Logins
Endpoints
Database Scope
Users
Assemblies
Roles
Schemas
View
Table
Keys
Certificates
Scheme Scope
Databases
Figure 6-9: Security levels.
If you also wanted Ted to be able to have the permissions to alter logins and to allow others to alter
logins, you could use the following statement:
USE Master
GRANT ALTER ANY LOGIN TO Ted
WITH GRANT OPTION;
GO
To remove Ted’s ability to alter logins, you could use the following statement:
USE master
REVOKE ALTER ANY LOGIN TO Ted CASCADE;
GO
The CASCADE keyword is required because you gave Ted the GRANT_W_GRANT permission. This ensures
that not only will Ted lose his ability to alter any login, but so will anyone that Ted granted the
ALTER ANY LOGIN permission. If you had not used GRANT OPTION, the CASCADE keyword would have
been optional.
230
11:54am
Page 230
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Note that the preceding example revokes a permission that had been previously granted to Ted. If Ted
were a member of the securityadmin fixed server role, he would still have the ability to alter logins for
that server.
Now, if you want to prohibit Ted from being able to create a new database, you could use the DENY
statement as follows:
USE master
DENY CREATE ANY DATABASE TO Ted;
GO
Contrary to what I said earlier, the DENY permission state isn’t always the end-all be-all answer to whether
or not a login or user will be able to perform a certain action. If a login is a member of the sysadmin fixed
server role, that login has complete control over the SQL Server and its resources, and it wouldn’t make
a lot of sense to prevent that login from being able to access any object on the server. Even if the DENY
permission statement were successfully executed on an object, the sysadmin role can always change the
permissions on that object.
Also, if the GRANT OPTION was specified in the GRANT statement, as with the REVOKE keyword, you will
need to ensure that you use the CASCADE option.
The following table identifies the permissions that can be used to control the server, as well as granting
blanket permissions to any resource of a particular type on the server. You can control access by using
the following statement:
{GRANT | REVOKE | DENY} action on object to principal WITH {options}
Action
Securable
ADMINISTER BULK OPERATIONS
ALTER
❑
ANY CONNECTION
❑
ANY CREDENTIAL
❑
ANY DATABASE
❑
ANY ENDPOINT
❑
ANY EVENT NOTIFICATION
❑
ANY LINKED SERVER
❑
ANY LOGIN
❑
RESOURCES
❑
SERVER STATE
❑
SETTINGS
❑
TRACE
AUTHENTICATE SERVER
Continued
231
Page 231
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Action
Securable
CONNECT SQL
CONTROL SERVER
CREATE
❑
ANY DATABASE
❑
ANY DDL EVENT NOTIFICATION
❑
ENDPOINT
❑
TRACE EVENT NOTIFICATION
❑
ANY DATABASE
❑
ANY DEFINITION
❑
SERVER STATE
EXTERNAL ACCESS ASSEMBLY
SHUTDOWN
UNSAFE ASSEMBLY
VIEW
Endpoints are server-level objects that use a slightly different syntax from server permissions when
granting, revoking, or denying. The following example creates an endpoint named ServiceBroker that
will be used for a Service Broker application (endpoints are covered in Chapter 7, and Service Broker is
introduced in Chapter 19), and then grants the ALTER permission for that endpoint to Ted:
CREATE ENDPOINT ServiceBroker
STATE = STARTED
AS TCP( LISTENER_PORT = 5162 )
FOR SERVICE_BROKER (AUTHENTICATION=WINDOWS);
GO
USE master
GRANT ALTER ON ENDPOINT :: ServiceBroker TO Ted;
GO
The following table lists the permissions you can grant for endpoints:
232
Action
Description
ALTER
Modify all properties of an endpoint, except ownership.
CONNECT
Connect to an endpoint.
CONTROL
Modify all properties of an endpoint, including ownership.
TAKE OWNERSHIP
Take ownership of an endpoint.
VIEW DEFINITION
View metadata about an endpoint.
11:54am
Page 232
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
The next server-level object you can set permissions for is logins. The syntax for setting permissions on
logins is similar to the syntax for setting permissions on endpoints. For example, to give Carol the ability
to alter Ted’s login, you would use the following statement:
USE master
GRANT ALTER ON LOGIN :: Ted TO Carol
WITH GRANT OPTION;
GO
The following table shows how you can control these permissions for logins:
Action
Description
ALTER
Change any property of an existing login except ownership.
CONTROL
Change all properties of an existing login including
ownership.
IMPERSONATE
Perform an action as that login.
VIEW DEFINITION
View metadata information about that login.
Finally, the last object type at the server level is the database object. Unlike logins and endpoints, database
permissions are specified for database users. This keeps the security of the database within the database
itself. Additional options may be available based on whether you are granting, denying, or revoking. The
following table lists permissions that can be granted on the database object.
Action
ALTER
Securable
❑
ANY APPLICATION ROLE
❑
ANY ASSEMBLY
❑
ANY ASYMMETRIC KEY
❑
ANY CERTIFICATE
❑
ANY CONTRACT
❑
ANY DATABASE DDL TRIGGER
❑
ANY DATABASE EVENT NOTIFICATION
❑
ANY DATASPACE
❑
ANY FULLTEXT CATALOG
❑
ANY MESSGE TYPE
❑
ANY REMOTE SERVICE BINDING
❑
ANY ROLE
❑
ANY ROUTE
❑
ANY SCHEMA
Continued
233
Page 233
Leiter
c06.tex
Chapter 6: SQL Server 2008 Security
Action
Securable
❑
ANY SERVICE
❑
ANY SYMMETRIC KEY
❑
ANY USER
❑
DATABASE
❑
LOG
❑
AGGREGATE
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
DATABASE
❑
DATABASE DDL EVENT NOTIFICATION
❑
DEFAULT
❑
FULLTEXT CATALOG
❑
FUNCTION
❑
MESSAGE TYPE
❑
PROCEDURE
❑
QUEUE
❑
REMOTE SERVICE BINDING
❑
ROLE
❑
ROUTE
❑
RULE
❑
SCHEMA
❑
SERVICE
❑
SYMMETRIC KEY
AUTHENTICATE
BACKUP
CHECKPOINT
CONNECT
CONNECT REPLICATION
CONTROL
CREATE
234
V3 - 03/25/2009
11:54am
Page 234
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Action
Securable
❑
SYNONYM
❑
TABLE
❑
TYPE
❑
VIEW
❑
XML SCHEMA COLLECTION
❑
DATABASE STATE
❑
DEFINITION
DELETE
EXECUTE
INSERT
REFERENCES
SELECT
SHOWPLAN
SUBSCRIBE QUERY NOTIFICATIONS
TAKE OWNERSHIP
UPDATE
VIEW
Database Scope Permissions
In the database scope, there are additional permissions you can assign based on the different types of
securable objects you have. Permissions assigned to an object class allow you to perform the defined
action on all members of that class. However, an object can be explicitly identified by declaring the class
and then the object name. The syntax for assigning permissions to database securables is as follows:
{GRANT | REVOKE | DENY} action ON class :: object TO principal
In the following example, you can grant the CONTROL permission for the Sales schema to the user Alice:
USE AdventureWorks2008
CREATE USER Alice FOR LOGIN [AughtEight\Alice]
WITH DEFAULT_SCHEMA = SALES;
GO
GRANT CONTROL ON SCHEMA :: Sales TO Alice;
GO
235
Page 235
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
The following table lists the various permissions and the database objects and classes to which you can
assign them:
Action
ALTER
CONTROL
236
Securable
❑
APPLICATION ROLE
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
FULLTEXT CATALOG
❑
MESSAGE TYPE
❑
REMOTE SERVICE BINDING
❑
ROLE
❑
ROUTE
❑
SCHEMA
❑
SERVICE
❑
SYMMETRIC KEY
❑
USER
❑
APPLICATION ROLE
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
FULLTEXT CATALOG
❑
MESSAGE TYPE
❑
REMOTE SERVICE BINDING
❑
ROLE
❑
ROUTE
❑
SCHEMA
❑
SERVICE
❑
SYMMETRIC KEY
❑
USER
11:54am
Page 236
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Action
Securable
DELETE
SCHEMA
EXECUTE
❑
ASSEMBLY
❑
SCHEMA
IMPERSONATE
USER
INSERT
SCHEMA
REFERENCES
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
FULLTEXT CATALOG
❑
MESSASGE TYPE
❑
SCHEMA
❑
SYMMETRIC KEY
SELECT
SCHEMA
SEND
SERVICE
TAKE OWNERSHIP
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
FULLTEXT CATALOG
❑
MESSAGE TYPE
❑
REMOTE SERVICE BINDING
❑
ROLE
❑
ROUTE
❑
SCHEMA
❑
SERVICE
❑
SYMMETRIC KEY
UPDATE
SCHEMA
VIEW CHANGE TRACKING
SCHEMA
Continued
237
Page 237
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Action
VIEW DEFINITION
Securable
❑
APPLICATION ROLE
❑
ASSEMBLY
❑
ASYMMETRIC KEY
❑
CERTIFICATE
❑
CONTRACT
❑
FULLTEXT CATALOG
❑
MESSAGE TYPE
❑
REMOTE SERVICE BINDING
❑
ROLE
❑
ROUTE
❑
SCHEMA
❑
SERVICE
❑
SYMMETRIC KEY
❑
USER
Schema Scope Permissions
Finally, within the scope of a schema, there are additional permissions you can assign to objects, data
types, and XML schema collections. When granting permissions to schema-level objects, the syntax is
similar to what you saw earlier:
{GRANT | REVOKE | DENY} action ON class :: securable TO principal
When the class is an OBJECT, you can omit OBJECT :: as long as the schema name is included with the
object name, as in the following example:
Use AdventureWorks2008
GRANT SELECT, UPDATE ON Person.Person to Alice;
GO
Schema objects include the following:
238
❑
Aggregates
❑
Constraints
❑
Functions
❑
Procedures
11:54am
Page 238
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
❑
Queues
❑
Statistics
❑
Synonyms
❑
Tables
❑
Views
The following table lists the schema classes and the permissions that can be set for each of them. Remember that not all permissions are valid for every object type. You can’t expect to grant EXECUTE on a table,
or SELECT on a stored procedure.
Class
OBJECT
TYPE
XML SCHEMA COLLECTION
Permissions
❑
ALTER
❑
CONTROL
❑
DELETE
❑
EXECUTE
❑
INSERT
❑
RECEIVE
❑
REFERNCES
❑
SELECT
❑
TAKE OWNERSHIP
❑
UPDATE
❑
VIEW CHANGE TRACKING
❑
VIEW DEFINITION
❑
CONTROL
❑
EXECUTE
❑
REFERNCES
❑
TAKE OWNERSHIP
❑
VIEW DEFINITION
❑
ALTER
❑
CONTROL
❑
EXECUTE
❑
REFERNCES
❑
TAKE OWNERSHIP
❑
VIEW DEFINITION
239
Page 239
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Using SQL Server Management Studio for Managing
Permissions
You can also use Object Explorer in SQL Server Management Studio to set or view permissions on objects.
In this section, you will learn how to use the GUI to control access to SQL resources.
The first thing to look at is auditing permissions on the objects themselves.
For the next example, create a new login, a new database user for the AdventureWorks2008 database, and
then grant control permissions to the Sales schema for this new user. Use the following code:
USE master
CREATE LOGIN Chris WITH PASSWORD = ‘[email protected]’,
DEFAULT_DATABASE = AdventureWorks2008;
GO
USE AdventureWorks2008
CREATE USER Chris WITH DEFAULT_SCHEMA = Sales;
GO
GRANT CONTROL ON SCHEMA :: SALES TO Chris;
GO
Now, use Object Explorer to see what permissions have been granted to Chris. First, look at the database
itself:
1.
2.
3.
4.
5.
Expand your server.
Expand Databases.
Right-click AdventureWorks2008 and select Properties.
Select Permissions.
In the Users or Roles pane, select ‘‘Chris.’’
Under ‘‘Explicit permissions for Chris,’’ scroll down until you find ‘‘Connect.’’ Note that the user who
granted the permission, in this case the dbo, is also listed in the Grantor column.
Next to the list of explicit permissions for this user, there is an ‘‘Effective Permissions’’ tab. Clicking on
this tab will give you a list of the permissions the user has for this resource, including those that were
granted through membership in a role or group. This new feature can really help simplify the process of
auditing your security settings, or troubleshooting why a user is having problems accessing a resource.
Because you granted control of the Sales schema to Chris, take a look at what permissions have actually
been assigned to that schema and the objects within it. To do this, open the property sheet for Chris’s
user account in the AdventureWorks2008 database (see Figure 6-10):
1.
2.
240
Close the Database Properties — AdventureWorks2008 window by clicking OK or Cancel.
In Object Explorer, expand AdventureWorks2008.
11:54am
Page 240
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Figure 6-10: Property sheet for Chris.
3.
4.
5.
6.
7.
8.
9.
Expand Security.
Expand Users.
Right-click ‘‘Chris’’ and select ‘‘Properties.’’
Select the Securables page and click Search.
Select ‘‘All objects belonging to the schema.’’
From the ‘‘Schema name’’ dropdown list, select ‘‘Sales.’’
Click OK.
If you look at the list of explicit permissions on the Sales schema, notice that Chris only has CONTROL
permissions. Clicking the ‘‘Effective Permissions’’ tab will show you that the user has full access to any
object in the schema.
Now, take a look at specific objects in the Sales schema. Select CreditCard in the list of Securables, and
select the ‘‘Effective Permissions’’ tab.
241
Page 241
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Look at the list of explicit permissions for Sales.CreditCard (see Figure 6-11), and notice that Chris has
no explicit permissions on this table. Clicking the ‘‘Effective Permissions’’ tab will show you that the user
has full access to the table and its contents.
Figure 6-11: Sales.CreditCard permissions.
You now have a user with full access to the Sales schema, but no access to resources outside of it. Any
attempt to query a view in another schema will result in the following error:
SELECT * FROM HumanResources.vEmployee
-----------------------------------------------------------------------------Msg 229, Level 14, State 5, Line 1
SELECT permission denied on object ‘vEmployee’, database ‘AdventureWorks2008’,
schema ‘HumanResources’.
242
11:54am
Page 242
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Also note that you can add permissions for database objects in the User Properties dialog box. You can
use the Management Studio to assign permissions by editing the properties of the securable, or by editing
the properties of a principal.
SQL Ser ver Encr yption
Protecting data, both in storage and during transmission, is important for the integrity of your applications and services. Microsoft SQL Server 2008 offers several options for both. In this section, you will see
some of the tools available for protecting your data.
First of all, whether you’re using symmetric keys, asymmetric keys, or certificates, there are two main
components to encrypting data: the encryption algorithm and the key value. The encryption algorithms
available include Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), RC4, and
Advanced Encryption Standard (AES_256), as well as others. An encryption algorithm is simply a mathematical formula that dictates how to turn the data from plain text into cipher text. The key is a value that
is used within that formula to determine the actual output based on the input. It’s not unlike basic algebra, where you take a statement like x + y = z. In this case, x is the plain-text value, y is the encryption
key, and z is the cipher text. Fortunately, the encryption algorithms are significantly more complex than
that, but you get the idea.
Keys come in two flavors: symmetric and asymmetric. Symmetric keys use the same data key value
to both encrypt and decrypt data. This is actually very good for encrypting large amounts of data,
but has a relatively low level of security. Asymmetric keys use one key value for encrypting data and
a different value for decrypting data. This provides a higher level of security than symmetric keys,
but is a costly operation and not good for large amounts of data. A well-designed encryption method
encrypts data using symmetric keys, and encrypts the symmetric keys using asymmetric keys. Certificates use asymmetric keys, but have additional functionality that can be used for authentication and nonrepudiation.
Now, take a look at how SQL provides encryption services. Figure 6-12 shows a high-level overview of
the encryption hierarchy used by SQL Server 2008. At the top level is the Windows layer, which includes
the Windows Data Protection API (DPAPI). The DPAPI is responsible for encrypting the server’s service
master key using the server’s local machine key. The service master key is the top of the encryption food
chain within the SQL environment. The service master key is automatically generated the first time a
lower-level key is created.
Beneath the service master key is the database master key. The database master key can protect the private
keys of all certificates and asymmetric keys within a database. It is a symmetric key that is encrypted
using the 3DES algorithm and a password. Copies of the key are encrypted using the service master key
and are stored in both the master database and the database for which it was created. If the database
is moved to another server, the database master key can be decrypted by using the OPEN MASTER KEY
statement and providing the password used to encrypt it.
Also in the database scope are symmetric and asymmetric keys you can create for encrypting data, as
well as certificates that can also be used for digital signing and non-repudiation. Creating and managing
the different key types are discussed in the next section.
243
Page 243
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Windows DP API
Windows Level
Service Master Key
Server Level
Database Master Key
Asymmetric
Key
Symmetric
Key
Certificate
Data
Symmetric
Key
Data
Data
Data
Database Level
Figure 6-12: Encryption hierarchy.
One of the first steps you should take is creating the database master key. Remember that the database
master key is a symmetric key that encrypts all private key data within the database. This is helpful if
you are using asymmetric keys or certificates, in that they can be created without having to supply a
password or other mechanism to protect the private keys associated with both. To create a new master
key for the AdventureWorks2008 database, you can execute the following command:
USE AdventureWorks2008
CREATE MASTER KEY
ENCRYPTION BY PASSWORD = ‘[email protected]’;
GO
Creation of a master key requires CONTROL permission on the database. Also, if you already have a master
key created, you must drop the existing one if you need to create a new master key. An existing master
key cannot be dropped if it is being used to encrypt a private key in the database.
Once you’ve created your master key, you can query the sys.databases catalog view to see if the
database master key has been encrypted using the service master key by looking at the value of the
244
11:54am
Page 244
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
is_master_key_encrypted_by_server column. This column uses a Boolean value to indicate whether
the database master key is encrypted with the service master key. The value may be 0 if the database
master key was created on another server.
SELECT NAME, [is_master_key_encrypted_by_server] FROM sys.databases
GO
Before continuing on to the subject of working with other keys to encrypt database information, let’s
look at the topic of backing up your service master key and database master keys. This can be extremely
valuable in case you have to perform a disaster-recovery operation and need to recover data that had
been protected or encrypted with one of these keys. The syntax for both keys is similar, but an additional
step is required to back up an encrypted database master key.
Let’s start with the service master key first. Quite simply, use the BACKUP SERVICE MASTER KEY statement
with a file path, which can be a local or UNC path, and a password that meets your password-complexity
requirements. Using a password on the backup file prevents someone from being able to restore your
master key on another server and then being able to decrypt your database master keys. The following
example will save a backup of the service master key to a folder called C:\KeyBackups (this folder must
already exist):
BACKUP SERVICE MASTER KEY TO FILE = ‘C:\KeyBackups\ServiceMasterKey’
ENCRYPTION BY PASSWORD = ‘[email protected]@ssw0rd’;
GO
If you need to restore the service master key, you can issue the following statement:
RESTORE SERVICE MASTER KEY FROM FILE = ‘C:\KeyBackups\ServiceMasterKey’
DECRYPTION BY PASSWORD = ‘[email protected]@ssw0rd’;
GO
To back up and restore a database master key, use the following examples:
--Backup the database master key
USE AdventureWorks2008;
OPEN MASTER KEY
DECRYPTION BY PASSWORD = ‘[email protected]’
BACKUP MASTER KEY TO FILE = ‘C:\KeyBackups\AWorksMasterKey’
ENCRYPTION BY PASSWORD = ‘dn9e8h93ndwjKJD’;
GO
--Restore the database master key
USE AdventureWorks2008;
RESTORE MASTER KEY FROM FILE = ‘c:\KeyBackups\AWorksMasterKey’
DECRYPTION BY PASSWORD = ‘dn9e8h93ndwjKJD’
ENCRYPTION BY PASSWORD = ‘[email protected]’
GO
There are a couple of things to note about the previous example. First, in order to back up the database
master key, you must decrypt it by using the password that was originally used to encrypt it. Also note
that when you use the RESTORE MASTER KEY statement, you need to provide a password for encrypting
the database master key. The command will fail without this step.
245
Page 245
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Extensible Key Management (EKM)
One of the most important new features of SQL Server 2008 is Extensible Key Management, or EKM for
short. EKM works with the Microsoft Cryptographic API (MSCAPI) to allow encryption keys that are
used for data encryption, as well as encryption of other keys, to be generated and stored outside of the
SQL Server 2008 environment. This provides a more robust and flexible mechanism for key management,
given that you can now separate the keys from the data they protect.
This is often accomplished through the use of Hardware Security Models (HSM). HSM vendors can
create a provider that will interface with the MSCAPI, exposing at least some of the features of the HSM
to SQL Server 2008 and other applications that leverage the MSCAPI. Unfortunately, because MSCAPI
acts as a middle tier between the HSM and the SQL Server, not all of the features of the HSM may be
exposed to the SQL Server.
In order to use EKM, you must first enable it on the server. It is turned off by default, but can be turned
on with the sp_configure command. Because enabling EKM is considered an advanced feature, the
show advanced configuration must also be specified. The following example shows you how to turn on
EKM for your server:
sp_configure ‘show advanced’, 1;
GO
RECONFIGURE
GO
sp_configure ‘EKM provider enabled’, 1;
GO
RECONFIGURE
GO
With EKM enabled, you can now store your encryption keys on HSM modules, smart cards, or USB
devices. Whenever data is encrypted using a key stored on one of these devices, that same device must be
present in order to decrypt the data. This can protect against an unauthorized user copying and attaching
the database files to a rogue SQL Server and being able to access all your confidential data.
EKM can also be leveraged to provide the following benefits:
❑
Additional authorization checks
❑
Easier key recovery
❑
Encryption key retrieval
❑
External key generation and storage
❑
External key retention and rotation
❑
Higher performance when using hardware-based encryption and decryption
❑
Manageable key distribution
❑
Secure key disposal
Encryption Tools
Now that you understand some of the basics of encryption, take a look at creating and managing encryption tools. Each of the objects in this section serves a specific purpose. After you learn how to create
symmetric keys, asymmetric keys, and certificates, you will learn how to use them.
246
11:54am
Page 246
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Symmetric Keys
As mentioned earlier, symmetric keys offer an efficient model for being able to encrypt large amounts of
data. The resource overhead is minimized by using the same keys for both encryption and decryption.
Here’s the syntax for generating symmetric keys:
CREATE SYMMETRIC KEY name [AUTHORIZATION owner] [FROM PROVIDER] providername
WITH options
ENCRYPTION BY mechanism
The following table shows the arguments that can be used:
Argument
Description
AUTHORIZATION owner
Identifies who the owner of the key is.
FROM PROVIDER
Specifies that an EKM provider will be used and the
name of the provider.
KEY_SOURCE pass phrase
Identifies a pass phrase used to derive the key.
ALGORITHM
Choose one of the following: DES, TRIPLE_DES,
TRIPLE_DES_3KEY, RC2, RC4, RC4_128, DESX,
AES_128, AES_192, AES_256.
IDENTITY_VALUE pass phrase
Used to generate a GUID for identifying data that has
been encrypted with this key.
CREATION_DISPOSITION
When using an EKM device, you can specify to create
a new key on the device or map the symmetric key to
an existing one by using the following options:
ENCRYPTION BY mechanism
Try It Out
❑
CREATE_NEW
❑
OPEN_EXISTING
One or more of the following methods for encrypting
the symmetric key:
❑
CERTIFICATE certificate_name
❑
PASSWORD = ‘password’
❑
SYMMETRIC KEY symmetric_key_name
❑
ASYMMETRIC KEY asym_key_name
Create a Symmetric Key
The following example creates a new symmetric key named SalesKey1, which uses the 192-bit Triple
DES 3-Key algorithm:
USE AdventureWorks2008
GO
--Create Symmetric Key
247
Page 247
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
CREATE SYMMETRIC KEY SalesKey1
WITH ALGORITHM = TRIPLE_DES_3KEY,
KEY_SOURCE = ‘The quick brown fox jumped over the lazy dog’,
IDENTITY_VALUE = ‘FoxAndHound’
ENCRYPTION BY PASSWORD = ‘[email protected]’;
GO
You can add or remove methods for encrypting the key with the ALTER SYMMETRIC KEY statement, and
you can remove a symmetric key by using the DROP SYMMETRIC KEY statement.
In this example, use the SalesCert certificate created in the earlier section, ‘‘Database Users,’’ to encrypt
the symmetric key and remove the password encryption from the previous example:
--Open the symmetric key
OPEN SYMMETRIC KEY SalesKey1
DECRYPTION BY PASSWORD = ‘[email protected]’
--Add encryption using the certificate created earlier
ALTER SYMMETRIC KEY SalesKey1
ADD ENCRYPTION BY CERTIFICATE SalesCert
--Remove the password encryption
ALTER SYMMETRIC KEY SalesKey1
DROP ENCRYPTION BY PASSWORD = ‘[email protected]’
--Close the symmetric key
CLOSE SYMMETRIC KEY SalesKey1
Asymmetric Keys
Asymmetric keys use a pair of keys rather than a single one. These keys are often referred to as the public key
and the private key. One key is used for encryption, and the other is used for decryption. It doesn’t really
matter which key is used for encryption, but the data cannot be decrypted without the corresponding
key. The process for creating an asymmetric key pair is similar to creating a symmetric key. Here’s the
syntax for generating symmetric keys:
CREATE ASYMMETRIC KEY name [AUTHORIZATION owner] [FROM key_source]
WITH ALGORITHM = algorithm [ENCRYPTION BY PASSWORD = ‘password’]
The following table shows the arguments that can be used:
248
Argument
Description
AUTHORIZATION owner
Identifies who the owner of the key is. The owner
cannot be a role or a group.
FROM key source
Specifies the key source that will be used.
FILE = ‘path to filename’
Specifies a strong-name file that can be used as a
source for the key pair.
EXECUTABLE FILE
Specifies an executable file that can be used to load the
key pair.
11:54am
Page 248
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Argument
Description
ASSEMBLY
Specifies an assembly file that can be used to load the
key pair.
ENCRYPTION BY PASSWORD =
‘password’
Specifies the password used to encrypt the private
key. The password is limited to 128 characters.
ALGORITHM
Choose one of the following: RSA_512, RSA_1024, or
RSA_2048.
KEY_NAME key
When using EKM, this allows you to specify the key
name from the external provider.
CREATION_DISPOSITION
When using an EKM device, you can specify to create
a new key on the device or map the symmetric key to
an existing one by using the following options:
❑
CREATE_NEW
❑
OPEN_EXISTING
When creating an asymmetric key pair, you can specify the owner of the key pair and the key source
(which is either a strong-name file, an assembly, or an executable assembly file). Alternatively, you can
use an algorithm that determines the number of bits used by the private key, selecting a key length using
512, 1,024, or 2,048 bits. You can also use the ENCRYPTION BY PASSWORD option to encrypt the private key.
If you do not specify a password, the database master key will encrypt the private key.
USE AdventureWorks2008
CREATE ASYMMETRIC KEY HumanResources
WITH ALGORITHM = RSA_2048;
GO
You can use the ALTER ASYMMETRIC KEY statement to change the properties of a key pair. You can use the
REMOVE PRIVATE KEY option to take the private key out of the database (make sure you have a backup
of the private key first!), or you can change the way the private key is protected. For example, you can
change the password used to encrypt the private key and then change the protection from password to
database master key, or vice versa.
In the following example, use the following code to encrypt the private key from the HumanResources
key pair created in the earlier example using a password:
USE AdventureWorks2008
ALTER ASYMMETRIC KEY HumanResources
WITH PRIVATE KEY (
ENCRYPTION BY PASSWORD = ‘[email protected]’);
GO
In the next example, you can change the password used to encrypt the private key by first decrypting it,
and then re-encrypting it with a new password:
USE AdventureWorks2008
ALTER ASYMMETRIC KEY HumanResources
249
Page 249
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
WITH PRIVATE KEY (
DECRYPTION BY PASSWORD = ‘[email protected]’,
ENCRYPTION BY PASSWORD = ‘[email protected]*hda’);
GO
Certificates
Certificates (also known as public key certificates) are objects that associate an asymmetric key pair with a
credential. Certificates are objects that can be used not only for encryption, but also for authentication
and non-repudiation. This means that not only can you obfuscate data that would normally be in plain
text, but you can also provide a means of guaranteeing the source, the trustworthiness of that source, or
that the data has not changed since it was signed.
The details of a certificate identify when the certificate was created, the validity period of the
certificate, who created the certificate, and what the certificate can be used for. It also identifies the
public key associated with the certificate and the algorithm that can be used for digitally signing
messages.
The ability to create and use certificates is a feature that was first introduced in SQL Server 2005, and one
that even experienced DBAs may have trouble grasping at first. Certificates are part of the bigger scope of
application security and identity, and the functionality extended to SQL Server 2008 is no different from
how you would use certificates with other applications and services. This topic is almost like opening a
Pandora’s Box, but once you understand the basics of how certificates work and how they can be used to
protect your services and data, you will appreciate their flexibility.
Certificates also have a feature that lets you trace the genealogy of the certificate, its ‘‘family tree,’’ if you
will (see Figure 6-13). This certificate hierarchy identifies not only what Certification Authority (CA) issued
the certificate, but what CA generated the certificate used by the CA to generate the certificate you have.
This is known as the certificate chain. The certificate chain can be used to identify either a common Root
CA (the highest authority in a chain) that can be trusted for authentication or another Root CA that is
considered a trustworthy source. Many applications and operating systems include a list of commercial
CAs that are automatically trusted. When the certificate from a Root CA is trusted, it is assumed that any
certificate that can trace its genealogy back to that root is also trusted. If the certificate is not from a trusted
certificate chain, the user may be warned that the certificate is not trusted, and they should proceed with
caution. Commercial CAs are often used to obtain Server Authentication and SSL certificates, simply
because many Web browsers already trust the most popular Root CAs.
Many organizations have developed their own Public Key Infrastructure (PKI). These companies have
found it necessary to deploy and use certificates for a variety of reasons. Some might use certificates with
smart cards for logging in to their computers. Some may use certificates for encrypting data on the NTFS
file system, using Encrypting File System (EFS). Some organizations may use certificates for digitally
signing applications and macros, so that their users can verify where the application came from or that
it hasn’t been modified. These organizations often have their own CA hierarchy. They may have a Root
CA they manage themselves, or they may have the ability to generate their own certificates that are part
of a third-party certificate chain.
Microsoft SQL Server 2008 has the ability to create its own self-signed certificates. In a way, SQL can be
its own CA, but don’t expect these certificates to be automatically trusted outside of the SQL instance.
The certificates generated by SQL Server conform to the X.509 standard and can be used outside of the
SQL Server if necessary, but they are not part of a trusted hierarchy. A more common approach is to use
a certificate generated by another CA and import that into SQL Server. Certificates can be just as widely
250
11:54am
Page 250
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
used in SQL Server as they can outside SQL. You can use them for server authentication, encryption, and
digital signing.
Figure 6-13: Certificate information.
On the subject of encryption, public key certificates operate in the same way as asymmetric keys. The
key pair, however, is bound to this certificate. The public key is included in the certificate details, and the
private key must be securely archived. Private keys associated with certificates must be secured using a
password, the database master key, or another encryption key. When encrypting data, the best practice
is to encrypt the data with a symmetric key and then encrypt the symmetric key with a public key.
When creating a certificate that will be self-signed, you can use the CREATE CERTIFICATE statement. You
can choose to encrypt the private key using a strong password or by using the database master key.
You can also use the CREATE CERTIFICATE statement to import a certificate and private key from a file.
Alternatively, you can create a certificate based on a signed assembly.
Once the certificate has been created, you can modify the certificate with the ALTER CERTIFICATE statement. Some of the changes you can make include changing the way the private key is protected or
removing the private key from the SQL Server. Removing the private key should be done only if the
certificate is used to validate a digital signature. If the public key had been used to encrypt data or a
symmetric key, the private key should be available for decryption.
It is a good idea when creating certificates to make a backup of the certificate and the associated private
key with the BACKUP CERTIFICATE statement. You can make a backup of the certificate without archiving
the private key, and use the public key for verification or encrypting messages that can only be decrypted
with the private key.
Once a certificate is no longer needed, you can get rid of it with the DROP CERTIFICATE statement. Be
aware that the certificate can’t be dropped if it is still associated with other objects.
251
Page 251
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Try It Out
Create a New Certificate
In the following example, create a new certificate named PersonnelDataCert, which you will use later
to encrypt data. After creating this certificate, back up the certificate to the file system (you can either
change the path in the example or create a new folder on your C: drive called certs). Once that is done,
the last step is to import the certificate into the tempdb database.
-- Create the Personnel Data Certificate
USE AdventureWorks2008;
CREATE CERTIFICATE PersonnelDataCert
ENCRYPTION BY PASSWORD = ‘[email protected]’
WITH SUBJECT = ‘Personnel Data Encryption Certificate’,
EXPIRY_DATE = ‘12/31/2011’;
GO
--Backup the certificate and private key to the file system
Use AdventureWorks2008
BACKUP CERTIFICATE PersonnelDataCert TO FILE = ‘c:\certs\Personnel.cer’
WITH PRIVATE KEY (DECRYPTION BY PASSWORD = ‘[email protected]’,
FILE = ‘c:\certs\Personnelkey.pvk’ ,
ENCRYPTION BY PASSWORD = ‘@notherPassword’ );
GO
--Import the certificate and private key into the TempDB database
USE tempdb
CREATE CERTIFICATE PersonnelDataCert
FROM FILE = ‘c:\certs\Personnel.cer’
WITH PRIVATE KEY (FILE = ‘c:\certs\Personnelkey.pvk’,
DECRYPTION BY PASSWORD = ‘@notherPassword’,
ENCRYPTION BY PASSWORD = ‘TempDBKey1’);
GO
In the next example, change the password used to encrypt the private key using the ALTER CERTIFICATE
statement:
Use tempdb
ALTER CERTIFICATE PersonnelDataCert
WITH PRIVATE KEY (ENCRYPTION BY PASSWORD = ‘[email protected]’,
DECRYPTION BY PASSWORD = ‘TempDBKey1’);
GO
Now you can remove the private key from the AdventureWorks2008 database. Because the certificate and
the private key are backed up, you can perform this action safely.
Use AdventureWorks2008
ALTER CERTIFICATE PersonnelDataCert
REMOVE PRIVATE KEY
GO
Finally, clean up the tempdb database:
USE tempdb
DROP CERTIFICATE PersonnelDataCert;
GO
252
11:54am
Page 252
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
Encrypting Data
Now that you’ve seen the different objects that can be used for encryption or non-repudiation, take a look
at how you can actually use them. First of all, not everything needs to be encrypted. Because the process
of encrypting and decrypting data can be resource-intensive, you should be mindful of what data you
need to encrypt. Data that should be kept confidential (such as credit card or Social Security numbers)
might fall into this category. An employee’s middle name, no matter how embarrassing it might be,
would not. Also note that not every data type can be encrypted with the encryptbykey function. The
valid data types are nvarchar, char, wchar, varchar, and nchar.
It is also a good idea to know when to encrypt the data, and when not to. Frequently queried columns
in tables or views should not be encrypted, because the process of decrypting large amounts of data that
is queried over and over again can often become counterproductive. In this case, a better strategy might
be to store the sensitive information in a separate table that has much tighter security on it. Remember
that you can give insert or update permissions on a row in a foreign table without having to grant select
permissions on that related table. HSMs may offset some of the overhead involved with the decryption
process, but that may require significant testing to verify how well it will perform in production.
Prior to encrypting data, you must open the key that will perform the encryption process. Again, data is
commonly protected with a symmetric key, which is, in turn, protected with an asymmetric key pair. If
the symmetric key is protected with a password, then any user with ALTER permissions on the symmetric
key and the password can open and close the symmetric key. If the symmetric key is protected by an
asymmetric key or certificate, the user also needs CONTROL permissions on the asymmetric key or the
certificate.
Try It Out
Create an Encrypted Column
Use the following sample code to create an encrypted column in the Sales.CreditCard table. In this
example, use the symmetric key SalesKey1 and the certificate SalesCert, both created earlier in this
chapter:
ALTER TABLE Sales.CreditCard
ADD EncryptedCardNumber varbinary(128);
GO
OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY
CERTIFICATE SalesCert WITH PASSWORD = ‘[email protected]’
UPDATE Sales.CreditCard
SET EncryptedCardNumber
= EncryptByKey(Key_GUID(’SalesKey1’), CardNumber);
GO
CLOSE SYMMETRIC KEY SalesKey1;
GO
Because the symmetric key was used to encrypt the data, it will also be used for decryption. Using the
preceding example as a template, you could use the following commands to create another new column
that stores the decrypted data. A SELECT statement is included that allows you to view the original data,
the encrypted data, and the decrypted data columns:
ALTER TABLE Sales.CreditCard
ADD DecryptedCardNumber NVARCHAR(25);
253
Page 253
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
GO
OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY
CERTIFICATE SalesCert WITH PASSWORD = ‘[email protected]’;
GO
UPDATE Sales.CreditCard
SET DecryptedCardNumber
= DecryptByKey(EncryptedCardNumber);
GO
CLOSE SYMMETRIC KEY SalesKey1;
GO
Select TOP (10) CreditCardID, CardNumber AS Original, EncryptedCardNumber AS
Encrypted, DecryptedCardNumber AS Decrypted
FROM Sales.CreditCard;
GO
You don’t have to create a whole new column to view the decrypted data, though. The DECRYPTBYKEY
function can be executed in a SELECT statement to view the unencrypted data. The following example
shows you how:
OPEN SYMMETRIC KEY SalesKey1 DECRYPTION BY
CERTIFICATE SalesCert WITH PASSWORD = ‘[email protected]’;
GO
SELECT CreditCardID, CardNumber,EncryptedCardNumber
AS ‘Encrypted Card Number’,
CONVERT(nvarchar, DecryptByKey(EncryptedCardNumber))
AS ‘Decrypted Card Number’
FROM Sales.CreditCard;
GO
CLOSE SYMMETRIC KEY SalesKey1;
GO
Transparent Data Encryption
Another new feature of SQL Server 2008 is Transparent Data Encryption (TDE). TDE is designed to perform real-time I/O encryption, using a Database Encryption Key (DEK), of the database and transaction
log files for databases that have TDE enabled. The benefit of TDE is that it protects all data ‘‘at rest.’’ This
means that anything not currently being read into memory is protected using the DEK. However, when
a query is run, the data that is retrieved from that query is decrypted as it is being read into memory.
Unlike the use of symmetric and asymmetric keys for decrypting data in a single table or column, it is
not necessary to invoke a decryption function when reading from or writing to a table in a database
protected by TDE (hence the use of the word Transparent).
Setting up TDE is slightly more complex than other encryption methods, in that there are certain dependencies that must be in place before you can enable it.
254
11:54am
Page 254
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
1.
2.
First of all, a Database Master Key must exist in the master database.
3.
Then you will need to create the DEK in the database that you will be encrypting.
Finally, enable encryption on that database. The following script provides an example of
these steps:
Secondly, you must either create a certificate or install a certificate in the master database
that can be used to encrypt the DEK; or you may use an asymmetric key from an EKM
provider.
USE master
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘[email protected]’;
GO
CREATE CERTIFICATE AughtEightTDE WITH SUBJECT =
‘TDE Certificate for the AUGHTEIGHT Server’;
GO
USE AdventureWorks2008
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = TRIPLE_DES_3KEY
ENCRYPTION BY SERVER CERTIFICATE AughtEightTDE;
GO
ALTER DATABASE AdventureWorks2008
SET ENCRYPTION ON;
GO
You can also use SQL Server Management Studio to manage the Transparent Encryption Properties of a
database. Do this by performing the following steps:
1.
2.
In Object Explorer, expand Databases.
Right-click on the AdventureWorks2008 database, and select Tasks, then ‘‘Manage Database
Encryption.’’
As you can see in Figure 6-14, you have several options you can perform from this window, including
‘‘Re-Encrypt Database Encryption Key’’ using a server certificate or server asymmetric key (stored in the
master database), as well as regenerating the key using an AES 128, AES 192, AES 256, or Triple DES
encryption algorithm. You can also enable or disable TDE for this database by checking (or unchecking)
the box next to ‘‘Set Database Encryption On.’’
Digital Signatures
Digital signatures provide authentication and non-repudiation. Often, with public key pairs, the private
key is used to digitally sign a message (or, in the case of a code-signing certificate, an application or
assembly). Take a look at how digital signing works with e-mail messages as an example.
Bob sends Alice a message, and his e-mail client is configured to automatically add his digital signature
to all outgoing messages. In this case, while the message is being prepared for delivery, a key is generated
and passed to a hashing algorithm for a one-way transformation of the data into a hash value. The hash
value is attached to the message, and the key that was used to generate the hash is encrypted with Bob’s
private key.
255
Page 255
Leiter
c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
Figure 6-14: Manage Database Encryption.
The message is delivered to Alice, who receives the message in plain text, as well as receiving the hashed
version of the message. Alice, who has access to Bob’s public key, uses it to decrypt the key that was
used to generate the hash. The key is then passed through the hashing algorithm, and a new hash is
generated. If the new hash matches the hash that was sent with the message, Alice can feel confident that
the message hasn’t been changed during delivery. If the hash values do not match, then the message may
have been altered since it was transmitted and should not be trusted.
In a similar vein, you can use digital signatures to sign SQL Server components (such as stored procedures) to associate the stored procedure with a hash value. If the stored procedure changes by a single
bit, then the hash values will differ; and you’ll know that someone must have used an ALTER PROCEDURE
statement on it!
You can use both asymmetric keys and digital certificates to sign stored procedures, functions,
or DML triggers in SQL Server. The following code creates a simple stored procedure called
Sales.DisplaySomeVendors. You can then add a signature to that stored procedure using the SalesCert
certificate from earlier. The private key will need to be decrypted to digitally sign the stored procedure.
CREATE PROCEDURE Sales.DisplaySomeVendors AS
SELECT TOP (20) * FROM Purchasing.Vendor;
GO
USE AdventureWorks2008;
ADD SIGNATURE TO Sales.DisplaySomeVendors
BY CERTIFICATE SalesCert WITH PASSWORD = ‘[email protected]’;
GO
256
11:54am
Page 256
Leiter c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
If you look at the properties of the stored procedure, you can now see that the stored procedure has been
digitally signed, and it was signed by the SalesCert certificate (see Figure 6-15). You can also query the
sys.crypt_properties catalog view. This view will show any objects that have been digitally signed. In
the next example, you will query the sys.crypt_properties view to see the digital signature assigned
to the Sales.DisplaySomeVendors stored procedure. Then you can alter the procedure, query the view
again, and note that the procedure is no longer digitally signed.
SELECT * FROM sys.crypt_properties
GO
ALTER PROCEDURE Sales.DisplaySomeVendors AS
SELECT TOP (10) * FROM Purchasing.Vendor
GO
SELECT * FROM sys.crypt_properties
Figure 6-15: Digital signature.
Best Practices
Like any other application or server product, there are a few guidelines you should follow to help
increase the level of security in place. Remember that you will never be able to plan for and protect
against every possible threat, but you can make it more difficult for malicious users to gain access to
your data.
257
Page 257
Leiter c06.tex
V3 - 03/25/2009
Chapter 6: SQL Server 2008 Security
258
❑
Use Strong Passwords — As mentioned earlier in this chapter, you should take advantage of
the password policies and require users to create complex passwords that get changed regularly.
You should educate your users about the importance of strong passwords. While password policy enforcement for SQL Logins is managed at the server, you should provide an application or
tool that allows users a way to change their passwords and be notified when their passwords are
about to expire.
❑
No One Should Log on as sa — The sa account should rarely (if ever) log in. To provide more
accurate auditing information, users should be forced to use their own logins (or log in through
the membership in a group) in order to track what users are performing which actions. If everyone has the sa password and everyone is able to log in as that account, nothing would stop them
from being able to steal or destroy your data. You wouldn’t be able to hold that person accountable, because you may not know who that person is!
❑
Use Least-Privilege Accounts for SQL Services — Apply the principle of least privilege, and use
accounts that have exactly the rights and permissions needed by the services, and nothing else.
While it might be tempting to make the SQL Server account or the SQL Server Agent account a
member of an administrative group, it is not necessary. Identify what resources outside of the
SQL Server each of these accounts will be interacting with, and assign only the required permissions.
❑
Audit Principals Regularly — A diligent administrator will know what accounts have been created and who is responsible for these accounts, and identify what steps must be taken to disable
or remove superfluous accounts.
❑
Disable or Remove Any Unused Network Protocols — In the SQL Configuration Manager, you
have the ability to enable or disable protocols used by the SQL Server. Additionally, consider
disabling the NetBIOS protocol for your network adapter if NetBIOS will not be used by your
server or applications.
❑
Use On-the-Wire Encryption to Protect Your Data in Transit — It’s not enough for you to protect the data while it sits idly on the server. As a database administrator, you should use technologies like Secure Sockets Layer (SSL) encryption and Internet Protocol Security (IPSec) to
protect the data while it’s moving from client to server, server to client, or server to server.
❑
Do Not Place the SQL Server in a Location with Poor Physical Security — There is a
well-known article published by the Microsoft Security Response Center known as the ‘‘10
Immutable Laws of Security.’’ The first law dictates that if a malicious user has physical access
to your computer, it’s no longer your computer. Unless you can provide the means to control
access to the hardware, your data can easily be stolen, compromised, damaged, or destroyed.
Hardware locks, secure server rooms, and security personnel can all be instrumental in helping
to protect your data.
❑
Minimize the Visibility of the Server — SQL Servers should never be publicly available. The
Slammer worm should never have been a problem, had application architects and database
administrators taken the necessary precautions to protect against that type of attack. Slammer
was able to propagate so much, so fast, because few organizations recognized the harm in
publishing SQL connectivity through their firewalls. A well-designed database application will
use a robust and secure front-end, minimizing the exposure to the Database Engine.
❑
Remove or Disable Unnecessary Services and Applications — You should minimize the attack
surface of your SQL Server as much as possible by turning off services and features that will not
be used. Typically, it’s a good idea to avoid running other services such as IIS, Active Directory,
and Exchange on the same machine as SQL. Each one of these services can be a potential entry
11:54am
Page 258
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Chapter 6: SQL Server 2008 Security
point for a malicious user to exploit, thereby granting the user access to your data. Because SQL
Server Reporting Services no longer requires IIS, this can help reduce the attack surface of your
system.
❑
Use Windows Authentication Whenever Possible — Windows and Kerberos authentication
are inherently more secure than SQL Authentication, but this is a design decision that you, your
application developers, and security team must address.
❑
Do Not Use Column Encryption on Frequently Searched Columns — Encrypting frequently
accessed or searched columns may cause more problems than it solves. If encrypting a column is
the best, or only, way to protect the data, make sure that the performance impact is tested before
implementing encryption in production.
❑
Use TDE to Protect Data at Rest — Encrypting the database and transaction log files can reduce
the likelihood that someone can copy your data files and walk away with sensitive business data.
❑
Always Back up Data Encryption Keys — This is probably pretty self-explanatory, but make
sure that any of the keys you use to back up your data, or other encryption keys, are safely and
securely backed up. Test your backup and recovery strategy, as well.
❑
Understand Your Role in the Company’s Security Policy — Most organizations have a documented security policy that defines acceptable use for the network and expectations for server or
service behavior. As a database administrator, your responsibilities to configure and secure your
servers may be documented as part of the overall security policy. What is expected of you and of
your servers must be unambiguous. Your liabilities should also be clearly stated.
Summar y
In this chapter, you learned about many of the security features available to you in SQL Server 2008.
You should have a good understanding of the way security is applied to SQL Server from the top down,
including:
❑
How to configure the different authentication modes
❑
How to create and manage server and database principals
❑
How to assign and control permissions
❑
How to protect your data on the server
You should also be able to apply some of the best practices discussed in this chapter to your own environments. Remember that you will never have a server that is 100 percent secure, and you should never be
overconfident of your security design, because complacency leads to sloppiness, which leads to ginormous
holes in your security design. But having read this chapter, you should feel confident in implementing
the security mechanisms covered.
In Chapter 7, you will learn about creating and managing SQL endpoints and how you can enable access
to database resources using a variety of connectivity methods.
259
Page 259
Leiter
c06.tex
V3 - 03/25/2009
11:54am
Page 260
Leiter
c07.tex
V3 - 03/25/2009
11:58am
7
Configuring SQL Ser ver
Network Communication
SQL Server 2008 is a client-server application designed to efficiently exchange data and instructions
over multiple network connections. Understanding the network connections and how they can
be configured is a big part of a DBA’s job. Microsoft has made your job easier by minimizing the
number of network protocols that SQL Server 2008 supports to the most commonly implemented
protocols, but at the same time, the job of the DBA is made more complex by the ability to configure multiple connection types with each protocol with the endpoint server object. This chapter
discusses the different endpoints that can be configured, as well as the protocol configurations that
the endpoints rely on. The chapter also takes a brief look at the client configurations that can be
configured with SQL Server 2008.
SQL Ser ver 2008 Network Protocols
SQL Server 2008 provides support for four protocols:
❑
Shared Memory
❑
TCP/IP
❑
Named Pipes
❑
Virtual Interface Adapter (VIA)
By default, the only network protocols enabled for most editions of SQL Server are TCP/IP and
Shared Memory. The Developer and Enterprise Evaluation editions are configured with all
protocols except Shared Memory disabled during installation, but the remaining protocols can be
enabled if required. If a protocol is not enabled, SQL Server will not listen on an endpoint that is
configured to use that protocol. This helps reduce the attack surface of SQL Server.
SQL Server Configuration Manager is used to configure server protocols. With this tool, each
supported protocol can be enabled, disabled, and configured as required. The configuration options
of the network protocols may not be intuitive, so they justify a little explanation.
Page 261
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Opening SQL Server Configuration Manager displays a node for configuring SQL Server services, SQL
Server network protocols, and SQL Native Client protocols. To configure the Server protocols, expand the
SQL Server 2008 Network Configuration node and select the instance to be configured. The right-hand
pane shows all four of the supported protocols and their status. To display the configurable properties of
any of the protocols, double-click on the protocol or right-click on the protocol and select Properties to
launch the corresponding Properties window.
Shared Memory
The Shared Memory protocol can only be used by local connections, because it is a shared memory and
process space used for inter-server communication. It has only one configurable property: Enabled. The
Enabled property can be set to Yes or No, resulting in a status of Enabled or Disabled. Applications or
tasks that are designed to run locally on a SQL Server can take advantage of the Shared Memory protocol.
Named Pipes
Named Pipes uses Interprocess Communication (IPC) channels for efficient inter-server communication,
as well as local area network (LAN) communication. The Named Pipes protocol has some enhancements
in SQL Server 2008 including support for encrypted traffic, but because of the excessive overhead of
Named Pipes when connecting across networks or firewalls and the additional port that Named Pipes
requires to be opened (445), it is generally a good idea to leave the Named Pipes protocol disabled. However, there are many applications, particularly older applications, that require the Named Pipes protocol
because they were designed around NetBIOS or other LAN-based protocols. Named Pipes provides easy
access to Remote Procedure Calls (RPC) within a single security domain and thus is advantageous to
these applications. If you need to support one of these applications and the SQL Server is not exposed to
external traffic, the risk of enabling the Named Pipes protocol and corresponding endpoint is minimal.
Named Pipes has two configurable properties: Enabled and Pipe Name. The Enabled property works the
same as the Shared Memory protocol. The Pipe Name specifies the inter-process pipe that SQL Server will
listen on. The default pipe is \\.\pipe\MSSQL$<instance_name>\sql\query.
TCP/IP
The TCP/IP protocol is the primary and preferred protocol for most SQL Server installations. It is configured on two separate tabs on the TCP/IP Properties window: the Protocol tab and the IP Addresses tab,
as shown in Figure 7-1.
The Protocol tab has the following three configurable properties:
❑
Enabled — This works the same as the other protocols.
❑
Keep Alive — This specifies how many milliseconds SQL Server waits to verify that an idle connection is still valid by sending a KEEPALIVE packet. The default is 30,000 milliseconds.
❑
Listen All — This specifies whether SQL Server will listen on all IP addresses configured on the
server.
As you can see in Figure 7-1, the ‘‘IP Addresses’’ tab contains configuration settings for each configured
IP address on the server and one section for the configuring of all IP addresses. In addition to IPv4, SQL
Server 2008 now includes support for IPv6 addresses.
262
11:58am
Page 262
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Figure 7-1: Tabs for configuring the TCP/IP protocol.
A detailed explanation of the pros and cons of IPv6 is outside the scope of this book, but you should
be aware that it is not uncommon for a single physical adapter to have multiple IPv6 addresses associated with it. Unlike IPv4 addresses, which allow variable-length network masks, IPv6 addresses use
fixed-length fields for the network portion and the host portion of the address (each portion uses 64
bits, or half, of the available address). A single host may belong to one or more networks, as defined
by the IPv6 protocol. For example, a single host computer will have one IPv6 address to identify it on a
non-routed network segment, a second IPv6 address to identify it on a LAN that may include multiple
routes, and a third IP address to uniquely identify it on the Internet. What is interesting about IPv6 is that
in all cases, the host portion of the address (the second half) stays the same (and is usually a variant of
the hardware, or MAC address of the adapter), and the network portion of the address (the first 64 bits)
will be different, to identify the networks to which the host machine is connected.
SQL Server will have more than one IPv4 address as well, if only to include the loopback (127.0.0.1)
address. All IP addresses, whether version 4 or version 6, are managed from the ‘‘IP Addresses’’ tab of
the TCP/IP Properties window.
IP address settings are described in the following table:
Setting
Description
Active
Specifies whether the individual address is active and available on the server.
This setting is not available for the IPALL configuration (shown in the bottom
of the right-hand pane in Figure 7-1).
Enabled
If the Listen All property on the Protocol tab is set to No, this property
indicates whether SQL Server is listening on the IP address. If the
Listen All property on the Protocol tab is set to Yes, the Enabled property is
ignored. This setting is not available for the IPALL configuration.
Continued
263
Page 263
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Setting
Description
IP Address
Specifies the IP address for individual configuration, not available for the
IPALL configuration.
TCP Dynamic
Ports
Specifies whether the TCP port will be dynamically generated at start-up. If
left blank, dynamic assignment is disabled. A setting of 0 (zero) specifies that
dynamic assignment is enabled.
TCP Ports
Specifies the TCP port to be used for all addresses in the IPALL section or the
port for a specific address in an individual IP address section. If dynamic port
assignment is enabled, this property will display the value of the dynamically
configured port.
Virtual Interface Adapter (VIA)
SQL Server 2008, like its predecessors, also supports the Virtual Interface Adapter protocol, which is used
with supported hardware and network configurations. The Virtual Interface Architecture was jointly
developed by Compaq (now HP), Intel, and Microsoft, and was designed as a high-performance protocol
that could reduce much of the overhead of traditional networking protocols by operating in a user-mode
context instead of in a kernel-mode context. VIA network clients connect to a System Area Network (not
to be confused with a Storage Area Network, despite the fact that they share an acronym).
SQL Native Client Configuration
The same four server-side protocols are supported for the SQL Native Client, and, again, SQL Server
Configuration Manager is used to enable, disable, or configure these protocols. In addition to the configuration of the client protocols, the binding order of the protocols can also be set. You can do this by
expanding the SQL Native Client Configuration node and selecting Client Protocols. In the right-hand
pane, right-click on a protocol and select Order to set the order of all enabled protocols, as shown in
Figure 7-2.
As Figure 7-2 shows, if the Shared Memory protocol is enabled, it is always first in the binding order. It
is not available for manual ordering.
Aliases can be created using the SQL Native Client Configuration. Aliases are very useful in enabling
clients to connect to a server even though the name of the server does not match that in the client’s
connection string. For example, a standby server may be brought up to take the place of a failed server
that serves an application with a hard-coded connection string. Without an alias, either the application’s
connection string would need to be changed, or the server name would have to be changed. By specifying
an alias, client requests can be directed to the server without changing the server name. Aliases can also
be used to replace a complicated named-instance name.
Figure 7-3 shows the alias YODAHOME being configured for the named instance
AUGHTEIGHT\DAGOBAH. To launch the New Alias dialog, right-click on the Aliases node
and select ‘‘New Alias.’’ Once the alias has been created, new connections can be created by referencing
the alias name in lieu of the instance name.
264
11:58am
Page 264
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Figure 7-2: Setting the order of enabled
protocols.
Figure 7-3: Configuring the alias YODAHOME.
SQL Ser ver Endpoints
When SQL Server 2005 came out, there was a lot of confusion and trepidation about SQL Server
Endpoints. More to the point, I think a lot of people I worked with were unsure about what they
were and why they would use them. The term endpoint simply refers to a point of termination on a
265
Page 265
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
network, or to be perfectly precise, an endpoint is the name for the entity on one end of a transport layer
connection. In previous releases of SQL Server, the default network endpoints were UDP port 1434 for
the SQL Server Resolution Service and TCP port 1433 for the default instance of SQL Server. Additional
TCP ports could be configured for the default and/or any additional named instances. Most database
administrators didn’t really think of the server listener as an endpoint, but that’s what it is, and that’s
what it will remain. SQL Server 2008 leverages connection objects as endpoints, allowing SQL Server
2008 to listen on different ports, using different transport protocols for different services.
SQL Server provides four different types of endpoints:
❑
TSQL (both default and TCP)
❑
Database Mirroring
❑
SOAP
❑
Service Broker
Each endpoint provides separate functionality and can be uniquely configured to control access to the
Database Engine and associated services.
Default TSQL Endpoints
TSQL endpoints are essentially the same as the standard endpoints that existed in earlier versions of
Microsoft SQL Server. During installation, five TSQL endpoints are created:
❑
TSQL Default TCP
❑
TSQL Default VIA
❑
TSQL Named Pipes
❑
TSQL Local Machine
❑
Dedicated Administrator Connection (DAC)
The TSQL endpoints are created to provide connection services for the four supported protocols (TCP,
VIA, Named Pipes, and Shared Memory). These protocols correspond to the Default TCP, Default VIA,
Named Pipes, and Local Machine endpoints. The fifth endpoint created to support the DAC listens on a
dedicated TCP port that is configured at start-up to support an administrative connection. The configured
port is logged in the current SQL Server log file. (SQL Server log files are described in Chapter 10.)
Regardless of the condition of the network protocol, TSQL endpoints have two states: started and stopped.
If the network protocol is enabled and the endpoint is started, SQL Server will listen and accept connections on that endpoint. A stopped endpoint still listens, but actively refuses new connections. If the
corresponding protocol is disabled, the TSQL endpoint will not listen and will not respond to client
requests.
TSQL endpoints are also known as Tabular Data Stream (TDS) endpoints. TDS has been around since
Sybase created it in 1984 to support its fledgling relational Database Engine. Microsoft inherited the
protocol during its joint venture with Sybase and has since made many changes to the protocol to make
it more efficient and secure. It remains the primary protocol for transmitting data from SQL Server to
clients via the TCP, Named Pipes, VIA, and Shared Memory protocols.
266
11:58am
Page 266
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
TSQL Default TCP
The TSQL Default TCP endpoint is created during the installation of a SQL Server instance and is automatically configured to listen on port 1433 for default instances. Named-instance TSQL Default TCP
endpoints are randomly assigned a TCP port every time the named instance starts up. However, the port
number for named instances can be statically configured with SQL Server Configuration Manager. Configuring a static port can simplify client access and reduce the dependency on the SQL Server Browser
Service that enumerates named instances.
To statically configure the port that a named instance of SQL Server will listen on, open SQL Server Configuration Manager, expand the SQL Server 2008 Network Configuration node, and select the instance
to configure. Double-click on the TCP/IP protocol in the right-hand pane, or right-click on it and click
Properties to launch the TCP/IP Properties window. By default, SQL Server is configured to listen on all
available IP addresses, and so the only place that the static port needs to be set is in the IPALL section of
the IP Addresses tab on the TCP/IP Properties window (see Figure 7-4). This behavior can be changed by
setting the Listen All property to No on the Protocol tab and individually configuring each IP address.
Figure 7-4: The IPALL section of the IP
Addresses tab.
Figure 7-4 shows the TCP port for the named instance DAGOBAH being statically set to port
50101. When configuring ports for named instances, it is best practice to choose a port above
50,000, because many ports below 50,000 are associated with other applications. To retrieve a list of
reserved and well-known ports, visit the Internet Assigned Numbers Authority (IANA) web site at
www.iana.org/assignments/port-numbers.
Keep in mind that the supported protocols are separate from endpoints, and multiple endpoints can
be configured for each protocol. In fact, it might be necessary to create multiple TCP endpoints, either
for security reasons, such as publishing a SQL Server through a firewall using the non-default port; or
for enabling connections that execute against specific processors with Non-Uniform Memory Access
(NUMA).
267
Page 267
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
By default, all users have access to the Default TCP endpoint. However, access to the endpoint,
as well as any user-created endpoints, can be more tightly controlled with the
GRANT CONNECT | DENY CONNECT | REVOKE CONNECT commands.
The state of any endpoint can also be changed with the ALTER ENDPOINT command, as shown in the
following example:
USE Master;
GO
ALTER ENDPOINT [TSQL Default TCP]
STATE=STOPPED;
USE Master;
GO
ALTER ENDPOINT [TSQL Default TCP]
STATE=STARTED;
TSQL Default VIA
The VIA protocol is used to support VIA hardware devices such as VIA System Area Networks (SAN).
The VIA protocol is dependent on vendor implementations, so a discussion of the VIA endpoint is somewhat difficult without seemingly endorsing one hardware vendor over another. The VIA configurations
are usually very straightforward and only require a port assignment. If you are using a VIA hardware
implementation for your SAN configuration, make sure you get all the technical documentation you can
from your supplier.
TSQL Named Pipes
The Named Pipes endpoint is created to support Named Pipes protocol connections. The Named Pipes
protocol was described earlier in this chapter.
TSQL Local Machine
The TSQL Local Machine endpoint allows connections to occur using the Shared Memory protocol.
Shared Memory is only accessible on the local machine, hence the TSQL Local Machine designation for
this endpoint. Installations of the Enterprise Evaluation and Developer editions of SQL Server 2008 use
this endpoint exclusively, unless additional protocols are enabled.
Dedicated Administrator Connection (DAC)
The Dedicated Administrator Connection (DAC) endpoint is used to support limited administrative
actions when other connections are unavailable or unresponsive. It uses its own memory area, dedicated
TCP port, and CPU scheduler. By default, the DAC endpoint only listens for local connections. Remote
DAC connections can be enabled by executing the following code:
USE Master;
GO
sp_configure ‘remote admin connections’, 1;
GO
RECONFIGURE;
GO
DAC connections are facilitated through the SQLCMD command-line tool.
268
11:58am
Page 268
Leiter c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
TSQL TCP Endpoints
In addition to the default TCP endpoints created automatically, additional TSQL TCP endpoints can be
created. These TSQL TCP endpoints can be created to support special security or application requirements. However, an important fact to keep in mind is that when a new TSQL TCP endpoint is created,
SQL Server automatically revokes all connect permissions to the default endpoint. If connection support
is still required for the default endpoint, explicit GRANT CONNECT permissions will be necessary to use the
default endpoint. SQL Server helps you remember this important fact by always returning a message
informing you of the impact of creating a new TCP endpoint, as shown in the next example.
If an additional TSQL TCP endpoint is needed, it can be created using T-SQL. The following example
creates an additional TSQL TCP endpoint that is configured to listen on port 50102 and all IP addresses
and shows the resulting message warning about permissions:
USE Master;
GO
CREATE ENDPOINT DagobahEP
STATE = STARTED
AS TCP
(LISTENER_PORT = 50102, LISTENER_IP = ALL)
FOR TSQL();
GO
RESULTS:
--------------------------------------------------------------------------Creation of a TSQL endpoint will result in the revocation of any ‘Public’ connect
permissions on the ‘TSQL Default TCP’ endpoint. If ‘Public’ access is desired on
this endpoint, reapply this permission using ‘GRANT CONNECT ON ENDPOINT::[TSQL
Default TCP] to [public]’.
If a single IP address is needed, the LISTENER_IP argument can be set to a specific value inside parentheses, as the following example illustrates:
USE Master;
GO
CREATE ENDPOINT DagobahEP
STATE = STARTED
AS TCP
(LISTENER_PORT = 50102, LISTENER_IP = (192.168.1.101))
FOR TSQL();
GO
As mentioned earlier, IPv6 is also supported by SQL Server 2008. The address can be configured by
passing in the hexadecimal IPv6 address as a binary string in single quotes enclosed in parentheses, as
the following example illustrates:
USE Master;
GO
CREATE ENDPOINT DagobahEPv6
STATE = STARTED
AS TCP
269
Page 269
Leiter c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
(LISTENER_PORT = 50102
, LISTENER_IP = (’fe80::846a:46a7:b245:5255’))
FOR TSQL();
GO
In a previous example, the TCP/IP protocol was configured for the named instance DAGOBAH to listen
on port 50101. With the additional endpoint and associated port, it will be necessary to add the port to
the TCP/IP protocol with SQL Server Configuration Manager. This is done by simply adding another
port to the port assignment delimited by a comma, as shown in Figure 7-5.
Figure 7-5: Adding another port to the port
assignment.
Database Mirroring Endpoints
SQL Server 2008 uses a mirroring endpoint for exclusive use of the server that is configured to participate
in a database mirroring configuration. In mirroring, which is described in Chapter 12, each instance of
SQL Server is required to have its own dedicated database mirroring endpoint. All mirroring communication uses this database mirroring endpoint, but client connections to a database configured with a
mirror use the standard TDS endpoint.
The configuration of an exclusive mirroring endpoint ensures that database mirror process communication is handled in a separate process from all other database activities. The easiest way to configure
mirroring endpoints is to run the Mirroring Wizard as explained in Chapter 12. To create and configure a mirroring endpoint manually and enforce secure encrypted communication over the endpoint, the
following code can be used:
CREATE ENDPOINT AughtEightDagobahMirror
AUTHORIZATION sa
STATE=STARTED
270
11:58am
Page 270
Leiter c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING
(ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE
,ENCRYPTION = REQUIRED ALGORITHM RC4);
This example can be used to create the mirroring endpoint on either the principal or mirror server. It
assumes that the same domain account is used for the SQL Server service on both the principal and the
mirror. For the witness server, the ROLE argument would need to be changed to WITNESS.
If different accounts are used for each MSSQLSERVER service on the servers, logins that are mapped to the
service accounts from each server will need to be granted the CONNECT permission to the other servers
participating in the mirroring configuration. The following script can be run to ensure encrypted authenticated communication between the three servers configured to take part in a mirroring relationship.
AughtEight is the principal server, Dagobah is the mirror server, and Tatooine is the witness server. In
this example, all three instances are running on the same physical server, which is why each endpoint is
configured with a different port number. In the case of separate physical servers, the port numbers could
be configured consistently.
--Run on AughtEight
USE Master;
GO
CREATE ENDPOINT AughtEightDagobahPrincipal
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM RC4);
GO
CREATE LOGIN [AughtEight\DagobahSQL] FROM WINDOWS;
CREATE LOGIN [AughtEight\TatooineSQL] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::AughtEightDagobahPrincipal
TO [AughtEight\TatooineSQL];
GRANT CONNECT ON ENDPOINT::AughtEightDagobahPrincipal
TO [AughtEight\DagobahSQL];
--Run on Dagobah
USE Master;
GO
CREATE ENDPOINT AughtEightDagobahMirror
AS TCP (LISTENER_PORT = 5023)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM RC4);
GO
CREATE LOGIN [AughtEight\AughtEightSQL] FROM WINDOWS;
CREATE LOGIN [AughtEight\TatooineSQL] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::AughtEightDagobahMirror
TO [AughtEight\AughtEightSQL];
GRANT CONNECT ON ENDPOINT::AughtEightDagobahMirror
TO [AughtEight\TatooineSQL];
--Run on Tatooine
USE Master;
GO
CREATE ENDPOINT AughtEightDagobahWitness
AS TCP (LISTENER_PORT = 5024)
271
Page 271
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM RC4);
GO
CREATE LOGIN [AughtEight\AughtEightSQL] FROM WINDOWS;
CREATE LOGIN [AughtEight\DagobahSQL] FROM WINDOWS;
GO
GRANT CONNECT ON ENDPOINT::AughtEightDagobahWitness
TO [AughtEight\AughtEightSQL];
GRANT CONNECT ON ENDPOINT::AughtEightDagobahWitness
TO [AughtEight\DagobahSQL];
The preceding commands set up the communication framework for mirroring, but do not actually initialize mirroring. See Chapter 12 for more information on how to configure and monitor mirroring.
SOAP Endpoints
Simple Object Access Protocol (SOAP) is a platform-independent protocol that defines how to use XML
and HTTP to access services, objects, and servers. SOAP endpoints are created to publish SQL Server
programming objects over data-tier Web Services without the use of IIS as a Web server.
Data-tier Web Services provide a very powerful alternative to XML Web Services and provide the means
of exposing stored procedures and functions over HTTP the same as conventional Web Service architecture. In addition to stored procedures and functions, SOAP endpoints can be configured to allow ad hoc
queries, but as a general rule, ad hoc access should be avoided.
Although SOAP endpoints were introduced in SQL Server 2005, they have been considered deprecated
in SQL Server 2008. Microsoft intends to remove SOAP endpoints in a future version of SQL Server.
Microsoft recommends that existing applications that use SOAP endpoints should instead switch to
using either ASP.NET or Windows Communications Foundation (WCF). The information provided in
this section regarding the configuration of SOAP endpoints should be treated as reference only, and
development of applications that use SOAP endpoints in SQL Server should be discouraged.
SOAP endpoints return SOAP messages consisting of an XML document with a header and a body. SOAP
messages are essentially one-way transmissions from a sender to a receiver. SOAP does not define any
application semantics such as a programming model or implementation-specific details. Web Services,
on the other hand, require a request/response model. The solution is to send SOAP messages within the
body of an HTTP request and response. This solution provides the required model for Web Services, and
SOAP endpoints provide the structure to accomplish the communication.
In order to be able to create SOAP endpoints successfully, the URL must already be registered with
the HTTP.sys kernel-mode driver. This will ensure that requests for the SOAP endpoint URL are
passed to the SQL Server, and not handled by other applications, such as IIS. If the SQL Server service
account has full administrative permissions on the local machine, this can be performed by using the
sp_reserve_http_namespace stored procedure. However, since it is generally not recommended to
run SQL Server services under an administrative account, you may have to register the URL manually
using the netsh Windows configuration tool (for Windows Server 2003 environments, use the httpcfg
Windows system tool) before executing the sp_reserve_http_namespace stored procedure.
272
11:58am
Page 272
Leiter c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
The following syntax is used for creating a SOAP endpoint:
CREATE ENDPOINT endPointName [ AUTHORIZATION login ]
STATE = { STARTED | STOPPED | DISABLED }
AS HTTP (
PATH = ‘url’
, AUTHENTICATION =( { BASIC | DIGEST | INTEGRATED | NTLM | KERBEROS }
[ ,...n ] )
, PORTS = ( { CLEAR | SSL} [ ,... n ] )
)
FOR
[
(
)
}
[
[
SOAP (
{ WEBMETHOD [’namespace’.] ‘method_alias’
NAME = ‘database.schema.name’
[ ,...n ] ]
, DATABASE = { ‘database_name’ | DEFAULT }
, HEADER_LIMIT = int ])
Because syntax specifications can be a bit arcane, the following example is provided to demonstrate
the creation of a SOAP endpoint. The example creates a SOAP endpoint called AWSales that uses
Windows integrated security to control access to a Web Service that is published at the location
http://AughtEight/AdventureWorks2008/Sales. The endpoint exposes the stored procedure
AdventureWorks2008.dbo.uspGetBillOfMaterials as the Web method GetBillOfMaterials. The
SOAP document that is created by this Web Service can be viewed by opening Internet Explorer and
navigating to the Web Service URL and appending a Web Service Description Language (WSDL) query
to the end of the URL:
http://AughtEight/AdventureWorks2008/Sales?wsdl
Keep in mind that you will most likely have to change the server name in your environment.
USE master;
--Turn on Advanced Options for the sp_configure utility
EXEC sp_configure ‘show advanced option’, ‘1’;
RECONFIGURE
GO
-- enable xp_cmdshell
EXEC sp_configure ‘xp_cmdshell’, ‘1’;
RECONFIGURE
GO
--Allow SQL to create the reservation (Windows Server 2008/Vista only)
EXEC xp_cmdshell ‘netsh http add urlacl url=
http://AughtEight:80/AdventureWorks2008 user=AughtEight\SQLService delegate=yes’;
GO
--Reserve the URL
EXEC sp_reserve_http_namespace N’http://AughtEight:80/AdventureWorks2008’;
GO
273
Page 273
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
-- Create the SOAP endpoint
USE Master;
GO
CREATE ENDPOINT AWSales
STATE = STARTED
AS HTTP(
PATH = ‘/AdventureWorks2008/Sales’
,AUTHENTICATION = (INTEGRATED)
,PORTS = ( CLEAR )
,SITE = ‘AughtEight’)
FOR SOAP(
WEBMETHOD ‘GetBillOfMaterials’
(NAME=’AdventureWorks2008.dbo.uspGetBillOfMaterials’
,FORMAT=ROWSETS_ONLY)
,WSDL = DEFAULT
,DATABASE = ‘AdventureWorks2008’
,NAMESPACE = ‘http://AughtEight/’
);
GO
In the preceding example, the xp_cmdshell extended stored procedure was used to execute the necessary netsh command to allow SQL to register the URL, although this can be just as easily done from a
command line. Because xp_cmdshell is disabled by default, the sp_configure stored procedure had to
be run to enable its use.
Although Internet Explorer can be used to view the SOAP document, the real use for data-tier Web
Services is for applications that are created to connect to and consume XML Web Services. Later in this
chapter, you will see how to do this.
The HTTP arguments available for configuration in a CREATE ENDPOINT statement are described in the
following table:
274
Argument
Description
PATH
Specifies the path of the Web Service. An analogous setting would
be the virtual directory name in IIS. Thus, the PATH setting specifies
what comes after the http://Servername, as specified in the SITE
argument.
AUTHENTICATION
The AUTHENTICATION argument is used to specify what type or
types of authentication are allowed for the endpoint. One or more
of the following settings can be configured: BASIC, DIGEST, NTLM,
KERBEROS, or INTEGRATED. Multiple settings can be specified by
comma-delimiting the settings.
PORTS
Specifies whether HTTP or HTTPS is used with the endpoint. When
CLEAR is specified, HTTP is used. SSL specifies that requests must
use HTTPS. Both CLEAR and SSL can be configured concurrently,
enabling communication with either HTTP or HTTPS.
11:58am
Page 274
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Argument
Description
SITE
The SITE argument specifies the host name used along with
the PATH configuration. Possible choices are ‘*’, ‘+’, or
‘webSite’.
❑
The asterisk (’*’) specifies that the endpoint
will listen to all available hostnames that are not
reserved.
❑
The plus sign (’+’) specifies that the endpoint will
listen to all configured hostnames.
❑
webSite is used for a specific server name (e.g.,
AughtEight).
CLEAR_PORT
Specifies the clear port to use. The default is 80.
SSL_PORT
Specifies the SSL port to use. The default is 443.
AUTH_REALM
AUTH_REALM defaults to NONE, but when the AUTHENTICATION
argument is DIGEST, AUTH_REALM can be used to return the
digest realm hint to the client.
DEFAULT_LOGON_DOMAIN
When AUTHENTICATION is set to BASIC, this setting specifies
the default login domain. The default is NONE.
COMPRESSION
When set to ENABLED, SQL Server will process requests
where gzip encoding is accepted and return compressed
responses. The default setting is DISABLED.
The configurable SOAP arguments are described in the following table:
Argument
Description
WEBMETHOD
The published method that will be exposed through an HTTP
SOAP request to an endpoint. More than one WEBMETHOD clause
can be defined to publish multiple SQL Server functions and
stored procedures. In the preceding example, the WEBMETHOD was
GetBillOfMaterials.
(WEBMETHOD) NAME
The physical name of the function or procedure published as the Web method, as in AdventureWorks2008.dbo
.uspGetBillOfMaterials.
Continued
275
Page 275
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Argument
Description
(WEBMETHOD) SCHEMA
Determines whether an inline XSD schema will be returned for the
Web method in SOAP responses. The possible choices are NONE,
STANDARD, and DEFAULT.
❑
NONE omits the Web method from the schema if a schema
is returned.
(WEBMETHOD) FORMAT
❑
STANDARD specifies that an XSD schema is returned.
❑
DEFAULT specifies that the endpoint SCHEMA option setting
is to be used.
Specifies the format of data returned by the endpoint. The possible
choices are ALL_RESULTS, ROWSETS_ONLY, and NONE. The default
is ALL_RESULTS.
❑
ALL_RESULTS specifies that a result set or row count,
including any error message or warnings, is returned.
❑
ROWSETS_ONLY specifies that just the result set is returned
without errors, warnings, or row count information.
❑
NONE configures the endpoint not to return any
SOAP-specific formatting with the result. If this option is
used, the stored procedure or function is responsible for
proper formatting of the result set as well-formed XML.
BATCHES
The BATCHES argument specifies whether ad-hoc batches can be
sent to the endpoint. It can be set to ENABLED or DISABLED. The
default setting is DISABLED.
WSDL
WSDL stands for ‘‘Web Services Description Language.’’ The WSDL
setting is used to determine how a SOAP endpoint responds to
a WSDL request. The possible configuration settings are NONE,
DEFAULT, or the name of a stored procedure that returns the
desired WSDL information.
❑
NONE specifies that the endpoint will not return any infor-
❑
DEFAULT specifies that basic metadata about the published
mation to a WSDL request.
Web method will be returned to a WSDL request. This
information includes any possible parameters and the
type of data returned.
❑
Proc_Name is a procedure created to return a custom
WSDL document to a WSDL request.
276
11:58am
Page 276
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Argument
Description
SESSIONS
When set to ENABLED, allows multiple SOAP request/response
message pairs in a single SOAP session. The default is DISABLED.
LOGIN_TYPE
Specifies which type of Login authentication is supported by the
endpoint. The choices are WINDOWS and MIXED. The choices correspond to the Server Authentication Mode. If WINDOWS is specified,
only Windows logins will be allowed. If MIXED is specified, both
Windows and SQL Server logins are allowed.
SESSION_TIMEOUT
Specifies how long a session will stay open without activity. The
value is an integer and specifies the number of seconds to wait
before closing a session. Subsequent requests that use an expired
session ID will return an exception.
DATABASE
Specifies the database context that the Web method will be executed in.
NAMESPACE
Specifies an XML namespace to be used with the endpoint. If
no namespace is specified, or if the DEFAULT option is used, the
namespace will be configured as http://tempuri.org.
SCHEMA
Like the WEBMETHOD SCHEMA argument, this option specifies
whether inline XML Schema Definition (XSD) data is returned.
The possible choices are NONE and STANDARD.
❑
NONE configures the endpoint not to return inline XSD
data with the SOAP response.
❑
CHARACTER_SET
STANDARD specifies that inline XSD data is returned with
the SOAP response. If the SCHEMA setting is omitted in the
WEBMETHOD section, the Web method will use the setting
specified here.
Specifies what to do with result data that is not valid in an XML
document. The two choices are XML and SQL.
❑
XML specifies that all characters are returned as XML or
delimited XML, and is the default setting.
❑
SQL specifies that non-XML characters are encoded as
character references, and are returned with the XML data.
HEADER_LIMIT
Configures the maximum size of the header section in the SOAP
envelope. The default size is 8 K. If the SOAP headers are larger
than the configured size, a parsing exception will be thrown.
277
Page 277
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Service Broker Endpoints
As described in Chapter 19, Service Broker is a powerful feature of SQL Server 2008 that enables database
applications to communicate asynchronously with other database applications in a Service-Oriented
Architecture (SOA). Service Broker endpoints are only required if the two instances of the broker service
are located on separate instances of SQL Server. They are created in much the same way as SOAP endpoints. The basic CREATE ENDPOINT command is used, but instead of the FOR SOAP clause that defines the
endpoint as a SOAP endpoint, the FOR SERVICE_BROKER clause is used. The syntax for creating a Service
Broker endpoint is as follows:
CREATE ENDPOINT endPointName [ AUTHORIZATION login ]
STATE = { STARTED | STOPPED | DISABLED }
AS TCP (
LISTENER_PORT = listenerPort
[ [ , ] LISTENER_IP = ALL | ( 4-part-ip ) | ( "ip_address_v6" ) ]
)
FOR SERVICE_BROKER (
[ AUTHENTICATION = { WINDOWS [ { NTLM | KERBEROS | NEGOTIATE } ]
| CERTIFICATE certificate_name
| WINDOWS [ { NTLM | KERBEROS | NEGOTIATE } ] CERTIFICATE certificate_name
| CERTIFICATE certificate_name WINDOWS [ { NTLM | KERBEROS | NEGOTIATE } ]
} ]
[ [ , ] ENCRYPTION = { DISABLED | { { SUPPORTED | REQUIRED }
[ ALGORITHM { RC4 | AES | AES RC4 | RC4 AES } ] }
]
[ [ , ] MESSAGE_FORWARD_SIZE = forward_size ]
)
An example of this syntax put in use to create a Service Broker endpoint is as follows:
CREATE ENDPOINT MyEndpoint
STATE = STARTED
AS TCP ( LISTENER_PORT = 50001 )
FOR SERVICE_BROKER ( AUTHENTICATION = WINDOWS );
In all likelihood, when creating Service Broker or mirroring endpoints, certificates will be used to ensure
authenticated and encrypted traffic between endpoints, especially if the endpoints are located on different
physical servers. For more information on the workings of Service Broker, take a look at Chapter 19. For
information about creating and using certificates, see Chapter 6.
Securing Endpoints
A critically important aspect of all endpoints is securing them so that only connections that are authorized can enumerate and call the Web methods or other services that the endpoint provides. The key
permission for endpoints is the CONNECT permission. Only those logins that have been explicitly granted
the CONNECT permission will be able to expose the functionality behind the endpoint. In addition, the
login will need permissions to the underlying objects that the endpoint provides access for.
278
11:58am
Page 278
Leiter c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Try It Out
Data-Tier Web Services
To re-create this exercise requires that you have Visual Studio 2008 installed, as well as SQL Server 2008.
As described in Chapter 2, the SQL Server 2008 installation installs a piece of Visual Studio, but it does
not install everything you need to create database applications. The following examples and descriptions
assume that you have installed either C# or VB.NET (or both). If you haven’t, the information is still very
useful, but you will not be able to practice or re-create it. The examples using Visual Studio may seem to
be a bit out of context in this book. However, it is difficult to describe the use of SOAP endpoints without
using a Visual Studio application to demonstrate the purpose of data tier Web Services.
Create the Endpoint
The first step is to create the endpoint that will publish the two stored procedures you want
to make available via a data-tier Web Service where they can be used by any SOAP-compliant
application. Execute the following code to create the SOAP endpoint HRWebService that publishes the uspGetEmployeeManagers and uspGetManagerEmployees stored procedures as the
GetEmployeeManagers and GetManagerEmployees Web methods:
USE Master;
GO
CREATE ENDPOINT HRWebService
STATE = STARTED
AS HTTP(
PATH = ‘/AdventureWorks2008/HR’
,AUTHENTICATION = (INTEGRATED)
,PORTS = ( CLEAR )
,SITE = ‘AughtEight’)
FOR SOAP(
WEBMETHOD ‘GetEmployeeManagers’
(NAME=’AdventureWorks2008.dbo.uspGetEmployeeManagers’
,FORMAT=ROWSETS_ONLY)
,WEBMETHOD ‘GetManagerEmployees’
(NAME=’AdventureWorks2008.dbo.uspGetManagerEmployees’
,FORMAT=ROWSETS_ONLY)
,WSDL = DEFAULT
,DATABASE = ‘AdventureWorks2008’
,NAMESPACE = ‘http://AughtEight/’
);
GO
Once the endpoint has been created to make the procedures visible through the Web Service, a
SOAP-compliant application will be able to enumerate and reference the Web methods specified in the
endpoint.
1.
Start Visual Studio 2008 and create a new VB.NET or C# Windows Application Project by clicking
on the File menu, selecting New, and then Project.
2.
In the New Project window, select either Visual Basic or Visual C# from the Project Types pane,
and then choose Windows Forms Application from the Templates pane, as shown in Figure 7-6.
Ensure that .NET Framework 2.0 is selected (this will not work with later versions of .NET).
279
Page 279
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Figure 7-6: Selecting ‘‘Windows Forms Application’’ from the Templates pane.
3.
Give the project a name such as HRSampleApp. Choose a folder for the solution to be created in,
and click OK. A design window showing a blank Windows form will appear.
4.
From the toolbox (to the left of the form designer by default), select and drag a button control to
the upper-left-hand side of the form. Then drag a textbox and place it to the right of the button.
Lastly, drag a datagridview control onto the form, and place it under the button and textbox
controls, as shown in Figure 7-7. If the toolbox is not visible, it can be launched by pressing
[Ctrl]+[Alt]+X or by selecting it from the View menu.
5.
You may want to adjust the size of the form and the datagridview control to accommodate multiple columns and rows. After creating the form, right-click on the project name in the Solution
Explorer window, and select ‘‘Add Web Reference,’’ as shown in Figure 7-8.
The Add Web Reference window will display where the data-tier Web Service can be added as a
Web reference to the project.
6.
In the URL dropdown textbox, type in the appropriate address for your server followed by a WSDL query command. In my case, the URL and query take the form of
http://AughtEight/Adventureworks2008/hr?wsdl.
7.
Click the GO button to query the SQL Server for information regarding any Web methods published at that location. You should see results similar to those shown in Figure 7-9.
8.
In the ‘‘Web reference name’’ field, type in the name HRWebService, and click OK.
Now that all the foundation work has been completed, it is time to write the code that will call on the
Web methods made available with the SOAP endpoint.
280
11:58am
Page 280
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Figure 7-7: Placing a datagridview control.
Figure 7-8: Selecting ‘‘Add Web
Reference.’’
281
Page 281
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
Figure 7-9: Viewing the results of a query for information regarding Web methods.
9.
Double-click on the Button1 button on the Form Designer. This will launch the Code Editor window and create the basic code to handle the button click event. In the button
click event handler, type in the code shown in the next example. There is one set of code
for a VB.NET application, and another for Visual C# application.
Following is the Visual C# code:
private void button1_Click(object sender, EventArgs e)
{
DataSet dsEmployees;
HRWebService.HRWebService proxy =
new HRSampleApp.HRWebService.HRWebService();
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
try
{
Int32 intMgrID;
intMgrID = Convert.ToInt32(textBox1.Text);
dsEmployees = proxy.GetManagerEmployees(intMgrID);
dataGridView1.DataSource = dsEmployees;
dataGridView1.DataMember = dsEmployees.Tables[0].TableName;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
282
11:58am
Page 282
Leiter
c07.tex
V3 - 03/25/2009
11:58am
Chapter 7: Configuring SQL Server Network Communication
Following is the Visual Basic.NET code:
Private Sub button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles btnGetEmployees.Click
Dim Proxy As New HRWebService.HRWebService
Proxy.Credentials = System.Net.CredentialCache.DefaultCredentials
Try
Dim dsEmployees As DataSet = Proxy.GetManagerEmployees(textBox1.Text)
dataGridView1.DataSource = dsEmployees
dataGridView1.DataMember = dsEmployees.Tables(0).TableName
Catch
MsgBox(Err.Description)
End Try
End Sub
Notice that the amount of code required to consume the Web Service is actually very small. Not counting
error-handling code, there are only five lines of code for VB.NET and eight lines for Visual C#. This is
one of the features that make consuming Web Services so attractive; most of the work has been done at
the Web Service side.
10.
Once the code has been entered into the button click event, press [F5] or click the green triangle
on the menu to start the application debugging process. If everything goes well, what you should
see is the Windows form created earlier.
11.
Enter the number 1 in the textbox, and click Button1. Your results should look like those in
Figure 7-10.
Figure 7-10: Results of entering 1.
SOAP endpoints can be created to not only return data, but also to manipulate data in the database. The
amount of code required does not change dramatically.
283
Page 283
Leiter
c07.tex
V3 - 03/25/2009
Chapter 7: Configuring SQL Server Network Communication
As a database administrator, this may all seem a bit over the top, but it is very important to understand
why developers may want to use SOAP endpoints and exactly what they do. Keep in mind, however,
that SOAP endpoints are no longer supported in SQL Server 2008. Instead, encourage your developers to
use Windows Communications Foundation in the newer versions of .NET Framework.
Summar y
SQL Configuration Manager offers the database administrator a one-stop shop for troubleshooting and
configuring SQL Server connection objects and networking devices. The tools you will use to manage
these objects are simple, if not intuitive. Diagnosing networking problems has never been easier. Using
the information in this chapter, you should be able to configure and secure the network protocols and
endpoints that make it possible to make the most of SQL Server 2008 services and features. With the
introduction of Service Broker and mirroring, the database administrator’s responsibility for network and
transport security has never been greater. Be sure to carefully evaluate all the security and configuration
options available for each networking object to ensure the highest level of security and functionality.
In Chapter 8, you will learn about automating SQL Server 2008 administrative and maintenance processes. You’ll learn to configure jobs and alerts that will keep you informed of SQL Server performance,
and keep it performing at peak efficiency.
284
11:58am
Page 284
Leiter c08.tex
V3 - 03/25/2009
12:01pm
8
Automating Administrative
Tasks
‘‘Set it and forget it!’’ Wouldn’t it be nice if SQL Administration were that easy? Unfortunately, that’s
not a realistic goal for many of us. SQL Server is a product that needs regular maintenance and
monitoring to ensure the health and stability of your servers. Fortunately, there are several tools
available out-of-the-box to help DBAs manage and maintain their systems. Even better are the tools
you can use to automate some of these processes that can also make your job easier.
Managing the SQL Servers in your organization can be a full-time job. In fact, it might be yours!
Realistically, the complexities of our database systems and applications (both supported and supporting) might be overwhelming at first, but there are many ways that you can keep your system
in shape. This chapter will introduce you to some of the more common tools and features that
Database Administrators can leverage to take control of their servers.
❑
Policy-Based Management
❑
Database Mail
❑
Event Notifications
❑
SQL Server Agent
❑
SQL Server Maintenance Plans
As you begin this chapter, understand that some of what you will learn will serve as an introduction
to topics that are covered in later chapters. Backups, replication, performance monitoring, and the
Service Broker are just a few of the topics that can be managed or automated through many of the
tools and examples that you will see in this chapter.
The examples in this chapter use the local server configured as both a Simple Mail Transfer Protocol
(SMTP) server and a Post Office Protocol (POP3) server. Both features are available out-of-the-box
with Windows Server 2003. However, the POP3 server has been removed from Windows Server
2008. Configuration of SMTP and POP3 is beyond the scope of this book; however, there are some
free POP3 servers available.
Page 285
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Policy-Based Management
One of the most compelling additions to SQL Server 2008 for Database Administrators is the new
Policy-Based Management feature. To simplify, Policy-Based Management allows you to define criteria that can control object creation and behavior, as well as gather information about objects that are out
of compliance. It is both an automated management tool as well as a management auditing tool.
If you are familiar with how group policy objects work in the Active Directory, it’s somewhat similar, in
that you have a wide variety of settings that can be configured, locked, or reported on. All Policy-Based
Management is configured from the Management folder of the server in SQL Server Management Studio.
As you can see in Figure 8-1, there are three subfolders for the different types of management objects:
Policies, Conditions, and Facets.
Figure 8-1: Policy Management folder.
By default, no policies are installed; however, there are several policy templates that are
included when SQL Server is installed. You can import these policies from the SQL Server
installation directory, which, if you used the default settings, is C:\Program Files\Microsoft SQL
Server\100\Tools\Policies\DatabaseEngine\1033. These policies are disabled when they’re imported,
but you can enable them after you’ve had a chance to review and configure them.
Before creating and using policies, you should understand some of the basic components of Policy Management. These components include:
❑
Targets
❑
Facets
❑
Conditions
❑
Policies
❑
Policy categories
❑
Effective policies
Each of these topics is introduced in greater detail in the following sections.
Targets
A target is simply a specific entity or object that is managed by one or more policies. A target might be
a single index or table, or it might be every database attached to the local server. The Database Engine
itself might be the target of a policy.
286
12:01pm
Page 286
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Targets can also be grouped in sets, such as defining all tables that belong to a particular schema.
For example, you might have a policy that specifies every table in the Person schema in the
AventureWorks2008 database as a target set.
Facets
Facets are collections of properties that represent all or some portion of a target object that are grouped
together based on behavior or characteristics. There are 74 facets that are available from the default
installation of SQL Server 2008. These include facets for databases, schemas, logins, tables, and full text
catalogs, to name a few. In some cases, a facet might be just a subset of properties from another facet. For
example, the Login facet includes properties such as Name, LoginType, IsPasswordExpired, CreateDate,
and DateLastModified; whereas the Login Options facet only includes a subset of these properties,
excluding DateLastModified and IsPasswordExpired, among others. Facets are used when defining a
condition, described in the next section.
Conditions
Conditions are one or more Boolean expressions that are associated with the properties of a specific facet.
When more than one expression is defined, you can decide whether to use the AND operator or the OR
operator when evaluating these expressions. For example, I can create a condition called Login Errors,
which uses the Login facet and checks to see if the @IsDisabled, @IsLocked, or @IsPasswordExpired
properties are true. See Figure 8-2 for reference.
Figure 8-2: New condition.
If you import the pre-defined polices from the SQL Server installation folder, several conditions on which
those policies are based will also be added to your SQL Server instance.
287
Page 287
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Policies
Policies are what you can use to evaluate, configure, or restrict your server and the objects that reside on
it. Each policy consists of five main elements that must be defined. The first, obviously, is a unique name
for the policy. Then, a condition that will be evaluated must be selected for the policy. The third element
defines the targets against which the condition will be evaluated and to which the policy will be applied.
Next, you must choose the Evaluation mode that the policy will execute against. Depending on the type
of policy you are creating, you can select one of four available evaluation modes:
❑
On Demand — The policy must be run manually.
❑
On Change: Prevent — Uses DDL triggers to prevent a non-compliant event from occurring.
This might be useful if, for example, you want to standardize the naming conventions on certain
object types. This option will specifically prevent objects that do not comply with the naming
rules from being created.
❑
On Change: Log Only — Uses DDL triggers to log non-compliant events, but will not prevent
them from executing.
❑
On Schedule — Creates a SQL Server Agent job (described later in this chapter) to automatically
evaluate policies.
Finally, you can also define a Server restriction property. This might be useful if you want to prevent the
policy from applying to a specific version of SQL Server or a particular platform. Figure 8-3 shows a
sample policy that uses a Login Errors condition (shown in Figure 8-2) and evaluates it manually against
SQL Server 2005 and later platforms.
Note that the Enabled checkbox is grayed out. This is because the On Demand evaluation mode has been
selected. If I change the evaluation mode of the policy, you can enable it as part of a scheduled operation.
Figure 8-3: New policy.
288
12:01pm
Page 288
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Policy Categories
On the description page of the policy, I can set additional properties that allow me to better manage
multiple policies on my server. With the default policies imported, I can see a list of available ‘‘Microsoft
Best Practice’’ categories, or I can create my own, as shown in Figure 8-4.
Figure 8-4: Policy Management folder.
Databases can be subscribed to a category, meaning that all policies within that category will automatically
be evaluated against the database. Although a policy can only belong to one category, a single database
can subscribe to more than one policy. This is done by right-clicking the database, choosing Policies from
the context menu, and selecting Categories. From there, you will see a dialog box that lists all the available policy categories you want this database to subscribe to. By default, policy categories are enforced
at the server level, automatically applying to all databases. This can be managed by right-clicking the
Policy Management node in Object explorer and choosing Manage Categories. Deselecting the ‘‘Mandate
Database’’ option for a category will allow you to subscribe individual databases to that category.
Also note in Figure 8-4 that I provided descriptive text as well as information in the additional Help
hyperlink section. This allows me to provide a reference to a URL that might contain more information
about that specific policy. For example, if I am creating a policy that requires a specific naming convention
for certain object types, I might include a URL for the document that defines that policy.
Effective Policies
Effective policies are all policies that are being applied to an object by meeting three criteria:
❑
The policy must be enabled. This rules out policies that are configured to run ‘‘On Demand.’’
❑
The target identified, such as a table, must belong to the target set of the policy. A login policy
has no effect on that table.
289
Page 289
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
❑
The target, or a parent object in the target hierarchy, must subscribe to the policy category that
contains the effective policies. This means that a policy may be applied to a table if its schema,
database, or server subscribes to that policy.
Try It Out
Creating a Naming Policy
In this example, you will be creating a new policy that specifies a naming convention for tables that
belong to the Sales schema of the AdventureWorks2008 database. You will use this to prevent the creation of new tables that don’t meet this policy condition, as well as get an accounting of tables that already
exist that are not compliant with this naming policy.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Begin by creating a new Policy Condition called AWSalesTableNames. Navigate to the Conditions
folder, right-click, and select ‘‘New Condition.’’
Enter the AWSalesTableNames for the Name, and select ‘‘Multipart Name’’ for the Facet.
For the first row of the expression line, select @Name for the field.
Select LIKE as the operator.
Enter AW_Sls_% in the Value field.
Add a new row, using the OR operator.
Select @Schema for the Field value.
Set the Operator to !=.
Enter Sales for the Value field. Click OK to create the new condition.
Right-click on the Policies folder in Object Explorer, and click ‘‘New Policy.’’
Enter AW Sales Name for the Policy Name.
In the Check condition list, scroll down until you find the AWSalesTableNames condition (it will
be under the ‘‘Multipart Name’’ header).
13.
Select the check next to the "Every Table in Every Database" line, and click the dropdown arrow
next to ‘‘Database.’’
14.
15.
16.
17.
18.
19.
20.
Select ‘‘New Condition.’’
Enter AdventureWorks2008 DB for the name of the new condition.
Select the Database Facet.
Set the Condition Expression to @Name = ‘AdventureWorks2008’, and click OK.
Change the Evaluation Mode to ‘‘On change: prevent.’’
Leave the server restriction as None.
Check the Enable checkbox underneath the Name property.
Your settings should resemble Figure 8-5.
Now let’s test the new policy:
1.
290
First, ensure that you can create a table in any schema other than Sales that doesn’t require this
naming convention.
12:01pm
Page 290
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Figure 8-5: Creating the Sales Table Name policy.
2.
Enter the following code to create a new table in the Person schema:
Use AdventureWorks2008;
Create Table Person.Foo (
Col1 Int,
Col2 nvarchar(25)
);
The command should succeed as expected.
3.
Next, try to create a table called Foo in the Sales schema using the following code:
Use AdventureWorks2008
Create Table Sales.Foo (
Col1 Int,
Col2 nvarchar(25)
);
4.
At this point, the operation should fail, indicating that the expected name isn’t provided. So now
you should create a new table that does follow the expected naming convention. Enter the following code to create the new table:
Use AdventureWorks2008
Create Table Sales.AW_Sls_Foo (
Col1 Int,
291
Page 291
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Col2 nvarchar(25)
);
This should complete successfully.
You have now created a policy that enforces a specific naming convention on a particular schema in the
AdventureWorks2008 database. As you explore the different facet and condition options, it is easy to see
how powerful the Policy-Based Management system can be.
Because several objects already existing in the Sales schema don’t meet our required naming convention,
we can get an audit of those tables that are in violation of the policy. Keep in mind that the policy will only
apply the DDL trigger to new objects. Existing objects will still function. To get a list of non-compliant
objects, navigate to the AW Sales Name policy, right-click on it, and select Evaluate. Your results should
look similar to Figure 8-6.
Figure 8-6: Evaluating a policy against AdventureWorks2008.
Central Management Ser vers
One of the most important concerns for a DBA is how to find the best way to manage multiple servers at
once. The examples in the previous section regarding Policy-Based Management were designed around
a single instance; however, if you browse through some of the options for Policy-Based Management (or
PBM, for short), you will notice that there are options that allow you to specify to which platform and
version of SQL Server these policies will apply.
292
12:01pm
Page 292
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
‘‘How can that be,’’ you might ask, ‘‘if PBM doesn’t exist in prior versions of SQL?’’ The answer is
through the use of Central Management Servers (CMS). More than simply an extension of PBM, the concept of Central Management Servers is to allow not only policies, but also queries to be executed against
several servers simultaneously. This can be extremely useful if, for example, you have a database that is
distributed among multiple SQL Servers and you’re not sure on which server a particular row exists. You
could write a query that includes a select statement against all servers, specifying the full object name in
a separate line, or you could add these servers to a Central Management group and execute the query in
a single operation.
There are, however, two key factors to keep in mind when considering a Central Management Server:
❑
First of all, the Central Management Server and all registered target servers must use
Windows-based logins for authentication and management. SQL Login creation and
management will not be replicated among servers that are members of a management group.
❑
The other important item to note is that a Central Management Server cannot have itself as a
target. This means that policies that are applied at the CMS are applied to the registered servers,
but not the CMS itself.
To define a new CMS, you need to display the Registered Servers window. You can access this from SQL
Server Management Studio by selecting View Registered Servers. The Registered Servers window will
display two categories:
❑
The first is the Local Server Groups category. This is where you can add a list of servers you regularly manage for easy access, without having to connect Object Explorer to them every time.
You can create folders known as Server Groups to logically arrange and collect the servers you
typically manage.
❑
The second category is where you will define (if any) the Central Management Servers. After
you have defined a server as a Central Management Server, you will need to create a new server
group and register servers you want to centrally manage in that new server group
In Figure 8-7, you can see that I have created a new Local Server Group called MyServers, of which
AughtEight is a member. I have also defined AughtEight as a Central Management Server, with a new
server group called Bespin. This server group contains the AughtEight\Dagobah and AughtEight\Hoth
instances.
Figure 8-7: Registered
Servers.
293
Page 293
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
By right-clicking on my CMS, I can choose the ‘‘Evaluate Policies’’ option, which allows me to evaluate
one or more policies against the managed servers. I will need to specify the policy from the file system,
or I could use a policy that exists on a server (including the CMS). If you look at Figure 8-8, you will see
the results of evaluating the Check Bad Logins policy I created.
Figure 8-8: Evaluating policies against multiple servers.
Database Mail
Microsoft SQL Server 2008 includes a simple method for message delivery to and from the SQL Server.
This feature, known as Database Mail, allows SQL Server to send and receive messages through SMTP
delivery. One of the many benefits of SQL Server’s Database Mail service is that it will work with any
SMTP service, regardless of whether or not it requires authentication (which it should, but that’s a security discussion that is beyond the scope of this chapter).
The Database Mail feature in SQL Server 2008 is a tool that allows you to generate and send e-mail messages from your server, which can be relayed through a corporate mail system. This can provide several
advantages, including using an alternate method of returning information to your users, notifying the
appropriate personnel that certain events or conditions have been met, or providing status information about jobs and SSIS packages. Database Mail was designed with security, scalability, and reliability
in mind.
Be aware that the Database Mail feature is not included with the Express Edition of SQL Server 2008.
How It Works
Database Mail uses SMTP for message delivery. Messages can be generated from within SQL and can
include attachments from outside the SQL environment. One of the primary benefits of the Database
Mail feature is its ability to use any SMTP server to relay messages. This is a significant improvement
294
12:01pm
Page 294
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
over prior versions of SQL Server that use SQL Mail, which requires a MAPI-compliant mail server (such
as Microsoft Exchange) and a MAPI client (such as Microsoft Outlook). SQL Mail still exists in SQL Server
2008 but is considered a legacy feature and should not be used.
Another benefit of Database Mail is that it allows you to configure authentication credentials if required
by your SMTP server to forward messages, as well as allowing you to configure different servers for
delivery, in case your preferred server is not available. SQL Server also uses an external executable,
DatabaseMail.exe, to handle message delivery to an SMTP server. This allows the SQL Server to isolate
itself from the process that relays the messages to the SMTP server.
The msdb database is used for storing configuration information about Database Mail, controlling access
to the feature, and queuing messages until they are ready for delivery. Prior to configuring Database
Mail, there are a few things you should consider:
❑
First, you should know which SMTP servers are available for use and what credentials are
needed. As you’ll see in the next section, you can configure multiple servers, with multiple
accounts, if necessary.
❑
Another consideration is which messages will be retained, and how long they need to be
retained. By default, all Sent messages and their attachments are stored in the msdb database. Be
aware of your company’s security and retention policies for e-mail messages. You may also be
under a legal obligation to keep messages for a specific amount of time.
The Database Mail feature uses accounts to configure access to SMTP servers and profiles to configure
access to mail accounts. However, profiles and accounts can be mutually exclusive. You can create
accounts without an association to a profile, and you can use the same account with multiple profiles, if
necessary.
How to Configure Database Mail
The easiest way to configure SQL Server to use Database Mail is through the Database Mail Configuration
Wizard in SQL Server Management Studio. This section steps you through the different pages in the
Wizard and explains what each page configures:
1.
To launch the Wizard, navigate to the Management section of your server in Object Explorer
(see Figure 8-9).
Figure 8-9: Launching the Database Mail
Wizard.
295
Page 295
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
2.
3.
Expand Management, right-click ‘‘Database Mail,’’ and select ‘‘Configure Database Mail.’’
4.
On the next screen, you’ll be asked to identify which configuration task you’re using the
Wizard to perform. You can use this to initialize Database Mail for use on the server; or, if
it’s already configured, you can manage existing mail profiles and configured accounts. You
can also change system settings. For this run, select the first option to set up Database Mail
(see Figure 8-10).
The first page you will see is simply a start page that explains each of the following steps in
the Wizard. If you don’t want to see this page again, select the checkbox at the bottom of the
page indicating that you wish to skip this page in the future.
Figure 8-10: Choosing a Database Mail configuration task.
5.
Database Mail is disabled by default. If this is the first time you’ve run this Wizard
and you have not manually enabled Database Mail, you will be prompted to enable
it. Once you’ve enabled Database Mail, the next screen will ask you to provide information for a new Database Mail profile. Enter a name for the profile and, optionally, a
description to help identify the profile and how it will be used. For this example, enter
AdventureWorksSalesProfile as the profile name.
Once that information has been entered, you must configure at least one account that this
profile will use. The ability to configure multiple accounts under a single profile helps guarantee the availability of the Database Mail feature to users who need to receive information,
and the path of delivery isn’t relevant. The order in which the accounts are listed will determine the order of precedence when sending messages. Accounts listed at the top of the list
will be preferred over those listed below them.
296
12:01pm
Page 296
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
6.
To create a new account, click on the Add button. In the New Database Mail Account screen
(see Figure 8-11), enter an account name and description, and then information about the
account, including the e-mail address that the messages will originate from, the display
name for that address, the reply-to address, and the name or IP address of the SMTP server.
There is also a box where you can enter the port number used by the SMTP server. Unless
you know that your server uses a different port, you should use the standard SMTP port, 25.
If your server uses Secure Sockets Layer (SSL) to protect the data in transit, select the appropriate checkbox.
Figure 8-11: New Database Mail Account screen.
7.
Also on the new Database Mail Account screen, you will select the method of authentication
that the SMTP server requires. By default, Anonymous authentication is selected, but this
is not the preferred method for most SMTP servers. If your SMTP server is Windows-based
(such as in the case of Microsoft Exchange or IIS) and is a member of the same domain or a
different domain that shares a trust relationship, you may be able to use Windows Authentication with Database Engine service credentials. Otherwise, you can use Basic authentication, providing a username and password manually. Be aware that if SSL is not used
between the SQL Server and the SMTP server, the authentication information may be sent
in clear text and may be vulnerable to interception.
In this example, I am using an SMTP service installed on the local machine through IIS. You
can use the information in Figure 8-11 to configure your mail account appropriately for your
mail server.
8.
Once you’ve entered in the information about the account, click OK to close the New
Database Mail Account window. You can enter in more accounts to be used by the same
profile, or you can continue on to the next screen by clicking Next.
297
Page 297
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
9.
On the Manage Profile Security screen, you can use the Public Profiles tab (see Figure 8-12)
to elect to make the profile public. When a profile is public, it means that the profile will
be available to all users who are members of the DatabaseMailUserRole role in the msdb
database. You can also define which public profile is the default public profile. The default
profile is the one that is used when a profile is not specified during the Send mail operation.
For private profiles, you can specify (on a per-user basis) which profiles are available to that
user (see Figure 8-13). Each user can also have a default profile available to them. The user
must already exist in the msdb database. For this example, mark the profile as public, and
make it the default. Once you’ve configured the Profile Security options, click Next.
Figure 8-12: Configuring Public Profiles.
10.
298
On the final input page of the Wizard, you can change the system configuration values for
mail messages sent from the SQL Server. You can identify the information shown in the following table:
Option
Description
Account Retry Attempts
The number of retry attempts that SQL Server
will make for a mail account within a profile
before it moves on to the next account
Account Retry Delay
The amount of time (in seconds) that the SQL
Server will wait between retries
12:01pm
Page 298
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Option
Description
Maximum File Size
Maximum size (in bytes) of file attachments
Prohibited Attachment File Extensions
List of file extensions that the SQL Server will not
send
Database Mail Executable Minimum
Lifetime
The time-out value for the external executable if
there are no more messages in queue
Logging Level
Choose one of the following:
❑
Normal — Logs only errors.
❑
Extended — Errors, Warnings, and
Informational messages. This is the
default setting.
❑
Verbose — Extended logging, plus success messages and internal messages
Figure 8-13: Configuring Private Profiles.
299
Page 299
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
11.
Click Next on the Configure System Parameters page to move to the last page in the Wizard.
Once you’ve provided the appropriate values to the Wizard, it gives you a summary page
with the options you’ve selected. Clicking Finish will commit your changes and give you a
quick report on the success or failure of each step.
Configuring Database Mail Options
Alternatively, you can enable Database Mail using the sp_configure stored procedure. Once Database
Mail has been enabled, you can use the sysmail_configure_sp stored procedure to configure Database
Mail settings. The syntax of the sysmail_configure_sp stored procedure is as follows:
sysmail_configure_sp [ @parameter_name = ] ‘name’ , [ @parameter_value = ]
‘value’ , [ @description = ] ‘description’
Similar to the options listed here, you can use the values in the following table for the parameters:
Parameter
Description
AccountRetryAttempts
The number of retry attempts SQL Server will make for
a mail account within a profile before it moves on to the
next account
AccountRetryDelay
The amount of time (in seconds) that the SQL Server will
wait between retries
DatabaseMailExeMinimumLifeTime
The time-out value for the external executable if there are
no more messages in queue
DefaultAttachmentEncoding
The default encoding for e-mail attachments
MaxFileSize
Maximum size (in bytes) of file attachments
ProhibitedExtensions
List of file extensions that the SQL Server will not send
LoggingLevel
Choose one of the following numeric values:
1.
2.
3.
Normal
Extended
Verbose
The sysmail_configure_sp stored procedure (as do many of the Database Mail stored procedures) lives
in the msdb database. When executing these stored procedures, you’ll have to qualify them from within
your application or T-SQL statements. Use the following example to set the maximum file size for all
attachments sent by Database Mail to 4 MB:
EXECUTE msdb.dbo.sysmail_configure_sp
‘MaxFileSize’, ‘4194303’, ‘Max Size 4 MB’
Note that the description parameter is optional. Although it may not be required, it is always a good idea
to use it to define or explain why a particular configuration value is used.
300
12:01pm
Page 300
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Managing Profiles and Accounts
Profiles are commonly used as a unit of management for SMTP accounts. However, as mentioned earlier, there is no one-to-one relationship between the two. You can use the Database Mail Configuration
Wizard, or you can use a series of stored procedures to create and delete profiles and accounts as needed.
Because you’ve already been exposed to the different elements of the Wizard, you should easily be able
to fumble through the different pages to find what you need to configure the accounts and profiles you
want. In this section, you learn about the stored procedures used to create and manage Database Mail
accounts and profiles.
sysmail_add_profile_sp
The first stored procedure you should know is sysmail_add_profile_sp. This stored procedure allows
you to create a new profile to be used by the Database Mail service and uses the following syntax:
sysmail_add_profile_sp [ @profile_name = ] ‘name’ , [ @description = ] ‘desc’,
[ @profile_id = ] profile_id OUTPUT
The following table shows the available options.
Option
Description
profile_name
The name of the profile
description
An optional description that provides information about the profile
profile_id
An optional parameter that displays the unique value generated by SQL to
identify the profile
OUTPUT
Keyword used to output the profile_id value
Try It Out
Create a New Profile
The following example creates a new mail profile and returns the integer value generated for the profile
ID. Begin by declaring the variable for the profile_id:
DECLARE @profileID INT;
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = ‘HumanResourcesMail’,
@description = ‘Mail Profile for the Human Resources team.’,
@profile_id = @profileID OUTPUT ;
SELECT @profileID ;
Note the ID returned from the SELECT statement. You’ll use this in the next example.
The sysmail_help_profile_sp stored procedure will return information about the profiles created on
the SQL Server. It will return the profile ID, the profile name, and the description, if any. You can also
301
Page 301
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
use the @profile_id or @profile_name variables to limit the results to just the specific profile you’re
interested in.
EXEC msdb.dbo.sysmail_help_profile_sp @profile_id=2
You can also query the sysmail_profile table in the msdb database to return information about the profiles that have been created. In addition to the information returned from the sysmail_help_profile_sp
stored procedure, you can identify who last modified the account and when.
SELECT * FROM msdb.dbo.sysmail_profile
sysmail_add_account_sp
To create a new account, use the sysmail_add_account_sp stored procedure. This stored procedure will
create an account that is not associated with a profile. A different stored procedure can be used to add
accounts to a profile, which is discussed later in this chapter.
Creating accounts, as you’ve seen from the Database Mail Configuration Wizard, is a little more complex
than creating profiles, because the accounts may vary from server to server. The following table lists the
options you can use with the sysmail_add_account_sp procedure:
302
Parameter
Description
@account_name = name
The name of the new account
@email_address = address
The e-mail address associated with the account
@display_name = display
How messages sent from this account display the sender’s name
@replyto_address =
address
The address that will be used for replies when the client is
responding to a message sent to this account
@description = desc
An optional description for this account
@mailserver_name =
server
Name or IP address of the SMTP server this account will use
@mailserver_type =
servertype
Made available for future technology, SMTP is currently the only
value supported, and is the default.
@port = serverport
TCP port used by the SMTP server. The default is 25.
@username = username
Used if your SMTP server requires authentication.
@password = password
The password to be provided for authentication to the SMTP server
@use_default_credentials
= [0|1]
A value of 1 indicates that the SQL Server service account will be
used for SQL authentication.
@enable_ssl = [0|1]
A value of 1 indicates that SSL will be used between the SQL
Server and the SMTP server.
@account_id = accountID
OUTPUT
Returns the account ID generated when the account is created.
12:01pm
Page 302
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Try It Out
Create a New Account
So, take a look at this in action. Use the following example to create a new account:
DECLARE @accountID INT;
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = ‘Mail Sender’,
@description = ‘Generic Account for sending mail’,
@email_address = ‘[email protected]’,
@display_name = ‘SQL Database Mail Account’,
@mailserver_name = ‘mail.adventureworks.com’,
@username = ‘MailSender’,
@password = ‘[email protected]’,
@account_id = @accountID OUTPUT ;
SELECT @accountID;
Note the account ID returned. You can use this in the next example.
To find out more about the accounts that have been created, use the sysmail_help_account_sp stored
procedure. This will give you information about the account, such as the ID, the name, and the server
options for this account. Use the @account_id or @account_name variables to limit the results to a specific
account.
EXECUTE msdb.dbo.sysmail_help_account_sp
To limit the output to just the account you’re interested in, use the following:
EXECUTE msdb.dbo.sysmail_help_account_sp @account_id=2
You can also return a simple list of configured accounts by querying the sysmail_account table, which
includes the datetime information of when the account was last modified and who last modified it:
SELECT * FROM msdb.dbo.sysmail_account
sysmail_add_profileaccount_sp
So, you’ve created a new profile and a new account. Now you can associate that account with that profile.
Remember that accounts can be associated with more than one profile, and each profile can be configured
to use more than one account.
To create the mapping, you can use the sysmail_add_profileaccount_sp stored procedure. This allows
you to map an account to a profile using the profile name or profile ID and the account name or account
ID. Another option you can specify is the sequence number of the account ID. This is used to determine
the order of preference for the account within that profile.
Because this is a fairly simple stored procedure, you will see a couple of examples that use the profiles
and accounts created previously.
303
Page 303
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
In this first example, you will use the account created during the Database Mail Configuration Wizard
and add it to the profile you created from the sysmail_add_profile_sp stored procedure example. This
example has you use the profile_id of the HumanResourcesProfile and the name of the SalesAccount
account. You can easily mix and match, as long as you declare the correct parameter.
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_id = 2,
@account_name = ‘SalesAccount’,
@sequence_number = 1;
In the next example, add the account created from the sysmail_add_account_sp stored procedure to the
HumanResourcesProfile profile, only this time, you will refer to the profile by name, and the account by
ID number.
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘HumanResourcesMail’,
@account_id = 2,
@sequence_number = 2;
To find out what mappings exist between the accounts and profiles, you can use the sysmail_help_
profileaccount_sp stored procedure. You can limit your results using @account_id, @account_name,
@profile_id, or @profile_name. Each row returned identifies the profile ID, the profile name, the
account ID, the account name, and the sequence number for the account.
EXECUTE msdb.dbo.sysmail_help_profileaccount_sp
Querying the sysmail_profileaccount table in the msdb database returns the IDs of profiles and associated accounts, but not the names. It also returns the sequence number for those accounts and the last
modified information.
SELECT * FROM msdb.dbo.sysmail_profileaccount
sysmail_update_profile_sp
Quite simply, you can use this stored procedure to change the name or description of an existing profile.
If you’re changing the description of the profile, you can refer to it using @profile_id or @profile_name.
If you want to change the name of the profile, you will use @profile_id.
Use the following example to change both the name and the description of the HumanResourcesMail
profile created earlier. Assuming that you did not create any new accounts or profiles other than those
used in the examples, the profile_id of HumanResourcesMail should be 2.
EXECUTE msdb.dbo.sysmail_update_profile_sp
@profile_id = 2,
@profile_name = ‘HRMail’,
@description = ‘Human Resources Mail Profile’;
EXECUTE msdb.dbo.sysmail_help_profile_sp;
This will produce the following output:
profile_id name
description
----------- --------------------------- --------------------------------------
304
12:01pm
Page 304
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
1
2
AdventureWorksSalesProfile
HRMail
NULL
Human Resources Mail Profile
sysmail_update_account_sp
This stored procedure can be used to update the properties of a mail account after it has been created. Unlike profiles, accounts have a lot more parameters that can be modified or adjusted as needed.
The same parameters from the sysmail_add_account_sp procedure can be used, and not unlike the
sysmail_update_profile_sp procedure, you can identify the account by account_name or account_id.
In this example, you reconfigure the name, replyto_address, and the description of the SalesMail
profile. Unfortunately, with this stored procedure, you cannot cherry-pick which values you want to
update. You will have to specify the values for all parameters, as shown here:
EXECUTE msdb.dbo.sysmail_update_account_sp
@account_id = 1,
@account_name = ‘SalesMail’,
@display_name = ‘Microsoft SQL Server - AughtEight’,
@replyto_address = ‘[email protected]’,
@description = ‘Sales Mail Account’,
@mailserver_name = ‘AughtEight’,
@mailserver_type = ‘SMTP’,
@port = 25,
@username = NULL,
@password = NULL,
@use_default_credentials = 1,
@enable_ssl = 0;
EXECUTE msdb.dbo.sysmail_help_account_sp
sysmail_update_profileaccount_sp
If you want to change the sequence in which the accounts will be used within a profile, you can use the
sysmail_update_profileaccount_sp stored procedure. Specify the profile and the account by either
name or ID, and then enter the preferred sequence number. Be aware that more than one account within
a profile can have the same sequence number. If this is the case, SQL will arbitrarily decide which one to
use. Use the following example to change the sequence numbers of the accounts in the HRMail profile:
-- Assigns the Mail Sender account a sequence of 1
EXECUTE msdb.dbo.sysmail_update_profileaccount_sp
@profile_id = 2,
@account_id = 2,
@sequence_number = 1;
-- Assigns the SalesMail account a sequence number of 2
EXECUTE msdb.dbo.sysmail_update_profileaccount_sp
@profile_name = ‘HRMail’,
@account_name = ‘SalesMail’,
@sequence_number = 2;
EXECUTE msdb.dbo.sysmail_help_profileaccount_sp
305
Page 305
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
sysmail_add_principalprofile_sp
This stored procedure is used to control access to a mail profile. In order for the profile to be accessible,
the profile will be made available to specific database principals within the msdb database. The following
table outlines the parameters for the sysmail_add_principalprofile_sp stored procedure:
Option
Description
@principal_id
The ID of the user or role in the msdb database. Use the value 0 to
specify the public role. The principal must be specified by either the
ID or name.
@principal_name
The name of the user or role in the msdb database. Use the public
role if the profile is a public profile.
@profile_id
The ID of the profile. Use either the ID or name to specify the profile.
@profile_name
The name of the profile. Use to identify the profile.
@is_default
Indicates that this profile is the default profile for the specified
principal.
Take a look at this stored procedure in action. In this first example, create a new profile with a new
account. Then, ensure that the profile is public.
-- Create the profile
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = ‘Purchasing’,
@description = ‘Purchasing Mail Profile’;
-- Create the account
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = ‘PurchasingMail’,
@description = ‘Purchasing Mail Account’,
@email_address = ‘[email protected]’,
@display_name = ‘AdventureWorks Purchasing Application’,
@mailserver_name = ‘localhost’,
@use_default_credentials = 1;
-- Associate the profile and the account
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘Purchasing’,
@account_name = ‘PurchasingMail’,
@sequence_number = 1;
-- Make the profile public
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = ‘public’,
@profile_name = ‘Purchasing’,
@is_default = 0;
To view the security configuration, use the sysmail_help_principalprofile_sp stored procedure.
You can specify the principal_id, principal_name, profile_id, and/or profile_name. Note that you
306
12:01pm
Page 306
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
should only provide either the ID or the name for each, not both. For example, if you wanted to see which
profiles are available to the public role, use the following example:
EXECUTE msdb.dbo.sysmail_help_principalprofile_sp
@principal_name = ‘public’;
If you’ve been following all the steps in this chapter so far, you should expect to see the following output:
principal_id
-----------0
0
principal_name
-------------public
public
profile_id
profile_name
is_default
----------- --------------------------- ---------1
AdventureWorksSalesProfile
1
3
Purchasing
0
Interestingly enough, if you execute the sysmail_help_principalprofile_sp stored procedure without
any parameters (such as the principal_name as in the previous example), it returns results for the guest
account, not the public role. This is not surprising, though, because the guest account, when available,
is used when the requestor does not have a user mapping in the msdb database.
In the next example, you learn how to create a new profile, account, and database user named
AWOrderProcessing. You’ll then see how to configure the new profile as the default for that user.
-- Create the user
-- In the real world, you would map this to an existing server credential.
USE msdb
CREATE USER AWOrderProcessing
WITHOUT LOGIN;
GO
-- Create the profile
EXECUTE msdb.dbo.sysmail_add_profile_sp
@profile_name = ‘OrderEntry’,
@description = ‘OrderEntry Mail Profile’;
-- Create the account
EXECUTE msdb.dbo.sysmail_add_account_sp
@account_name = ‘Orders’,
@description = ‘Order Entry Primary Mail Account’,
@email_address = ‘[email protected]’,
@display_name = ‘AdventureWorks Purchasing Application’,
@replyto_address = ‘[email protected]’,
@mailserver_name = ‘localhost’,
@use_default_credentials = 1;
-- Associate the profile and the account
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘OrderEntry’,
@account_name = ‘Orders’,
@sequence_number = 1;
--Configure the purchasing account as a backup account
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
@profile_name = ‘OrderEntry’,
307
Page 307
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
@account_name = ‘PurchasingMail’,
@sequence_number = 2;
-- Make the profile available to the AWOrderProcessing user
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = AWOrderProcessing,
@profile_name = ‘OrderEntry’,
@is_default = 1;
-- Show which profiles the AWOrderProcessing user has access to.
EXECUTE msdb.dbo.sysmail_help_principalprofile_sp
@principal_name = ‘AWOrderProcessing’;
One thing you should note when you return the list of profiles available to the AWOrderProcessing user
is that both of the profiles available to the public role are also available to this user. Also note that the
public role and the AWOrderProcessing user each has a default profile. When a database user or a role
that is not public has a default profile defined, that profile will be the one used if a profile isn’t identified.
If the user or role does not have a default profile specified, the default profile of the public role will
be used.
sysmail_update_principalprofile_sp
Each principal can only have one default profile defined. If you need to change which of the available
profiles is the default, use the sysmail_update_principalprofile_sp stored procedure. As with the
sysmail_add_principalprofile_sp, you can identify the principal and the profile either by name or ID.
The only value you can alter with this stored procedure, though, is the @is_default parameter. Using
the last example, if you changed the @is_default option for AWOrderProcessing, then the user would
need to manually specify the appropriate profile. Otherwise, in this case, the default profile would come
from the public role.
-- Remove the default profile for AWOrderProcessing
EXECUTE msdb.dbo.sysmail_update_principalprofile_sp
@principal_name = AWOrderProcessing,
@profile_id = 4,
@is_default = 0;
-- Show which profiles the AWOrderProcessing user has access to.
EXECUTE msdb.dbo.sysmail_help_principalprofile_sp
@principal_name = ‘AWOrderProcessing’;
sysmail_delete_principalprofile_sp
If you need to remove the association between a principal and a profile, use the sysmail_delete_
principalprofile_sp stored procedure. Note that this does not delete the principal or the profile from
the database but, rather, removes the explicit mapping between the two. You might want to use this if you
have to remove the public role’s access to the specified profile, for example. The syntax is very straightforward, requiring you to identify both the principal and the profile; but again, you can use the name or
ID value for either. Use the following example to remove the Purchasing profile from the public role:
EXECUTE msdb.dbo.sysmail_delete_principalprofile_sp
@principal_name = ‘public’,
@profile_name = ‘Purchasing’;
EXECUTE msdb.dbo.sysmail_help_principalprofile_sp
@principal_name = ‘public’;
308
12:01pm
Page 308
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
sysmail_delete_profileaccount_sp
If you want to remove an account from a profile, simply use the sysmail_delete_profileaccount_sp
stored procedure. You need to specify both the profile and the account either by name or ID. The following example removes the Orders account from the OrderEntry profile:
EXECUTE msdb.dbo.sysmail_delete_profileaccount_sp
@profile_name = ‘OrderEntry’,
@account_name = ‘Orders’;
EXECUTE msdb.dbo.sysmail_help_profileaccount_sp;
sysmail_delete_account_sp
Next, to remove an account from the msdb database entirely, use the sysmail_delete_account_sp stored
procedure. This will not only remove the account, but all references to the account in all profiles where it
was configured, as in the following example. If the account to be deleted is the only account in the profile,
the profile will remain, but will be empty.
EXECUTE msdb.dbo.sysmail_delete_account_sp
@account_name = ‘Orders’;
EXECUTE msdb.dbo.sysmail_help_account_sp;
sysmail_delete_profile_sp
Finally, to remove a profile from the msdb database, use the sysmail_delete_profile_sp stored procedure. This removes the profile but will not delete the accounts in the profile. This is because the accounts
may be used in other profiles.
EXECUTE msdb.dbo.sysmail_delete_profile_sp
@profile_name = ‘OrderEntry’;
EXECUTE msdb.dbo.sysmail_help_profileaccount_sp;
Guidelines for Deleting Mail Objects
As a general rule, be careful about deleting accounts or profiles. If you are going to delete an account,
profile, or account mapping, use the following guidelines:
❑
Deleting a profile/account mapping is non-destructive. It simply removes the relationship
between the profile and account. If necessary, this can be easily re-created. If another account is
properly configured within the profile, this should not disrupt operations.
❑
Deleting an account removes its availability in all profiles. If the profiles already have another
valid account configured, then you (or your users) shouldn’t notice any problems. If you are
deleting an account that is the only account in one or more profiles, those profiles will not be
able to send mail.
❑
Deleting a profile removes a list of configured accounts, not the accounts themselves. If, however, your application is configured to use a mail profile you’ve recently deleted, once again,
your SQL Server will be unable to send messages.
309
Page 309
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Sending Mail
This chapter has spent a lot of time looking at the elements and configuration of Database Mail, so now
let’s see where your efforts have gotten you. Sending mail is an easy process. This section introduces the
parameters of the sp_send_dbmail stored procedure, as well as a couple of useful examples of how to
prepare data for sending.
sp_send_dbmail
As mentioned earlier, the stored procedure for sending mail using the Database Mail feature is
sp_send_dbmail. As with the other Database Mail stored procedures covered earlier in this chapter, this
one lives in the msdb database; and if you’re going to be instantiating it from outside of that database,
you’ll need to qualify it, as you have been doing throughout the chapter.
Keep in mind that although a mail profile may be made public and is available to the members of the
public role, the sp_send_dbmail can only be executed by members of the DatabaseMailUserRole. Ensure
that all logins that need access to the sp_send_dbmail stored procedure are mapped to a user in the msdb
database and are members of the DatabaseMailUserRole.
The following table identifies the different parameters available to sp_send_dbmail and their
descriptions:
310
Parameter
Description
@profile_name
Name of the profile the stored procedure will use. If a default profile
is specified for the user or one has been defined for the public role,
this value is optional.
@recipients
List of e-mail addresses that will receive your message. Use semicolons between values. Although this value is technically optional,
you must specify at least one recipient through @recipients (To:),
@copy_recipients (CC:), or @blind_copy_recipients (BCC:).
@copy_recipients
The same as using the CC: (also called Carbon Copy) field in a
standard e-mail client. As with the recipients list, you can use
semicolons between multiple values.
@blind_copy_
recipients
The same as using the BCC: (also known as Blind Carbon Copy) field
in a standard e-mail client. This value will indicate a list of recipients
for your messages, but the addresses are obfuscated by e-mail
clients. Use semicolons between multiple values.
@subject
Subject of the mail message. Defaults to SQL Server Message with no
value specified.
@body
Text of the message. The default is NULL.
@body_format
Message delivery format. Choose between TEXT and HTML. The
default is TEXT.
@importance
Allows you to specify a value indicating how the client should treat
the message. Choose between Low, Normal, and High. The default is
Normal.
12:01pm
Page 310
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Parameter
Description
@sensitivity
Allows you to define a sensitivity level for the message, interpreted
by the client. Choose from Normal, Personal, Private, and
Confidential. The default is Normal.
@file_attachments
Allows you to provide a list of external files that can be attached to
the e-mail message. The user executing the stored procedure must
specify (and have access to) the absolute file path where the files
reside. Use a semicolon between file paths to specify multiple files.
@query
Identifies a query whose results will be sent as part of the message.
The query results can be added to the body of the message or
attached as a file.
@execute_query_
database
Identifies the database context in which the aforementioned query
will run. This defaults to the current database, and is only used if the
@query option is used.
@attach_query_result_
as_file
Specifies if the query result is returned as part of the message body
or an attached file. It uses a bit value of 0 to append to the body, and
a value of 1 to attach a file with the results. Defaults to 0.
@query_attachment_
filename
Allows you to define the filename that will be attached if
@attach_query_result_as_file is set to 1. If a filename is not
provided, SQL will make one up for you.
@query_result_header
Bit value that specifies if column headers are included with the
results. Not surprisingly, 0 equals no, and 1 equals yes. Defaults to 1.
@query_result_width
Allows you to specify the line width by maximum number of
characters. This is an int value with a range between 10 and 32,767.
The default is 256.
@query_result_
separator
Allows you to define a single character delimiter between columns
in a query output. The default is a single space (’ ‘).
@exclude_query_output
This option allows you to define (when using a query in a mail
message) whether to output the query results to the console. This
defaults to 0, which will display the results.
@append_query_error
If an error is returned from a query, setting this value to 1 will
include the error in the e-mail message. The default of 0 does not
include error information.
@query_no_truncate
Setting the value of this option to 1 will override the default
behavior, which is to truncate variable-length columns greater than
256. If you override the default, be aware that columns that store a
large amount of data may take longer to process and send.
@mailitem_id id OUTPUT
This option allows you to return the mailitem_id after the message
has been generated. You can use this to review or clean up sent
messages.
311
Page 311
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Take a look at some examples of how to send mail messages from within SQL Server.
In this first example, you can create a simple mail message that doesn’t rely on any additional data source.
This can be executed as a SendMail task upon completion of a job, or through an event notification. This
one will send a simple message, indicating that an import task has been successfully completed.
EXECUTE msdb.dbo.sp_send_dbmail
@profile_name = ‘HRMail’,
@recipients = ‘[email protected]’,
@copy_recipients = ‘[email protected]’,
@body = ‘Your data has been successfully imported!’,
@subject = ‘Import Notification Message - Success’;
In order for the message to actually be delivered, you must be running SMTP and POP3 services for the
adventureworks.com domain, and you must also have Gregory.House and the Administrator accounts
configured as POP3 recipients. If you have a different SMTP server configured, you can change the
@recipients and @copy_recipients parameters to valid mail accounts. The Query window will simply
return ‘‘Mail Queued.’’ The resulting e-mail should look something like Figure 8-14.
Figure 8-14: Simple mail message.
Another example uses a query within the sp_send_dbmail stored procedure to send the results to the
intended recipient list. In this example, you’re going to use a query that returns the first names, last
names, and hire dates of all employees hired in the year 2002:
EXECUTE msdb.dbo.sp_send_dbmail
@profile_name = ‘HRMail’,
@recipients = ‘[email protected]’,
@blind_copy_recipients = ‘[email protected];
[email protected]’,
@body = ‘Per your request, here are the employees hired in 2002.’,
@query = ‘SELECT Person.Person.FirstName AS First,
Person.Person.LastName AS Last,
312
12:01pm
Page 312
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
HumanResources.Employee.HireDate AS [Date of Hire]
FROM Person.Person INNER JOIN HumanResources.Employee
ON Person.Person.BusinessEntityID =
HumanResources.Employee.BusinessEntityID
WHERE HireDate > ‘’2002-01-01" AND HIREDATE < ‘’2003-01-01’’
ORDER BY HireDate’,
@execute_query_database = ‘AdventureWorks2008’,
@subject = ‘Employees Hired in 2002’,
@attach_query_result_as_file = 1;
The resulting attachment should look something like Figure 8-15.
Figure 8-15: Raw output of 2002 new hires.
One more example shows you how to take the information in a query and prepare it as an HTML document. You can then e-mail the HTML document as the body of the mail message, and as long as the
recipient’s mail reader can render HTML, the recipient will have a nice-looking display.
USE AdventureWorks2008
DECLARE @tableHTML NVARCHAR(MAX) ;
SET @tableHTML =
N’<H1>Employees Hired in 2002</H1>’ +
N’<table border="1">’ +
N’<tr><th>First Name</th><th>Last Name</th>’ +
N’<th>Hire Date</th>’ +
CAST ((SELECT td = Person.Person.FirstName,
‘’,
td = Person.Person.LastName, ‘’,
td = HumanResources.Employee.HireDate, ‘’
FROM Person.Person INNER JOIN HumanResources.Employee
ON Person.Person.BusinessEntityID =
HumanResources.Employee.BusinessEntityID
WHERE HireDate > ‘2002-01-01’ AND HIREDATE < ‘2003-01-01’
Order by HireDate
FOR XML PATH(’tr’), TYPE
) AS NVARCHAR(MAX) ) +
N’</table>’;
EXEC msdb.dbo.sp_send_dbmail @recipients=’[email protected]’,
@subject = ‘2002 New Hires’,
@body = @tableHTML,
@body_format = ‘HTML’;
313
Page 313
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
This will return the output shown in Figure 8-16 to the mail client.
Figure 8-16: HTML document as body of e-mail message.
Managing Messages
As mentioned earlier, Database Mail messages are retained on the server. If you want to view which
messages have been retained, you can query the sysmail_mailitems table in the msdb database. This
returns detailed information about each message, such as who the recipients were, what the body of the
message contained, and which profile sent the message.
SELECT * FROM msdb.dbo.sysmail_mailitems
You can also delete messages from the server by using the sysmail_delete_mailitems_sp stored
procedure. This will allow you to delete messages that have either failed or succeeded, or delete just
messages older than a specific date. Service Pack 1 requires that you provide either the @sent_before or
@sent_status option.
To delete messages from before January 31, 2009, use the following example:
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
@sent_before = ‘January 31, 2009’ ;
To delete messages that show a specific status value, use the following examples:
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
@sent_status = ‘failed’;
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
314
12:01pm
Page 314
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
@sent_status = ‘retrying’;
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
@sent_status = ‘unsent’;
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
@sent_status = ‘sent’;
Event Notifications
Event Notifications are database objects that send information about server and database events to a Service Broker. They execute in response to data definition language (DDL) statements and SQL Trace
events by sending information about these events to a Service Broker service. You can use Event Notifications either to log activity within a database or to execute an action asynchronous to an event. They are
designed to be an alternative to creating DDL triggers or using SQL Trace functions.
Because Event Notifications run outside the scope of a transaction, they can be used inside a database
application to respond to events without using any resources defined by the immediate transaction.
Event Notifications operate independently of whether or not the transaction commits. They can also be
used to perform an action inside an instance of SQL Server in response to a SQL Trace event.
Every Event Notification has its own exclusive Service Broker conversation between an instance of SQL
Server and the target service you specify. The conversations usually remain open as long as the Event
Notification still exists on the server. Ending a conversation prevents the target service from receiving
more messages, and the conversation will not reopen when the Event Notification fires again.
Event information is an XML data type that provides information about when the event occurs, the object
it affects, the batch statement involved, and more. This data can be used by applications that help SQL
Server track progress and make decisions.
When designing an Event Notification, you must define both the scope of the notification and the
statement or batch that raises the notification. For example, the Event Notification can occur as a
response to a statement made on all objects in the AdventureWorks2008 database. You can also define
the scope as being server-wide, such as triggering Event Notifications when new databases or logins are
created.
More information about the architecture used to create services and queues is covered in Chapter 19.
However, you should be aware that some of the mechanisms discussed in this section are also applicable
to the next topic, the SQL Server Agent Service. For this reason, you should ensure that the msdb database
is configured to manage Service Broker objects and process Event Notifications. Two important elements
of this are ensuring that the SQL Server can trust the database and the object within it, and that the
database is configured for Service Broker message delivery. To do this for the msdb database, use the
following ALTER DATABASE statement:
ALTER DATABASE msdb
SET TRUSTWORTHY ON,
ENABLE_BROKER;
GO
315
Page 315
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Because the SQL Server Agent Service may have an active connection to the msdb database, it may be
necessary to stop the service prior to running this statement and then restart it once the command has
completed successfully.
There is also a feature in SQL Server 2008 known as SQL Server Extended Events. A full description of
Extended Events is beyond the scope of this book; however, you should be aware that they can be used
for more advanced troubleshooting and diagnostics. One of the key benefits of using Extended Events
is the ability to associate SQL events with operating system or database application events, through the
use of Event Tracing for Windows (ETW). More information on Extended Events can be found under the
topic ‘‘Introducing SQL Server Extended Events’’ in Books Online.
SQL Ser ver Agent
This section explains how to automate SQL Server tasks using the Microsoft SQL Server Agent Service.
The SQL Server Agent Service runs as a Windows service that is dependent on the SQL Server service.
Each instance of SQL Server will have its own SQL Server Agent Service to manage jobs, schedules,
operators, and alerts. You learn about the essential components of the SQL Server Agent Service for
single and multiple server management configurations.
The primary purpose of the SQL Server Agent is to make your job easier. In a perfect world, you could
configure your servers, let them run, and never worry about losing data or the database going offline.
But this isn’t a perfect world. Things happen. And because you can’t realistically monitor every server
every minute of every day, you can use the SQL Server Agent to leverage against what you can’t do.
The SQL Server Agent Service is not available in SQL Server 2008 Express Edition.
Configuring the SQL Server Agent Service
In Chapter 2, you learned about installing SQL Server and defining which accounts are used by the SQL
Server service and the SQL Server Agent Service. A common configuration is to use the same account for
both services, but this is not required. In fact, because of certain job or administrative requirements, you
may need to use completely different credentials for each. Regardless of whether or not you use the same
account, the account used by the SQL Server Agent must be a member of the sysadmin fixed server role
and must have the following rights in the Windows operating system where the server is installed:
❑
Adjust memory quotas for a process.
❑
Act as part of the operating system.
❑
Bypass traverse checking.
❑
Log on as a batch job.
❑
Log on as a service.
❑
Replace a process-level token.
These rights can be granted by an administrator editing the Local Security Policy. If the SQL Server
Agent will be interacting with services and features outside the local system, an Active Directory domain
account should be used. This allows the SQL Server Agent to use an authenticated account to connect to
a remote file system, Web Service, or another SQL Server.
316
12:01pm
Page 316
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
An out-of-the-box installation of SQL Server with no changes to the default configuration does not start
the SQL Server Agent Service but, instead, requires manual control over the start and stop behavior of
the service. Don’t do this. If you are going to use the SQL Server Agent for automation or alerting features,
it needs to be running. If the SQL Server Agent is stopped, no scheduled jobs can run, and no operator
will receive notification indicating that a job did or did not run successfully. When installing SQL Server,
it is a good practice to configure the SQL Server Agent to run automatically when Windows starts.
If, however, you did not configure the SQL Server Agent to start automatically, you’ll need to know how
to start it manually. There are actually four different ways you can start and stop the SQL Server Agent
Service.
One way is to use the NET START command from a Windows command prompt:
NET START SQLSERVERAGENT
To stop the service, use the NET STOP command:
NET STOP SQLSERVERAGENT
You can also use the Services snap-in from the Administrative Tools menu or the Computer Management
console. From this tool, you can also configure the account that the service runs under, change the start-up
behavior, choose service recovery options, and view the dependencies of the service. In Chapter 3, you
learned how to use SQL Server Configuration Manager. You can use that similarly to configure the
account used by the SQL Server Agent Service and the start-up behavior, as well as error reporting
options. Finally, you can use SQL Server Management Studio to configure the behavior and properties of
the SQL Server Agent Service.
This section will spend more time going into depth about configuring the various properties of the service, so you have a good understanding of each of the configurable elements from within a familiar tool.
In Object Explorer, you can right-click ‘‘SQL Server Agent’’ and either stop or start the service as needed.
To configure the service, select Properties from the context menu.
General Properties
From the General Properties sheet (see Figure 8-17), you can see the current state of the service, and you
can configure both the SQL Server and SQL Server Agent to automatically restart if they stop unexpectedly. You can also change the location of the error log and elect to include execution trace messages in
the logs for advanced troubleshooting. There is also an option to use an original equipment manufacturer
(OEM) file. This allows the log information to store data in a non-Unicode format, which can take up less
space on the system. However, if the error logs contain any Unicode data, it may be more difficult to read
or interpret. Finally, the NET SEND RECIPIENT indicates an operator that can be notified of messages that
SQL Server writes to the log file.
The messenger service is disabled by default in Windows Server 2003 and Windows Server 2008. The
ability to use NET SEND may not be available.
Advanced Properties
In the Advanced Properties sheet (see Figure 8-18), you can enable event forwarding, which will re-direct
SQL Server events to a different server. To configure this, enable the checkbox next to ‘‘Forward events
317
Page 317
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
to a different server,’’ and then select an available server or instance from the dropdown list. Once this
is configured, you can also determine what type of events will get forwarded. ‘‘Unhandled events’’ are
those that do not have alerts defined by the SQL Server Agent system, or you can select ‘‘All events.’’ You
can also decide to forward events with a minimum severity level. Severity-level values are discussed in
detail later in this chapter.
Figure 8-17: SQL Server Agent General Properties.
From this window, you can also define the CPU idle threshold. This can be useful if you have any job
schedules that define the job and should be run when the CPU is idle, such as backing up the transaction
log. In this case, the default values indicate that CPU usage must fall below 10 percent for 10 minutes.
You can adjust this as necessary to meet your performance needs.
Alert System Properties
You can configure the Alert System properties from this page (see Figure 8-19) by first defining if the SQL
Server Agent Mail service is enabled. If you want your operators to receive alert notifications by e-mail,
you should enable this feature. You can also decide if you are going to use the Database Mail feature or
the SQL Mail feature. Remember that SQL Mail is provided for backward compatibility only and should
not be used with new applications because it will be phased out. If you are upgrading from a previous
version of SQL, you should try to convert your applications to use Database Mail as soon as possible.
318
12:01pm
Page 318
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Figure 8-18: SQL Server Agent Advanced Properties.
Once you’ve selected your mail system (Database Mail, preferably), you can then select an appropriate
profile to use. If you are using SQL Mail, you can test the MAPI connectivity and allow Sent messages to
be saved in the Sent Items folder of the Microsoft Outlook profile.
If you will be paging operators, you can configure options for formatting addresses in the To, CC, and
Subject lines of the message. You can also elect to include the body of the e-mail message in the page.
Additionally, you can define a fail-safe operator and methods for notifying that person. The role of the
fail-safe operator is discussed in more detail later in this chapter.
Finally, there is the option to replace tokens for all job responses to alerts. Tokens are a feature (similar to
variables) of job steps that are discussed later in this chapter. For now, though, you should understand
that this enables token replacement, replacing the variable with an actual value, for any job executed by
the alert systems.
Job System Properties
You can specify the time-out value for jobs in the Job System Properties window (see Figure 8-20). This
option configures how long the SQL Server Agent will wait for a job to complete before forcefully terminating the job. The default is 15 seconds, but be aware of how long certain jobs may need to take (because
of their complexity) or the type of operations being performed.
319
Page 319
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Figure 8-19: SQL Server Agent Alert system properties.
There is also an option to configure a non-administrative account as a proxy account for job steps. This is
only applicable if you are using SQL Server Management Studio to manage an older version of SQL
Server and its corresponding Agent service. You can specify the authentication information for the
account by providing a username, password, and domain name. Configuring a proxy account for SQL
Server 2008 job steps is covered in the section, ‘‘Creating Jobs,’’ later in this chapter.
Agent Connection Properties
If you need to connect to an instance of SQL Server that uses a non-standard connection property, you
can enter an alias used by the SQL Server to allow the SQL Server Agent Service to establish and maintain
a connection (see Figure 8-21). You can also specify whether you require the SQL Server Agent Service
to use Windows authentication or SQL Server authentication. If you select SQL Server authentication,
you must provide a valid login and password for an account that is a member of the sysadmin fixed
server role.
Job History Properties
Finally, the History page allows you to configure retention settings for job logs in the msdb database. By
default, a maximum of 1,000 rows are stored in the sysjobhistory table, and each job can use no more
than 100 rows in that table. You can use this window to remove or change the limit to the size of the job
history table (see Figure 8-22).
320
12:01pm
Page 320
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Figure 8-20: SQL Server Agent Job system properties.
You can also have the SQL Server Agent service automatically purge old job history rows from the
sysjobhistory table. This feature is disabled by default. However, if enabled, it allows you to specify
how many days, weeks, or months old a job history record must be before it can be purged from the
database. If you need to maintain the job history indefinitely or need to have greater control over what
gets purged, consider creating a custom job that will meet your needs.
SQL Server Agent Security
When planning to use the SQL Server Agent Service, or allowing other users to access it, you need to
ensure that appropriate access is granted. By default, only members of the sysadmin fixed server role
have complete access to the SQL Server Agent Service. In the msdb database, additional roles are created
with varying levels of rights and permissions, but these roles are empty until a user is explicitly added
to one or more of these roles. This section identifies each of these roles and the permissions assigned
to them.
SQLAgentUserRole
The SQLAgentUserRole is the most limited of the three SQL Server Agent roles. Users who are members of this role have the ability to create new jobs and schedules and can manage only those jobs and
schedules they create. However, they cannot view the properties of other jobs on the system, nor can they
321
Page 321
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
define operators or proxies. If they need to assign an operator or proxy to a job step, it must have already
been defined. Members of this role also cannot delete job history information, even for jobs they own,
unless they are granted EXECUTE permission on the sp_purge_jobhistory stored procedure. Another
important limitation on this role is the inability to create or manage multi-server jobs. This means that
any job created by members of this role is limited to the server on which it was created.
Figure 8-21: SQL Server Agent Connection properties.
SQLAgentReaderRole
The SQLAgentReaderRole role can enable users to create local jobs and schedules and manage only those
that they create. In addition to these permissions, they can also view the properties of other local jobs, as
well as multi-server jobs. This gives them the ability to audit the configuration of other jobs on the server,
without having any rights to change those settings. This role is also prevented from creating multi-server
jobs, but the job histories of all local and remote jobs are available for review. Members of this role,
too, are prohibited from deleting the history of jobs they own, unless granted EXECUTE permission on
sp_purge_jobhistory.
SQLAgentOperatorRole
Members of this role can create local jobs, as well as manage and modify jobs they own. They can also
view and delete the job history information for all local jobs. To a limited extent, they can also enable or
disable jobs and schedules owned by other users. However, they are still prohibited from creating and
322
12:01pm
Page 322
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
managing operators and proxies. They are also limited to Read Only access for multi-server jobs, as well.
Outside of the sysadmin fixed server role, this role is granted the most rights and privileges to the job
system in the SQL Server Agent Service.
Creating Jobs
Jobs are really at the core of the SQL Server Agent service. Jobs are operations that perform through a
sequence of steps that run Transact-SQL scripts and launch command-prompt applications, ActiveX
script tasks, replication tasks, and a variety of other tasks. Each task is defined as a separate job step. Part
of the design of the job system is to build each task so that you can build dependencies and workflows
between the job steps. A very simple example of this would be a backup job that ran nightly and then
e-mailed an administrator to inform him or her that the job was complete. The simplicity and complexity
of a job depend on what you need it to do. In some cases, you’ll want to create multiple jobs, rather than
a single, overly complex one, because of the time-out settings mentioned earlier.
Figure 8-22: SQL Server Agent History properties.
Try It Out
Creating a New Job
Begin by creating a new job in SQL Server Management Studio. For this example, you’re going to populate only the most basic information about the job from the General Properties page. Feel free to browse
323
Page 323
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
through the other property pages in this exercise, but be aware that the configurable elements in those
pages are covered later in this chapter.
1.
2.
3.
In Object Explorer, expand SQL Server Agent.
Right-click Jobs and select ‘‘New Job.’’
In the New Job dialog box (see Figure 8-23), enter Simple Backup as the job name.
Figure 8-23: New Job properties.
4.
5.
6.
7.
8.
Leave the Owner as the default.
Select Database Maintenance in the Category dropdown list.
In the description, enter Simple Backup Job. Test 1.
Remove the check next to Enabled.
Click OK.
This creates a new job and prevents the job from running once you close the New Job window. Because
the job has no steps, there would have been little harm in letting it run, but it’s a habit you will want to
get into, until you’ve tested your jobs to ensure that they work as expected.
324
12:01pm
Page 324
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Now look at how to create a new job using Transact-SQL. The sp_add_job stored procedure allows you
to create a new job and set configurable options on the job. The following table lists all the options for
sp_add_job:
Option
Description
@job_name
The name of the job
@enabled
The default value of 1 indicates the job is enabled, and a value of
0 means the job is disabled. Disabled jobs can still be manually
executed.
@description
An optional description of the job. If no value is specified, the field
is populated with No description available.
@start_step_id
In more complex jobs, where you have multiple steps built around
dependencies and error handling, you can actually have the job
start at a step other than the first one. Use the integer-based job ID
value for the initial job step.
@category_name
Allows you to type a category name to assign the job. Categories
make it easier to group and manage jobs that have similar functions. Be aware that if you misspell an existing job category (as in
‘‘Databizase Maintenance’’), it will return an error. You must use an
existing category name.
@category_id
Allows you to use the category_id value rather than category name. Category names and IDs are stored in msdb.dbo
.syscategories.
@owner_login_name
Allows a system administrator to set a different login as the owner
of the job.
@notify_level_eventlog
Indicates what information should be added to the Windows
Application Log. This is an int data type with the following
values:
0 — Never
1 — On success
2 — On Failure (Default)
3 — Always
@notify_level_email
Indicates when to send e-mail messages regarding this job, using
the levels described in @notify_level_eventlog. The default is 0.
@notify_level_netsend
This value indicates when a NET SEND message should be sent. The
Messenger service must be started on both the sender and the recipient machines for this to work. With a default value of 0, the levels
for @notify_level_eventlog can be used to change its behavior.
Continued
325
Page 325
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Option
Description
@notify_level_page
Indicates when to send messages to an SMTP-enabled
pager, using the same values as @notify_level_eventlog.
The default is 0.
@notify_email_operator_name
The name of an operator that will receive e-mail messages if
e-mail notification is enabled. Do not use the e-mail address
but, rather, the sysname value of the operator.
@notify_netsend_operator_name
The name of an operator that will receive NET SEND
messages
@notify_page_operator_name
The name of the operator that will receive SMTP pages
@delete_level
Indicates when to delete the job, using the values defined in
@notify_level_eventlog. If the level is set to 3, the job is
deleted upon completion, and no further instances of this
job will run. The default is 0.
@job_id job_id OUTPUT
Returns the value of the job_id. The job_id is of the
uniqueidentifier data type.
Take a look at using the sp_add_job stored procedure to create a new job with only the basic elements.
After creating other elements such as schedules, operators, and alerts, you will add those into the jobs
you create in this section. For this example, you will create a new job that will be used for data retrieval tasks:
DECLARE @job_id uniqueidentifier;
EXECUTE msdb.dbo.sp_add_job
@job_name = ‘Poor Performers Report’,
@description = ‘Monthly task to indicate which sales team members have less
than remarkable sales figures over previous year’,
@job_id = @job_id OUTPUT;
SELECT @job_id
One thing you should notice about the job_id parameter is that it uses the uniqueidentifier data
type. This is also referred to as a Globally Unique Identifier (GUID). GUIDs are used for both jobs
and schedules if either will be used for multi-server jobs. Multi-server jobs are covered later in this
chapter.
If you’re adding a job using the sp_add_job stored procedure, you will also need to ensure that the job
can run on the server by using the sp_add_jobserver stored procedure. If the job is going to run on the
local server, all you need to define is the job either by job_id or job_name, as in the following example:
EXECUTE msdb.dbo.sp_add_jobserver
@job_name=’Poor Performers Report’;
326
12:01pm
Page 326
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
So, now you have two new jobs available to your SQL Server Agent Service. Neither job has any steps
defined, so running them won’t accomplish anything, other than receiving a failure message. (But hey,
if that’s what you’re after, go for it.) Before adding steps to your jobs, take a look at how to manage job
categories.
Categories
The easiest and preferred method for managing job categories is through SQL Server Management Studio. Although you could directly edit the syscategories table, it’s not recommended. You can add new
categories and delete user-created categories. Be aware that you cannot delete built-in categories. In this
example, you will add a new category called AW–Performance Tasks.
Try It Out
1.
2.
3.
Creating a New Category
From Object Explorer, expand your server, and then expand SQL Server Agent.
Next, right-click Jobs, and select ‘‘Manage Job Categories.’’
In the Manage Job Categories window (see Figure 8-24), click Add.
Figure 8-24: Manage Job Categories screen.
4.
5.
6.
7.
8.
For the category name, enter AW–Performance Tasks.
Check the box next to ‘‘Show all jobs.’’
Check the box in the row for the Poor Performers Report job.
Click OK.
Click Cancel to close the Manage Job Categories window.
You have now successfully created the AW–Performance Tasks category and added the Poor Performers
Report job to it. This category will now be available for any new jobs you want to create.
327
Page 327
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Creating Job Steps
Now that you have a couple of jobs you can work with, add some simple steps to these jobs. Before doing
this, though, take a look at the different types of job steps you can define, as shown in the following table:
Step Type
Description
Windows Executable (CmdExec)
This will run Windows executable code, including files
with the following extensions: .exe, .bat, .cmd, .com. For
fully automated tasks, the executable may contain
command-line parameters that can be passed to control
execution.
Transact-SQL
Any T-SQL script that will execute in the context of the
job owner if not otherwise specified. The Transact-SQL
script can contain multiple batches and can include
executing stored procedures.
ActiveX Script
Can use any language supported by the Windows
Scripting Host. Common examples use VBScript and
JavaScript. The script itself is written into the job task.
Replication
Used to initiate replication agents for the different
replication types. Chapter 16 introduces replication and
the function of these agents.
Analysis Services
Can be either command steps or queries.
Integration Services
Can execute a SQL Server Integration Services (SSIS)
package. For more information about SSIS, see
Chapter 13.
For each job step type, you can identify one or more proxy accounts that can be used to execute that step
type, in case the owner of the job, or the login under which the job is run, does not have permissions
to execute that type of task. It allows you to let users run jobs that contain steps that they would not
be able to run under their own credentials. You learn about creating and managing proxies later in this
chapter.
This first example uses SQL Server Management Studio again to edit the properties of the Simple Backup
job. You’re going to add a Transact-SQL step that will perform a full backup of the AdventureWorks2008
database onto the local disk. Before beginning, you should create a folder called dbBackups on your
C: drive.
1.
2.
3.
328
From Object Explorer, expand your server, and then expand SQL Server Agent.
Expand Jobs.
Right-click ‘‘Simple Backup,’’ and select Properties.
12:01pm
Page 328
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
4.
5.
6.
7.
8.
9.
10.
Under the ‘‘Select a Page’’ list, select Steps.
Click on the New button.
In the ‘‘Step Name’’ box, enter AdventureWorks2008 Backup.
In the Type dropdown list, ensure that Transact-SQL is listed.
Leave ‘‘Run as’’ empty.
Ensure that master is the selected database.
Enter the following code in the command window:
BACKUP DATABASE AdventureWorks2008 TO DISK = ‘C:\dbBackups\AWFull.bkf’;
11.
12.
13.
Click OK to close the New Job Step window.
Click OK to close the Job Properties window.
In the SQL Server Management Studio Note, it informs you that the last step will be changed
from ‘‘Go to Next Step’’ to ‘‘Quit with Success.’’ Click Yes.
You have now created a simple job step. Feel free to enable the job by right-clicking on the job and selecting Enable from the context menu. You can also manually run the job at any time, even if it’s disabled,
by right-clicking and selecting ‘‘Start Job.’’ The job should execute with success.
If you go back into the job step properties and look at the Advanced Properties page, you will notice
options to configure how the job responds when this step completes. If the job is successful, you can have
it perform one of the following tasks:
❑
Go on to the next step.
❑
Quit the job reporting success.
❑
Quit the job reporting failure.
❑
Go to Step: (number).
The option to go to a numbered step is only available if you have more than one step in the job. Be careful
about creating cyclical jobs where the first step will go to the next step, and the second step will go to the
first step.
On this page, you can also identify the number of retry attempts and how long (in minutes) the server
should wait between retries. If the job step cannot be completed successfully, you can also define how
the job should behave. You have the same options for defining what to do when the step fails as when it
succeeds.
Also, depending on the type of step being executed, you can define additional options or parameters. For
example, with Transact-SQL steps, you can specify an output file, log the output to a table, and include
output information with the job history. You can also identify who the step should run as.
329
Page 329
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
sp_add_jobstep
You can use the sp_add_jobstep stored procedure to add steps to an existing job. Using this procedure
allows you to append a step to an existing job or insert a new step between two existing steps. The
following table provides a breakdown of the parameters for sp_add_jobstep:
Parameter
Description
@job_id
The uniqueidentifier value of the job. You can use this or
job_name to refer to the job to which you are adding the step.
@job_name
The display name of the job. Use either this or the job_id, but not
both.
@step_name
A display name for the step
@step_id
A unique number indicating where this step should be added
into the job step order. If no value is specified, the step_id will
auto-increment by 1. If the value specified already exists, this will
insert this step and increment the step that previously held this
value (and all steps that follow it) by 1.
@subsystem
This parameter allows you to identify which subsystem will be
used to interpret the step. The available values are:
ACTIVESCRIPTING — ActiveX script
CMDEXEC — Windows command or executable
DISTRIBUTION — Replication Distribution job
SNAPSHOT — Replication Snapshot job
LOGREADER — Replication Log Reader Agent job
MERGE — Replication Merge Agent job
QueueReader — Replication Queue Reader Agent job
ANALYSISQUERY — MDX or DMX Analysis Services query
ANALYSISCOMMAND — XMLA Analysis Services command
Dts — Integration Services Package
PowerShell — Invokes a PowerShell script.
TSQL — Transact-SQL script. This is the default.
330
@command
The command that will be executed as the job step. The syntax will vary depending on the subsystem used to process the
command.
@additional_parameters
This is not implemented but may be used in a future version.
@cmdexec_success_code
Value returned by the CmdExec subsystem. Uses int data type,
and the default is 0.
12:01pm
Page 330
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Parameter
Description
@on_success_action
Allows you to specify what to do if the step is successful. Use one
of the following values:
1 — Quit with success (default).
2 — Quit with failure.
3 — Go to the next step.
4 — Go to step on_success_step_id.
@on_success_step_id
The ID of the step to go to if option 4 is selected above
@on_fail_action
The same values as on_success_action except on_success_
step_id is replaced by on_fail_step_id
@on_fail_step_id
The ID of the step to go to if option 4 is selected for on_
fail_action
@database_name
The database in which a Transact-SQL step will execute. If no
value is specified, the Master database is used. If the step is
an ActiveX script, this can be used to identify the scripting
language.
@database_user_name
The user account under which the Transact-SQL step will execute
@retry_attempts
The number of attempts a step will make before it fails. The
default is 0.
@retry_interval
The number of minutes before retry_attempts. The default is 0.
@os_run_priority
This is not available in this version of SQL Server, but may be
implemented in the future.
@output_file_name
An external file in which step output is saved. Valid for
Transact-SQL and CmdExec steps.
@flags
Options that control output behavior. Uses the following values:
0 — Overwrite output file (default).
2 — Append to output file.
4 — Write T-SQL step output to step history.
8 — Write log to table, overwriting existing history.
16 — Write log to table, appending to existing history.
@proxy_id
The ID of a proxy account that will be used for this job step, if
needed
@proxy_name
The name of a proxy account that will be used for this job step, if
needed
331
Page 331
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
There are additional parameters listed in SQL Server Books Online that are identified as ‘‘reserved.’’
Because they are not configured, they are not included in this list.
Now take a look at creating a couple of job steps for the Poor Performers Report job. The first step will
generate an e-mail message that identifies sales employees who have not exceeded their previous year
sales by $200,000 (slackers!). The second step will e-mail an administrator indicating that the job has been
successful:
-- Create the First Step
EXECUTE msdb.dbo.sp_add_jobstep
@job_name = ‘Poor Performers Report’,
@step_id = 1,
@step_name = ‘Send Report’,
@subsystem = ‘TSQL’,
@command = ‘DECLARE @tableHTML NVARCHAR(MAX) ;
SET @tableHTML =
N’’<H1>Lowest Sales Increase</H1>" +
N’’<table border=1>" +
N’’<tr><th>First Name</th><th>Last Name</th>" +
N’’<th>Current Year Sales</th>" +
N’’<th>Previous Year Sales</th>" +
CAST ((SELECT td = pC.FirstName, ‘’’’,
td = pC.LastName, ‘’’’,
td = sP.SalesYTD, ‘’’’,
td = sP.SalesLastYear, ‘’’’
FROM AdventureWorks2008.Sales.SalesPerson AS sP INNER JOIN
AdventureWorks2008.HumanResources.Employee AS hrE ON
sP.BusinessEntityID = hrE.BusinessEntityID INNER JOIN
AdventureWorks2008.Person.Person AS pC
ON hrE.BusinessEntityID = pC.BusinessEntityID AND
hrE.BusinessEntityID = pC.BusinessEntityID
WHERE (sP.SalesYTD - sP.SalesLastYear) < 200000
FOR XML PATH(’’tr’’), TYPE
) AS NVARCHAR(MAX) ) +
N’’</table>’’;
EXECUTE msdb.dbo.sp_send_dbmail
@recipients = ‘’[email protected]’’,
@subject = ‘’First to go...’’,
@body = @tableHTML,
@body_format = ‘’HTML’’;’;
-- Create Step 2
EXECUTE msdb.dbo.sp_add_jobstep
@job_name = ‘Poor Performers Report’,
@step_id = 2,
@step_name = ‘Notify Administrator’,
@subsystem = ‘TSQL’,
@command = ‘EXEC msdb.dbo.sp_send_dbmail
@recipients = ‘’[email protected]’’,
@subject = ‘’Message Sent’’,
332
12:01pm
Page 332
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
@body = ‘’The Monthly Sales Report has been sent’’,
@body_format = ‘’HTML’’;’;
Now, you must tell the step that you created earlier to go to the next step once the first step has been
completed. For this, use the sp_update_jobstep stored procedure, as follows:
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = ‘Poor Performers Report’,
@step_id = 1,
@on_success_action = 3;
Remember that when on_success_action is set to 3, the step will go to the next step.
Token Replacement
SQL Server 2008 uses tokens in job steps as parameter placeholders. These tokens allow the SQL Server
Agent Service to replace the token with an actual value at run time (this token will not be replaced when
executed as a query in SQL Server Management Studio). This is similar to using a variable within a script
or an application. When writing jobs, consider using some of these tokens to provide accurate reporting
of job status. These tokens can also allow your jobs to be more flexible. The following table provides a list
of tokens supported by the SQL Server Agent Service:
Token
Description
$(A-DBN)
Database name, used in jobs launched by alerts
$(A-SVR)
Server name, used in jobs launched by alerts
$(A-ERR)
Error number, used in jobs launched by alerts
$(A-SEV)
Error severity, used in jobs launched by alerts
$(A-MSG)
Message text, used in jobs launched by alerts
$(DATE)
Current date (YYYYMMDD)
$(INST)
Instance name. The default instance returns an empty value.
$(JOBID)
Job ID
$(MACH)
Computer name
$(MSSA)
Master SQL Server Agent Service name
$(OSCMD)
Prefix for the program used to run CmdExec steps
$(SQLDIR)
The SQL Server installation directory
$(STEPCT)
The number of times this step has executed, excluding retries. Can be used to
force a multi-step loop to terminate.
$(STEPID)
Step ID
$(SRVR)
Name of the computer running SQL Server, including the instance name, if any
Continued
333
Page 333
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Token
Description
$(TIME)
Current time (HHMMSS)
$(STRTTM)
The time (HHMMSS) the job began executing
$(STRTDT)
The date (YYYYMMDD) the job began executing
$(WMI(property))
The value of the property specified by property, when the job is
launched by a Windows Management Instrumentation (WMI) alert
Using Tokens in Job Steps
When SQL Server 2005 Service Pack 1 was released, it significantly changed the way tokens are used
in job steps. Prior to that release, you could simply use a token like a variable, as seen in the following
example:
PRINT ‘The database backup of $(A-DBN) is now complete.’
If your job backed up the AdventureWorks2008 database, the job step would have returned the output:
’The database backup of AdventureWorks2008 is now complete.’
Job steps in SQL Server 2008 require the use of an escape macro to successfully replace the token. The
escape macros are used to prevent parsing errors that may exist because of invalid characters in the data
that replaces the token. For example, if you installed SQL Server to a folder called C:\Finance Department’s
Database and tried to use the $(SQLDIR) token, your job step might fail, believing that the value ended at
the word Department. There are four possible escape macros. The following table lists the escape macros
and their uses:
Escape Macro
Usage
$(ESCAPE_SQUOTE(token))
This allows any single quotation mark in the replacement
token string to be replaced by two single quotation marks.
$(ESCAPE_DQUOTE(token))
This escape macro replaces a double quotation mark with
two double quotation marks.
$(ESCAPE_RBRACKET(token))
Use this escape macro to replace a right bracket character
with two right bracket characters.
$(ESCAPE_NONE(token))
This allows the token to be replaced without escaping any
characters. This is designed for backward compatibility.
So, the correct way to use a token is to use the appropriate escape macro when calling the token. For
example, the following will prevent a database name that contains a single quote (which is possible)
from causing the command to end prematurely:
PRINT ‘The database backup of $(ESCAPE_SQUOTE(A-DBN)) is now complete.’
334
12:01pm
Page 334
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
In SQL Server 2008, because users that have Write permissions on the Windows Event Log can access
job steps that are activated by SQL Server Agent alerts or WMI alerts, use of any token that launched
by an alert is disabled by default. To enable these tokens, you can enable the ‘‘Replace tokens for all job
responses to alerts’’ option in the Alert System page of the SQL Server Agent properties.
Creating Schedules
To automate many of the tasks you need to perform to maintain your SQL Server, you must define schedules for when your jobs run. Schedules, not unlike categories, can be created and managed independently
of the creation and management of jobs. This allows you to use the same schedule for multiple jobs.
Each job can also use multiple schedules. For example, you may create a job that performs a Transaction Log backup. If your operation is not a 24/7 business, you might want to create a schedule so that
the transaction log is backed up more frequently during business hours. Let’s use every 2 hours as an
example. Then, you may want to continue to back up the transaction log after normal business hours,
but because there is less activity after hours, and therefore fewer changes to your database, you could
back up the transaction log every 4 hours. On the weekends, you may want to back up the transaction
logs every 8 hours. Not that you would expect a lot of activity, but if someone comes in to work over the
weekend, you will want to have a backup of any changes.
You can also enable or disable individual schedules as needed. When a schedule is disabled, any job
that uses that schedule will not run under that schedule. However, if a job is configured to use other
schedules, the job will run under those schedules. If the job itself is disabled, it will not run under any
schedule.
Take a look at the tools used to manage schedules. In this first example, you’re going to create a new
schedule for your Simple Backup job that will run the job every weekday at noon:
1.
2.
3.
4.
From Object Explorer, expand your server, and then expand SQL Server Agent.
5.
6.
7.
8.
9.
Ensure that the schedule type is Recurring, and ensure that the schedule is Enabled.
10.
11.
Right-click Jobs and select ‘‘Manage Schedules.’’
In the Manage Schedules window, click New.
In the New Job Schedule window (see Figure 8-25), enter Weekdays–Noon for the schedule
name.
In the Frequency section, make sure that the schedule is set to occur weekly.
Select the checkboxes for Monday, Tuesday, Wednesday, Thursday, and Friday.
If selected, remove the check in the box next to Sunday.
In ‘‘Daily frequency,’’ select the radio button marked ‘‘Occurs once at:’’ and set the time to
12:01:00 PM.
Leave the ‘‘Start date’’ as the current date, and ensure that ‘‘No end date’’ is selected.
Click OK.
At this point, you can either add the job to the schedule, or you can add the schedule to the job in the
properties. Let’s look at both methods.
335
Page 335
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Figure 8-25: New Job Schedule screen.
First, in the Manage Schedules window (which should be open, unless you closed it), you should notice
that the ‘‘Jobs in schedule’’ column for the Weekdays–Noon schedule contains the value 0, which is also
a hyperlink.
1.
Click on the number 0 (note that it is a hyperlink) in the ‘‘Jobs in schedule’’ column for the
Weekdays–Noon schedule (see Figure 8-26).
2.
In the ‘‘Jobs Referencing a Schedule’’ dialog box, click the checkbox in the Selected column
for the Simple Backup schedule (see Figure 8-27).
3.
4.
Click OK. Note that the number of jobs in this schedule has incremented.
Click OK to close the Manage Schedules window.
If you want to add the schedule to the job through the Job Properties dialog box, follow these instructions:
1.
2.
3.
4.
336
In Object Explorer, expand the Jobs folder.
Right-click on the Poor Performers Report job, and select Properties.
Under the ‘‘Select a page’’ section, click Schedules.
Under the Schedule list, click Pick (see Figure 8-28).
12:01pm
Page 336
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Figure 8-26: Manage Schedules window.
Figure 8-27: Jobs Referencing a Schedule.
337
Page 337
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Figure 8-28: Picking an existing schedule.
5.
A list of available schedules will appear. Select the ‘‘Weekdays–Noon’’ schedule, and
click OK.
6.
Click OK to close the Job Properties window.
Note that you can also create a new schedule from this window, as well. One of the benefits of SQL Server
2008, and especially of SQL Server Management Studio, is that you usually have more than one option
for performing a task. Use whichever tool or method best suits your administrative needs.
sp_add_schedule
You can also create new schedules with the sp_add_schedule stored procedure. When you create the
new schedule, you can specify the parameters shown in the following table:
338
Option
Description
@schedule_name
Friendly name of the schedule
@enabled
The default value of 1 means that the schedule is enabled. A
value of 0 will disable the schedule.
12:01pm
Page 338
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Option
Description
@freq_type
Integer value indicating the frequency type of the schedule, using
the following values:
1 — Once
4 — Daily
8 — Weekly
16 — Monthly
32 — Monthly relative to freq_interval
64 — Run when the SQL Server Agent starts.
128 — Run when CPU is idle.
@freq_interval
The days the job is executed. See the next table for options. This
option is not used with all freq_type values.
@freq_subday_type
Identifies the units for freq_subday_interval, with the following
values:
1 — At the specified time
2 — Seconds
4 — Minutes
8 — Hours
@freq_subday_interval
The number of freq_subday_type periods between executions
@freq_relative_interval
This value is the occurrence of freq_interval in each month if the
value of freq_interval is 32. Can use the following values:
1 — First
2 — Second
4 — Third
8 — Fourth
16 — Last
@freq_recurrence_factor
Number of weeks or months between executions. Used only if
freq_type is 8, 16, or 32. The default is 0.
@active_start_date
Date the job can start. This uses the YYYYMMDD format, and the
date must be greater than 19900101. The default is NULL.
@active_end_date
Last date the job will run on this schedule. This also uses the
YYYYMMDD format, but has a default of 99991231.
Continued
339
Page 339
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Option
Description
@active_start_time
Time of day on any day between the active_start_date and
active_end_date to start a job. The default is 000000 using a
24-hour HHMMSS format.
@active_end_time
Time of day on any day between the active_start_date and
active_end_date to end a job. The default is 235959 using a
24-hour HHMMSS format.
@owner_login_name
The name of the login that owns the schedule. By default, the
creator of the schedule becomes the owner.
@schedule_uid uid OUTPUT
A uniqueidentifier for the schedule
@schedule_id id OUTPUT
The ID for the schedule using an int data type
The following table shows the values of freq_type and options for freq_interval:
Value of freq_type
Options for freq_interval
1
No recurrence
4
Every freq_interval days
8
Use one or more of the following values. Add the values together
to allow multiple days to be selected. For example, to specify the
schedule for Tuesday, Wednesday, and Thursday add the values
4 + 8 + 16 for a total value of 24.
1 — Sunday
2 — Monday
4 — Tuesday
8 — Wednesday
16 — Thursday
32 — Friday
64 — Saturday
16
On the freq_interval day of the month
32
Uses one of the following values for monthly relative:
1 — Sunday
2 — Monday
3 — Tuesday
340
12:01pm
Page 340
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Value of freq_type
Options for freq_interval
4 — Wednesday
5 — Thursday
6 — Friday
7 — Saturday
8 — Day
9 — Weekday
10 — Weekend day
You’ve probably been able to figure out why SQL Server Management Studio is the preferred method
for managing jobs and schedules. But look at an example for creating a new schedule. In this example,
you’re going to create a new schedule that will run the associated job(s) every 8 hours on the weekend.
Some comments have been added to help make sense out of some of the values.
DECLARE @schguid UNIQUEIDENTIFIER
DECLARE @schid INT
EXECUTE msdb.dbo.sp_add_schedule
@schedule_name = ‘Weekend Schedule’,
@freq_type = 8, -- Weekly
@freq_interval = 65, -- Combination of Saturday(64) and Sunday(1)
@freq_subday_type = 8, -- Hours
@freq_subday_interval = 8, -- specifies that the job runs every 8 hours
@freq_recurrence_factor = 1,
@active_end_date = 20101031,
@active_end_time = 235959,
@schedule_uid = @schguid OUTPUT,
@schedule_id = @schid OUTPUT
SELECT @schguid as GUID,@schid as ID
sp_attach_schedule
Creating the schedule will not associate the schedule with any of the jobs you have created, so either you
can go back and use SQL Server Management Studio or you can use the sp_attach_schedule stored
procedure. When you created the schedule from the previous example, it should have returned both the
GUID and the ID of the schedule.
When creating the mapping between a schedule and a job, you can use either the ID or the name
of either element. Note that the schedule_id is an int value for the local ID, and not the
uniqueidentifier GUID.
EXECUTE msdb.dbo.sp_attach_schedule
@schedule_name = ‘Weekend Schedule’,
@job_name = ‘Simple Backup’;
341
Page 341
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Creating Operators
Operators are objects that represent a unit of notification for SQL Server Agent jobs and alerts. They
can represent an individual person, or a group. Operators are not associated with database or server
principals, but are exclusive to the SQL Server Agent Service. Earlier in this chapter, you learned how
to configure the SQL Server Agent Service to use either Database Mail or SQL Mail for the alert system.
Whichever one you configured, the SQL Server Agent Service will use that to notify the appropriate
operators.
When you create a new operator, you assign a name to the operator and then define the methods for notifying the operator. Your options for notifying an operator include e-mail, NET SEND using the Windows
Messenger service, and SMTP-enabled pager.
In this example, you create a new operator for the administrator account. This operator will be available
for paging only on the weekend.
1.
2.
3.
From Object Explorer, expand your server, and then expand SQL Server Agent.
Right-click on the Operators folder, and select ‘‘New Operator.’’
In the New Operator window (see Figure 8-29), enter Server Administrator in the Name
field.
Figure 8-29: Creating a new operator.
342
12:01pm
Page 342
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
4.
5.
6.
7.
8.
Ensure that the Enabled box is checked.
In the ‘‘E-mail name’’ field, enter [email protected]
Leave the ‘‘Net send address’’ field empty.
In the ‘‘Pager e-mail name’’ field, enter [email protected]
In the ‘‘Pager on duty schedule,’’ set the following values:
a.
b.
c.
9.
‘‘Friday’’: 5:00:00 PM and 11:59:59 PM
‘‘Saturday’’: 12:00:00 AM and 11:59:59 PM
‘‘Sunday’’: 12:00:00 AM and 11:59:59 PM
Click OK to close the New Operator properties window.
If you open the properties of the operator you just created, you will notice there are two additional pages.
The Notifications page displays a list of jobs and alerts that have sent notifications to this operator. The
History page reports the time of the last notification attempt for each notification type.
sp_add_operator
Use the sp_add_operator to create a new operator. You can use the values shown in the following
table:
Parameter
Description
@name
Name of the operator
@enabled
The default value is 1. A value of 0 will disable the operator.
@email_address
The e-mail address used to notify the operator
@pager_address
The SMTP address of the pager
@weekday_pager_start_time
This value marks the time during the week when the SQL
Server Agent will page the operator if necessary. Time is in
the 24-hour HHMMSS format.
@weekday_pager_end_time
This value marks the time during the week when the SQL
Server Agent will no longer page the operator. Time is in
the 24-hour HHMMSS format.
@saturday_pager_start_time
This value marks the time on Saturday when the SQL
Server Agent will page the operator if necessary. Time is in
the 24-hour HHMMSS format.
@saturday_pager_end_time
This value marks the time on Saturday when the SQL
Server Agent will no longer page the operator. Time is in
the 24-hour HHMMSS format.
Continued
343
Page 343
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Parameter
Description
@sunday_pager_start_time
This value marks the time on Sunday when the SQL Server
Agent will page the operator if necessary. Time is in the
24-hour HHMMSS format.
@sunday_pager_end_time
This value marks the time on Sunday when the SQL Server
Agent will no longer page the operator. Time is in the
24-hour HHMMSS format.
@pager_days
Allows you to indicate the days the operator will be available for paging. To enable multiple days, simply add the following values:
1 — Sunday
2 — Monday
4 — Tuesday
8 — Wednesday
16 — Thursday
32 — Friday
64 — Saturday
@netsend_address
The network address of the operator the SQL Server Agent
will send a message to
@category_name
The name of the category for this operator
In this example, you create a new operator that represents the Sales Managers group and enable paging
for the group between 8:00 a.m. and 5:30 p.m.:
EXECUTE msdb.dbo.sp_add_operator
@name = ‘Sales Managers’,
@email_address = ‘[email protected]’,
@pager_address = ‘[email protected]’,
@weekday_pager_start_time = 080000,
@weekday_pager_end_time = 173000,
@pager_days = 62;
To add the operator to an existing job, you can use the sp_update_job stored procedure. You can use
this to specify that the operator should be notified using any of the defined methods for that operator.
The following example notifies the Sales Managers by e-mail when the Poor Performers Report succeeds,
and pages them if the job fails:
EXECUTE msdb.dbo.sp_update_job
@job_name = ‘Poor Performers Report’,
@notify_email_operator_name = ‘Sales Managers’,
@notify_page_operator_name = ‘Sales Managers’,
@notify_level_email = 1, -- on success
@notify_level_page = 2; -- on failure
344
12:01pm
Page 344
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
You can also edit the properties of an existing job to notify an operator when a job fails or succeeds, or
both by using the ‘‘When the job completes’’ option. Also on this page, you can configure the job to write
an event to the application log and have the job automatically deleted if one of the completion conditions
is met.
The Fail-Safe Operator
After you have created at least one operator, you can designate an operator as the fail-safe operator. The
fail-safe operator is an operator whose contact information is cached in memory while the SQL Server is
running. This ensures that the operator can still be contacted in case the msdb database becomes unavailable. The fail-safe operator can also be notified if the primary operators for a job or alert cannot be
notified. It is defined in the SQL Server Agent properties window. In the Alert System page, there is
a dropdown list allowing you to select an existing operator as the fail-safe operator, and you can use the
checkboxes to determine the methods of notification for this operator.
Creating Alerts
‘‘Danger, Will Robinson, Danger!’’ The term alerts tends to carry such negative connotation. You may
think of loud klaxons going off, the emergency lights turning on, and people shoring up the doors to
keep the zombies out. You know, stuff like that. But alerts in SQL Server 2008 don’t necessarily mean the
end of the world. Alerts can be simply informational, such as letting a manager know that someone on
the sales staff is deleting rows from the Customers table.
Creating alerts consists of three steps:
1.
Name the alert. You should use a name that will be descriptive, which may also include
information about the severity of the event that triggered the alert.
2.
3.
Define the event or performance condition that will trigger the alert.
Identify what this alert will actually do. Will it notify an operator, or will it run a job?
Alerts typically fall into one of three categories:
❑
Event-Based Alerts — These are generated on database- or system-level events. These can be
system-defined, or you can write your own events.
❑
Alerts on Performance Conditions — These use SQL Server Performance counters to indicate
that a threshold value has been met.
❑
WMI Events — You can also create alerts based on WMI events.
SQL Server Event-Based Alerts
SQL Server event-based alerts can be used to execute a task or notify an operator based on a pre-defined
SQL Server event. These events exist as both system-created, usually referring to system-wide activity, or
they can be user-created, allowing you to define conditions within a specific database. Before you create
an alert, you should learn how to create an event.
SQL Server events are defined as an instance of an action being performed or a condition being met.
Although that may sound like a very broad definition, events themselves can be very broad in scope.
SQL Server 2008 has several events already defined for you. In fact, the number of events defined is
345
Page 345
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
almost 8,900 just for the English language! These events can be generated when a query contains too
many referenced tables, or when an index is corrupted. There is also a mechanism for you to create your
own events that may be system-wide or database-specific, as needed.
Each event is defined with a unique numerical ID, a severity level, the text of the message, and a language
ID number. Severity levels are values between 0 and 25 and are used to categorize the event.
Error messages configured with a severity level of 9 or less will not actually raise a system-level exception. This comes in handy when you want to create an alert on a SQL Server event, but you don’t want
to throw an exception to the calling application. The following table lists the different severity levels and
what they represent:
346
Severity Level(s)
Description
0–9
Messages with a severity level between 0 and 9 indicate informational
messages that do not raise a system error. SQL Server will treat a
severity level of 10 as a 0.
11
The object or entity does not exist.
12
Indicates that the query does not use locking because of special query
hints. Read operations may result in inconsistent data.
13
Deadlock errors
14
Security errors
15
Syntax errors
16
General errors
17
The SQL Server has run out of resources or has reached an
administrator-defined limit.
18
There is a problem in the database engine, but the statement has been
executed, and the connection has been maintained.
19
A non-configurable limit has been reached, and the current batch has
stopped. Events with a severity level of 19 or higher are automatically
logged.
20
A problem has occurred in the current statement.
21
A problem that affects the entire database has occurred, but the
database may not have been damaged.
22
A table or index has been damaged by a hardware or software problem.
23
The database has been damaged by a hardware or software problem.
24
General media failure
25
User-defined
12:01pm
Page 346
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Querying the sysmessages catalog view returns a list of all events defined on the server. To create your
own messages that can be used by events, you can use the sp_addmessage stored procedure. When using
sp_addmessage, you can use the values shown in the following table. All values default to NULL unless
otherwise stated. The only required values are @msgnum, @severity, and @msgtext.
Option
Description
@msgnum
This is the ID number of the message. You must use a value greater than
50,000 for all user-defined messages.
@severity
Use an appropriate severity level for this event.
@msgtext
This is an nvarchar(255) field that contains the message text. You can use
parameter placeholders such as %d for decimal values and %s for string
values. When the event is raised, these placeholders are replaced with the
actual values.
@lang
The language for the message. Each message can be stored for multiple
languages, allowing you to localize the message.
@with_log
Use TRUE to have the event logged in the Windows Application log. FALSE
is the default.
@replace
Use the value replace if you are overwriting an existing message.
Take a look at an example of the sp_addmessage stored procedure. In this exercise, you create a
simple error message that contains notification information whenever a user adds a row to the
Sales.CreditCard table. In the next step, you’ll create a stored procedure that will insert a row into the
Sales.CreditCard table, and then you’ll execute that stored procedure.
-- Create the message
EXECUTE sp_addmessage
@msgnum = 60001,
@severity = 10,
@msgtext = ‘Credit Card ID #%d has been added by %s as %s’,
@with_log = ‘True’;
GO
-- Create a stored procedure for inserting credit card data that will raise
-- the error
USE AdventureWorks2008;
GO
CREATE PROCEDURE AddNewCreditCard
@CardType nvarchar(50),
@CardNumber nvarchar(25),
@ExpMonth tinyint,
@ExpYear smallint
AS
DECLARE @username varchar(60)
DECLARE @loginame varchar(60)
DECLARE @CreditCardInfo Table(CreditCardID INT)
DECLARE @CreditCardID INT
347
Page 347
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
SET @loginame = suser_sname()
SET @username = user_name()
BEGIN TRANSACTION
INSERT Sales.CreditCard(CardType,CardNumber,ExpMonth,ExpYear)
OUTPUT INSERTED.CreditCardID
INTO @CreditCardInfo
VALUES (@CardType,@CardNumber,@ExpMonth,@ExpYear);
SET @CreditCardID = (Select CreditCardID FROM @CreditCardInfo)
RAISERROR (60001, 10, 1, @CreditCardID, @loginame, @username)
COMMIT TRANSACTION;
GO
-- Run the stored procedure and return the message
EXECUTE AddNewCreditCard
@CardType=’Veesa’,
@CardNumber=’111187620190227’,
@ExpMonth=’2’,
@ExpYear=’2011’
This should result in the following output:
(1 row(s) affected)
Credit Card ID #19238 has been added by AUGHTEIGHT\Administrator as dbo
Now that you have an event, you should create an alert on that event. In this next exercise, you create an
alert that will use the error message created in the previous example and have a notification sent to the
Sales Managers operator:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
348
In Object Explorer, expand SQL Server Agent.
Right-click Alerts and select ‘‘New Alert.’’
For the name, enter NewCCAlert (see Figure 8-30).
Ensure that ‘‘Type’’ is ‘‘SQL Server event alert.’’
Select AdventureWorks2008 as the database.
Under ‘‘Alerts will be raised based on,’’ select ‘‘Error number.’’
Type 60001 for the error number.
Switch to the Response page.
Select ‘‘Notify Operators.’’
Select ‘‘E-mail for Sales Managers.’’
Switch to the Options page.
Select ‘‘E-mail’’ under ‘‘Include error alert text in.’’
Click OK.
12:01pm
Page 348
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Figure 8-30: Creating a new alert.
The following example shows you how to use the sp_add_alert stored procedure to create a new alert,
and the sp_add_notification stored procedure to associate the alert with operators that will be notified.
Because you cannot have two alerts defined for the same event in the same database, you will need to
delete the ‘‘NewCCAlert’’ you created in the previous step first.
EXECUTE msdb.dbo.sp_delete_alert
@name = ‘NewCCAlert’;
EXECUTE msdb.dbo.sp_add_alert
@name = ‘New Credit Card Alert’,
@message_id = 60001,
@include_event_description_in = 1,
@database_name = ‘AdventureWorks2008’;
EXECUTE msdb.dbo.sp_add_notification
@alert_name = ‘New Credit Card Alert’,
@operator_name = ‘Sales Managers’,
@notification_method = 1;
349
Page 349
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
The sp_add_alert stored procedure includes a number of options for creating and adding alerts. The
following table identifies all the parameters available, but be aware that, depending on the type of alert
you are creating, not all options will be used, and, in fact, some cannot be used together.
Option
Description
@name
The name of the alert
@message_id
The error number of the alert. Only messages written to the application log can cause an alert to be
sent.
@severity
The severity level for messages that will generate
the alert. If you specify this option, all messages
with this severity level will issue this alert.
@enabled
The default value of 1 enables the alert.
@delay_between_responses
The wait period between alert responses in seconds. Raising this value decreases the likelihood of
multiple alerts being generated within a short time.
@notification_message
Optional additional message
@include_event_description_in
The notification type, if any, the message text
will be included in. The values here are also used
with the sp_add_notification stored procedure.
Adding the values indicates multiple notification
types:
0 — None
1 — E-mail
2 — Pager
4 — Net Send
350
@database_name
Identifies the database for which this alert is active.
If you do not specify a database name, the alert will
be active for all databases.
@event_description_keyword
This option uses a pattern match to generate
the alert only if certain keywords or phrases are
present in the error message.
@job_id
ID number of a job that will run as a response to the
alert
@job_name
Name of a job that will run as a response to the
alert. Use either job_id or job_name, not both.
@raise_snmp_trap
The default is 1. Changing the value to 0 will not
raise an SNMP trap message.
12:01pm
Page 350
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Option
Description
@performance_condition
Allows you to define a performance condition alert in
the format of ItemComparatorValue:
Item — Performance object or counter
Comparator — Using greater than (>), less than,
(<), or equal to (=)
Value — Numeric value for the counter
@category_name
Name of the alert category
@wmi_namespace
Namespace used for WMI queries when using WMI
Event alerts
@wmi_query
A WQL query for WMI providers that report on health
or state information
Performance Condition Alerts
Performance condition alerts use SQL Server performance objects and counters to allow alerts to be
defined on server or database activity. For example, you can use this to trigger an alert when the number
of transactions per second for the AdventureWorks2008 database rises above a specific value. In this
example, you create an alert that will notify you when the transaction log of AdventureWorks2008 is
above 85 percent full:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
In Object Explorer, expand SQL Server Agent.
Right-click Alerts and select ‘‘New Alert.’’
For the name, enter AWXtactLogSpace (see Figure 8-31).
Select ‘‘SQL Server performance condition alert’’ as the Type.
From the Object dropdown list, select SQLServer:Databases.
From the Counter dropdown list, select ‘‘Percent Log Used.’’
From the Instance dropdown list, select AdventureWorks2008.
From the ‘‘Alert if counter’’ dropdown list, select ‘‘rises above.’’
Enter 85 for the value.
Switch to the Response page.
Select ‘‘Notify Operators.’’
Select ‘‘E-mail and Pager for the Server Administrator.’’
Click OK.
You’ve now created a new performance alert that will notify an administrator whenever the transaction
log for AdventureWorks2008 grows above 85 percent. Alternatively, you could create a job that would
351
Page 351
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
back up and truncate the transaction log. For more information about performance objects and counters,
see Chapter 10.
Figure 8-31: Creating a performance condition alert.
WMI Event Alerts
SQL Server 2008 can use WMI to collect events for alerting operators. SQL Server uses the WMI Provider
for Server Events to make the SQL Server an object manageable by WMI. Any event that can generate
Event Notification can be managed by WMI. SQL Server alerts use WMI Query Language (WQL) to
retrieve an event type for a specific database or database object. WQL is similar to SQL, but with extensions specific to WMI. When an alert is created for a WMI Event, the WMI Provider for Server Events
translates a WMI query into an Event Notification. The WMI provider will dynamically create a service and queue in the msdb database. The provider reads the data from the queue and returns it to the
application in a managed object format.
To be able to successfully create a WMI Event alert, you must ensure that the WMI Performance Adapter
service is running. The service is set to be started manually, but if you plan to make WMI Event alerts
part of your administrative solution, you may want to configure the service to start automatically. Also,
ensure that Service Broker service is enabled in the msdb database, as well as any databases that you will
be managing through WMI.
352
12:01pm
Page 352
Leiter
c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
WMI is a very powerful and complex tool, and with it, there are several different Data Definition Language (DDL) and trace events that you can watch for with WMI alerts. I recommend reading the topic
entitled ‘‘WMI Provider for Server Events Classes and Properties’’ in Books Online for a list of available events.
Creating Proxies
SQL Server Agent properties allow you to execute specific job steps with a different security account.
This allows you greater flexibility over your application and maintenance designs. It also allows you to
create job steps that can be executed by users whose security context would normally prohibit them from
running a task. The benefit of this is that the user who creates the job need only have access to the proxy
account. The user does not need to create credentials or users or be given elevated permissions to execute
a job step. You can create proxies for the following types of job steps:
❑
ActiveX Script
❑
Operating System (CmdExec)
❑
Replication Distributor
❑
Replication Merge
❑
Replication Queue Reader
❑
Replication Snapshot
❑
Replication Transaction-Log Reader
❑
Analysis Services Command
❑
Analysis Services Query
❑
SSIS Package Execution
❑
PowerShell
There is also a folder for creating and managing unassigned proxies. Note that a single proxy can be used
for multiple task types, if needed.
Try It Out
Creating a New Proxy
Take a look at the process for creating a new proxy. First of all, proxies use credentials to execute. In
Chapter 6, you learned how to create a new credential, but in case you’ve deleted it or you’re not reading this book from cover to cover, you can create a new credential now. Begin by first creating a new
Windows user:
1.
Navigate to the Local Users and Groups folder on your system. This may vary depending on
which Operating System you are using.
2.
3.
4.
5.
Expand Local Users and Groups, and select the Users folder.
Right-click on the Users folder and select ‘‘New User.’’
In the User name box, enter ScriptRunner.
Enter [email protected] as the password, and remove the check next to ‘‘User must change password at
next logon.’’
353
Page 353
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
6.
7.
8.
Click Create.
Click Close.
Close Server Manager (or Computer Manager, depending on your OS).
So, now that you have a new user, create a credential for this user:
1.
2.
3.
Go back to SQL Server Management Studio.
In Object Explorer, expand your server, and expand Security.
Right-click Credentials and select ‘‘New Credential’’ (see Figure 8-32).
Figure 8-32: Creating a new credential.
4.
5.
6.
7.
354
For the name, enter ActiveXProxy.
In the identity box, enter AughtEight\ScriptRunner (or use your server and domain name in
place of AughtEight).
Enter [email protected] for the Password and ‘‘Confirm password’’ fields.
Click OK.
12:01pm
Page 354
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
You now have a new Windows user with an associated credential on your server. Now you can use that
credential to create one or more proxies:
1.
2.
3.
4.
In Object Explorer, expand SQL Server Agent.
Expand Proxies and select ‘‘ActiveX Script.’’
Right-click ‘‘ActiveX Script’’ and select ‘‘New Proxy.’’
Enter ScriptRunner as the ‘‘Proxy name’’ (see Figure 8-33).
Figure 8-33: Creating a proxy account.
5.
6.
7.
Enter ActiveXProxy as the ‘‘Credential name.’’
8.
Click OK.
Ensure that ‘‘ActiveX Script’’ is selected under ‘‘Active to the following subsystems.’’
Alternatively, add additional subsystems or use the Principals page to identify SQL Server logins,
server roles, or msdb database roles that can reference this proxy in job creation.
355
Page 355
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Now that you’ve created a new proxy, let’s see how it can be used in a job step. In this next example, you
add a new step to your Poor Performers Report job that will contain an ActiveX script. It’ll be a fairly
useless script, but ‘‘Hello World’’ always makes for great proof of concept!
EXECUTE msdb.dbo.sp_add_jobstep
@job_name = ‘Poor Performers Report’,
@step_id = 2,
@step_name = ‘Hello World’,
@subsystem = ‘ACTIVESCRIPTING’,
@database_name = ‘VBScript’,
@command = ‘Sub main()
Print ("Hello World.")
End Sub’,
@on_success_action = 3,
@proxy_name = ‘ScriptRunner’;
Now that this has been added, you can execute the job and review the job history to see the successful
execution of the script as the ScriptRunner.
Multi-Server Jobs
SQL Server also supports the ability to create and manage jobs on one server that can be run on multiple
SQL Servers. This functionality grants you the ability to administer and control multiple servers at once.
This can be beneficial when performing system-level tasks, such as backing up the system databases, or
controlling database-level tasks like replication.
Multi-server jobs are configured by first defining a master server. This master server acts as the source
for all jobs that will be run on multiple target servers (see Figure 8-34). When defining a multi-server
configuration, be aware that although you can enlist multiple target servers on which remote jobs will
run, not every multi-server-enabled job will run on all target servers. In fact, you can specify which
target servers a multi-server job will run. The downside to this is that each target server can only have
one master server. Plan your multi-server job configuration carefully.
There are a few things you need to know about setting up multi-server jobs:
❑
Jobs running on multiple servers that have steps running under a proxy account use the proxy
account on the target server. Ensure that you have a proxy server on both the master and target
servers that has the same access and permissions.
❑
Each target server can have only one server for all jobs.
❑
If you are going to change the name of a target server, you must remove it from the master
server, through a process known as defecting, and then re-enlist it after the name change.
❑
When removing a multi-server configuration, first defect all target servers before decommissioning the master.
To create multi-server jobs, you must first define the master servers and the target server. You can begin
by running the Master Server Wizard in SQL Server Management Studio:
1.
356
In Object Explorer, right-click ‘‘SQL Server Agent,’’ and select ‘‘Multi Server Administration,’’ then ‘‘Make this a Master.’’ The Wizard begins with an introductory page that informs
you of the steps that will be taken in this Wizard.
12:01pm
Page 356
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
Master Server
MSJob 1
MSJob 2
Jo
b
fig
Co
n
Co
nf
ig
b
Jo
Job Config
Jo
b
us
at
St
St
at
us
b
Jo
Job Status
Target 3
MSJob 1
Target 1
MSJob 1
MSJob 2
Target 2
MSJob 2
Figure 8-34: Multi-server configuration.
2.
The next step creates an MSXOperator account. This operator is used to send information
about multi-server jobs. You can provide an e-mail address, pager address, and NET SEND
address for message delivery.
3.
Then, you will specify at least one server that will be identified as a target server. SQL Server
2008 includes a compatibility check to ensure that the target server will work with the master
server.
4.
The final step identifies the credentials that will be used to establish authentication and
authorization between the two servers. As a best practice, you should use Windows Active
Directory domain accounts for the SQL Server Agent service on your master server and
all target servers, so that the accounts use the benefit of Active Directory security without
having to create duplicate accounts on the servers. If the login for MSXOperator does not
exist on the target server, the Wizard will ask you if you want to create it.
Once this has completed, the Wizard will perform the following tasks:
❑
Create the MSXOperator.
❑
Ensure that the SQL Server Agent Service is running on the master server.
❑
Ensure that the SQL Server Agent Service account on the target server has rights to log in as a
target server.
❑
Enlist the target server into the master server.
Once the Wizard has completed successfully and the server is configured as a master server, you can
create new jobs that will run on the local server, remote servers, or both. You will also be able to go back
357
Page 357
Leiter c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
into an existing job, and specify that job will run as a multi-server job. You can then select on which
servers the job will run. This is managed in the Targets property sheet.
Maintenance Plans
SQL Server Management Studio includes a very robust platform for creating and managing maintenance
plans. Plans can be created with a wizard or manually with the Maintenance Plan Designer. Maintenance plans are actually created as Integration Services packages. To create and use Maintenance Plans,
Integration Services must be installed.
Maintenance Plan Wizard
Microsoft SQL Server 2008 includes a wizard for checking database integrity, as well as running tasks that
help reorganize the data and re-index the data. As you step through the Wizard, you are asked to choose
which tasks to perform, and then you will provide the configuration options for each task, including
which databases to perform the tasks on. The available tasks include the following:
❑
Checking database integrity
❑
Shrink the database
❑
Reorganize indexes
❑
Rebuild indexes
❑
Update statistics
❑
Clean up history
❑
Executing a SQL Server Agent job
❑
Backing up databases using full, differential, or transaction log backups
Once you’ve specified which options to include and configured them in your maintenance plan, you can
schedule the job to run on a recurring basis. This creates a job that will execute an Integration Service
package, which contains each of the steps defined in the maintenance plan. You can execute the maintenance plan from the Maintenance Plan folder under the Management node in Object Explorer, or simply
execute the job that was created. You can also modify the maintenance plan at any time, and add or
remove tasks as needed.
Maintenance Plan Designer
Although the Wizard is an easy way to create a new maintenance plan, it lacks the flexibility that creating
a plan with the Designer provides. To create a new maintenance plan, right-click on the Maintenance
Plans folder in SQL Server Management Studio, and click ‘‘New Maintenance Plan.’’
In the resulting New Maintenance Plan dialog, enter a name in the Name field and click OK. This will
launch the Maintenance Plan Designer, which is based on Integration Services (see Figure 8-35).
358
12:01pm
Page 358
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
To create a maintenance plan, drag the desired tasks from the Toolbox onto the design surface. Once the
task is on the surface, you can either double-click on the task or right-click on the task and then select Edit
from the context menu to configure the task’s properties. Additional tasks can be added to the Designer
and joined by precedence constraints. Each task added is configured with a Success constraint by default.
However, right-clicking on the constraint (see Figure 8-36) displays a context menu where the constraint
can be configured for Success, Failure, or Completion.
Figure 8-35: Maintenance Plan Designer.
Figure 8-36 shows a Rebuild Index Task configured to rebuild the indexes on the Person.Person
table. This task will execute a Notify Operator task called ‘‘Notify Failure’’ in the event that it fails
and a Backup Database task if it succeeds. The Backup Database task that performs a Full backup of
AdventureWorks2008 will also execute the Notify Operator task if it fails, but it executes the Maintenance
Cleanup Task if it succeeds. The Maintenance Cleanup Task is configured to delete any backup files
more than 4 weeks old, and then to notify an operator that the plan has succeeded if it succeeds, or
notify of failure if it fails.
359
Page 359
Leiter
c08.tex
V3 - 03/25/2009
Chapter 8: Automating Administrative Tasks
Figure 8-36: Maintenance Plan precedent constraints and tasks.
Maintenance plans are configured to run on-demand by default, but they can be configured with a recurring schedule by clicking the ellipses to the right of the Schedule field and setting the properties of the
schedule in the resulting schedule screen.
Best Practices
Here are some guidelines that can help you automate administration of your servers:
360
❑
Use Database Mail instead of SQLMail — SQLMail is included for backward compatibility
only, and its dependence on an extended MAPI client and server configuration can make it more
cumbersome than it’s worth.
❑
Configure Database Mail to Use Multiple Accounts and Multiple SMTP Servers for Each Profile — This will help increase the ability to deliver messages to the appropriate operators and
personnel.
❑
Configure the SET TRUSTWORTHY ON and ENABLE_BROKER Options for the msdb Database — This
will help ensure that your Event Notification messages and alerts can be delivered to the appropriate personnel.
❑
Configure the SQL Server Agent to Start Automatically When Windows Starts, and Configure
Automatic Restart if the Service Fails — This helps ensure that scheduled jobs are able to run in
case the system is accidentally shut down or restarted.
❑
Configure the SQL Server Agent to Use a Domain User Account — This allows you to use several features, including the ability to run and control multi-server jobs using a single account, as
well as having better auditing capabilities of how that account is used.
❑
Configure Proxy Accounts with Only the Level of Access Needed to Perform the Tasks They
Were Designed for and Nothing Else — Use the principle of least privilege in all layers of your
administrative model.
12:01pm
Page 360
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Chapter 8: Automating Administrative Tasks
❑
Designate Groups Rather than Individuals as Operators — You can specify the e-mail address
of a group or distribution list rather than an individual user. This gives you the flexibility of
modifying the group membership and, thereby, changing the target delivery without having
to change the job, operator, or notification method.
❑
Use Maintenance Plans to Define a Comprehensive Set of Steps That Will Check the Integrity
of Your Database and Help Resolve Performance Issues — Schedule the maintenance plan to
run regularly, but at a time when it least impacts your users.
Summar y
In this chapter, you learned about the different tools that can be used to help automate the management
of SQL Server 2008. Beginning with an introduction to the new Policy-Based Management tools, you
also learned about Central Management Servers. Database Mail is one of the more essential features to
help you administer your server, in that you can use it for notification of both critical and non-critical
server events. Its flexibility in its ability to use any standard SMTP server allows you to provide a robust
solution without incurring some of the costs of a large-scale enterprise mail solution. You were also
introduced to the topic of Event Notifications, which can provide you with an alternative method of
receiving notifications of system or database events.
Finally, you got an exhaustive look at the elements of the SQL Server Agent, including administrative
tools for managing jobs, schedules, operators, alerts, and proxy accounts. In the next few chapters, you are
going to learn about different tools and resources to manage the SQL Server environment. This chapter
should serve as a building block for the materials from the next chapters, in that you should be able to
take the concepts you’ve learned here and apply them to backing up your databases, covered in Chapter
9, and performance monitoring and optimization, which are covered in Chapters 10 and 11.
361
Page 361
Leiter c08.tex
V3 - 03/25/2009
12:01pm
Page 362
Leiter c09.tex
V3 - 03/25/2009
12:13pm
9
Disaster Prevention and
Recover y
‘‘There are two things that every database administrator can’t live without. The first is an effective
backup and restore plan. The second is an up-to-date résumé. If you have the first, you may never
need the second, but if you don’t have the first, sooner or later the résumé will be critical to your
future employment.’’ I give that speech to every group of database administrators that I address,
and I address a lot of them. It is a fact that disks fail and data gets corrupted. We have all probably
suffered from some form of data loss that could have been prevented if the data had been properly
backed up. As the individual responsible for the stability and integrity of the organization’s data,
the database administrator must be diligent and meticulous about planning a database backup
strategy so that in the event of equipment failure, user error, or intentional data corruption, the
database can be returned to service in as short as time as possible with minimal loss of data.
This chapter is about the mechanics of database backup and recovery, with a little bit of strategy
thrown in for good measure. I will try not to give specific recommendations since no cookie-cutter
recommendation will work for each situation. It is up to you as the database administrator to examine all possible backup and restore operations and come up with a plan that will prevent data loss
and minimize downtime. There are people counting on you, and the very organization that you
work for may succeed or fail because of your efforts. It is a pretty heavy responsibility to bear, but as
more and more line-of-business applications are built on top of SQL Server, it is a very real responsibility. So take a deep breath, and learn all that you can about disaster prevention and recovery to
ensure that you are always the hero and never the person to blame for lost data.
Chapter Preparation
The AdventureWorks2008 database is a fairly large sample database. To reduce the amount of time
and disk space required to practice the examples in this chapter, we’re first going to create a
smaller version of AdventureWorks2008. The following script creates a database called SmallWorks
made up of a Primary filegroup and two additional filegroups with one data file each. It then
creates a table in each filegroup and populates it with data from the AdventureWorks2008 database.
The last action of the script is to set the Read Only attribute on the second user-defined filegroup.
The script assumes the existence of the C:\SQLData path.
Page 363
Leiter
Chapter 9: Disaster Prevention and Recovery
CREATE DATABASE SmallWorks ON PRIMARY
( NAME = ‘SmallWorksPrimary’
, FILENAME = ‘C:\SQLData\SmallWorks.mdf’
, SIZE = 10MB
, FILEGROWTH = 20%
, MAXSIZE = 50MB)
, FILEGROUP SWUserData1
( NAME = ‘SmallWorksData1’
, FILENAME = ‘C:\SQLData\SmallWorksData1.ndf’
, SIZE = 10MB
, FILEGROWTH = 20%
, MAXSIZE = 50MB)
, FILEGROUP SWUserData2
( NAME = ‘SmallWorksData2’
, FILENAME = ‘C:\SQLData\SmallWorksData2.ndf’
, SIZE = 10MB
, FILEGROWTH = 20%
, MAXSIZE = 50MB)
LOG ON
( NAME = ‘SmallWorks_log’
, FILENAME = ‘C:\SQLData\SmallWorks_log.ldf’
, SIZE = 10MB
, FILEGROWTH = 10%
, MAXSIZE = 20MB)
GO
USE SmallWorks
GO
ALTER DATABASE SmallWorks
MODIFY FILEGROUP SWUserData1 DEFAULT
GO
CREATE TABLE dbo.Person(
PersonID int NOT NULL
, FirstName varchar(50) NOT NULL
, MiddleName varchar(50) NULL
, LastName varchar(50) NOT NULL
, EmailAddress nvarchar(50) NULL
) ON SWUserData1
CREATE TABLE dbo.Product(
ProductID int NOT NULL
, ProductName varchar(75) NOT NULL
, ProductNumber nvarchar(25) NOT NULL
, StandardCost money NOT NULL
, ListPrice money NOT NULL
) ON SWUserData2
INSERT dbo.Person
(PersonID, FirstName, MiddleName, LastName, EmailAddress)
SELECT DISTINCT TOP 5000
P.BusinessEntityID
364
c09.tex
V3 - 03/25/2009
12:13pm
Page 364
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
, P.FirstName
, P.MiddleName
, P.LastName
, LOWER(P.FirstName + ‘.’ + P.LastName + ‘@adventureworks.com’)
FROM AdventureWorks2008.Person.Person P
INNER JOIN AdventureWorks2008.Person.EmailAddress E
ON P.BusinessEntityID = P.BusinessEntityID
WHERE P.FirstName NOT LIKE ‘%.%’
ORDER BY P.BusinessEntityID
INSERT dbo.Product
(ProductID, ProductName, ProductNumber, StandardCost, ListPrice)
SELECT ProductID
, Name
, ProductNumber
, StandardCost
, ListPrice
FROM AdventureWorks2008.Production.Product
ALTER DATABASE SmallWorks MODIFY FILEGROUP SWUserData2 READONLY
Database Recover y Models
SQL Server has three possible recovery models; however, only two are meant for regular use — the
Simple and Full recovery models. The third recovery model, Bulk-Logged, is designed to be an adjunct
to the Full recovery model. Each recovery model has its advantages and disadvantages. It is absolutely
critical that you have a complete understanding of each model so that you can make an informed and
appropriate decision as to what recovery model to operate each database in. Recovery models change the
behavior of the transaction log, what backups can be performed, and how data is recovered.
Full Recovery Model
In the Full recovery model, all activity that affects the database is logged in the transaction log in some way
or another. Some events are minimally logged, like the TRUNCATE TABLE command, which completely
clears the contents of a table. When the TRUNCATE TABLE command is executed, SQL Server logs only
the de-allocation of the data pages affected by the truncation. However, all regular database activity is
fully logged, including the rebuilding of indexes, bulk copy, SELECT INTO, BULK INSERT, and BLOB (Binary
Large Object) updates. The advantage of this full logging is that every transaction can be recovered in
the event of a failure. You never have to worry about a lost transaction due to loss of a data file. With the
loss of the actual transaction log, all transactions since the last CHECKPOINT would be lost.
The disadvantage of the Full recovery model is the same as the advantage: Almost everything that
affects the database is fully logged. As a result, the transaction log can fill up very quickly. If it is set
to auto-grow, it can also get very large, very quickly. When the database is set to Full recovery model,
it is imperative that an effective plan for backing up the transaction log on a regular basis be developed
and implemented. Backing up the transaction log clears it of all old transactions and makes room for
new ones.
365
Page 365
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
In the Full recovery model, the transaction log contains a record of all the modifications made to the
database since the last BACKUP LOG event. It can be used to recover those transactions, as described later
in this chapter.
Bulk-Logged Recovery Model
The Bulk-Logged recovery model, as previously noted, is an adjunct model to the Full recovery model. There
are times when the full logging behavior of the Full recovery model can be detrimental to performance
and cause unacceptable log file-growth. In these situations, the database can be configured to minimally
log bulk operations by changing the recovery model to Bulk-Logged. In the Bulk-Logged recovery model,
the following database operations are minimally logged:
❑
Index Creation
❑
Index Rebuild
❑
Bulk Copy operations
❑
BULK INSERT
❑
SELECT INTO
❑
BLOB operations
Minimal logging means that the operations listed are logged as having occurred, but the individual rows
affected are not logged. In addition to the record of the operation being logged, a record of the physical extents allocated or affected by the operation is recorded in the transaction log. During the next
BACKUP LOG event, the affected physical extents are copied to the log backup. Bulk-Logged recovery
keeps the log smaller by minimally logging data-intensive operations, but the log backups can actually
be larger. Because the log backups rely on the physical data being intact during the log backup, if the
disks are damaged or unavailable, the log backup will fail.
In Bulk-Logged recovery, the transaction log contains a record of all the fully logged modifications made
to the database and the identification of changed extents modified by minimally logged operations since
the last BACKUP LOG event. Like the transaction log in the Full recovery model, the transaction log in
Bulk-Logged recovery is available to restore transactions in the event of a database failure.
Simple Recovery Model
In the Simple recovery model, the inactive portion of the log is truncated every time SQL Server issues
a checkpoint. As explained in Chapter 4, Checkpoints are issued periodically by SQL Server to keep
the amount of time necessary to recovery a database to a minimum. The inactive portion of the log is
essentially the portion of the log from the oldest open transaction to the end of the log.
The Simple recovery model has the advantage of decreasing the administrative overhead of transaction
log management. Because the inactive portion of the log is basically cleared after every Checkpoint, the
log, if planned appropriately, should never grow and should never need to be managed. However,
the transaction log cannot be backed up and used for data recovery since it does not have a complete
record of all the transactions that have modified the database.
366
12:13pm
Page 366
Leiter
c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
SQL Ser ver 2008 Database Backup
For years I stated that the best part of native SQL Server backups is the price of the backup software,
which is free. Other than the price, however, native SQL Server backups offered little in the area of
performance and flexibility that most enterprise database administrators needed. As a result of this
shortcoming, several third-party software vendors created excellent backup software that would back up
SQL Server databases up to 10 times faster than the native utility while compressing and encrypting the
backup at the same time. With the release of SQL Server 2008, Microsoft has significantly improved the
native backup system so that it now adds some exciting new features to database backup routines. The
first is that SQL Server 2008 backups are faster than those of previous editions. The speed is made even
more impressive by the fact that SQL Server 2008 also provides the ability to compress the backups and
that compressed backups are even faster than non-compressed backups. On my copy of SQL Server 2008,
a backup of the AdventureWorks2008 database takes 6 seconds when using compression and 9 seconds
without. SQL Server 2008 provides the ability to encrypt backups as well.
SQL Server 2008 backups can be performed during normal database activity. There is no need to disconnect users or shut down any services. Backups can be sent to disk or tape. To send backups to tape, the
tape device must be locally attached to the Database Server. This limitation can be overcome by using
third-party products or mounting the tape device on a SAN that presents the drive as a logical disk
device.
Disk destinations are identified by a physical or Universal Naming Convention (UNC) location as the
following examples illustrate:
--Full database backup of SmallWorks to a drive location
BACKUP DATABASE SmallWorks
TO DISK = ‘D:\SQLBackups\FullSmallWorks.BAK’
WITH DESCRIPTION = ‘SmallWorks DB Full Backup’
--Full database backup of SmallWorks to a UNC location
BACKUP DATABASE SmallWorks
TO DISK = ‘\\AUGHTEIGHT\SQLBackups\FullSmallWorks.BAK’
WITH DESCRIPTION = ‘SmallWorks DB Full Backup’
Backup Devices
Tape or disk locations can be mapped to a backup device. A backup device is an alias to the disk or tape
location. The only real advantage of backup devices is that they make the syntax of the backup command
simpler. However, since the backup devices are usually created once to hold many backups, the device
name will typically be less descriptive than is usually desired.
The following example shows how to create a backup device and then back up the Master database to it:
--Create a device for backups of the Master database
sp_addumpdevice ‘Disk’
, ‘MasterDBBackups’
, ‘D:\SQLBackups\masterDB.Backups.BAK’
--Backup the Master database to the new device
367
Page 367
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
BACKUP DATABASE Master TO MasterDBBackups
WITH DESCRIPTION = ‘Master DB Full Backup’
Backup devices can also be created graphically by expanding the Server Objects node in Object Explorer
of SQL Server Management Studio, right-clicking on ‘‘Backup Devices,’’ and clicking on ‘‘New Backup
Device.’’
Try It Out
SQL Server Database Backups
Regardless of the type of database backup executed, SQL Server performs the following actions:
❑
Logs the BACKUP statement in the transaction log.
❑
Issues a Checkpoint causing all outstanding dirty buffer pages to be written to the disk.
❑
Writes all data pages specified by the FULL, DIFFERENTIAL, FILE, or FILEGROUP backup
options to the backup media.
❑
Writes all data modifications recorded in the transaction log that occurred during the backup to
the backup media.
❑
Logs the completion of the backup in the transaction log.
Back up the Master database by executing the following command in SQL Server Management Studio:
--Full database backup of the Master database
BACKUP DATABASE Master
TO DISK = ‘D:\SQLBackups\FullMaster.BAK’
WITH DESCRIPTION = ‘MASTER DB FULL Backup’
The script performs a Full database backup of the Master database. It assumes that you have a ‘‘D’’
volume and a folder named SQLBackups. The backup command will create designated files, but it will
not create folders.
Databases can also be backed up using the graphical tools provided with Management Studio. To accomplish the same results as the previous script, follow these steps:
368
1.
Expand the Databases and then the System Databases nodes in Object Explorer of Management
Studio.
2.
Right-click on the Master database, then click Tasks Back Up to launch the Back Up Database
dialog (Figure 9-1).
3.
4.
5.
Click on the Remove button to remove the default backup location.
6.
Click OK to start the backup.
Click on the Add button to specify a new destination for the database backup.
In the Select Backup Destination dialog, type in a new destination for the backup such as
D:\SQLBackups\Master.BAK.
12:13pm
Page 368
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Figure 9-1: The Backup Database dialog.
SQL Ser ver 2008 Backup Types
SQL Server 2008 supports several backup types that can be combined or used independently to create
backup strategies. In this section, we’ll explore the different types, and then in the next section, we’ll
examine the backup options and how to combine the backup types into an effective backup strategy.
Most of the backups are performed the same way using the graphical tools, and the interface is very
intuitive. With that in mind, in the following examples, each backup type will only be accompanied by
the appropriate Transact-SQL to use to perform the backup.
Full Backup
Probably the most common and easy way to implement backups is the Full backup. The Full backup
simply backs up all the data in the database and records all database file locations. SQL Server logs the
beginning of a Full database backup in the transaction log and then records all modifications made to the
database for the duration of the backup in the transaction log. When all the data pages from the database
data files have been transferred to the backup media, SQL Server logs the completion of the backup and
369
Page 369
Leiter
c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
transfers the portion of the transaction log that occurred during the backup to the backup media. Full
backups can be used in any recovery model.
The advantage of the Full backup is that it is exceptionally simple. However, Full backups take longer
than other backup methods and typically result in the same unchanged data being backed up over and
over again along with the new and updated data.
--Full database backup of SmallWorks
BACKUP DATABASE SmallWorks
TO DISK = ‘D:\SQLBackups\SmallWorksFull.BAK’
WITH DESCRIPTION = ‘SmallWorks FULL Backup’
Differential Backup
Differential backups are used to back up only the data that has changed since the last Full backup. Like
the Full backup, the Differential backup also consists of the portion of the transaction log that contains
database modifications that occurred during the backup. Because Differential backups only contain the
extents of data files that have changed since the last Full backup, they take less time to execute than
Full backups. However, each consecutive Differential backup will in most cases become progressively
larger. If just 1 byte of a 64-KB extent is modified, the Differential backup will back up the entire extent.
The Differential backup is available regardless of the database recovery model and requires a base Full
database backup.
--Differential database backup of SmallWorks
BACKUP DATABASE SmallWorks
TO DISK = ‘D:\SQLBackups\SmallWorksDiff.BAK’
WITH DIFFERENTIAL, DESCRIPTION = ‘SmallWorks Differential Backup’
File/Filegroup Backup
When a database is divided across many files and filegroups, these files and filegroups can be backed
up individually. This type of backup is particularly useful for very large databases. File and Filegroup
backups work similarly as Full and Differential backups in that the data pages of the file and then all
transactions made against the file or filegroup are added to the backup media.
--Backup of the "SWUserData1" User-Defined Filegroup
BACKUP DATABASE SmallWorks
FILEGROUP = ‘SWUserData1’
TO DISK = ‘D:\SQLBackups\SmallWorksUserData1FG.BAK’
WITH DESCRIPTION = ‘SmallWorks SWUserData1 Filegroup Backup’
--Backup of the SmallWorks data file "SmallWorksData1"
--The logical name of the file **NOT the physical file name**
BACKUP DATABASE SmallWorks
FILE = ‘SmallWorksData1’
TO DISK = ‘D:\SQLBackups\SmallWorksData1File.BAK’
WITH DESCRIPTION = ‘SmallWorks UserData1 File Backup’
File/Filegroup with Differential
An additional option available when backing up files or filegroups is the ability to perform a Differential
File or Filegroup backup. This option works exactly like the typical Differential backup; only the changes to
the file or filegroup since the last full File or Filegroup backup are captured as well as any changes to the
files during the backup.
370
12:13pm
Page 370
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
--Differential Filegroup Backup of the "SWUserData1" User-Defined Filegroup
BACKUP DATABASE SmallWorks
FILEGROUP = ‘SWUserData1’
TO DISK = ‘D:\SQLBackups\SmallWorksUserData1FGDIFF.BAK’
WITH DIFFERENTIAL, DESCRIPTION = ‘SmallWorks Filegroup Differential Backup’
File and Filegroup backups are only available if the database is in Full or Bulk-Logged recovery model,
with one exception. If a filegroup is marked as Read Only and the database is configured in the Simple
recovery model, then that filegroup can be backed up.
Transaction Log Backup
In Full or Bulk-Logged recovery models, it is imperative that periodic Transaction Log backups are
completed to both maintain the size of the transaction log within reasonable limits and to allow for the
recovery of data with the least amount of data loss.
Transaction Log backups come in three forms: Pure Log backups, Bulk Log backups, and Tail Log
backups.
❑
Pure Log Backup — A Pure Log backup contains only transactions and is completed when the
database is in Full recovery model or Bulk-Logged recovery model, but no bulk operations have
been executed.
--Pure or Bulk Log Backup of SmallWorks
BACKUP LOG SmallWorks
TO DISK = ‘D:\SQLBackups\SmallWorksLog.TRN’
WITH DESCRIPTION = ‘SmallWorks Log Backup’
❑
Bulk Log Backup — Bulk Log backups contain both transactional data and any physical extents
modified by bulk operations while the database was in Bulk-Logged recovery.
❑
Tail Log Backup — Tail Log backups are completed when the database is in Full or Bulk-Logged
recovery prior to a database restoration to capture all transaction log records that have not yet
been backed up. It is possible in some instances to execute a Tail Log backup even if the database
is damaged.
--Tail Log Backup of SmallWorks
BACKUP LOG SmallWorks
TO DISK = ‘D:\SQLBackups\SmallWorksTailLog.TRN’
WITH NO_TRUNCATE, DESCRIPTION = ‘SmallWorks Tail Log Backup’
Partial Backup
A Partial database backup consists of the Primary filegroup, Read Write filegroups, and any Read Only
filegroup specified. The idea behind the Partial backup is that the Primary filegroup, which contains all
the information necessary to bring the database online, and all the filegroups subject to modifications can
be backed up together, leaving the filegroups that do not change to be backed up separately and not as
often, saving both time and backup media space.
BACKUP DATABASE SmallWorks READ_WRITE_FILEGROUPS
TO DISK = ‘D:\SQLBackups\SmallWorksPartial.BAK’
WITH DESCRIPTION = ‘Partial Backup of all Read/Write filegroups’
371
Page 371
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Copy Only Backup
Copy Only backups can be performed on database files and transaction logs to create a backup without
affecting the chain of backups required to restore a database. They are essentially non-logged backups
that can be used outside the maintenance environment. For instance, if a copy of the database is needed
for test and development, a Copy Only backup can be performed so as not to break the backup chain.
Backup chains are discussed in the ‘‘Restoring Databases’’ section later in this chapter.
BACKUP DATABASE SmallWorks
TO DISK = ‘D:\SQLData\SmallWorksCopyOnly.BAK’
WITH COPY_ONLY, DESCRIPTION = ‘Copy only backup’
Backup Options
As previously described, backups can be sent to either a disk or tape destination. When sent to these
destinations, the choice can be made to compress the database backup. Another possibility for backup
destinations is to send the backups to multiple destinations at the same time. The multiple destinations
can be configured as a stripe of the backup or a mirror.
Backup Stripe
Striping a backup across multiple devices may save time in the backup process since multiple physical
devices are being written to simultaneously. To create a backup stripe, simply add multiple destinations
to the backup command as shown in the following code:
BACKUP DATABASE SmallWorks
TO DISK=’D:\StripedBackupsA\SmallWorksStripe1.bak’
, DISK=’E:\StripedBackupsB\SmallWorksStripe2.bak’
, DISK=’F:\StripedBackupsC\SmallWorksStripe3.bak’
WITH DESCRIPTION = ‘Striped Backup’
Once a stripe set has been created, each file will only accept backups that also include all the members of
the stripe. The three files are now a set made up of three family members. In order to send a backup to
just one of the members, the FORMAT option must be specified. Although the striped backup can improve
performance of the backup, a loss or corruption of any file in the stripe will result in a total loss of the
backup.
Mirrored Backup
I received a call late one night from a colleague who had taken over my position after I had moved on
to another job. He was desperate. He explained to me that their main database server had suffered a
catastrophic failure. They had rebuilt the server and were in the process of restoring from tape when
the tape drive inexplicably decided to devour the tape and the redundant drive I had set up was out of
commission. I listened intently to his story, but in the end I could only respond with ‘‘If you have another
copy of the tape, simply get a different tape drive and restore from the copy. If you don’t have another
copy, restore from the most recent copy you do have and update your résumé.’’
I tell every SQL Server Administration class I teach this story. I do so to highlight the importance of
having redundant backups. It is too easy to feel safe and secure in the knowledge that you are regularly
372
12:13pm
Page 372
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
backing up your data. However, your backups are just as vulnerable as the data that they are ostensibly
protecting. I have encountered many organizations who wouldn’t dream of storing their data on anything
but redundant arrays, yet they back up their critical data to a single device and don’t make copies of it.
In the past, creating redundant backups meant backing the database up and then backing up the backups
or using a hardware solution that mirrored the backups while they were being created. SQL Server 2008
provides the built-in ability to mirror database backups.
Mirrored backups are not supported through the visual tools. The following code demonstrates how to
back up a database to one destination and mirror the entire backup to another destination simultaneously. The WITH FORMAT option is required to create a new mirrored backup set.
BACKUP DATABASE SmallWorks
TO DISK=’D:\MirroredBackupsA\SmallWorksMirror1.bak’
MIRROR TO DISK=’E:\MirroredBackupsB\SmallWorksMirror2.bak’
WITH FORMAT, DESCRIPTION = ‘Mirrored Backup’
Compressed Backup
As I mentioned previously, compressed backups actually are faster than non-compressed backups. They
also restore faster. However, this speed does not come without a cost. Compressed backups consume
significantly more CPU resources than non-compressed backups. If your database server is already overworked in the area of CPU usage, you may want to avoid compressed backups or schedule them for
low-CPU-usage time periods. The following code demonstrates how to create a compressed backup:
BACKUP DATABASE SmallWorks
TO DISK=’D:\SQLBackups\SmallWorksCompressed.bak’
WITH COMPRESSION, DESCRIPTION = ‘Compressed Backup’
WITH Options
The following table lists and briefly describes each option that can be included in the WITH clause of a
database backup command:
Option
Description
BLOCKSIZE = integer
Specify a specific block size. If not specified, SQL Server will
attempt to choose a block size that is optimum for the tape or
disk destination.
CHECKSUM | NO_CHECKSUM
The CHECKSUM option specifies that SQL Server will validate
any page checksum or torn page information when reading the
page. SQL Server will also generate page checksums that can
be used to validate backups with the RESTORE command. The
CHECKSUM option will decrease the speed and performance of
the backup. The NO_CHECKSUM setting is the default setting and
configures SQL Server to not generate or validate page
checksum data during the backup.
Continued
373
Page 373
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
374
Option
Description
STOP_ON_ERROR |
CONTINUE_AFTER_ERROR
The default setting of STOP_ON_ERROR aborts the backup if a
bad page checksum or torn page is detected during the
backup. The CONTINUE_AFTER_ERROR setting overrides this
behavior, allowing the database to be backed up even if there
are errors in the database.
DESCRIPTION = string
A description of the database backup is often useful to identify
the backup media. The description property supports a
description length of 255 characters.
DIFFERENTIAL
Specifies that a Differential backup is to be performed on the
associated database or data file/filegroup.
EXPIREDATE = datetime
A date specification used to identify when the backup is no
longer required and may be overwritten
RETAINDAYS = integer
Specifies the number of days the backup is required. This
option or the EXPIREDATE option is used to control this
behavior.
PASSWORD = string
A password can be assigned to a backup so that the password
is required to use the backup during a restore operation. The
password protection is very weak and should not be relied on
to guarantee the security of a backup. The PASSWORD option is
deprecated and will be removed in a future release.
FORMAT | NOFORMAT
The FORMAT option is used to create a new backup media set. It
will overwrite any existing media set at the destination.
NOFORMAT is the default setting that would prevent an
inadvertent overwriting of a backup file that was participating
in a backup stripe set.
INIT | NOINIT
The default setting of NOINIT specifies that any backups sent to
the destination will be appended to the backup file. INIT
specifies that subsequent backups will overwrite the existing
backup file contents.
NOSKIP | SKIP
The NOSKIP default setting configures SQL Server to check the
backup media’s expiration date to prevent inadvertent
overwriting of previous backups. The SKIP setting ignores the
expiration date information
MEDIADESCRIPTION = string
A maximum length string of 255 characters used to describe
the backup media
MEDIANAME = string
The backup media’s logical name with a maximum of 128
characters
12:13pm
Page 374
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Option
Description
MEDIAPASSWORD =
string
Like the PASSWORD option that defines a password for an
individual backup, the MEDIAPASSWORD sets a password on the
backup media set. The MEDIAPASSWORD is also very weak and
should not be relied on for media set security. This option is
deprecated.
NAME = string
A maximum length of 128 characters to identify the name of the
backup set
NOREWIND | REWIND
This option is only used when the backup destination is specified
as TAPE. The default REWIND option configures SQL Server to
rewind the tape when the backup is completed or the end of the
tape is reached during a backup.
NOUNLOAD | UNLOAD
This option is only used with tape backups. The default setting is
UNLOAD, which configures SQL Server to rewind and eject the tape
when the backup is complete. NOUNLOAD overrides this default
behavior and leaves the tape open and mounted.
RESTART
This option does absolutely nothing. It does not generate an error
when used and is included to prevent old scripts from previous
releases from failing.
STATS = percentage as
integer
Configures SQL Server to return progress information every time
the specified percentage is reached. The default is 10.
COPY_ONLY
COPY_ONLY backups do not affect the transaction log sequence.
These backups cannot be used for a Differential or Transaction
Log backup base.
COMPRESSION
COMPRESSION backups average about 80 percent smaller in size
than uncompressed backups. The compression will vary
depending on the type of data stored in the database
NORECOVERY
The NORECOVERY option backs up the database and then places it
in the non-accessible ‘‘Restoring’’ mode. This is useful for a last
backup of a database before taking it offline or moving it to a new
location
Backup Strategies
As previously mentioned, the various backup types provided by SQL Server 2008 can be used in different
combinations to create a variety of backup strategies. In this section, we will cover just a few of the more
commonly used backup strategies.
Full Backup Only
The Full backup strategy (Figure 9-2) uses periodic Full database backups with no Log or Differential
backups. It is a very useful and simple strategy but is generally limited to small databases configured in
375
Page 375
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
the Simple recovery model and for system databases. This strategy exposes the database to the risk of
losing one period of data modifications. For example, if the database is backed up every day at 1:00 a.m.
and there is a database failure anytime before 1:00 a.m., the most recent restore point will be 1:00 a.m. of
the previous day. For small databases with very few daily updates, this may be acceptable.
Full Backup Strategy
Full
Full
Full
Full
Full
A.M.
A.M.
A.M.
A.M.
A.M.
Mon
Tue
Wed
Thu
Fri
Figure 9-2: Full backup strategy.
Full Backup with Differential
Like the Full backup strategy, the Full backup with Differential (Figure 9-3) is generally limited to
databases configured in Simple recovery model because it does not provide for any management of
the transaction log. However, the addition of a periodic Differential backup makes this backup strategy
more appropriate for slightly larger changing databases where the management of a transaction log is
not desired. Because only data modified since the last Full backup is copied to the backup media, the
periodic Differential backups will be smaller when compared to the Full backups and will take less time
to execute.
Full Backup with Differential Strategy
Full
Differential
Differential
Differential
Full
A.M.
A.M.
A.M.
A.M.
A.M.
Mon
Tue
Wed
Thu
Fri
Figure 9-3: Full backup with Differential strategy.
Full Backup with Transaction Log
The disadvantages of the Full and Full with Differential plans are that they expose the database to the
risk of data loss equal to the periodicity of the backup. By introducing Transaction Log backups into the
backup plan (Figure 9-4), this risk is reduced dramatically. However the management of transaction logs
introduces more complexity to the administration of database files. As previously discussed, when the
database is not in Simple recovery model, the transaction log must be periodically backed up to prevent
it from growing too large and filling up. The alternative method of maintaining the log is to periodically
clear it, but this is strongly discouraged as described later.
In the event of a database failure, the database can be restored up to the moment of failure by performing
periodic Transaction Log backups between Full backups. The number of log backups and the periodicity
of the backups depend on how busy the database is and what the acceptable degree of data loss is. In
376
12:13pm
Page 376
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
a worst case scenario, both the database and the transaction log could be lost. If that is the case, then
like the Full and Differential backup plans, the database can only be restored to the end of the previous
Transaction Log backup. However, if only the data files are damaged, the database backup, log backups,
and online log can be used to restore the database to the moment of failure.
Full with Log Backup Strategy
Full
Full
A.M.
A.M.
P.M.
P.M.
P.M.
A.M.
Mon
Mon
Mon
Mon
Mon
Tue
Figure 9-4: Full with Log backup strategy.
Because Transaction Log backups are typically smaller and faster, they can be scheduled to occur as
often as necessary. It is not uncommon to see Transaction Log backups scheduled for every 10 minutes
on databases that are subject to very frequent modifications.
Full and Differential Backup with Transaction Log
The disadvantage of performing several Transaction Log backups between Full backups is that in order to
restore a database, the Full backup and all the logs must be sequentially restored. This can be burdensome
if there are a large number of log backups to restore. To minimize this issue, a Differential backup (Figure
9-5) can be performed to capture all the changes to the database since the last Full backup. To restore the
database, the log backups between the Full and the Differential can be ignored.
Full and Differential with Log Backup Strategy
Differential
Full
Full
A.M.
A.M.
A.M.
P.M.
P.M.
P.M.
A.M.
Mon
Mon
Mon
Mon
Mon
Mon
Tue
Figure 9-5: Full and Differential with Log backup strategy.
File and Filegroup Backup
With very large databases, it is sometimes more efficient to back up the database in slices. This offers a
great deal of flexibility in the backup plan, but it also introduces a proportionate increase in the complexity of the backup plan. Database data files and filegroups can be backed up and restored individually,
enabling the administrator to avoid a time-consuming and unnecessary restore of a large database in its
entirety. This method is especially useful if some of the filegroups contain Read Only data. These filegroups can be backed up once and then recovered later in the event of a failure with no loss of interim
data. For example, a production database is comprised of four 25-GB filegroups. One of the filegroups
377
Page 377
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
contains tables that are updated about once every three months. The other three contain transactional
data that is updated on a regular basis. The first filegroup can be configured as Read Only and backed
up. The remaining three can be backed up on a rotating basis interspersed with Transaction Log backups,
as Figure 9-6 illustrates.
File/Filegroup Backup Strategy
Full
RO
File
Group
File
Group
1
File
Group
2
A.M.
A.M.
A.M.
P.M.
P.M.
A.M.
A.M.
P.M.
P.M.
A.M.
Mon
Mon
Mon
Mon
Mon
Tue
Tue
Tue
Tue
Wed
Figure 9-6: File/Filegroups backup strategy.
Filegroup with Differential
If the Filegroup strategy still backs up too much data that does not change, a File or Filegroup backup
can be combined with a File or Filegroup Differential backup. This way only the changes to the respective
file or filegroup will be backed up. However, since the straightforward File/Filegroup backup increases
complexity, adding a Differential backup to the mix will complicate things even more, and this strategy
will require a great deal of planning and maintenance.
Partial Backup
As previously described, the Partial backup (Figure 9-7) backs up the Primary filegroup and all
READ_WRITE configured filegroups by default. In addition, any READONLY configured filegroups can be
added to the backup set by specifying them in the BACKUP statement. The purpose behind this strategy is
to back up the Read Only filegroups once and then to periodically backup only the filegroups subject to
modification.
Partial Backup Strategy
RO
File
Group
RW File
Groups
RW File
Groups
A.M.
A.M.
A.M.
P.M.
P.M.
A.M.
Mon
Mon
Mon
Mon
Mon
Tue
Figure 9-7: Partial backup strategy.
Backup Summary
As you can see, there are quite a few different ways to combine backup types to develop an appropriate
backup strategy. Each backup type has its advantages and disadvantages. I wish I could give a prescrip-
378
12:13pm
Page 378
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
tive guide to backing up your databases, but I can’t. Each environment is unique, from the size of the
database and number of transactions per hour to the disk subsystem supporting the database. It is critically important to develop a backup strategy that mitigates the risk of data loss while at the same time
allowing for a realistic and effective data recovery strategy.
Restoring Databases
I have met with many database administrators who were shocked to discover that their database backup
plan did not lend itself to a problem-free recovery. If having an effective backup plan is critical, then
having an effective restoration plan is even more critical. SQL Server is very lenient in allowing different
backup types at different times, but it is a bit pickier about how those backups are restored. The critical
issue in most restoration plans is the sequence of backups. This section will describe the restore process,
how to prepare a database for restoration, and how to restore databases backed up using the strategies
outlined previously.
Restore Process
The restore process is made up of three phases: the Data Copy phase in which data pages are copied from
the backup media to the data file(s); the Redo phase in which the record of committed transactions is
restored from a log backup or the log portion of a database backup; and finally, the Undo phase in which
uncommitted transactions are rolled back from a log backup or the log portion of a database backup.
The Data Copy and Redo phases can span multiple backups. For example, a database is backed up with
a Full backup, followed by a Differential backup and then a Transaction Log backup. To restore the
database to its most recent state would require restoring the Full backup and then the Differential backup
as part of the Data Copy phase. The log portion of the Differential backup would begin the Redo phase,
followed by the committed transactions in the Transaction Log backup. After all committed transactions
are reapplied to the database, the Undo phase begins in which all uncommitted transactions are rolled
back and the database is brought online.
Each phase is linked to the next. If any backup is missing from the sequence, the process stops at the
end of the backup preceding the missing sequence. Figure 9-8 illustrates a lost or corrupted log backup.
Even though there are an additional two good log backups, they cannot be used because the effects of the
transactions recorded in the 12:01 p.m. Transaction Log backup are unknown. The database can only be
restored to the end of the 9:00 a.m. Transaction Log backup.
Missing Backup
Full
A.M.
A.M.
P.M.
P.M.
P.M.
Mon
Mon
Mon
Mon
Mon
Figure 9-8: Missing backup.
379
Page 379
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Delaying Recovery
When restoring a sequence of backups such as a Full backup and a series of Transaction Log backups,
the Undo phase and database recovery will have to be delayed so that each additional backup can be
restored. Once a database has been recovered, no additional backups can be applied. To delay recovery,
the option NO RECOVERY must be specified along with the RESTORE DATABASE command.
RESTORE Command
Although databases can be restored effectively with the graphical tools provided in Management Studio,
there are many advanced restore options that are only available by utilizing Transact-SQL. The simplified
RESTORE command syntax is as follows:
RESTORE DATABASE | LOG database_name
[File | FileGroup]
[FROM <backup_media> [ ,...n ] ]
[WITH
[CHECKSUM | NO_CHECKSUM]
[[,] FILE = file_number]
[[,] MOVE ‘logical_file_name’ TO ‘operating_system_file_name’] [,...n]
[[,] RECOVERY | NORECOVERY | STANDBY = standby_file_name]
[[,] REPLACE]
[[,] STOPAT = date_time
]
For simplicity, let’s break down the RESTORE command into its constituent pieces. The first is the actual
RESTORE command, which is typically followed by the argument DATABASE or LOG and then the target
database name. However, the RESTORE command can also be used to expose backup media metadata
and to verify the integrity of a backup set. The following table gives the various RESTORE commands that
expose information about the backup without actually restoring the database. The table is followed by
descriptions of the actual restore process.
380
Command
Description
RESTORE HEADERONLY
Exposes information from the backup media such as the name,
description, and type of backup, as well as information about
the backed-up database.
RESTORE FILELISTONLY
Exposes the name of the files contained in the backup set.
RESTORE LABELONLY
Retrieves media information such as the media name and
description.
RESTORE VERIFYONLY
Checks the integrity of the backup media. If the backup set
was created using the CHECKSUM option, the VERIFYONLY
command will read the page checksums as well as check to
make sure that the backup set is readable.
12:13pm
Page 380
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
RESTORE DATABASE database_name
Specifies that the restore process is for a database and specifies the name of the target database to restore
to. The database name specified does not need to exist or be the same name as the backed-up database.
FILE
The RESTORE DATABASE database_name statement can be followed by the logical name of a database data
file so that only that file is restored from the backup media. A file can be specified for Full, File, and
Filegroup backups.
RESTORE DATABASE SmallWorks
FILE = ‘SmallWorksData2’
FROM DISK = ‘D:\SQLBackups\SmallWorksFull.BAK’
FILEGROUP
The RESTORE DATABASE database_name statement can also be followed by the name of a database filegroup so that only that filegroup is restored from the backup media. A filegroup can be specified for Full
and Filegroup backups.
RESTORE DATABASE SmallWorks
FILEGROUP = ‘SWUserData2’
FROM DISK = ‘D:\SQLBackups\SmallWorksFull.BAK’
READ_WRITE_FILEGROUPS
The READ_WRITE_FILEGROUPS option only restores those filegroups in the database not marked as Read
Only. This option can be used with Full and Partial backups.
RESTORE DATABASE SmallWorks
READ_WRITE_FILEGROUPS
FROM DISK = ‘D:\SQLBackups\SmallWorksFull.BAK’
PAGE
To recover from Torn Page or checksum errors that identify one or more corrupted data pages, the
RESTORE DATABASE database_name statement can specify the 8-K data page to be restored. The page
restore option requires the file ID and page ID to be passed, as the following example illustrates:
RESTORE DATABASE SmallWorks PAGE = ‘1:14’
FROM DISK = ‘D:\SQLBackups\SmallWorksFull.BAK’
RESTORE LOG database_name
The RESTORE LOG statement specifies that the restore process is for a database transaction log. The backup
must be from a BACKUP LOG process. The restoration of the transaction log must be applied to an
existing database. The first Log Sequence Number (LSN) of the log backup being restored must be the
next consecutive LSN after the last LSN of the previous Log or database backup.
RESTORE LOG SmallWorks
FROM DISK = ‘D:\SQLBackups\SmallWorksLog.BAK’
381
Page 381
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
FROM Options
When restoring a database from either a database backup or a log backup, the RESTORE command expects
a backup media location to be specified in the FROM clause of the RESTORE statement. If no backup media
location is specified, then the recovery operation is executed. During the recovery operation, SQL Server
rolls forward all complete transactions from the existing transaction log and rolls back all incomplete
transactions, as this example shows:
RESTORE DATABASE SmallWorks
With this syntax, the database is recovered in place. This may be necessary if the database is left in a
RECOVERING state but there are no additional backups to be applied.
Other than the recover in place option, the following arguments are valid.
FROM DISK
The FROM DISK = file_location specifies that the backup media resides on one or more physical disks
identified by a drive letter and location or a network location identified by a UNC, as the following code
illustrates:
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackUps\SmallWorksFull.BAK’
RESTORE DATABASE SmallWorks
FROM DISK = ‘\\AughtEight\SQLBackUps\SmallWorksFull.BAK’
FROM TAPE
The FROM TAPE = tape_device specifies that the backup media resides on one or more tapes identified by
a tape UNC, as shown in the following code:
RESTORE DATABASE SmallWorks
FROM TAPE = ‘\\.\tape1’
FROM DATABASE_SNAPSHOT
The DATABASE_SNAPSHOT option specifies that the online database will be restored back to the state it was
in when the specific Database Snapshot was created. Database Snapshots will be discussed at the end of
this chapter.
WITH Clause
After the FROM clause and its arguments comes the WITH clause. The WITH clause of the RESTORE command
has several options. The most commonly used are described in the following sections.
RECOVERY | NORECOVERY
When restoring a database from a sequence of backups, all but the last backup must be restored with
the NORECOVERY option. This allows for additional backups to be applied to the database. The RECOVERY
option completes the Redo/Undo phase of restoration as previously described, making the database
available to client connections and preventing further restore operations. WITH RECOVERY is the default
382
12:13pm
Page 382
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
setting, so it is important to override it until the final backup is being applied. There is no ‘‘UnRecover’’
command that will allow you to restart the restoration process. Once the database is recovered, the entire
restore process must be restarted to apply additional backups. However, if all the available backups
have been applied but the database was not recovered, the RESTORE DATABASE command can be specified
without designating a source for the restore to invoke the recovery process with the current transaction
log.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH RECOVERY
STANDBY
The NORECOVERY option leaves the database in a state of recovering and prevents access to the database.
The STANDBY option functions much the same way except it allows for Read Only access to the database.
It does this through the use of a standby file that stores all the Undo information that would normally be
used to recover the database. The STANDBY option allows for a copy of the database to be maintained on
a separate server and periodically updated with additional transaction log restores. This functionality is
at the heart of Log Shipping, which is described in Chapter 12.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH STANDBY = ‘E:\SQLBackups\SmallWorksUndoRollback.DAT’
CHECKSUM | NO_CHECKSUM
The CHECKSUM option specifies that page checksum information is verified before the data is rewritten to
the database during a restore operation. If the backup was not created using the checksum option, the
RESTORE . . . WITH CHECKSUM command will fail. It will also throw an error if any checksum errors are
encountered during the restore process.
BACKUP DATABASE SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksCheckSumFull.BAK’
WITH CHECKSUM
--Capture the tail of the log prior to restore operation
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH NO_TRUNCATE
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksCheckSumFull.BAK’
WITH CHECKSUM
CONTINUE_AFTER_ERROR | STOP_ON_ERROR
The CONTINUE_AFTER_ERROR option specifies that the restore operation will continue regardless of errors
found in the backup media. The default setting of STOP_ON_ERROR will cause the restore operation to fail
if any error is encountered.
383
Page 383
Leiter
c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
FILE
One of the more confusing aspects of the RESTORE command is that there is a FILE = option in the RESTORE
clause that specifies a logical filename and another FILE = option in the WITH clause, where an integer
value that represents the backup location in the file is specified. Since multiple backups can be stored in
a single location identified with a name, it is important to be able to differentiate them. When sending
multiple backups to the same file location, it is essentially like storing files within files. To differentiate
between the different backups stored in a single file, the FILE = backup_number option is specified. The
following example shows multiple backups being sent to the same destination. The first is a Full backup,
the second is a Differential backup, and the last is a Tail Log backup. The example goes on to show the
restoration of the backups from the same file.
--Initialize the backup file and backup the SmallWorks database to the file
BACKUP DATABASE SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH INIT, DESCRIPTION = ‘Full Backup of SmallWorks’
--Send an Additional backup to the file
BACKUP DATABASE SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH DIFFERENTIAL, DESCRIPTION = ‘Differential Backup of SmallWorks’
--Capture the tail of the log prior to restore operation
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH NO_TRUNCATE, DESCRIPTION = ‘Tail Log Backup of SmallWorks’
--Restore the Full Backup with NORECOVERY
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH FILE = 1, NORECOVERY
--Restore the Differential Backup with NORECOVERY
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH FILE = 2, NORECOVERY
--Restore the Tail Log Backup with RECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksBackups.BAK’
WITH File = 3, RECOVERY
MOVE . . . TO . . .
When restoring databases it is sometimes necessary to change the physical name or location of the
database file. The MOVE logical_filename TO operating_system_filename accomplishes this. For
instance, a new database server has been installed, and you need to move a database from the old server
to the new server. The new server’s file system is not organized the same as the old server so new locations must be specified. The following example shows how to move the SmallWorks database from its
original location to the new drives identified for data files and log files.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH MOVE ‘SmallWorksPrimary’ TO ‘S:\SQLData\SmallWorks.mdf’
384
12:13pm
Page 384
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
,
,
,
,
MOVE ‘SmallWorks_log’ TO ‘T:\SQLLogs\SmallWorks_log.ldf’
MOVE ‘SmallWorksData1’ TO ‘S:\SQLData\SmallWorksData1.ndf’
MOVE ‘SmallWorksData2’ TO ‘S:\SQLData\SmallWorksData2.ndf’
REPLACE
PARTIAL
The PARTIAL option specifies that the Primary filegroup and any designated user-defined filegroups will
be restored. Partial restores are described later in this Chapter.
REPLACE
The REPLACE option overrides the normal database restoration safety checks and specifies that the backup
files referenced should replace the existing files. This is sometimes necessary if the transaction log is not
available for a Tail Log backup, but the restore operation fails with errors because of no Tail Log backup
existing. The REPLACE option also enables the backup of one database to be restored over an existing
database even if the files and names are different.
Database Restore Preparation
There are a few different reasons to restore a database, and only one of them involves a failure of the
database. It may very well be that the only time you will be required to restore a database is to move a
database from one server to another or to restore a test and development database, in which case there is
still some pre-planning to do.
Generally the preparation tasks are as follows:
1.
2.
Isolate the database by placing it in SINGLE_USER mode (if it is accessible).
3.
Gather information about all the backups that are required to restore the database to the
most recent consistent state.
Back up the tail of the transaction log if in Full or Bulk-Logged recovery model. This captures
all the recent activity.
Isolate the Database
Isolating the database is typically required because when restoring a database that is still online, SQL
Server essentially drops and then recreates the database from the backup media. As we learned earlier, a database cannot be dropped if someone is connected to it. Some documentation specifies that the
database should be set to RESTRICTED_USER instead of SINGLE_USER. However, when a database is set
to RESTRICTED_USER access, it will still allow multiple connections. SQL Server just limits those connections to privileged users such as the DBO or SA. If there are multiple DBO users in your organization,
RESTRICTED_USER will not prevent them from connecting to the database. RESTRICTED_USER will also not
prevent you from opening multiple windows and multiple connections to the database you are trying to
restore, thus preventing the restore from occurring. Each Query Window and Object Explorer in Management Studio uses its own connection. To ensure that the restore operation will succeed, it is much easier
to just place the database in SINGLE USER access. Ironically, to change the database from MULTI_USER to
SINGLE_USER or RESTRICTED_USER access, you must have exclusive access to the database, which equates
to SINGLE_USER.
385
Page 385
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Capture Recent Activity
Backing up the tail of the log ensures that the most recent transactions (since the last backup) are recorded
and recoverable. Often, this is not an optional step, and restore operations will not be permitted until the
Tail Log backup has been completed.
Gather Backup Information
This last step can be made easier if the entire database server has not suffered a failure. SQL Server
records all database backup and restore history in the msdb database. To see what backups SQL Server
Management Studio thinks need to be restored, in Object Explorer right-click Databases, click ‘‘Restore
Database,’’ and then choose the database to restore from the ‘‘Source for Restore’’ database dropdown
list. Management Studio will automatically choose the backups to restore, as shown in Figure 9-9. Keep
in mind that this is for a complete restore. If you are restoring a file or filegroup, Management Studio
is not as helpful. It will list all the File and Filegroup backups performed, but it will not select any for
recovery. You will have to do that manually. Likewise, if the choices made by Management Studio are
not what you want, you are able to override the selected backups. If the backup history is not available,
the ‘‘From device’’ option can be used to select a file or backup device, and the appropriate backups can
be chosen.
Figure 9-9: Multiple file restore.
As previously described, backup media information can also be retrieved through the use of three
RESTORE command arguments: RESTORE HEADERONLY, RESTORE FILELISTONLY, and RESTORE LABELONLY.
386
12:13pm
Page 386
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Restoring User Databases
The backup strategies outlined earlier in this chapter apply mostly to user databases. Although system
databases do need to be backed up, the strategy for backing them up is very straightforward and is
typically confined to Full database backups only. This is because system databases do not change as often
and are typically quite small. This section, therefore, describes the process of restoring user databases
from the backup strategies defined earlier.
Full Restore
The periodic Full backup of a database is the simplest of all backup strategies and is also a very simple
restore strategy. If the database needs to be restored, simply find the most recent Full backup, and use
it to restore the database. Figure 9-10 illustrates a database that is damaged at 9:00 a.m. The most recent
backup was completed at 12:02 a.m. In this case, the 12:02 a.m. backup would be restored with recovery.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksWed0002.BAK’
WITH RECOVERY
Database
Damaged
Full
Full
Full
A.M.
A.M.
A.M.
A.M.
Mon
Tue
Wed
Wed
Figure 9-10: Full restore scenario.
Full with Differential Restore
Differential backups require a Full backup to be applied prior to the restoration of the Differential. Figure
9-11 illustrates a failure of the SmallWorks database at 9:00 a.m. on Wednesday. Since a Differential
backup was completed at 12:02 a.m. on Wednesday, the Differential backup on Tuesday can be ignored.
The recovery process is the Monday Full backup followed by the Wednesday Differential backup.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFullMon0002.BAK’
WITH NORECOVERY
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksDiffWed0002.BAK’
WITH RECOVERY
Full with Transaction Log Restore
Like the Differential backup and restore process, the Transaction Log backup also requires a baseline
restore before it can be applied. Figure 9-12 illustrates a SmallWorks database damaged at 3:00 p.m. Since
387
Page 387
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
the database is in Simple or Bulk-Logged recovery model, the tail of the transaction log may be able to be
backed up to capture all the most recent changes to the database. In this way, very little to no data may be
lost. The Tail Log backup is completed at 3:10 p.m. After the Tail Log backup is complete, the restoration
process can be executed, starting at the Monday Full backup and then proceeding through the remaining
Transaction Log backups.
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLogMon1510.BAK’
WITH NO_TRUNCATE
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFullMon0002.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksLogMon0900.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksLogMon1202.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLogMon1510.BAK’
WITH RECOVERY
Database
Damaged
Differential
Full
Differential
A.M.
A.M.
A.M.
A.M.
Mon
Tue
Wed
Wed
Figure 9-11: Differential restore scenario.
Database
Damaged
Full
A.M.
A.M.
P.M.
P.M.
Mon
Mon
Mon
Mon
Figure 9-12: Transaction Log restore
scenario.
388
12:13pm
Page 388
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Full and Differential with Transaction Log Restore
When using both Differential and Transaction Log backups to capture changes to the database, the important thing to remember is sequence. Each Differential backup contains the changes made to the database
that were recorded in transaction logs during the interval between the Full backup and any Differential
backup completed. Figure 9-13 illustrates this behavior. Since the database is damaged at 6:00 p.m., a
Tail Log backup is completed to capture all activity between 3:00 p.m. and 6:00 p.m. The database is then
restored using the Full, Differential regular Transaction Log and Tail Log backups.
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLogMon1810.BAK’
WITH NO_TRUNCATE, NORECOVERY
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFullMon0002.BAK’
WITH NORECOVERY
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksDiffMon1202.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksLogMon1500.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLogMon1810.BAK’
WITH RECOVERY
Database
Damaged
Differential
Full
A.M.
A.M.
A.M.
P.M.
P.M.
P.M.
Mon
Mon
Mon
Mon
Mon
Mon
Figure 9-13: Full and Differential with Log scenario.
File and Filegroup Restore
File and Filegroup restore processes vary depending on the recovery model the database is configured
for and whether the file or filegroup is marked as Read Only. If the database is in Simple recovery model,
the only files or filegroups that can be restored independently of the complete database are those that
are marked as Read Only. Since the database is in Simple recovery model, no Tail Log backups are
allowed, and any restoration of a Read Only file or filegroup will result in that file or filegroup being
immediately available for queries. The syntax and process for individual file or individual filegroup
restores are identical.
389
Page 389
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Try It Out
File Restore Example 1
This first example shows the process of restoring a single damaged file in the SmallWorks database when
it is configured in Full Recovery.
1.
Back up the tail of the active transaction log.
--Capture the tail of the transaction log
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH INIT, NO_TRUNCATE, NORECOVERY
2.
Restore the damaged data file.
--Restore the damaged or corrupted file
RESTORE DATABASE SmallWorks FILE = ‘SmallWorksData1’
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
At this point the SmallWorksData1 file is offline, and any queries that reference the dbo.Person table,
which resides in the SmallWorksData1 file, will fail.
3.
Restore the tail of the log, which returns the SmallWorksData1 file to an online status.
--Restore the tail of the log to bring the SmallWorksData1 file online
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH RECOVERY
Try It Out
File Restore Example 2
This second example shows the process of restoring a single damaged data file that resides in a Read
Only filegroup. In this example, the capture of the tail of the log and the restoration of the tail to bring
the file online are unnecessary. This is because the file resides on a Read Only filegroup. There are no
changes to capture.
--Restore the damaged or corrupted file
RESTORE DATABASE SmallWorks FILE = ‘SmallWorksData2’
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
Once the restoration of the SmallWorksData2 file is complete, the database is completely online and
accessible.
Partial Restore
The Partial restore process is very similar to the File/Filegroup restoration process. The significant difference is that Partial restores always include the Primary filegroup.
390
12:13pm
Page 390
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Try It Out
Partial Restore Example 1
The following example shows the SmallWorks database being backed up with a Partial backup and then
the restore process to bring the database back online after suffering a failure of both the SWUserData1
READWRITE filegroup and the Primary filegroup.
1.
Perform the Partial backup:
BACKUP DATABASE SmallWorks READ_WRITE_FILEGROUPS
TO DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH INIT
2.
Sometime later the READ_WRITE configured filegroups including the Primary filegroup experience a failure. The first step after the failure is to capture all the recent activity and place the
database in a state to recover from the failure.
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH INIT, NORECOVERY, NO_TRUNCATE
3.
Restore the READ_WRITE configured filegroups. In the case of the SmallWorks database, that is
the Primary and SWUserData1 filegroups.
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH PARTIAL, NORECOVERY
4.
Restore the tail of the log and bring the database online
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH RECOVERY
5.
Even though the database is online, the user-defined filegroups are still inaccessible because
of restoring the Primary filegroup. To bring the user-defined filegroups online, we use the
RESTORE DATABASE command but do not specify a source for the restore. This completes the
recovery process for the filegroups and is near instantaneous since no data is actually being
restored.
RESTORE DATABASE SmallWorks FILEGROUP = ‘SWUserData1’
WITH RECOVERY
RESTORE DATABASE SmallWorks FILEGROUP = ‘SWUserData2’
WITH RECOVERY
The SmallWorks database is now completely online.
391
Page 391
Leiter
c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Try It Out
Partial Restore Example 2
In this example, only the SWUserData1 READWRITE filegroup is damaged so it is unnecessary to restore
the Primary database.
1.
Start off again with a Partial backup of the SmallWorks database.
BACKUP DATABASE SmallWorks READ_WRITE_FILEGROUPS
TO DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH INIT
2.
Sometime later the file in the SWUserData1 filegroup is damaged. When it is discovered, the tail
of the transaction log is captured and the database is put into a state to support recovery.
BACKUP LOG SmallWorks
TO DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH INIT, NORECOVERY, NO_TRUNCATE
3.
Restore just the SWUserData1 filegroup and then the tail of the log to bring the database completely online.
RESTORE DATABASE SmallWorks FILEGROUP = ‘SWUserData1’
FROM DISK = ‘E:\SQLBackups\SmallWorksFull.BAK’
WITH NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksTailLog.BAK’
WITH RECOVERY
Point-in-Time Restore
SQL Server 2008 supports the recovery of both databases and transaction logs to a specific point in time,
but only if the database is configured in the Full or Bulk-Logged recovery models. As previously discussed, the Bulk-Logged recovery model should only be used as an adjunct to the Full recovery model.
This is especially true because of the impact of the Bulk-Logged recovery on point-in-time restores. If
the database is configured for Bulk-Logged recovery and the transaction log contains bulk operations,
point-in-time recovery is not possible; the transaction log must be restored in its entirety.
Point-in-time database restore operations are useful to restore a database to a point just prior to data
corruption because of a malicious or accidental modification of data. For example, an accidental update
to the SmallWorks database occurs at 3:00 p.m. but is not detected until 6:15 p.m. A scheduled database
backup was completed at 4:00 p.m., and a scheduled Transaction Log backup occurred at 5:00 p.m. To
restore the database to just before the accidental update, a point-in-time restore is used. The sequence of
events to restore the database is as follows:
RESTORE DATABASE SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksFull1600.BAK’
WITH STOPAT = ‘12/05/2008 14:59:00’
392
12:13pm
Page 392
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
,NORECOVERY
RESTORE LOG SmallWorks
FROM DISK = ‘E:\SQLBackups\SmallWorksLog1700.BAK’
WITH STOPAT = ‘12/05/2008 14:59:00’
,RECOVERY
Recovering System Databases
System databases are just as vulnerable to failure as User databases, and it is very important to ensure
that they are adequately protected. Essentially you have two choices when it comes to recovering System
databases. You can restore them from backup, or you can rebuild them from scratch. I highly recommend
the backup and restore approach, since rebuilding them from scratch means a ton more work.
Because system databases are usually small, they don’t require a great deal of time to back up, and they
don’t take up much space when backed up. How often the structure of your system databases change
will determine how often you will need to back them up to minimize the post-restore tasks.
Recovering the Master Database
There are two scenarios for recovering the Master database. In the first scenario, the server is accessible.
And in the second, SQL Server is not accessible.
If you can connect to SQL Server, the server instance must be started in single-user mode in order to
restore and recover the Master database:
1.
To start an instance of SQL Server in single-user mode, type the following command at the
command prompt:
sqlservr.exe –m
2.
If the server supports multiple instances of SQL Server, be sure to start the right
one. The default instance of SQL Server is located in the folder \Program Files\
Microsoft SQL Server\MSSQL.1\MSSQL\Binn. Each additional instance will have its own
MSSQL.X folder, but depending on the installation sequence, they may not be in numerical
order.
3.
Once the server is started in single-user mode, the Master database can be restored. To
accomplish this, start another command prompt window and log in to the SQL Server
instance with SQLCMD. The following example shows a login command to an instance of
SQL Server called AughtEight (-S) using Windows Security (-E).
C:\>SQLCMD –S AughtEight -E
For a complete description of the SQLCMD syntax, consult SQL Server 2008 Books Online
under the topic ‘‘Using the sqlcmd Utility.’’
4.
After successfully logging in to the server, the restoration of the Master database can be completed through the normal RESTORE syntax.
393
Page 393
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
1>RESTORE DATABASE MASTER FROM DISK = ‘E:\SQLBackups\MasterFull.BAK’
2>GO
Processed 360 pages for database ‘Master’, file ‘master’ on file 1.
Processed 2 pages for database ‘Master’, file ‘mastlog’ on file 1.
The master database has been successfully restored. Shutting down SQL
Server.
SQL Server is terminating this process.
As shown in the preceding example, once the Master database has been restored, SQL Server will automatically shut down the instance so that it can be restarted with the newly restored Master database.
The only database that can be restored in single-user mode is the Master database. Once Master is
restored, restart SQL Server to continue restoring any other system or user databases.
If the instance of SQL Server is not accessible because of a corrupted Master database or total server
failure, then the Master database will have to be rebuilt. In previous versions of SQL Server this could
be done through a command prompt utility. However, Microsoft discontinued support of that utility.
In order to rebuild the Master database, you must re-install SQL Server. Once SQL Server has been
re-installed, the most recent backup of the Master database can be used to restore the server using the
same procedure outlined previously.
Once the Master database has been restored and the instance of SQL Server restarted, the remaining
system databases and user databases should be remounted automatically. If the backup of the Master
database is not up-to-date or does not exist at all, the remaining system and user databases may not
automatically remount and will have to either be restored or attached. Assuming that the remaining
database files are still intact in the file system, it is much faster and easier to attach the databases. The
simplest way to attach the existing databases is to use the graphical tools in SQL Server Management
Studio:
1.
To attach a database, right-click Databases and click Attach; the Attach Databases window
will appear.
2.
Click on the Add button to browse to the location of the database’s MDF file and select it.
Each database’s MDF file contains the metadata that identifies the location of all the
database’s constituent files. As long as none of the files are identified with a ‘‘Not Found’’
message, the database should attach with no difficulty.
3.
If a data file is missing, the database will not be able to be attached. However, if only the
transaction log file is missing, the database can still be successfully attached by selecting the
missing log file and clicking Remove. Once the log file is removed from the list, click OK to
attach the database. SQL Server will re-create a log file using the metadata of the original.
Orphaned Users
After the Master database and all the other databases have been restored or attached, it may be necessary
to check the user databases for orphaned users. Orphaned users occur when a SQL Server login has been
added to the Master database and granted access to a database, but the backup of the Master database
was performed before the login was created. When the user database was attached or restored, the user
database contained the database user, but the login in the Master database did not exist.
394
12:13pm
Page 394
Leiter c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
To find and fix orphaned users, two methods are available. The first is the ALTER USER command. If the
user FredF is orphaned, the following code can be used to re-associate the database user to the server
login:
USE SmallWorks
GO
ALTER USER FredF
WITH LOGIN = FredF
The second method is to use a deprecated stored procedure called sp_change_users_login. The
sp_change_users_login procedure has three modes defined by the input parameter @Action. The three
supported actions are defined in the following table:
Action
Description
Report
Returns a list of all database users not associated with a valid
SQL Server login.
Auto_Fix
Links the database user to a SQL Server login with the same
name. For example:
❑
USE SmallWorks
❑
GO
❑
sp_change_users_login ‘Auto_Fix’, ‘FredF’
This example links the SmallWorks database user FredF to a
Server login with the same name if one exists.
Update_One
Links a specific database user to a specific SQL Server Login.
❑
USE SmallWorks
❑
GO
❑
sp_change_users_login ‘Update_One’, ‘FredF’,
‘SQLFredFLogin’
This example links the SmallWorks database user FredF to a
SQL Server login called SQLFredFLogin.
Database Restore Summary
Like the backup strategy, it is exceptionally important to have a restore plan. A good restore plan will
cover any combination of possible failures and list the steps required to restore the database in the shortest time possible and with the least amount of data loss. There is no way I could cover every possible
combination in the few pages devoted to this topic. It is up to you to analyze your infrastructure and
choose the backup and restore plan that best fits your environment.
395
Page 395
Leiter
c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Database Snapshots
Database Snapshots can’t really be used for disaster recovery in the case of a complete database loss.
However, they can be very useful in reversing the effects of database modifications. They are also useful
in re-directing queries away from a busy transactional database.
What is a Database Snapshot? A snapshot is a point-in-time, static, Read Only view of a database. The
creation of a snapshot is instantaneous because the database that is the source of the snapshot is not
actually copied to create the snapshot. Instead, data files are created that will only hold the data pages
from the source database that have changed since the snapshot was created. This functionality is called
Copy On Write. When the Database Snapshot is initially created, near-identical data files are created to
hold the contents of the snapshot. The difference in the data files is that they have separate physical
locations from the source database, and they initially consume very little disk space.
The easiest way to understand Database Snapshots is to create and use one. The following script creates
a snapshot of the SmallWorks database.
CREATE DATABASE SmallWorksSnapShot ON
(NAME = ‘SmallWorksPrimary’
, FILENAME = ‘D:\SQLSnapShotData\SmallWorksPrimary.mdf’)
,(NAME = ‘SmallWorksdata1’
, FILENAME = ‘D:\SQLSnapShotData\SmallWorksData1.ndf’)
,(NAME = ‘SmallWorksdata2’
, FILENAME = ‘D:\SQLSnapShotData\SmallWorksData2.ndf’)
AS SNAPSHOT OF SmallWorks
A look in the file system reveals that the SmallWorks snapshot data files are all 10 MB, as they were when
you created the database (your size may vary based on any modifications you made to the SmallWorks
database), but the files are only consuming 128 KB for the primary file and 64 KB for each secondary data
file for a total of 256 KB. SQL Server reserves the same amount of disk space that the database is presently
using, but it only allocates enough to store the metadata of the database structure.
Now let’s take a look at the data in the SmallWorks and SmallWorksSnapshot databases and see what
happens to the snapshot database and the data when changes are made to the source database.
1.
First write a query to return some data from the first three rows of the dbo.Person table in
the SmallWorks database and the SmallWorksSnapshot database, as shown in the following
example:
USE SmallWorks
GO
SELECT FirstName, LastName, EmailAddress
FROM dbo.Person
WHERE PersonID < 4
FirstName
--------Ken
Terri
396
LastName
-------Sánchez
Duffy
EmailAddress
--------------------------------ken.sá[email protected]
[email protected]
12:13pm
Page 396
Leiter
c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
Roberto
Tamburello
[email protected]
(3 row(s) affected)
USE SmallWorksSnapShot
GO
SELECT FirstName, LastName, EmailAddress
FROM dbo.Person
WHERE PersonID < 4
FirstName
--------Ken
Terri
Roberto
LastName
-------Sánchez
Duffy
Tamburello
EmailAddress
--------------------------------ken.sá[email protected]
[email protected]
[email protected]
(3 row(s) affected)
Notice that both of the databases return the same results. In actuality, the query to the snapshot database was re-directed to the source database since the data pages containing the
contact information had not been changed since the snapshot was created.
2.
Now, let’s update the data in the source database by changing the last name of all the people
in the database. We’ll update all of them so we can more easily examine the changes to the
physical data files hosting the snapshot database.
USE SmallWorks
GO
UPDATE dbo.Person
SET LastName = ‘Flintstone’
(5000 row(s) affected)
The SmallWorksSnapShot data files now consume about 1.2 MB of space (your results may
vary). Updating the 5,000 rows in the SmallWorks database caused the original data pages
containing those rows to be copied to the snapshot, resulting in an increase in the size of the
snapshot.
3.
Now let’s query the two databases again to see what the results are. The source database is,
indeed, changed, reflecting the update of the LastName column.
USE SmallWorks
GO
SELECT FirstName, LastName, EmailAddress
FROM dbo.Person
WHERE PersonID < 4
FirstName
--------Ken
Terri
LastName
-------Flintstone
Flintstone
EmailAddress
--------------------------------ken.sá[email protected]
[email protected]
397
Page 397
Leiter
c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
Roberto
Flintstone
[email protected]
(3 row(s) affected)
However, the snapshot database still reflects the data as it appeared when the snapshot was
created. This is what is meant by a ‘‘static, Read Only copy’’ of the database.
USE SmallWorksSnapShot
GO
SELECT FirstName, LastName, EmailAddress
FROM dbo.Person
WHERE PersonID < 4
FirstName
--------Ken
Terri
Roberto
LastName
-------Sánchez
Duffy
Tamburello
EmailAddress
--------------------------------ken.sá[email protected]
[email protected]
[email protected]
(3 row(s) affected)
You can create as many snapshots as you want of a database, but keep in mind that each additional
snapshot is going to add additional overhead to your source database. The overhead is created because
every command that updates or deletes data or objects will cause a Write to the snapshot database to
record the previous version of the database.
Database Snapshot Limitations
There are some limitations of Database Snapshots and limitations on the source database created with
the snapshot:
❑
Database Snapshots cannot be backed up. Since the snapshot is a combination of data retrieved
from the source database and data stored internally, it is impossible to actually back up the snapshot.
❑
Database Snapshots cannot be modified.
❑
Source databases cannot be dropped while a snapshot exists.
❑
Source databases cannot be restored to a point in time prior to the creation of the snapshot while
the snapshot exists.
Disaster Recovery and Database Snapshots
How exactly do Database Snapshots fit in to the realm of disaster recovery? That is an excellent question!
Snapshots can be used to undo updates to a source database because they have the original copy of the
data as it looked prior to the modification.
Undoing Updates
In the previous example, we updated all 5,000 rows of the Person table with the last name of Flintstone.
To reverse the effects of this frivolous update, the following script can be used:
USE SmallWorks
GO
398
12:13pm
Page 398
Leiter
c09.tex
V3 - 03/25/2009
12:13pm
Chapter 9: Disaster Prevention and Recovery
UPDATE dbo.Person
SET LastName = S.LastName
FROM dbo.Person P
JOIN SmallWorksSnapShot.dbo.Person S
ON S.PersonID = P.PersonID
A query of the source database will now reveal that all the last names have been put back to their original
values.
Undoing Deletes
Consider the following command that deletes 50 of the rows from the dbo.Person table:
DELETE dbo.Person
WHERE PersonID < 51
If this was a malicious or accidental update, the normal pattern for restoring the data would be to restore
the database to a test server and then copy the data from the test server back to the production database.
With a Database Snapshot there is no need to involve the database backups.
To restore the data, simply insert the data back into the source database table by selecting from the
snapshot.
USE SmallWorks
GO
INSERT dbo.Person
(PersonID, FirstName, LastName, EmailAddress)
SELECT PersonID, FirstName, LastName, EmailAddress
FROM SmallWorksSnapShot.dbo.Person
WHERE PersonID < 51
Undoing Drops
If a database object is dropped from the source database, it can be scripted and re-created from the
snapshot database. If it was a table, the table can then be repopulated using the previous method for
undoing deletes.
--Inadvertant deletion of the Person table
USE SmallWorks
GO
DROP TABLE dbo.Person
--Recreate the Person Table
USE SmallWorks
GO
CREATE TABLE dbo.Person(
PersonID int NOT NULL,
FirstName varchar(50) NOT NULL,
MiddleName varchar(50) NULL,
LastName varchar(50) NOT NULL,
EmailAddress nvarchar(50) NULL
) ON SWUserData1
--Repopulate the table
INSERT dbo.Person
(PersonID, FirstName, LastName, EmailAddress)
399
Page 399
Leiter c09.tex
V3 - 03/25/2009
Chapter 9: Disaster Prevention and Recovery
SELECT PersonID, FirstName, LastName, EmailAddress
FROM SmallWorksSnapShot.dbo.Person
Restoring from Snapshots
If several undesired changes have been made to the source database, it can be restored to the point in time
when the snapshot was created by specifying the snapshot as the source of the restore operation. Remember that if multiple snapshots exist, the database cannot be restored to a point in time before a snapshot
was created. Those snapshots will have to be dropped first. The following command demonstrates how
to restore the SmallWorks database from a database snapshot:
USE MASTER
GO
RESTORE DATABASE SmallWorks
FROM DATABASE_SNAPSHOT = ‘SmallWorksSnapShot’
Summar y
In this chapter, we examined the different ways to back up and restore databases. We also took a look
at the different aspects of disaster recovery, which is most important to minimizing data loss and preserving our jobs. Hopefully, you have arrived at the planned conclusion to this chapter. That conclusion
is that it is all about planning. As database administrators we are ultimately responsible for maintaining
the integrity and security of the data entrusted to us. In order to accomplish this important goal, it is
imperative that we plan for disaster and, even more importantly, plan how to recover from any disaster
with the absolute minimum amount of data loss and downtime.
400
12:13pm
Page 400
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
10
Monitoring SQL Ser ver
One of the primary responsibilities of the database administrator is the ongoing monitoring of
SQL Server. Monitoring is done for a variety of reasons, including performance, storage, security,
and standards compliance. Much of this monitoring can be automated, but for the most part, the
monitoring results must be interpreted and acted on in a systematic approach by the DBA. The
monitoring job never ends, and it can become quite complex. Knowing what to monitor, when
to monitor, and what constitutes acceptable and unacceptable behavior can become a full-time
job. Making things even more challenging is the fact that each SQL Server installation is different,
making a global recommendation about what indicators identify unacceptable and acceptable
performance very difficult.
This chapter explains the various tools used to monitor SQL Server and provides guidelines on how
to use these tools to identify potential security problems and areas for optimization. Monitoring
SQL Server can be a challenging process. SQL Server interacts heavily with every operating system
subsystem. Some applications rely heavily on RAM, whereas others are CPU- or disk-intensive. SQL
Server can be all three at the same time. SQL Server can also be very network-intensive, especially
with distributed applications, replication, or database mirroring. Many database administrators
find the whole process of monitoring and optimizing arcane and nebulous. However, it doesn’t
have to be all that mysterious. A good understanding of the tools, as well as a familiarity with the
different objects requiring monitoring, will go a long way toward making your monitoring tasks
less intimidating.
Whole books have been written on the subject of monitoring, along with several web sites dedicated
to the subject. I won’t attempt to tell you everything you need to know about monitoring SQL Server
in this book, but I will describe the fundamentals, which, as in all things, is the best place to start.
Performance Monitoring
SQL Server 2008 performance monitoring can essentially be divided into five basic areas:
❑
System resources
❑
SQL Server itself
❑
The database
❑
The database application
❑
The network
Page 401
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Before getting into the specifics of performance monitoring, it is very important to understand the
methodology. Monitoring for the sake of monitoring is useless. You monitor your hardware and SQL
Server implementations to anticipate and prevent performance problems. To do this, you must have
some kind of plan — a strategy that will enable you to invest the right amount of time and the right
amount of resources to maintain and improve the performance of your SQL Server.
Performance Monitoring Strategy
The strategy for monitoring and optimizing SQL Server is fairly straightforward and is made up of the
following steps:
1.
Create a Performance Baseline — Without a baseline of your database server, it is very
unlikely that you will be able to make changes to the server platform with complete confidence that the changes will accomplish the improvements you are looking for. A baseline
contains measurements from all the systems previously mentioned (system resources, SQL
Server, the database, the database application, and the network). Specific counters and measurements are discussed later in this chapter. When evaluating the baseline, you may identify areas that warrant immediate optimization. If changes are made, a new baseline must be
created.
2.
Complete Periodic Performance Audits — After the baseline is completed, periodic performance audits are performed to ensure that performance has not degraded from when the
baseline was created. This step is often supplemented or replaced by reactive audits that are
performed in response to complaints of poor server performance. I prefer to be proactive and
schedule the audits, but there will invariably be times when a reactive audit will be required
because unexpected performance problems arise.
3.
Make Changes and Evaluate Their Impact — After performing audits, you may find areas
that require modification. When making these changes, it is important to be meticulous. As a
rule, you should not make multiple changes at once. Instead, make one or two changes, and
then evaluate the measurements that prompted the changes to be made. This makes it much
easier to identify what changes have the greatest impact on performance. Chapter 11 goes
into more detail on what specific changes you can make to optimize SQL Server when your
performance audit identifies a problem area.
4.
Reset the Baseline — After completing all the modifications, create another baseline to measure future performance trends.
The Mad Clicker
I work with a colleague that we affectionately call the ‘‘Mad Clicker.’’ When something
goes wrong in the server room, he invariably gets involved and starts clicking away,
making sweeping changes to configuration settings in an attempt to correct the problem. Often, he is successful, but it is next to impossible to duplicate his actions in the
future because even he doesn’t know everything he changed. Don’t be a ‘‘Mad Clicker.’’
Complete a modification, and then measure and document the results. This makes it
easy to duplicate and easy to roll back if the modifications resulted in a degradation of
performance instead of an improvement.
402
12:22pm
Page 402
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Creating a Performance Baseline
It is very important when creating a baseline that typical activity is monitored. Monitoring performance
during a monthly import may give you some interesting data, but it will not help you evaluate and
improve overall system performance. There are different ways of creating baselines. Most database
administrators have their own preferences on how to gather and compare performance data. They
also have their own favorite counters and system views that they feel give them insight into how the
database is performing. SQL Server performance monitoring and optimization is more of an art than a
science.
I have seen many different recommendations on what System Monitor counters to collect and what SQL
Server–specific activity to monitor. All of them were different. Some database administrators recommended monitoring everything, whereas others recommended monitoring a small selection of processes.
I support the small selection philosophy for two different reasons. The first is that there is definitely such
a thing as ‘‘too much information.’’ Collecting every conceivable bit of performance data will most likely
result in a case of not seeing the forest because of the trees. There is just too much data to sift through.
The second reason (and maybe even more importantly) is the performance factor.
Gathering performance information is not free. The more information you gather, the more it costs in
terms of performance. This creates an interesting paradox. To adequately monitor performance, you must
introduce performance-degrading actions to the database. The quandary that creates is one in which you
can never be completely positive that your monitoring actions are not at least marginally responsible for
unacceptable performance.
Limiting the data retrieved will reduce this uncertainty, but it is also important to keep in mind that you
should not look at any particular counter in isolation. For example, heavy disk activity might be caused
by memory limitations, and unsatisfactory CPU performance can be caused by poorly written queries
and missing indexes. No one subsystem exists in a vacuum.
So, what should you have in your baseline? Over the years, I have condensed the list of objects and processes that I monitor for baselines and performance audits. Those counters are described in the following
pages.
The main tool for creating a performance baseline is Performance Monitor. However, Dynamic Management Views (DMVs) are used as well to give more context to the baseline. After explaining the counters
used for a baseline and performance audits, this chapter digs deeper into the SQL Server–specific tools
and explores how to identify misbehaving processes.
Performance Counters
The following are some of the most useful counters to use when auditing performance. This discussion
is not meant to be all-inclusive. It is made up of the counters I and a few of my colleagues have come to
rely on for a ‘‘big picture’’ view of SQL Server performance. There are many more counters that can be
used to diagnose performance issues and to dig deeper into the nuts and bolts of SQL Server activity. But
these few will most likely provide the information you need to quickly evaluate the health of your server.
Processor Counters
Processor counters are used in conjunction with other counters to monitor and evaluate CPU performance
and identify CPU bottlenecks.
403
Page 403
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
❑
Processor: % Processor Time — The Processor: % Processor Time counter displays the total
percentage of time spent processing non-idle threads. On a multiple-processor machine, each
individual processor can be monitored independently. If the CPU affinity settings have been
customized, you may want to monitor a specific CPU. Other than that, I normally use the _total
instance identifier to see the combined processor utilization. CPU activity is a good indicator of
SQL Server CPU activity and is a key way to identify potential CPU bottlenecks. Recommendations on what this counter should look like vary. As a general rule, if total % Processor Time is
consistently greater than 70 percent, you probably have a CPU bottleneck, and you should look
at either optimizing current application processes, upgrading the CPU, or both. Use this counter
along with the Processor Queue Length counter to positively identify CPU bottlenecks.
❑
Process: % Processor Time (sqlservr) — The Process: % Processor Time counter (when set to
monitor information from the SQL Server process) can be used to determine how much of the
total processing time can be attributed to SQL Server.
❑
System: Processor Queue Length — The Processor Queue Length counter displays the number
of threads waiting to be processed by a CPU. If the average queue length is consistently greater
than two times the number of processors, then you may have a CPU bottleneck, because the processors can’t keep up with the number of requests.
Use the Processor Queue Length and the % Processor Time counters together to determine if you have a
CPU bottleneck. If both counters are out of acceptable ranges, there is most assuredly a CPU bottleneck.
If the Processor Queue Length is not within acceptable limits, but the % Processor Time is, you may
not have a CPU bottleneck, but a configuration problem instead. Ensure that the max worker threads
server setting has not been set to a value that is too high for your system. The default setting for
max worker threads is 0, which configures SQL Server to automatically set max worker threads in
accordance to the values shown in the following table. However, in addition to 0, it is possible to
configure any value between 128 and 32,767. SQL Server Books Online gives the acceptable range as 32
through 32,767, which is incorrect. The graphical interface will accept any value between 0 and 32,767,
but any value between 1 and 127 results in a setting of 128.
CPUs
32-bit
64-bit
1
256
512
2
256
512
4
256
512
8
288
576
16
352
704
32
480
960
Disk Counters
Several disk counters return disk Read and Write performance information, as well as data transfer
information, for each physical disk or all disks. Physical disk statistics, when combined with memory
statistics, give a very accurate view of total I/O performance on the server.
404
12:22pm
Page 404
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
❑
PhysicalDisk: Avg. Disk Queue Length — As the last mechanical component in modern
computer systems, the disk is inherently the slowest, even with the built-in memory cache that
virtually all disk controllers are configured with. The Avg. Disk Queue Length counter returns
the average number of Read and Write operations that were queued for an individual disk or
all disks. The requests are queued because the disk or disks are too busy, and the controller’s
onboard memory cache has no space to temporarily store the Read or Write request. This
counter should remain below the number of physical disks multiplied by two. For example, if
your database is located on a 10-disk array, the counter should remain below 20.
❑
If this counter is consistently greater than the desired value, the most likely cause is an inadequacy in the disk subsystem, or an inadequate amount of memory on the server. A lack of memory can cause the disk subsystem to be overworked by SQL Server’s inability to cache data in
memory for long periods of time, resulting in more physical disk Reads. Spreading the database
across multiple disks and multiple controllers may increase performance. Adding memory, if
possible, to the disk controller may also alleviate the disk bottleneck.
❑
PhysicalDisk: % Disk Time — This counter measures how busy a physical disk or hardware
disk array is. The % Disk Time counter shouldn’t consistently run at more than 60 percent. If it
does, check out the % Disk Read and % Disk Write counters to determine what type of activity
the disk is primarily performing. If more than one array is used for the database, this counter can
be used to determine if the disk workload is equally divided among all the arrays.
Memory Counters
As previously noted, memory counters (along with disk counters) are used by the DBA to get an overall
picture of database I/O. A lack of memory will have a direct impact on disk activity. When optimizing a
server, adding memory should always be considered. SQL Server loves memory and effectively allocates
it to minimize the amount of disk access required for database operations. If you are looking for a SQL
Server performance panacea, adding memory is as close as you’re going to get.
❑
Memory: Pages/Sec — The Pages/Sec counter measures the number of pages per second that
are paged out of memory to disk or paged into memory from disk. The official recommendation for this counter is that it should never be consistently greater than zero. In all likelihood,
it will regularly spike higher than zero, then return to near zero, and then spike high again, as
Figure 10-1 shows. This is perfectly normal, but if the counter is consistently above zero, it indicates a possible memory bottleneck. The solution, of course, is to add memory. However, it may
also be that the maximum server memory setting is set too low if there is plenty of memory on
the server. The memory counter Available Bytes will show how much memory is available on
the system.
Another possible cause of steady memory paging is an application other than SQL Server running on the same server. Ideally, SQL Server should be the only application supported by the
server. Sometimes this is not possible, but it is still the ideal configuration.
❑
Memory: Available Bytes — The Available Bytes counter indicates how much memory is available to processes. The official recommendation is that there should always be at least 5 MB of
available memory, but this is a particularly low number, and it should probably be at least 10
times as much.
❑
Process: Working Set (sqlservr) — The SQL Server instance of the Working Set counter shows
how much memory is in use by SQL Server. If this number is always lower than the minimum
server memory setting or significantly lower than the maximum server memory setting, SQL
405
Page 405
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Server is most likely configured to use too much memory. This is not necessarily a bad thing, as
long as it is not interfering with other server processes.
❑
SQL Server: Buffer Manager: Buffer Cache Hit Ratio — The Buffer Cache Hit Ratio counter
measures the percentage of time that data was found in the buffer without having to be read
from disk. This counter should be very high, optimally 90 percent or better. When it is less than
90 percent, disk I/O will be too high, putting an added burden on the disk subsystem.
❑
SQL Server: Buffer Manager: Page Life Expectancy — The Page Life Expectancy counter
returns the number of seconds a data page will stay in the buffer without being referenced by a
data operation. The minimum value for this counter is approximately 300 seconds. This counter,
along with the Buffer Cache Hit Ratio counter, is probably the best indicator of SQL Server
memory health. A higher number for both counters is better.
Figure 10-1: Spiking of number of pages in and out of memory to disk.
Network Counters
For most network counters, there is no hard-and-fast recommendation for what you should see. The only
guidance that can possibly be given is to ensure that the network traffic being generated on the server
406
12:22pm
Page 406
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
is well within the capacity of the network connection. Network counters, however, are a good way to
measure the network traffic over a period of time to evaluate trends to determine if some type of scaling
or load balancing may be in order.
❑
Network Interface: Bytes Total/Sec — The Bytes Total/Sec counter measures the total number
of bytes that are being sent back and forth between the server and the network. If the server is
configured exclusively for SQL Server, almost all of the traffic should belong to SQL Server. As
mentioned, this counter is very useful in analyzing network traffic trends. This information is
very useful for planning scale-out and upgrade requirements.
SQL Server Counters
After installing SQL Server, a plethora of SQL Server performance objects and counters are configured
to assist in the performance monitoring and optimization of SQL Server. If you are like 99 percent of
all database administrators, you will most likely never look at a majority of these counters. However,
there will be a special few that you will come to completely rely on. The following SQL Server–specific
counters are extraordinarily useful in the establishment of a baseline, and comparing activity against the
baseline to establish SQL Server performance health:
❑
SQL Server: General Statistics: User Connections — The User Connections counter displays
the number of user connections that are currently connected to SQL Server. This counter is especially useful in monitoring and tracking connection trends to ensure that the server is configured
to adequately handle all connections. Keep in mind that this counter displays the number of
user connections, not users. Some applications will create more than one connection per user,
whereas others may create only one connection but support multiple users.
❑
SQL Server: Locks: Average Wait Time — The Average Wait Time counter is an excellent
counter to monitor and track the average amount of time that user requests for data resources
have to wait because of concurrent blocks to the data. With the baseline and subsequent audits,
this counter will be a leading indicator of database application performance. However, it is just
an indicator. Resolving long-term locking requires running traces to record lock information.
Traces are discussed later in this chapter.
❑
SQL Server: Locks: Deadlocks/Sec — Deadlocks occur when two or more transactions hold a
lock on different resources and the transactions require access to the resources held by the opposing transaction. If this sounds very confusing, see the sidebar ‘‘Sample Events Resulting in a
Deadlock’’ for a simple example illustrating the sequence of events that results in a deadlock.
❑
SQL Server Access Methods: Page Splits/Sec — As described in Chapter 5, page splits occur
when SQL Server attempts to insert a row in a clustered or non-clustered index page, but there
is not sufficient space available to accommodate the new row. To maintain the contiguousness of
the index page, SQL Server splits about half of the data out of the original page and moves it to a
free page. This splitting of data is necessary to maintain the indexes, but it causes excessive I/O
because logically contiguous data is no longer physically contiguous. As more and more rows
are inserted, the fragmentation of data will become worse.
The Page Splits/Sec counter enables the monitoring of page split activity to determine how fast table
indexes are becoming fragmented. Although a certain amount of page splitting is normal, excessive
page splits will cause a steady deterioration of database performance. Chapter 5 explains how to detect,
correct, and mitigate this fragmentation.
407
Page 407
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
When monitoring page split activity, create a baseline shortly after rebuilding the indexes. As subsequent
performance audits are completed, compare the page split activity. When the counter begins to spike, it
is probably time for the indexes to be rebuilt again with an appropriate fill-factor.
Sample Events Resulting in a Deadlock
Two stored procedures are executed at the same time on separate connections. The
first stored procedure, Proc1, updates one or more rows in TableA. The second stored
procedure, Proc2, updates one or more rows in TableB. At this time, Proc1 has an
exclusive lock on the updated rows in TableA, and Proc2 has an exclusive lock on the
rows in TableB.
Next, Proc1 attempts to update the same rows in TableB that Proc2 has updated. It
will not be able to, because Proc2 already has an exclusive lock. At this point, Proc1 is
blocked by Proc2. Proc2 then attempts to update the rows that Proc1 has updated and
is also blocked. This mutual blocking is a deadlock.
SQL Server does not allow deadlocks to continue. The Database Engine monitors for
deadlocks, and, if one is detected, it will select a victim process and kill that process.
The error raised by a terminated deadlock looks like the following message:
Msg 1205, Level 13, State 51, Line 6
Transaction (Process ID 53) was deadlocked on lock
resources with another process and has been chosen as the
deadlock victim. Rerun the transaction.
The selection process is based on cost. Whichever process would cost the least to roll
back is terminated, and the remaining process or processes are allowed to continue. The
most significant cause of deadlocks is the updating of tables in an inconsistent process.
When database developers are creating procedures for data modification, they should
update multiple objects in the same order whenever possible. For example, if Proc1
and Proc2 both update TableA first, and then TableB, a short-term blocking lock may
have occurred, but a deadlock would not have.
Deadlocks may occur occasionally, but they should not be a regular occurrence. Because
they are automatically detected and killed, they are sometimes difficult to troubleshoot.
The Profiler tool can be used to identify the offending processes involved in a deadlock,
as discussed later in this chapter.
Dynamic Management Views
SQL Server 2008 provides many Dynamic Management Views (DMVs) that can be used in the gathering
of baseline information and for diagnosing performance problems. Some of these views offer the same
information as performance counters, but in a relational and instantaneous format. Other views provide
more specific database performance information. I won’t try to cover all the views in this section, but the
following views can prove very helpful in the creation and comparison of performance baselines:
❑
408
sys.dm_os_performance_counters — A very interesting Dynamic Management View as far as
operating system information is concerned is sys.dm_os_performance_counters. This view
provides much the same information as Performance Monitor, except that the information is
returned in a relational format and the values returned are instantaneous. Because the data is
12:22pm
Page 408
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
instantaneous, per-second counters will have to be queried at least twice to determine their true
value. The columns that are returned by this view are described in the following table:
Column Name
Description
object_name
Counter category, such as SQLServer:Wait Statistics or
SQLServer:Buffer Manager
counter_name
Name of the counter
Instance_name
Name of the counter instance, such as database name or instance
description. Server-level counters will not have an instance value.
cntr_value
Instantaneous value of the counter
cntr_type
Counter types fall into the following type categories:
65792
Numeric (integer) counter
1073874176
Average value counter
1073939712
Base value counter
272696576
Per second counter
537003264
Ratio value counter
❑
sys.dm_db_index_physical_stats — As described in Chapter 5, this view returns information about the indexes on a table, including the amount of data on each data page, the amount
of fragmentation at the leaf and non-leaf level of the indexes, and the average size of records in
an index.
❑
sys.dm_db_index_usage_stats — The sys.dm_db_index_usage_stats view collects cumulative index usage data. This view can be used to identify which indexes are seldom referenced
and, thus, may be increasing overhead without improving Read performance. The following
code example demonstrates one possible use of this view by joining it with the sys.indexes
system view to return the index name, table name, and index usage information:
USE AdventureWorks2008;
GO
SELECT object_name(S.object_id) AS TableName
,I.name AS IndexName, S.user_seeks AS Seeks
,S.user_scans AS Scans, S.user_updates AS Updates
,S.last_user_seek AS LastSeek, S.last_user_scan AS LastScan
FROM sys.dm_db_index_usage_stats S
JOIN sys.indexes I ON S.object_id = I.object_id
AND S.index_id = I.index_id
WHERE S.object_id > 100000 --Return only user owned index data
ORDER BY Seeks, Scans;
Tools and Techniques for Monitoring
Chapter 3 described many of the tools available from a feature point of view. This chapter examines the
tools from an implementation point of view and discusses how to use them to actually perform some
409
Page 409
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
key database-monitoring tasks. The discussion also examines a few more tools that were not described in
Chapter 3, because they are intricately tied in to SQL Server Management Studio.
Log File Viewer
The Log File Viewer is an excellent tool for the viewing of SQL Server and operating system logs in a
one-time correlated view. For example, memory subsystem errors from the system log can be correlated
with SQL Server errors, indicating out-of-memory conditions and allowing you to isolate the problem
away from SQL Server. To open the Log File Viewer, expand the Management folder in SQL Server
Management Studio, expand SQL Server Logs, right-click on the log you want to view, and select ‘‘View
SQL Server Log.’’ Once the Log File Viewer is open, you can choose to open additional SQL Server logs
and/or operating system logs by expanding and selecting the logs you want to review (see Figure 10-2).
Notice that you can also open up log files for the SQL Server Agent and Database Mail.
Figure 10-2: Log File Viewer.
SQL Server and SQL Server Agent log files are closed and a new log is opened every time the respective
service is restarted. In a production system this may not occur very often, resulting in a large log file. To
avoid unacceptably large log files, the contents of the log files should be exported and the files cycled.
To cycle the SQL Server Log, execute the sp_cycle_errorlog stored procedure. To cycle the Agent Log,
the sp_cycle_agent_errorlog stored procedure is used. These procedures clear the contents of the logs
without requiring a service restart.
The number of logs that SQL Server keeps can be configured by right-clicking on the SQL Server Logs
folder and selecting Configure (see Figure 10-3). The minimum and default number of logs is 6, but it can
be increased to as many as 99. The number cannot be less than 6.
410
12:22pm
Page 410
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Figure 10-3: Configuring log files.
Activity Monitor
Microsoft bundled a surprise with the final release candidate of SQL Server 2008 when they included a
completely overhauled Activity Monitor. This was a surprise to the community because Activity Monitor
was moved from its traditional location, leading a number of concerned DBAs to flood the support
forums with postings. Apparently this was also a surprise to the Microsoft Books Online team, whom as
of this writing were still referencing the documentation for the old Activity Monitor!
Activity Monitor in SQL Server 2008 is now a feature-rich, near-real-time, graphical performance dashboard. The new Activity Monitor has a similar look and feel to the system Reliability and Performance
Monitor included in Vista and Server 2008. The first thing that experienced DBAs will notice is that Activity Monitor is no longer located in the Management node of SQL Server Management Studio. Now you
will find Activity Monitor on the context menu of a SQL Server instance.
Activity Monitor is a great tool for gaining a deeper understanding of the overall health and performance
of your server. Compared to prior versions, it is no longer limited to displaying simple process and lock
information. Activity Monitor now shows intuitive graphs, detailed process and lock information, file
I/O statistics, and information about long-running queries. In addition, all of the grid views can now be
sorted and filtered. Activity Monitor cannot replace a good set of Data Management Views in the hands
of an experienced DBA, but it is very useful in answering the basic question ‘‘Why is my server running
slowly?’’
In order to run Activity Monitor, you will need the view server state permission. To kill any processes,
you will also need to be a member of either the sysadmin or processadmin server roles. The new Activity
Monitor will work on SQL Server 2005, but not on prior versions.
411
Page 411
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Activity Monitor is comprised of five major sections, titled Overview, Processes, Resource Waits, Data
File I/O, and Recent Expensive Queries:
❑
Overview — The Overview section displays four near-real-time graphs that represent key performance metrics. Right-clicking on a graph will allow you to adjust the refresh rate or pause
data collection.
❑
Processes — The Processes section lists a row for every connection to SQL Server, along with
several columns describing the process (such as the user associated with the connection, the
database context, and the command presently running, as well as any wait status and blocking information). Right-clicking on a process and selecting Details will bring up the last command executed on that connection and provide the capability to kill the process, if necessary.
Right-clicking on a process will display a context menu with the option to trace the process in
SQL Server Profiler. Figure 10-4 illustrates this behavior. Also notice in Figure 10-4 that Process
59 is suspended, because it is waiting on the resource that is locked by Process 57, which, in turn,
is waiting on the resource that is locked by Process 60.
Figure 10-4: Processes.
❑
412
Resource Waits — The Resource Waits section displays a complete list of all resource waits
(CPU, Latch, Memory, Buffer I/O, etc.). This list does not provide any drill-in capability, but you
can filter and sort the results.
12:22pm
Page 412
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
❑
Data File I/O — The Data File I/O section displays file activity totals by database file. The list
can be filtered and sorted.
❑
Recent Expensive Queries — This is a welcome addition to the Activity Monitor! The Recent
Expensive Queries section shows all recent, costly queries and allows you to open the complete
query statement or the detailed execution plan in a new Query window. Figure 10-5 displays this
section and shows the context menu options for an expensive query.
Figure 10-5: Recent Expensive Queries.
By default, Activity Monitor will refresh the display every 10 seconds. To configure Activity Monitor for
a different refresh rate, right-click on any of the graphs, and select the desired Refresh Interval or select
Pause to disable refreshing. Keep in mind that frequent refreshing of process information can cause
degradation of SQL Server’s performance.
System Stored Procedures
Although Activity Monitor is a great graphical tool to view processes and the resources they are using,
often the simpler output of System Stored Procedures is more appropriate for identifying current processes and identifying any contention.
413
Page 413
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
sp_who and sp_who2
The sp_who2 stored procedure is an undocumented system procedure that offers a distinct advantage
over its documented sibling procedure, sp_who. They both return information about current SQL Server
processes, but the sp_who2 procedure’s information is more comprehensive.
These stored procedures are essentially equivalent to Activity Monitor’s Processes page. The output of
sp_who or sp_who2 can be restricted by specifying a process ID as an input parameter. The syntax of the
sp_who and sp_who2 procedures is as follows:
sp_who [process_ID] | login_name | [ACTIVE]
sp_who2 [process_ID] | [ACTIVE]
The sp_who stored procedure returns nine columns described in the following table:
Column Name
Description
spid
Server Process ID. The spid represents the session ID of the connection.
Every connection has one spid.
ecid
Execution Context ID. The ecid value indicates what thread the process
was executed on. An ecid of 0 indicates that the process was executed on
the main thread.
status
The status of the session. Possible status values are as follows:
Running — The session is performing some work.
Runnable — The session has performed some work, but it cur-
rently has no work to perform.
Sleeping — The session is waiting to perform work.
Background — Background processes (typically those owned by
the system) that periodically activate to perform an action
Suspended — The session has work to do but has been stopped
because it is waiting for a process (such as I/O) to complete.
Dormant — The session is being re-set by SQL Server.
Rollback — The session is currently rolling back a transaction.
Pending — The session is waiting on an available thread.
Spinloop — The session is waiting on a spinlock to become free.
Spinlocks are used for fast protection of critical memory regions
on multi-CPU machines.
414
loginame
The login associated with the session
hostname
Host name associated with the session
blk
The spid of the session that is blocking the session if one exists. If not, a
0 is returned.
12:22pm
Page 414
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Column Name
Description
dbname
The name of the database connected to by the session
cmd
The type of command executing on the session
request_id
The integer identifier of the request running in the session
The sp_who2 stored procedure returns 13 columns, although it returns one column, spid, twice — once
on the left side of the result set and once on the right to make the result set easier to read. The columns
are described in the following table:
Column Name
Description
SPID
Server Process ID. The spid represents the session ID of the connection.
Every connection has one spid.
Status
The status information is the same as for the sp_who command.
Login
The login associated with the session
HostName
Host name associated with the session
BlkBy
The spid of the session that is blocking the session if one exists
DBName
The name of the database connected to by the session
Command
The type of command executing on the session
CPUTime
The cumulative CPU usage for this process
DiskIO
The cumulative Disk I/O for this process
LastBatch
The last time the client process executed a remote stored procedure call
or an EXECUTE statement. If the process is a system process, the time is
the time that SQL Server was last started.
ProgramName
The name of the application (if reported) associated with the session
(e.g., Microsoft SQL Server Management Studio)
SPID
Duplicate of the spid recorded in the first column of the results
REQUESTID
The integer identifier of the request running in the session
When the ‘‘Active’’ option is added to sp_who or sp_who2, SQL Server does not return any session that
has the Command of ‘‘Awaiting Command,’’ which specifies that the session is waiting on input from a
user process.
sp_lock
The sp_lock stored procedure returns the number and types of locks held by active database processes.
The object locked or requested to be locked is returned with the lock status and any identifying information (such as the object’s integer identifier), along with the index ID, if any.
415
Page 415
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
SQL Server Locking
To interpret the information returned by sp_lock, it is important to understand the lockable resource
types and the modes these locks can take. The possible resource types are described in the following
table:
Resource Type
Description
RID
A RID lock is a row lock on a heap. The identifier is in the format
FileID:PageNumber:RID, where FileID is the data file containing the
row, PageNumber is the integer identifier of the 8K data page, and RID
identifies the specific row on the data page.
KEY
A KEY lock is a row-level lock when a clustered index exists. The KEY is a
hexadecimal number that the Database Engine uses internally to track
individual clustered index keys.
PAG
PAG indicates that the lock is requested or held on an 8-K data page. The
value of PAG is the combination of the data file FileID and the integer
identifier of the data page.
EXT
An EXT lock is a lock of an entire 64-K extent. The value of EXT is the data
file FileID and the identifier of the first page on the extent.
TAB
TAB locks are table locks. No resource information is returned for TAB
locks because the ObjID column already contains the Object_ID of the
table.
DB
DB indicates a database lock. No resource information is returned for DB
locks because the dbid column already contains the identifier for the
database locked.
APP
APP indicates a lock request held on an application resource. Application
locks are issued explicitly through the use of the sp_getapplock stored
procedure and are fairly rare.
FIL
A FIL lock is a lock held on a data file. The resource information contains
the integer value of the file identifier.
MD
MD locks are metadata locks. MD locks are typically on XML collection data.
HBT
A lock on a Heap or B-Tree index
AU
A lock on an Allocation Unit
Locks on resource types are requested and granted by mode. The sp_lock stored procedure returns
information that identifies the mode of the lock (e.g., whether the lock is a shared or exclusive lock). The
following table describes the most common modes:
416
12:22pm
Page 416
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Lock Mode
Description
Sch-S
Shared Schema Lock — Prevents processes from altering the schema of
a resource while it is in use. The Sch-S lock mode is compatible with
other shared locks.
Sch-M
Schema Modification Lock — Required to modify the schema of a
resource. This lock mode is not compatible with any other lock mode.
S
Shared Lock — A Shared lock is compatible with all other locks except
Exclusive locks.
U
Update Lock — An Update lock is used to prevent deadlocks by
specifying that a resource is locked for eventual updating.
X
Exclusive Lock — For any resource that is being modified, created, or
dropped, a process will have an Exclusive lock during the modification.
IS
Intent Shared Lock — Intent locks are used on resources higher in the
resource hierarchy to prevent more exclusive locks from being issued.
For example, an Intent Shared lock can be placed on a data page if an
individual row is being read. This prevents an Exclusive lock from being
placed on the page and trapping the shared process. Intent Shared locks
are compatible with all locks except Exclusive.
IU
Intent Update Lock — These locks function in the same way as Intent
Shared locks to prevent more exclusive locks from being granted higher
in the resource hierarchy. Intent Update locks are compatible with all
locks except Update and Exclusive.
IX
Intent Exclusive Lock — These locks work the same as the other two
Intent locks. Intent Exclusive locks are only compatible with other Intent
Exclusive locks.
SIU
Shared Intent Update — The SIU lock mode is a combination of the
Shared and Intent Update locks. It is compatible with all other locks
except Exclusive, Intent Exclusive, Shared with Intent Exclusive, and
Update with Intent Exclusive.
SIX
Shared with Intent Exclusive — The SIX lock mode is less restrictive
than the IX lock mode and allows for compatible shared locks higher in
the resource hierarchy.
UIX
Update with Intent Exclusive — The UIX lock mode is a combination of
the Update and Intent Exclusive locks. It is only compatible with Intent
Shared locks.
BU
Bulk Update — Bulk Update locks are issued to bulk load table
operation processes when the TABLOCK hint is used or when the
Table Lock On Bulk Load table option is set. Bulk Update locks are
incompatible with all locks except other Bulk Update locks.
417
Page 417
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
KILL
Although not a stored procedure, the KILL command enables the database administrator to kill an offending process just like the ‘‘Kill Process’’ button on the Process Property dialog shown in Figure 10-4. The
syntax for the KILL command is as follows:
KILL spid
The KILL command is very useful, but it should be used with great caution. Although it is sometimes
necessary to kill a stalled process, it is very important to gather as much information as possible about
that process before killing it. For example, killing a transaction that has updated a thousand rows will
result in a thousand row rollbacks, resulting in some undesired consequences such as a full transaction
log or lost data.
Try It Out
System Stored Procedures
Take a look at what information is returned by the System Stored Procedures and how you can use them
to isolate troublesome processes.
1.
Open a Query window. Type and execute the following code:
USE AdventureWorks2008;
GO
BEGIN TRAN
UPDATE Person.Person
SET LastName = ‘Gates’
WHERE BusinessEntityID = 1;
2.
Open a second Query window. Type and execute the following code:
USE AdventureWorks2008;
GO
SELECT * FROM Person.Person
WHERE BusinessEntityID = 1;
You will not see any results returned when executing this statement. It will not complete until the
first query releases its locks.
3.
Open a third Query window and run the sp_who System Stored Procedure by executing the following command:
EXEC sp_who;
Notice that one of the processes shows that it is being blocked by another session. In the case
shown in Figure 10-6, SPID 59 is being blocked by SPID 60.
4.
Execute the sp_who2 stored procedure, but restrict the result set to the Server Process ID (SPID)
that is responsible for the block in progress. In my case, the spid is 60.
EXEC sp_who2 60;
418
12:22pm
Page 418
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Figure 10-6: Result of running sp_who System Stored Procedure.
The more comprehensive results of the sp_who2 stored procedure execution return very useful
information (such as the program and user responsible, as well as when the session executed the
command responsible for the lock contention).
5.
Identify what object is being contested by the two processes. Execute the sp_lock stored procedure. The results of this procedure, like the sp_who and sp_who2 stored procedures, can be
restricted by passing in the appropriate process ID.
6.
Type and execute the following command to display the information about the SPID being
blocked. This is the SPID that returned a value in the BlkBy column of the sp_who2 results. For
me, it was 59, but remember that your SPID will most likely be different:
EXEC sp_lock 59;
The results are shown in Figure 10-7.
Figure 10-7: sp_lock results.
In Figure 10-7, notice that several locks have been requested and granted, but the shared lock on the
clustered index key 010086470766 (which represents the contact in the Person.Person table with the
419
Page 419
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
BusinessEntityID of 1) is in a WAIT status. This is because spid 60 is currently modifying that particular
row and has an exclusive lock on that key.
To terminate the blocking process, execute the KILL command specifying the appropriate SPID, which,
for me, is 60:
KILL 60;
Use caution when killing a process. SPID 60 is the process on my computer. Your results may vary!
Using Profiler
Chapter 3 described the basic features of Profiler. This section shows you how to gather performance
information to isolate and correct database application problems. The guidelines for the traces provided
can be combined into a comprehensive trace or run individually.
Another important consideration for using Profiler is overhead. Running Profiler interactively can create a great deal of server overhead and create a large uncertainty factor. Profiler is just a graphical
interface for viewing the results of a SQL trace. It is an excellent tool, but for large databases with a
heavy transaction load, you will probably want to use the sp_trace_setevent, sp_trace_setfilter,
sp_trace_setstatus, and sp_trace_create stored procedures to create, configure, and run traces with
the trace data collected in files. The data can then be viewed using Profiler straight from the collected
files, or you can import the data into a database for analysis.
Try It Out
Analyzing Deadlocks with Profiler
As mentioned earlier, detecting deadlocks is easy using Performance Monitor. Finding out why deadlocks are happening is more difficult and requires the running of traces and examining the data collected
with Profiler.
1.
Open SQL Server Management Studio, and connect to a server that hosts the
AdventureWorks2008 database. After connecting, launch SQL Server Profiler from the
Tools menu, and create a new trace based on the Blank template, as shown in Figure 10-8.
2.
On the Events Selection tab, select the Lock events Deadlock graph and Lock:Deadlock Chain,
as shown in Figure 10-9. Notice that when Deadlock graph is selected, the Events Extraction Settings tab appears.
3.
To limit the data returned to Profiler, click on the ‘‘Column Filters’’ button, and then select
Database Name. In the ‘‘Not Like’’ box, enter MSDB to prevent SQL Agent and scheduled
monitoring activity from being traced. Click OK.
Figure 10-10 shows the desired configuration. Be careful when filtering databases. It may seem
like the best filter would be one that specifies only a particular database by creating the filter
where the database ID or database name is like a specific value. However, there are many Profiler
events that do not have a specific database context, and these will not display if you set the filter
this way. Instead, you must tell Profiler what databases you don’t want to monitor. The deadlock
graph is one such event.
420
12:22pm
Page 420
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Figure 10-8: Creating a new trace based on the Blank template.
Figure 10-9: Selecting Deadlock graph and Lock:Deadlock Chain.
421
Page 421
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Figure 10-10: Desired configuration.
4.
In the Event Extraction Settings tab, check the ‘‘Save Deadlock XML events separately’’ checkbox, and enter a destination to save the files (see Figure 10-11). Select the option to save ‘‘Each
Deadlock XML batch in a distinct file,’’ and click Run.
Figure 10-11: Entering a destination to save the files.
422
12:22pm
Page 422
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
5.
6.
In SQL Server Management Studio, open two new Query windows.
In the first Query window (which is probably called SQLQuery1.sql), type the following code and
execute it:
--Connection 1
USE AdventureWorks2008;
GO
BEGIN TRAN
UPDATE Person.Address
SET City = ‘Redmond’
WHERE AddressID = 1;
7.
In the second Query window, type the following code and execute it:
--Connection 2
USE AdventureWorks2008;
GO
BEGIN TRAN
UPDATE Person.Person
SET LastName = ‘Gates’
WHERE BusinessEntityID = 1;
UPDATE Person.Address
SET AddressLine1 = ‘1 Microsoft Way’
WHERE AddressID = 1;
This update will not complete because the transaction in Connection 1 has an exclusive lock
on the row being updated in the Person.Person table. What is occurring at this point is a
blocking lock. The transaction in Connection 2 wants to update the row that is being locked by
Connection 1. Blocking locks are allowed and will continue indefinitely unless a lock time-out
has been set, the blocking transaction completes, or an administrator terminates the blocking
transaction.
8.
On the first connection, write and execute the following code to update the Person.Person table:
--Connection 1
UPDATE Person.Person
SET FirstName = ‘Bill’
WHERE BusinessEntityID = 1;
This update causes a deadlock to occur because both connections hold exclusive locks on
resources that the opposing transaction requires to complete. The deadlock is detected and one
of the deadlocked processes is killed (the deadlock victim). The remaining process will then
succeed.
9.
Return to Profiler, stop the trace, and select the Deadlock graph event class row. The deadlock
graph shows the server process IDs and locked resources that were deadlocked. Hovering the
mouse over one of the processes will expose the process that participated in the deadlock, as
shown in Figure 10-12.
423
Page 423
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Figure 10-12: Exposing the process that participated in the deadlock.
To restore the Person.Person table to its original state, be sure to execute a ROLLBACK statement on the transaction not killed by the deadlock.
10.
To capture the script that was used to run this trace, click on the File menu within SQL Profiler,
and select the Export Script Trace Definition For SQL Server 2005–2008 (see Figure 10-13). A
‘‘Save as’’ dialog will be displayed. Save the script as DeadLockTrace.SQL.
11.
Open the DeadLockTrace.SQL file that you just saved with SQL Server Management Studio. This
is the script that SQL Server ran to create the trace you just practiced. By saving this script, it
can be run at any time without having to launch and run Profiler. For more information about
each of the stored procedures, consult SQL Server Books Online, which contains a very thorough
description of each procedure.
Once the trace file is captured, it can either be opened with SQL Profiler or, in the case of larger traces,
it can be inserted into a table for analysis with conventional T-SQL queries. To move the data into a
table, the fn_trace_gettable table-valued function can be used. This table-valued function requires two
values: the name of the trace file to be imported and the maximum number of rollover files to collect.
The default for the number of files is the maximum number of files set with the trace. The following
example shows how the trace collected earlier can be added to a table called DeadLockTraceTable in the
AdventureWorks2008 database:
USE AdventureWorks2008;
GO
SELECT * INTO DeadLockTraceTable
FROM fn_trace_gettable(C:\ProfilerTraces\DeadLocks.trc’, NULL);
424
12:22pm
Page 424
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Figure 10-13: Export trace definition.
Detect and Analyze Long-Running Queries with Profiler
Profiler is a great tool for analyzing locks, as well as debugging stored procedures and database applications. It is also very useful in the identification and analysis of long-running queries that interfere with
the performance of SQL Server. Profiler can return query execution information that can be examined
by the database administrator to isolate the cause of the lengthy query. Is it poorly written? Are there no
indexes to support the query, or is it just a monster query?
Try It Out
Analyzing Queries
To analyze queries, follow these steps:
1.
Start Profiler and create a new trace called QueryTuning using the Blank template. Select the following events on the Events Selection tab:
❑
Performance: Showplan XML
425
Page 425
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
❑
Stored Procedures: SP:Completed
❑
TSQL: SQL:BatchCompleted
2.
Click on the ‘‘Column Filters’’ button, create a filter in which the database name is like
AdventureWorks2008, and click OK to apply the filter.
3.
Click on the ‘‘Organize Columns’’ button. Find the Duration column and move it up to the top of
the column list to make it easy to read duration data.
4.
On the Events Extraction Settings tab, select the ‘‘Save XML Showplan events separately’’ checkbox. Choose a destination to save the ShowPlan information, title the file QueryTuning, and then
choose the option to save each XML ShowPlan in a separate file. SQLPlan is the file extension
given to ShowPlan data. The ShowPlan data is stored as XML and can be viewed with Management Studio, as you will see later. When saving query plans in separate files, each file is given the
name of the file defined in the destination, along with a numerical identifier appended to the end
of the name.
5.
6.
Click Run to start the trace.
Next, open a new Query window in SQL Server Management Studio. Type and execute the following code:
USE AdventureWorks2008;
GO
SELECT P.ProductID, P.name AS Product, TH.TransactionDate,
SUM(TH.Quantity), SUM(TH.ActualCost), SUM(P.StandardCost)
FROM Production.Product P
INNER JOIN Production.TransactionHistory TH
ON P.ProductID = TH.ProductID
GROUP BY P.ProductID, P.Name, TH.TransactionDate;
GO
EXEC dbo.uspGetManagerEmployees 109;
GO
EXEC dbo.uspGetEmployeeManagers 1;
GO
SELECT P.name AS Product, SUM(SOD.OrderQty) AS SumQty
, SUM(SOD.UnitPrice) AS SumPrice, SUM(SOD.LineTotal) AS SumTotal
, CONVERT(char(10), SOH.OrderDate,101) AS orderDate
, CONVERT(char(10), SOH.ShipDate,101) AS ShipDate
, CONVERT(char(10), SOH.DueDate,101) AS DueDate
FROM Sales.SalesOrderDetail SOD
INNER JOIN Sales.SalesOrderHeader SOH
ON SOH.SalesOrderID = SOD.SalesOrderID
INNER JOIN Production.Product P
ON P.ProductID = SOD.ProductID
GROUP BY P.Name, SOH.OrderDate, SOH.ShipDate, SOH.DueDate;
After the query completes, stop the trace and examine the results. Notice that the longest-running
process is the last one that references the Sales.SalesOrderHeader, Sales.SalesOrderdetail,
and Production.Product tables.
7.
426
Navigate to the ShowPlan destination folder and examine the contents. You should see four files
named QueryTuning_1.SQLPlan through QueryTuning_4.SQLPlan.
12:22pm
Page 426
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
8.
Double-click on the QueryTuning_4.SQLPlan file. It will open with SQL Server Management Studio as a graphical execution plan, as shown in Figure 10-14.
Figure 10-14: SQL Server Management Studio as a graphical execution plan.
The ShowPlan files are very useful in evaluating the actual process that the Database Engine uses to
optimize queries and in identifying areas for improvement. The ShowPlans are read from right to left.
Hovering the mouse over an icon will display additional information about the process depicted, often
providing insight into how the process can be optimized. For example, if a process shows an unnecessary
implied conversion, the data types can be more strictly passed to avoid the implied conversion.
The information represented in Figure 10-14 is actually saved as XML. This is of particular interest to
organizations that want to consume the ShowPlan data with analysis applications such as the Database
Tuning Advisor that are built to analyze query plans and identify areas for improvement. Change
the name of the QueryTuning_4.SQLPlan to QueryTuning_4.XML. Right-click on the QueryTuning_4.XML file and choose ‘‘Open with ... Internet Explorer.’’ The ShowPlan file displayed is rendered
with Internet Explorer’s built-in XML parser and is readily identified as an XML file.
Monitoring Files
One of the more mundane (but imminently important) monitoring tasks for every database administrator is that of monitoring and managing file sizes. The default setting for both data files and log files is
to grow automatically with no maximum size. This is probably not the most ideal configuration. Generally, during the database design and planning phase, a determination of database size is made. This
determination should identify the starting size of the database files and the anticipated rate of growth of
each file type. However, unexpected growth, especially with the log file, is very typical. This makes the
monitoring of file sizes especially important. If a data file fills to capacity, no data modifications will be
allowed. The same goes for the log files.
Disk Usage Report
There are several ways to monitor database file sizes. The Disk Usage report in SQL Server Management
Studio (see Figure 10-15) is one. This report is very informative and can be used to find the tables that
427
Page 427
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
are consuming the most space, as well as index structures and files. The disadvantage of the Disk Usage
report is that you have to run the report to get it.
Figure 10-15: Disk Usage report.
sp_spaceused
The sp_spaceused stored procedure can also be used to return some of the same information as the Disk
Usage report, but the sp_spaceused stored procedure will only return space information for the entire
database if no object name parameter is passed with it or a single object. The following example shows
how to run sp_spaceused to retrieve information from the AdventureWorks2008 database and a table in
the AdventureWorks2008 database:
SET NOCOUNT ON;
USE AdventureWorks2008;
GO
SELECT ‘AdventureWorks2008 Space Used Data’
EXEC sp_spaceused; --Return total database size and available disk space
SELECT ‘Person.Person Space Used Data’
EXEC sp_spaceused ‘Person.Person’; --Return allocation data for Person.Person
The results of this script are as follows (your results will look a little different, because I formatted the
results to fit on the page):
-----------------------------AdventureWorks2008 Space Used Data
database_name
------------------
428
database_size
--------------
unallocated space
------------------
12:22pm
Page 428
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
AdventureWorks2008
198.06 MB
15.40 MB
reserved
data
index_size
unused
------------------ ------------------ ------------------ -----------------185000 KB
96312 KB
82112 KB
6576 KB
-----------------------------Person.Person Space Used Data
name
--------Person
rows
-------19972
reserved
--------83752 KB
data
--------30488 KB
index_size
------------52560 KB
unused
-----704 KB
sys.sysfiles
The system view sys.sysfiles is another great way to retrieve information about files in the database,
but the default data returned is not the most intuitive. For example, the size attribute is not a file size,
but the number of 8-K data pages, and the maxsize attribute returns -1 if no maximum size is specified.
To make the results more concise and readable, you can create a script like the one that follows:
SELECT Name, FileName
, CAST((Size * 8192 / 1048576) AS varchar(10)) + ‘MB’ AS FileSize
, MaxSize =
CASE MaxSize
WHEN -1 THEN ‘Unlimited’
ELSE CAST((Maxsize / 128) AS varchar(10)) + ‘MB’
END FROM sys.sysfiles;
The results of this query are simple and easy to understand (see Figure 10-16). They can also be consumed
by an application and programmatic decisions made based on the results.
Figure 10-16: Query results.
429
Page 429
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Monitoring Files with Performance Monitor
Probably the most efficient way of keeping abreast of the amount of free space in data and log files is
to use performance counters. The SQL Server:Databases performance object has several counters that
can be used to monitor disk and log file sizes. You can use these counters to create alerts as described
in Chapter 8. This way, SQL Server does the monitoring for you and sends you notifications when a
data file has exceeded a preconfigured size or the transaction log has filled to a percentage greater than a
certain value.
Auditing
At its root, auditing is simply the process of monitoring and tracking changes to a system. Increasingly,
DBAs are required to implement auditing to satisfy application security and business requirements.
Monitoring access to and changes to database data, in many cases, may be employed to satisfy industry
mandatory compliance in terms of HIPAA, SOX, and other regulatory measures.
Auditing is one of those topics that is very simple conceptually, but traditionally has been very difficult
in practice, often requiring custom solutions and extensive commitments of time and resources, with
varying degrees of success. SQL Server 2008 aims to change that by making auditing a more integrated,
standardized, and automated task, while at the same time increasing audit reliability and reducing the
overall system overhead.
At the core of the new auditing capabilities, SQL Server 2008 introduces the SQL Server Extended Events
engine. The Extended Events engine potentially allows any process to define and raise events, and consumers to receive events. Events are handled in a completely decoupled fashion, allowing a single event
to be efficiently dispatched to multiple consumers while ensuring that events are never lost.
With the wide variety of auditing tools available in SQL Server, a database administrator is able to easily
craft a comprehensive, customized auditing strategy to meet the needs of his particular organization.
In this section, I will introduce the various auditing tools and processes and attempt to give you some
insight on how you can use them effectively in your environment.
SQL Server Audit
SQL Server 2008 Enterprise Edition introduces a new automatic auditing option known as SQL Server
Audit. An SQL Server Audit is made up of a number of different elements working together to track and
log events that occur on the system. The elements are known as the SQL Server Audit Package, the Server
Audit Specification, the Database Audit Specification, and the Audit Destination (also known as the target).
To understand the elements that make up an SQL Server Audit and how they interact, it is useful to
compare it to a more well-known construct — a report. A report is the output generated by combining a
report definition with a data source. Similarly, an audit is the output generated by combining an audit
object with an audit specification.
The term audit can be a bit confusing because the same word is used in many
different contexts. SQL Server uses the term audit to describe the audit package, the
auditing process itself, and the output of the auditing process! It is no wonder that
the terminology can cause some confusion.
430
12:22pm
Page 430
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
The basic process for creating a SQL Server Audit is as follows:
1.
2.
Create a SQL Server Audit Package and define a destination for the output.
3.
4.
5.
Enable the Audit Specification(s).
Create a Server Audit Specification and/or one or more Database Audit Specifications that
define the audit event criteria.
Enable the Audit.
View and analyze the captured audit events. Depending on the audit destination, results can
be viewed using the Windows Event Viewer, the Log File Viewer in the SQL Server Management Console, or by using the fn_get_audit_file function.
Before actually creating an audit, I will go over each element in a little more detail. Then I will present an
example that ties it all together.
Audit Package
An Audit Package defines an audit, acts as the event consumer for captured audit events, and directs the
captured events to a target destination. Audit Packages can be managed from the Security Audits
folder of a server instance.
In addition to the target, there are only two other settings that you can change:
❑
Queue Delay — This setting indicates the number of milliseconds to buffer events before forcing
them to be processed. The default value is 1,000 (1 second). Setting this value to zero will force
events to be processed immediately. Buffering helps to minimize the performance impact of the
audit on the server, so in most cases I recommend leaving it at the default value.
❑
Shut Down Server on Audit Log Failure — When this flag is set, SQL Server will shut down if it
is unable to write events to the target. Most commonly, this occurs when the disk volume where
the logs are being written runs out of space. It is important to mention that if this flag is set and
you run out of log space, you will not be able to restart the server until you free up additional
space or start SQL Server using the -f flag to disable auditing.
An Audit Package can contain at most one server audit specification and one database audit specification
for each database. If necessary, you can create multiple audits that each map to a different specification.
Audit Packages are always created in the disabled state. Enabling the Audit Package will allow it to send
captured events to the target.
Server Audit Specification
A Server Audit Specification determines which server-level events should be included in the audit. Server
Audit Specifications are defined at the SQL Server instance level, so there can only be one per audit.
Server Audit Specifications are located in the Security Server Audit Specifications folder of each server
instance.
The Server Audit Specification can include multiple server-level action groups, where each group is a
pre-defined collection of related events. The specified events are included in the audit and saved to the
431
Page 431
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
destination. Most of the action groups have an equivalent security audit event category, as described
later in this chapter.
The following table shows the available server-level-only action groups and briefly describes the events
that are included:
Group
Description
SUCCESSFUL_LOGIN_GROUP
A principal (user or role) successfully logs in.
LOGOUT_GROUP
A principal logged out.
FAILED_LOGIN_GROUP
A principal failed to successfully log in.
LOGIN_CHANGE_PASSWORD_GROUP
The password is changed for any server login.
SERVER_ROLE_MEMBER_CHANGE_
GROUP
A login is added or removed from a fixed server
role.
BACKUP_RESTORE_GROUP
A backup or restore command is issued.
SERVER_OPERATION_GROUP
Any security audit operations are performed, such
as altering settings or resources.
SERVER_STATE_CHANGE_GROUP
The server service state is changed.
SERVER_OBJECT_CHANGE_GROUP
A CREATE, ALTER, or DROP command is used on a
server object.
SERVER_PRINCIPAL_CHANGE_GROUP
A server principal is created, altered, or dropped.
SERVER_PRINCIPAL_IMPERSONATION_
GROUP
Impersonation is used in a server context, such as
with Execute As <login>.
SERVER_PERMISSION_
CHANGE_GROUP
A GRANT, REVOKE, or DENY is issued for permissions
at the server scope, such as creating a login.
SERVER_OBJECT_PERMISSION_
CHANGE_GROUP
A GRANT, REVOKE, or DENY is issued for server object
permissions, such as when changing ownership.
BROKER_CONVERSATION_GROUP
An audit broker conversation is created.
BROKER_LOGON_GROUP
Audit messages related to Service Broker transport
security are reported.
DATABASE_MIRRORING_ACTION_
GROUP
Audit messages related to database mirroring
transport security are reported.
TRACE_CHANGE_GROUP
A trace is created, configured, or filtered.
In addition to the server-level-only action groups, you can also use any of the database action groups in
a Server Audit Specification. When you use a database action group at the server level, it applies to all
databases on the server. The database action groups are described in the next section.
432
12:22pm
Page 432
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Database Audit Specification
A Database Audit Specification works in the same way as a Server Audit Specification, but at the database
level. An audit can include one Database Audit Specification for each database on the server. Database
Audit Specifications can be managed from the Security Database Audit Specifications node of each
database. A Database Audit Specification can include multiple database-level action groups or single
audit events.
The following table shows the action groups that are available at the database level and briefly describes
which events they represent:
Group
Description
APPLICATION_ROLE_CHANGE_
PASSWORD_GROUP
An application role password is changed.
AUDIT_CHANGE_GROUP
An audit is created, modified, or deleted.
DATABASE_ROLE_MEMBER_
CHANGE_GROUP
A login is added or removed from a database role.
DATABASE_OPERATION_GROUP
Specific database operations occur, such as
checkpoint or subscribe query notification.
DATABASE_CHANGE_GROUP
A database is created, altered, or dropped.
DATABASE_OBJECT_CHANGE_GROUP
A CREATE, ALTER, or DROP statement is used on any
object in the database, including schemas.
DATABASE_PRINCIPAL_
CHANGE_GROUP
A user or role is created, modified, or dropped.
Password changes are included in this group.
DBCC_GROUP
Any DBCC command is issued.
SCHEMA_OBJECT_CHANGE_GROUP
A schema is created, altered, or dropped.
DATABASE_PRINCIPAL_
IMPERSONATION_GROUP
An impersonation event occurs in the database,
such as Execute As <Principal> or SETPRINCIPAL.
DATABASE_OWNERSHIP_
CHANGE_GROUP
The owner of a database is changed.
DATABASE_OBJECT_OWNERSHIP_
CHANGE_GROUP
The owner is changed for any object in a database.
SCHEMA_OBJECT_OWNERSHIP_
CHANGE_GROUP
When permission to change the owner of any object
is checked.
DATABASE_PERMISSION_
CHANGE_GROUP
Any database permission is changed, such as
granting access to a database.
DATABASE_OBJECT_PERMISSION_
CHANGE_GROUP
Permissions are changed for any object in a
database, including schemas.
Continued
433
Page 433
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Group
Description
SCHEMA_OBJECT_PERMISSION_
CHANGE_GROUP
When permission to change the permissions of any
object is checked
DATABASE_OBJECT_ACCESS_GROUP
Any access to any database or database object, such
as certificates or symmetric keys
SCHEMA_OBJECT_ACCESS_GROUP
Whenever an object permission is used in a schema
A powerful feature of the Database Audit Specification allows auditing of specific actions on specific
objects, performed by a specific principal (user or role). The actions that can be audited are DELETE,
EXECUTE, INSERT, RECEIVE, REFERENCES, SELECT, and UPDATE.
If you select a specific action in a Database Audit Specification, then you must also specify an object name
and a principal name. You can use the ‘‘public’’ principal to include all users and roles, since everyone
is automatically a member of ‘‘public.’’ You will not be able to save a specification that includes an
incomplete row.
Audit Destination
The audit destination (also known as the target of the audit) determines where the captured events will
be written. The destination of the audit can be one of the following:
❑
File — Saves the audit to a file. In addition to the file path, you can specify the maximum number
of rollover files, the maximum size of each file, and whether or not to reserve the necessary space.
The security of this selection will depend on the file system permissions that are assigned to the
file.
❑
Security Log — Writes the audited events to the Windows Security log. This is probably the best
choice for a high-security environment, but before selecting this destination, you will likely need
to modify a couple of system policies. Refer to the section below on targeting the security log for
more information.
❑
Application Log — Sets the audit destination to the Windows Application log. Remember when
choosing this destination that by default, the application log is readable by ordinary users. Some
audit information might be sensitive in nature and not fit for general consumption. This choice
may not be appropriate for a high-security environment.
Targeting the Security Log
In order to write events to the Security log, the SQL Server service account will need to be added to the
‘‘Generate Security Audits’’ policy, and the ‘‘Audit Object Access’’ security policy will need to be enabled
for both success and failure. This can be accomplished either from the security policy snap-in (secpol.msc)
or, in Windows Vista or Server 2008, by using the command-line audit policy program (auditpol.exe).
To enable targeting the security log using the security policy snap-in:
1.
2.
434
Open the security policy snap-in by entering secpol.msc in Start Run.
Expand ‘‘Local Policies,’’ and then click on ‘‘User Rights Assignment.’’
12:22pm
Page 434
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
3.
Open the ‘‘Generate Security Audits’’ policy, and add the SQL Server service account to the
local security setting.
4.
5.
Next, select ‘‘Audit Policy’’ from the left-hand pane.
6.
Close the security policy snap-in.
Open the ‘‘Audit Object Access’’ policy, and check both success and failure on the Local
Security setting tab.
By default, the Local System, Local Service, and Network Service are part of the Generate Security Audits
policy. If you are running SQL Server under one of these accounts, then you will only need to configure
the ‘‘Audit Object Access’’ policy.
Try It Out
Auditing Security Events
To audit security events, follow these steps:
1.
Open SQL Server Management Studio, and connect to the server that hosts the
AdventureWorks2008 database. Expand the Security node in Object Explorer, then right-click on
the Audits folder and select New Audit. Create the new audit as shown in Figure 10-17.
Figure 10-17: Creating a new Audit Package.
If the file path does not exist, you will receive an error when you click OK on the
Create Audit dialog. If necessary, you can leave the dialog open, use Explorer to
create the desired folder, and then complete the dialog.
435
Page 435
Leiter
c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
2.
Right-click on the Server Audit Specifications folder, and select New Server Audit Specification. In the Audit box, select the audit that you created above, and then add the following action
groups:
❑
SERVER_PRINCIPAL_CHANGE_GROUP
❑
SERVER_PRINCIPAL_IMPERSONATION_GROUP
❑
LOGIN_CHANGE_PASSWORD_GROUP
3.
Save the Audit Specification, and then right-click on it and select ‘‘Enable Server Audit Specification.’’ The icon on the Audit Specification should change to show that it is enabled.
4.
Expand the AdventureWorks2008 database, and create a new Database Audit Specification from
the Security Database Audit Specifications folder. Map this specification to the Audit Package
created above, and then add the following action groups as shown in Figure 10-18:
❑
SELECT: Object Class ‘‘Schema’’, Object Name ‘‘Person’’, Principal Name ‘‘public’’
❑
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
Figure 10-18: Creating a new Database Audit Specification.
5.
436
Save and enable the Audit Specification. The icon for the Database Audit Specification should
change to show that it is enabled.
12:22pm
Page 436
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
6.
Now enable the audit itself to begin receiving the included events. Once the audit is enabled, type
the following into a new Query window and execute it:
-- Create a new server login
EXEC sp_addlogin ‘Paul’, ‘Microsoft123’, ‘AdventureWorks2008’;
GO
-- Exclude this login from OS policy constraints
ALTER LOGIN Paul WITH CHECK_POLICY = OFF
GO
-- change password
EXEC sp_password @old = ‘Microsoft123’, @new = ‘Microsoft456’, @loginame =
‘Paul’
GO
-- Allow this user to access AdventureWorks2008
USE AdventureWorks2008
GO
CREATE USER Paul FOR LOGIN Paul
GO
-- Try to select as Paul, no permissions yet!
EXECUTE AS LOGIN=’Paul’
SELECT * FROM Person.Person WHERE BusinessEntityID=1;
REVERT
GO
-- Assign permissions
GRANT SELECT ON Person.Person TO Paul;
GO
-- Now the select should succeed
EXECUTE AS LOGIN=’Paul’
SELECT * FROM Person.Person WHERE BusinessEntityID=1;
REVERT
GO
-- Clean up
DROP USER Paul
GO
EXEC sp_droplogin ‘Paul’;
GO
Notice when you run the script that both a result set and an exception are displayed. This is
expected and is intended to highlight the ability of an audit to detect both successful and failed
access attempts. The exception was generated when user Paul attempted to read data from the
Person.Person table before permission was granted.
7.
Finally, disable the audit and then right-click on the audit and select ‘‘View Audit Logs’’ to display the results in the Log File Viewer. Your results should look similar to Figure 10-19.
437
Page 437
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
Figure 10-19: Viewing audit results using Log File Viewer.
Notice in the audit result that all the targeted events were captured; including the failed SELECT attempt.
You can also view audit results as a table by using the new fn_get_audit_file function. If you would
like to try this, execute the following code in a new Query window:
SELECT * FROM
fn_get_audit_file(’C:\SQLAudit\*’,default,default)
Login Auditing
The most fundamental auditing to manage and implement is Login Auditing. Login Auditing simply
records successful login attempts, failed login attempts, or both. Support for auditing logins is built into
SQL Server and can be enabled with the SQL Server Management Console from the security page of the
Server Properties dialog, as shown in Figure 10-20. After changing the login auditing level, you must
restart the server instance before the new setting will take effect.
Login success and failure events are written to the Windows Application Log as well as to the SQL Server
Log. Exactly the same information is written to both logs with one key exception. The SQL Server Log
receives an extra entry for a failed login that includes a special State code that describes in more detail
what caused the login failure. The most common state code values are listed in the following table:
438
12:22pm
Page 438
Leiter c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Error State
Error Description
2 or 5
Invalid user ID
6
Attempt to use a Windows login name with SQL authentication
7
Login disabled and password mismatch
8
Password mismatch
9
Invalid password
11 or 12
Login is valid, but user does not have any access to the server.
13
SQL Server service paused.
16
Login failed while trying to connect to the specified target database.
18
Password change is required.
23
Server is in the process of shutting down.
27
Unable to determine the initial database
Figure 10-20: Server Security Properties.
439
Page 439
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
C2 Audit Mode
C2 Audit Mode is a set of ratings originally established by the U.S. Department of Defense that applies
to levels of security in a computer system, based on their auditing and access control capabilities. SQL
Server has been C2-compliant since version 2000. This mode of operation may be required for government agencies and contractors.
C2 auditing goes beyond simple server events, such as login and logout, extending to include successful
and failed attempts to access all statements and objects. This can be of benefit when you are attempting
to identify possible security violations, but as you can imagine, it can also consume a massive amount of
storage as well as negatively affect performance. In a high-volume environment, the C2 logs will probably
be much larger than the database itself!
If you are using C2 Audit Mode and your server runs out of physical storage space for the log files, then
SQL Server will shut itself down to preserve the integrity of the audit. If this happens, you will not be
able to restart SQL Server until you either free up additional space or you disable auditing by using the
-f flag when starting the server instance.
To enable C2 Audit Mode, right-click on a server instance in SSMS Object Explorer, select Properties,
select the Security page, and check the ‘‘Enable C2 audit tracing’’ setting. To disable C2 Audit Mode,
clear the ‘‘Enable C2 audit tracing’’ checkbox. After changing this setting, you must restart your server
instance before it will take effect.
You can also enable or disable C2 Audit tracing using transact-SQL as follows:
-- Enable c2 audit mode
sp_configure ‘show advanced options’, 1
GO
RECONFIGURE
GO
sp_configure ‘c2 audit mode’, 1
GO
RECONFIGURE
GO
-- Disable c2 audit mode
sp_configure ‘show advanced options’, 1
GO
RECONFIGURE
GO
sp_configure ‘c2 audit mode’, 0
GO
RECONFIGURE
GO
As with the SMSS method, after changing the C2 Audit Mode setting, you must restart your server
instance before the change will take effect.
The C2 Audit log trace files are always stored in the server instance data directory. You can read these
files either by using SQL Server Profiler or with the sys.fn_trace_gettable system function.
440
12:22pm
Page 440
Leiter
c10.tex
V3 - 03/25/2009
12:22pm
Chapter 10: Monitoring SQL Server
Security Audit Event Category
If you like SQL Profiler as much as I do, you will be pleased to discover that you can use this ubiquitous
tool to monitor a wide variety of security audit events, such as successful and failed login attempts, new
users, and password changes. These events can all be found in the Security Audit section when selecting
the events to include in your trace.
The Security Audit Events allow you to selectively monitor much of the same information as a full C2
Audit, but when using SQL Profiler, you get to pick and choose exactly what you want to monitor and
only incur the overhead of monitoring when it is needed.
Try It Out
Auditing Security Events with SQL Server Profiler
To audit security events with SQL Server Profiler, follow these steps:
1.
Start SQL Server Profiler, and create a new trace called SecurityAudit using the Blank template.
Select the following events in the Security Audit section of the Events Selection tab:
❑
Audit Add DB User Event.
❑
Audit Add Member to DB Role Event.
❑
Audit Login Change Password Event.
❑
Audit Server Principal Management Event.
2.
Click the ‘‘Organize Columns’’ button. Find the EventSubClass, TargetLoginName,
TargetUserName, RoleName, and ObjectName columns, and move them to the top of the
column list just after the EventClass column to make it easier to read the results.
3.
4.
Click Run to start the trace.
Open a new Query window in SQL Server Management Studio. Type and execute the following
code:
-- Create a new server login
EXEC sp_addlogin ‘Paul’, ‘Microsoft123’, ‘AdventureWorks2008’;
GO
-- Exclude this login from OS policy constraints
ALTER LOGIN Paul WITH CHECK_POLICY = OFF
GO
-- change password
EXEC sp_password @old = ‘Microsoft123’, @new = ‘Microsoft456’, @loginame = ‘Paul’
GO
-- Allow this user to access AdventureWorks2008
USE AdventureWorks2008
GO
CREATE USER Paul FOR LOGIN Paul
GO
EXEC sp_addrolemember N’db_owner’, ‘Paul’
441
Page 441
Leiter c10.tex
V3 - 03/25/2009
Chapter 10: Monitoring SQL Server
GO
-- Clean up
DROP USER Paul
GO
EXEC sp_droplogin ‘Paul’;
GO
After the query completes, stop the trace and examine the results. Notice that each selected security
related event is recorded. Your output should look something like Figure 10-21.
Figure 10-21: Security Audit Trace.
As always, if you save the trace files, you can consume the trace data in a table in SQL Server by using
the sys.fn_trace_gettable system function.
SQL Trace
SQL Trace provides an alternative to using SQL Server Profiler to capture events. With SQL Trace, you
use System Stored Procedures to define traces in T-SQL. This is especially useful for organizations that
want to develop their own customized audit solutions.
The basic process for setting up a SQL Trace is as follows:
1.
2.
3.
442
Crea