Administering Microsoft® SQL Server® 2012 Database - Advanced ...

OFFICIAL MICROSOFT LEARNING PRODUCT 

10775A 

Administering Microsoft® 

SQL Server® 2012 Database

ii 10775A: Administering Microsoft SQL Server 2012 Databases 

Information in this document, including URL and other Internet Web site references, is subject to change 

without notice. Unless otherwise noted, the example companies, organizations, products, domain names, 

e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with 

any real company, organization, product, domain name, e-mail address, logo, person, place or event is 

intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the 

user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in 

or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, 

photocopying, recording, or otherwise), or for any purpose, without the express written permission of 

Microsoft Corporation. 

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property 

rights covering subject matter in this document. Except as expressly provided in any written license 

agreement from Microsoft, the furnishing of this document does not give you any license to these 

patents, trademarks, copyrights, or other intellectual property. 

The names of manufacturers, products, or URLs are provided for informational purposes only and 

Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding 

these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a 

manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links 

may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not 

responsible for the contents of any linked site or any link contained in a linked site, or any changes or 

updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission 

received from any linked site. Microsoft is providing these links to you only as a convenience, and the 

inclusion of any link does not imply endorsement of Microsoft of the site or the products contained 

therein. 

© 2012 Microsoft Corporation. All rights reserved. 

Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty 

/Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other trademarks are 

property of their respective owners 

Product Number: 10775A 

Part Number: X18-29125 

Released: 05/2012

MICROSOFT LICENSE TERMS 

OFFICIAL MICROSOFT LEARNING PRODUCTS 

MICROSOFT OFFICIAL COURSE Pre-Release and Final Release Versions 

These license terms are an agreement between Microsoft Corporation and you. Please read them. They apply to 

the Licensed Content named above, which includes the media on which you received it, if any. These license 

terms also apply to any updates, supplements, internet based services and support services for the Licensed 

Content, unless other terms accompany those items. If so, those terms apply. 

BY DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT 

THEM, DO NOT DOWNLOAD OR USE THE LICENSED CONTENT. 

If you comply with these license terms, you have the rights below. 

1. DEFINITIONS. 

a. “Authorized Learning Center” means a Microsoft Learning Competency Member, Microsoft IT Academy 

Program Member, or such other entity as Microsoft may designate from time to time. 

b. “Authorized Training Session” means the Microsoft-authorized instructor-led training class using only 

MOC Courses that are conducted by a MCT at or through an Authorized Learning Center. 

c. “Classroom Device” means one (1) dedicated, secure computer that you own or control that meets or 

exceeds the hardware level specified for the particular MOC Course located at your training facilities or 

primary business location. 

d. “End User” means an individual who is (i) duly enrolled for an Authorized Training Session or Private 

Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee. 

e. “Licensed Content” means the MOC Course and any other content accompanying this agreement. 

Licensed Content may include (i) Trainer Content, (ii) sample code, and (iii) associated media. 

f. “Microsoft Certified Trainer” or “MCT” means an individual who is (i) engaged to teach a training session 

to End Users on behalf of an Authorized Learning Center or MPN Member, (ii) currently certified as a 

Microsoft Certified Trainer under the Microsoft Certification Program, and (iii) holds a Microsoft 

Certification in the technology that is the subject of the training session. 

g. “Microsoft IT Academy Member” means a current, active member of the Microsoft IT Academy 

Program. 

h. “Microsoft Learning Competency Member” means a Microsoft Partner Network Program Member in 

good standing that currently holds the Learning Competency status. 

i. “Microsoft Official Course” or “MOC Course” means the Official Microsoft Learning Product instructorled 

courseware that educates IT professionals or developers on Microsoft technologies.

j. “Microsoft Partner Network Member” or “MPN Member” means a silver or gold-level Microsoft Partner 

Network program member in good standing. 

k. “Personal Device” means one (1) device, workstation or other digital electronic device that you 

personally own or control that meets or exceeds the hardware level specified for the particular MOC 

Course. 

l. “Private Training Session” means the instructor-led training classes provided by MPN Members for 

corporate customers to teach a predefined learning objective. These classes are not advertised or 

promoted to the general public and class attendance is restricted to individuals employed by or 

contracted by the corporate customer. 

m. “Trainer Content” means the trainer version of the MOC Course and additional content designated 

solely for trainers to use to teach a training session using a MOC Course. Trainer Content may include 

Microsoft PowerPoint presentations, instructor notes, lab setup guide, demonstration guides, beta 

feedback form and trainer preparation guide for the MOC Course. To clarify, Trainer Content does not 

include virtual hard disks or virtual machines. 

2. INSTALLATION AND USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is 

licensed on a one copy per user basis, such that you must acquire a license for each individual that 

accesses or uses the Licensed Content. 

2.1 Below are four separate sets of installation and use rights. Only one set of rights apply to you. 

a. If you are a Authorized Learning Center: 

i. If the Licensed Content is in digital format for each license you acquire you may either: 

1. install one (1) copy of the Licensed Content in the form provided to you on a dedicated, secure 

server located on your premises where the Authorized Training Session is held for access and 

use by one (1) End User attending the Authorized Training Session, or by one (1) MCT teaching 

the Authorized Training Session, or 

2. install one (1) copy of the Licensed Content in the form provided to you on one (1) Classroom 

Device for access and use by one (1) End User attending the Authorized Training Session, or by 

one (1) MCT teaching the Authorized Training Session. 

ii. You agree that: 

1. you will acquire a license for each End User and MCT that accesses the Licensed Content, 

2. each End User and MCT will be presented with a copy of this agreement and each individual 

will agree that their use of the Licensed Content will be subject to these license terms prior to 

their accessing the Licensed Content. Each individual will be required to denote their 

acceptance of the EULA in a manner that is enforceable under local law prior to their accessing 

the Licensed Content, 

3. for all Authorized Training Sessions, you will only use qualified MCTs who hold the applicable 

competency to teach the particular MOC Course that is the subject of the training session, 

4. you will not alter or remove any copyright or other protective notices contained in the 

Licensed Content,

5. you will remove and irretrievably delete all Licensed Content from all Classroom Devices and 

servers at the end of the Authorized Training Session, 

6. you will only provide access to the Licensed Content to End Users and MCTs, 

7. you will only provide access to the Trainer Content to MCTs, and 

8. any Licensed Content installed for use during a training session will be done in accordance 

with the applicable classroom set-up guide. 

b. If you are a MPN Member. 

i. If the Licensed Content is in digital format for each license you acquire you may either: 

1. install one (1) copy of the Licensed Content in the form provided to you on (A) one (1) 

Classroom Device, or (B) one (1) dedicated, secure server located at your premises where 

the training session is held for use by one (1) of your employees attending a training session 

provided by you, or by one (1) MCT that is teaching the training session, or 

2. install one (1) copy of the Licensed Content in the form provided to you on one (1) 

Classroom Device for use by one (1) End User attending a Private Training Session, or one (1) 

MCT that is teaching the Private Training Session. 

ii. You agree that: 

1. you will acquire a license for each End User and MCT that accesses the Licensed Content, 

2. each End User and MCT will be presented with a copy of this agreement and each individual 

will agree that their use of the Licensed Content will be subject to these license terms prior 

to their accessing the Licensed Content. Each individual will be required to denote their 

acceptance of the EULA in a manner that is enforceable under local law prior to their 

accessing the Licensed Content, 

3. for all training sessions, you will only use qualified MCTs who hold the applicable 

competency to teach the particular MOC Course that is the subject of the training session, 

4. you will not alter or remove any copyright or other protective notices contained in the 

Licensed Content, 

5. you will remove and irretrievably delete all Licensed Content from all Classroom Devices and 

servers at the end of each training session, 

6. you will only provide access to the Licensed Content to End Users and MCTs, 

7. you will only provide access to the Trainer Content to MCTs, and 

8. any Licensed Content installed for use during a training session will be done in accordance 

with the applicable classroom set-up guide. 

c. If you are an End User: 

You may use the Licensed Content solely for your personal training use. If the Licensed Content is in 

digital format, for each license you acquire you may (i) install one (1) copy of the Licensed Content in 

the form provided to you on one (1) Personal Device and install another copy on another Personal 

Device as a backup copy, which may be used only to reinstall the Licensed Content; or (ii) print one (1) 

copy of the Licensed Content. You may not install or use a copy of the Licensed Content on a device 

you do not own or control.

d. If you are a MCT. 

i. For each license you acquire, you may use the Licensed Content solely to prepare and deliver an 

Authorized Training Session or Private Training Session. For each license you acquire, you may 

install and use one (1) copy of the Licensed Content in the form provided to you on one (1) Personal 

Device and install one (1) additional copy on another Personal Device as a backup copy, which may 

be used only to reinstall the Licensed Content. You may not install or use a copy of the Licensed 

Content on a device you do not own or control. 

ii. Use of Instructional Components in Trainer Content. You may customize, in accordance with the 

most recent version of the MCT Agreement, those portions of the Trainer Content that are logically 

associated with instruction of a training session. If you elect to exercise the foregoing rights, you 

agree: (a) that any of these customizations will only be used for providing a training session, (b) any 

customizations will comply with the terms and conditions for Modified Training Sessions and 

Supplemental Materials in the most recent version of the MCT agreement and with this agreement. 

For clarity, any use of “customize” refers only to changing the order of slides and content, and/or 

not using all the slides or content, it does not mean changing or modifying any slide or content. 

2.2 Separation of Components. The Licensed Content components are licensed as a single unit and you 

may not separate the components and install them on different devices. 

2.3 Reproduction/Redistribution Licensed Content. Except as expressly provided in the applicable 

installation and use rights above, you may not reproduce or distribute the Licensed Content or any portion 

thereof (including any permitted modifications) to any third parties without the express written permission 

of Microsoft. 

2.4 Third Party Programs. The Licensed Content may contain third party programs or services. These 

license terms will apply to your use of those third party programs or services, unless other terms accompany 

those programs and services. 

2.5 Additional Terms. Some Licensed Content may contain components with additional terms, 

conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also 

apply to that respective component and supplements the terms described in this Agreement. 

3. PRE-RELEASE VERSIONS. If the Licensed Content is a pre-release (“beta”) version, in addition to the other 

provisions in this agreement, then these terms also apply: 

a. Pre-Release Licensed Content. This Licensed Content is a pre-release version. It may not contain the 

same information and/or work the way a final version of the Licensed Content will. We may change it 

for the final version. We also may not release a final version. Microsoft is under no obligation to 

provide you with any further content, including the final release version of the Licensed Content. 

b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or 

through its third party designee, you give to Microsoft without charge, the right to use, share and 

commercialize your feedback in any way and for any purpose. You also give to third parties, without 

charge, any patent rights needed for their products, technologies and services to use or interface with 

any specific parts of a Microsoft software, Microsoft product, or service that includes the feedback. You 

will not give feedback that is subject to a license that requires Microsoft to license its software, 

technologies, or products to third parties because we include your feedback in them. These rights

survive this agreement. 

c. Term. If you are an Authorized Training Center, MCT or MPN, you agree to cease using all copies of the 

beta version of the Licensed Content upon (i) the date which Microsoft informs you is the end date for 

using the beta version, or (ii) sixty (60) days after the commercial release of the Licensed Content, 

whichever is earliest (“beta term”). Upon expiration or termination of the beta term, you will 

irretrievably delete and destroy all copies of same in the possession or under your control. 

4. INTERNET-BASED SERVICES. Classroom Devices located at Authorized Learning Center’s physical location 

may contain virtual machines and virtual hard disks for use while attending an Authorized Training 

Session. You may only use the software on the virtual machines and virtual hard disks on a Classroom 

Device solely to perform the virtual lab activities included in the MOC Course while attending the 

Authorized Training Session. Microsoft may provide Internet-based services with the software included 

with the virtual machines and virtual hard disks. It may change or cancel them at any time. If the 

software is pre-release versions of software, some of its Internet-based services may be turned on by 

default. The default setting in these versions of the software do not necessarily reflect how the features 

will be configured in the commercially released versions. If Internet-based services are included with the 

software, they are typically simulated for demonstration purposes in the software and no transmission 

over the Internet takes place. However, should the software be configured to transmit over the Internet, 

the following terms apply: 

a. Consent for Internet-Based Services. The software features described below connect to Microsoft or 

service provider computer systems over the Internet. In some cases, you will not receive a separate 

notice when they connect. You may switch off these features or not use them. By using these features, 

you consent to the transmission of this information. Microsoft does not use the information to identify 

or contact you. 

b. Computer Information. The following features use Internet protocols, which send to the appropriate 

systems computer information, such as your Internet protocol address, the type of operating system, 

browser and name and version of the software you are using, and the language code of the device 

where you installed the software. Microsoft uses this information to make the Internet-based services 

available to you. 

• Accelerators. When you use click on or move your mouse over an Accelerator, the title and full web 

address or URL of the current webpage, as well as standard computer information, and any content 

you have selected, might be sent to the service provider. If you use an Accelerator provided by 

Microsoft, the information sent is subject to the Microsoft Online Privacy Statement, which is 

available at go.microsoft.com/fwlink/?linkid=31493. If you use an Accelerator provided by a third 

party, use of the information sent will be subject to the third party’s privacy practices. 

• Automatic Updates. This software contains an Automatic Update feature that is on by default. For 

more information about this feature, including instructions for turning it off, see 

go.microsoft.com/fwlink/?LinkId=178857. You may turn off this feature while the software is 

running (“opt out”). Unless you expressly opt out of this feature, this feature will (a) connect to 

Microsoft or service provider computer systems over the Internet, (b) use Internet protocols to send 

to the appropriate systems standard computer information, such as your computer’s Internet 

protocol address, the type of operating system, browser and name and version of the software you 

are using, and the language code of the device where you installed the software, and (c) 

automatically download and install, or prompt you to download and/or install, current Updates to 

the software. In some cases, you will not receive a separate notice before this feature takes effect.

By installing the software, you consent to the transmission of standard computer information and 

the automatic downloading and installation of updates. 

• Auto Root Update. The Auto Root Update feature updates the list of trusted certificate authorities. 

you can switch off the Auto Root Update feature. 

• Customer Experience Improvement Program (CEIP), Error and Usage Reporting; Error Reports. This 

software uses CEIP and Error and Usage Reporting components enabled by default that 

automatically send to Microsoft information about your hardware and how you use this software. 

This software also automatically sends error reports to Microsoft that describe which software 

components had errors and may also include memory dumps. You may choose not to use these 

software components. For more information please go to 

. 

• Digital Certificates. The software uses digital certificates. These digital certificates confirm the 

identity of Internet users sending X.509 standard encrypted information. They also can be used to 

digitally sign files and macros, to verify the integrity and origin of the file contents. The software 

retrieves certificates and updates certificate revocation lists. These security features operate only 

when you use the Internet. 

• Extension Manager. The Extension Manager can retrieve other software through the internet from 

the Visual Studio Gallery website. To provide this other software, the Extension Manager sends to 

Microsoft the name and version of the software you are using and language code of the device 

where you installed the software. This other software is provided by third parties to Visual Studio 

Gallery. It is licensed to users under terms provided by the third parties, not from Microsoft. Read 

the Visual Studio Gallery terms of use for more information. 

• IPv6 Network Address Translation (NAT) Traversal service (Teredo). This feature helps existing 

home Internet gateway devices transition to IPv6. IPv6 is a next generation Internet protocol. It 

helps enable end-to-end connectivity often needed by peer-to-peer applications. To do so, each 

time you start up the software the Teredo client service will attempt to locate a public Teredo 

Internet service. It does so by sending a query over the Internet. This query only transfers standard 

Domain Name Service information to determine if your computer is connected to the Internet and 

can locate a public Teredo service. If you 

· use an application that needs IPv6 connectivity or 

· configure your firewall to always enable IPv6 connectivity 

by default standard Internet Protocol information will be sent to the Teredo service at Microsoft at 

regular intervals. No other information is sent to Microsoft. You can change this default to use non- 

Microsoft servers. You can also switch off this feature using a command line utility named “netsh”. 

• Malicious Software Removal. During setup, if you select “Get important updates for installation”, 

the software may check and remove certain malware from your device. “Malware” is malicious 

software. If the software runs, it will remove the Malware listed and updated at 

www.support.microsoft.com/?kbid=890830. During a Malware check, a report will be sent to 

Microsoft with specific information about Malware detected, errors, and other information about 

your device. This information is used to improve the software and other Microsoft products and 

services. No information included in these reports will be used to identify or contact you. You may 

disable the software’s reporting functionality by following the instructions found at

www.support.microsoft.com/?kbid=890830. For more information, read the Windows Malicious 

Software Removal Tool privacy statement at go.microsoft.com/fwlink/?LinkId=113995. 

• Microsoft Digital Rights Management. If you use the software to access content that has been 

protected with Microsoft Digital Rights Management (DRM), then, in order to let you play the 

content, the software may automatically request media usage rights from a rights server on the 

Internet and download and install available DRM updates. For more information, see 

go.microsoft.com/fwlink/?LinkId=178857. 

• Microsoft Telemetry Reporting Participation. If you choose to participate in Microsoft Telemetry 

Reporting through a “basic” or “advanced” membership, information regarding filtered URLs, 

malware and other attacks on your network is sent to Microsoft. This information helps Microsoft 

improve the ability of Forefront Threat Management Gateway to identify attack patterns and 

mitigate threats. In some cases, personal information may be inadvertently sent, but Microsoft will 

not use the information to identify or contact you. You can switch off Telemetry Reporting. For 

more information on this feature, see http://go.microsoft.com/fwlink/?LinkId=130980. 

• Microsoft Update Feature. To help keep the software up-to-date, from time to time, the software 

connects to Microsoft or service provider computer systems over the Internet. In some cases, you 

will not receive a separate notice when they connect. When the software does so, we check your 

version of the software and recommend or download updates to your devices. You may not receive 

notice when we download the update. You may switch off this feature. 

• Network Awareness. This feature determines whether a system is connected to a network by either 

passive monitoring of network traffic or active DNS or HTTP queries. The query only transfers 

standard TCP/IP or DNS information for routing purposes. You can switch off the active query 

feature through a registry setting. 

• Plug and Play and Plug and Play Extensions. You may connect new hardware to your device, either 

directly or over a network. Your device may not have the drivers needed to communicate with that 

hardware. If so, the update feature of the software can obtain the correct driver from Microsoft and 

install it on your device. An administrator can disable this update feature. 

• Real Simple Syndication (“RSS”) Feed. This software start page contains updated content that is 

supplied by means of an RSS feed online from Microsoft. 

• Search Suggestions Service. When you type a search query in Internet Explorer by using the Instant 

Search box or by typing a question mark (?) before your search term in the Address bar, you will see 

search suggestions as you type (if supported by your search provider). Everything you type in the 

Instant Search box or in the Address bar when preceded by a question mark (?) is sent to your 

search provider as you type it. In addition, when you press Enter or click the Search button, all the 

text that is in the search box or Address bar is sent to the search provider. If you use a Microsoft 

search provider, the information you send is subject to the Microsoft Online Privacy Statement, 

which is available at go.microsoft.com/fwlink/?linkid=31493. If you use a third-party search 

provider, use of the information sent will be subject to the third party’s privacy practices. You can 

turn search suggestions off at any time in Internet Explorer by using Manage Add-ons under the 

Tools button. For more information about the search suggestions service, see 

go.microsoft.com/fwlink/?linkid=128106. 

• SQL Server Reporting Services Map Report Item. The software may include features that retrieve 

content such as maps, images and other data through the Bing Maps (or successor branded)

application programming interface (the “Bing Maps APIs”). The purpose of these features is to 

create reports displaying data on top of maps, aerial and hybrid imagery. If these features are 

included, you may use them to create and view dynamic or static documents. This may be done only 

in conjunction with and through methods and means of access integrated in the software. You may 

not otherwise copy, store, archive, or create a database of the content available through the Bing 

Maps APIs. you may not use the following for any purpose even if they are available through the 

Bing Maps APIs: 

• Bing Maps APIs to provide sensor based guidance/routing, or 

• Any Road Traffic Data or Bird’s Eye Imagery (or associated metadata). 

Your use of the Bing Maps APIs and associated content is also subject to the additional terms and 

conditions at http://www.microsoft.com/maps/product/terms.html. 

• URL Filtering. The URL Filtering feature identifies certain types of web sites based upon predefined 

URL categories, and allows you to deny access to such web sites, such as known malicious sites and 

sites displaying inappropriate or pornographic materials. To apply URL filtering, Microsoft queries 

the online Microsoft Reputation Service for URL categorization. You can switch off URL filtering. For 

more information on this feature, see http://go.microsoft.com/fwlink/?LinkId=130980 

• Web Content Features. Features in the software can retrieve related content from Microsoft and 

provide it to you. To provide the content, these features send to Microsoft the type of operating 

system, name and version of the software you are using, type of browser and language code of the 

device where you run the software. Examples of these features are clip art, templates, online 

training, online assistance and Appshelp. You may choose not to use these web content features. 

• Windows Media Digital Rights Management. Content owners use Windows Media digital rights 

management technology (WMDRM) to protect their intellectual property, including copyrights. This 

software and third party software use WMDRM to play and copy WMDRM-protected content. If the 

software fails to protect the content, content owners may ask Microsoft to revoke the software’s 

ability to use WMDRM to play or copy protected content. Revocation does not affect other content. 

When you download licenses for protected content, you agree that Microsoft may include a 

revocation list with the licenses. Content owners may require you to upgrade WMDRM to access 

their content. Microsoft software that includes WMDRM will ask for your consent prior to the 

upgrade. If you decline an upgrade, you will not be able to access content that requires the upgrade. 

You may switch off WMDRM features that access the Internet. When these features are off, you can 

still play content for which you have a valid license. 

• Windows Media Player. When you use Windows Media Player, it checks with Microsoft for 

· compatible online music services in your region; 

· new versions of the player; and 

· codecs if your device does not have the correct ones for playing content. 

You can switch off this last feature. For more information, go to 

www.microsoft.com/windows/windowsmedia/player/11/privacy.aspx. 

• Windows Rights Management Services. The software contains a feature that allows you to create 

content that cannot be printed, copied or sent to others without your permission. For more 

information, go to www.microsoft.com/rms. you may choose not to use this feature

• Windows Time Service. This service synchronizes with time.windows.com once a week to provide 

your computer with the correct time. You can turn this feature off or choose your preferred time 

source within the Date and Time Control Panel applet. The connection uses standard NTP protocol. 

• Windows Update Feature. You may connect new hardware to the device where you run the 

software. Your device may not have the drivers needed to communicate with that hardware. If so, 

the update feature of the software can obtain the correct driver from Microsoft and run it on your 

device. You can switch off this update feature. 

c. Use of Information. Microsoft may use the device information, error reports, and malware reports to 

improve our software and services. We may also share it with others, such as hardware and software 

vendors. They may use the information to improve how their products run with Microsoft software. 

d. Misuse of Internet-based Services. You may not use any Internet-based service in any way that could 

harm it or impair anyone else’s use of it. You may not use the service to try to gain unauthorized access 

to any service, data, account or network by any means. 

5. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some rights 

to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more 

rights despite this limitation, you may use the Licensed Content only as expressly permitted in this 

agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only 

allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not: 

• install more copies of the Licensed Content on devices than the number of licenses you acquired; 

• allow more individuals to access the Licensed Content than the number of licenses you acquired; 

• publicly display, or make the Licensed Content available for others to access or use; 

• install, sell, publish, transmit, encumber, pledge, lend, copy, adapt, link to, post, rent, lease or lend, 

make available or distribute the Licensed Content to any third party, except as expressly permitted 

by this Agreement. 

• reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the 

Licensed Content except and only to the extent that applicable law expressly permits, despite this 

limitation; 

• access or use any Licensed Content for which you are not providing a training session to End Users 

using the Licensed Content; 

• access or use any Licensed Content that you have not been authorized by Microsoft to access and 

use; or 

• transfer the Licensed Content, in whole or in part, or assign this agreement to any third party. 

6. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to you in 

this agreement. The Licensed Content is protected by copyright and other intellectual property laws and 

treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the 

Licensed Content. You may not remove or obscure any copyright, trademark or patent notices that 

appear on the Licensed Content or any components thereof, as delivered to you. 

7. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regulations. You 

must comply with all domestic and international export laws and regulations that apply to the Licensed 

Content. These laws include restrictions on destinations, End Users and end use. For additional 

information, see www.microsoft.com/exporting.

8. LIMITATIONS ON SALE, RENTAL, ETC. AND CERTAIN ASSIGNMENTS. You may not sell, rent, lease, lend or 

sublicense the Licensed Content or any portion thereof, or transfer or assign this agreement. 

9. SUPPORT SERVICES. Because the Licensed Content is “as is”, we may not provide support services for it. 

10. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail 

to comply with the terms and conditions of this agreement. Upon any termination of this agreement, you 

agree to immediately stop all use of and to irretrievable delete and destroy all copies of the Licensed 

Content in your possession or under your control. 

11. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed Content. 

The third party sites are not under the control of Microsoft, and Microsoft is not responsible for the 

contents of any third party sites, any links contained in third party sites, or any changes or updates to third 

party sites. Microsoft is not responsible for webcasting or any other form of transmission received from 

any third party sites. Microsoft is providing these links to third party sites to you only as a convenience, 

and the inclusion of any link does not imply an endorsement by Microsoft of the third party site. 

12. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates and support services are 

the entire agreement for the Licensed Content. 

13. APPLICABLE LAW. 

a. United States. If you acquired the Licensed Content in the United States, Washington state law governs 

the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws 

principles. The laws of the state where you live govern all other claims, including claims under state 

consumer protection laws, unfair competition laws, and in tort. 

b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of that 

country apply. 

14. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of 

your country. You may also have rights with respect to the party from whom you acquired the Licensed 

Content. This agreement does not change your rights under the laws of your country if the laws of your 

country do not permit it to do so. 

15. DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS," "WITH ALL FAULTS," AND "AS 

AVAILABLE." YOU BEAR THE RISK OF USING IT. MICROSOFT CORPORATION AND ITS RESPECTIVE 

AFFILIATES GIVE NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS UNDER OR IN RELATION TO 

THE LICENSED CONTENT. YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS 

WHICH THIS AGREEMENT CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, 

MICROSOFT CORPORATION AND ITS RESPECTIVE AFFILIATES EXCLUDE ANY IMPLIED WARRANTIES OR 

CONDITIONS, INCLUDING THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 

NON-INFRINGEMENT. 

16. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. TO THE EXTENT NOT PROHIBITED BY 

LAW, YOU CAN RECOVER FROM MICROSOFT CORPORATION AND ITS SUPPLIERS ONLY DIRECT 

DAMAGES UP TO USD$5.00. YOU AGREE NOT TO SEEK TO RECOVER ANY OTHER DAMAGES, INCLUDING 

CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES FROM MICROSOFT 

CORPORATION AND ITS RESPECTIVE SUPPLIERS.

This limitation applies to 

o anything related to the Licensed Content, services made available through the Licensed Content, or 

content (including code) on third party Internet sites or third-party programs; and 

o claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, 

or other tort to the extent permitted by applicable law. 

It also applies even if Microsoft knew or should have known about the possibility of the damages. The 

above limitation or exclusion may not apply to you because your country may not allow the exclusion or 

limitation of incidental, consequential or other damages. 

Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this agreement 

are provided below in French. 

Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses dans ce 

contrat sont fournies ci-dessous en français. 

EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute 

utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre garantie 

expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection dues 

consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties 

implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contrefaçon sont exclues. 

LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES. Vous 

pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement 

à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les autres dommages, y 

compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices. 

Cette limitation concerne: 

• tout ce qui est relié au le contenu sous licence , aux services ou au contenu (y compris le code) 

figurant sur des sites Internet tiers ou dans des programmes tiers ; et 

• les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité 

stricte, de négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur. 

Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel dommage. 

Si votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages indirects, 

accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus ne s’appliquera 

pas à votre égard. 

EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits prévus 

par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois de votre pays 

si celles-ci ne le permettent pas. 

Revised March 2012

xiv 10775A: Administering Microsoft SQL Server 2012 Databases

10775A: Administering Microsoft SQL Server 2012 Databases xv 

Acknowledgments 

Microsoft Learning would like to acknowledge and thank the following for their contribution towards 

developing this title. Their effort at various stages in the development has ensured that you have a good 

classroom experience. 

Design and Development 

This course was designed and developed by SolidQ. SolidQ is a global provider of consulting, mentoring 

and training services for Microsoft Data Management, Business Intelligence and Collaboration platforms. 

Greg Low – Lead Developer 

Dr Greg Low is a SQL Server MVP, an MCT, and a Microsoft Regional Director for Australia. Greg has 

worked with SQL Server since version 4.2 as an active mentor, consultant and trainer. Greg describes 

himself as a SQL Server junkie and also describes himself as having been involved in development since 

dinosaurs roamed the Earth. He has been an instructor in the Microsoft SQL Server Masters certification 

program for several years and was one of the first two people to achieve the SQL Server 2008 Master 

certification. He is the author of a number whitepapers on the Microsoft MSDN and TechNet web sites 

and the author of a number of SQL Server related books. Greg is based in Melbourne Australia. 

Herbert Albert – Course Developer 

Herbert Albert started his career in 1994. He works as a trainer, consultant, and author focusing on SQL 

Server technologies. Herbert is a mentor and the Central European CEO for SolidQ. He is based in Vienna, 

Austria. He has several Microsoft certifications including MCT which he has held since 1997. Herbert is a 

regular speaker at conferences and co-author of the SQL Server 2012 Upgrade Technical Reference Guide 

and SQL Server 2005 Step-by-Step Applied Techniques. Together with Gianluca Hotz, Herbert writes a 

regular column at the SolidQ Journal. 

Mark Hions – Technical Reviewer 

Mark's passion for computing and skill as a communicator were well suited to his position as instructor at 

Honeywell Canada, where he started working with minicomputers, mainframes and mature students in 

1984. He first met Microsoft SQL Server when it ran on OS/2, and has delivered training on every version 

since. An independent MCT and consultant for many years, he is a highly-rated presenter at TechEd, has 

designed SQL Server exams for Microsoft, and has delivered deep dive courses through the Microsoft 

Partner Channel. Mark is now the Principal SQL Server Instructor and Consultant at DesTech, which is the 

largest provider of SQL Server training in the Toronto area. 

Chris Barker – Technical Reviewer 

Chris Barker is an MCT working in the New Zealand market and currently employed as a staff trainer at 

Auldhouse, one of New Zealand’s major CPLS training centers in Wellington. Chris’ background includes 

programming from the early 1970s—his first program was written in assembly language and debugged in 

binary (literally)! While focusing training on programming (mostly .NET) and databases (mostly Microsoft 

SQL Server) Chris has also been an infrastructure trainer and has both Novell and Microsoft networking 

qualifications.

xvi 10775A: Administering Microsoft SQL Server 2012 Databases 

Contents 

Module 1: Introduction to SQL Server 2012 and Its Toolset 

Lesson 1: Introduction to the SQL Server Platform 1-3 

Lesson 2: Working with SQL Server Tools 1-14 

Lesson 3: Configuring SQL Server Services 1-26 

Lab 1: Introduction to SQL Server and Its Toolset 1-36 

Module 2: Preparing Systems for SQL Server 2012 

Lesson 1: Overview of SQL Server Architecture 2-3 

Lesson 2: Planning Server Resource Requirements 2-17 

Lesson 3: Pre-installation Testing for SQL Server 2-29 

Lab 2: Preparing Systems for SQL Server 2-35 

Module 3: Installing and Configuring SQL Server 2012 

Lesson 1: Preparing to Install SQL Server 3-3 

Lesson 2: Installing SQL Server 3-16 

Lesson 3: Upgrading and Automating Installation 3-24 

Lab 3: Installing and Configuring SQL Server 3-32 

Module 4: Working with Databases 

Lesson 1: Overview of SQL Server Databases 4-3 

Lesson 2: Working with Files and Filegroups 4-15 

Lesson 3: Moving Database Files 4-29 

Lab 4: Working with Databases 4-39 

Module 5: Understanding SQL Server 2012 Recovery Models 

Lesson 1: Backup Strategies 5-3 

Lesson 2: Understanding SQL Server Transaction Logging 5-12 

Lesson 3: Planning a SQL Server Backup Strategy 5-22 

Lab 5: Understanding SQL Server Recovery Models 5-32 

Module 6: Backup of SQL Server 2012 Databases 

Lesson 1: Backing up Databases and Transaction Logs 6-3 

Lesson 2: Managing Database Backups 6-14 

Lesson 3: Working with Backup Options 6-20 

Lab 6: Backup of SQL Server Databases 6-26

Module 7: Restoring SQL Server 2012 Databases 

10775A: Administering Microsoft SQL Server 2012 Databases xvii 

Lesson 1: Understanding the Restore Process 7-3 

Lesson 2: Restoring Databases 7-8 

Lesson 3: Working with Point-in-time recovery 7-19 

Lesson 4: Restoring System Databases and Individual Files 7-27 

Lab 7: Restoring SQL Server 2012 Databases 7-34 

Module 8: Importing and Exporting Data 

Lesson 1: Transferring Data To/From SQL Server 8-3 

Lesson 2: Importing & Exporting Table Data 8-15 

Lesson 3: Inserting Data in Bulk 8-20 

Lab 8: Importing and Exporting Data 8-29 

Module 9: Authenticating and Authorizing Users 

Lesson 1: Authenticating Connections to SQL Server 9-3 

Lesson 2: Authorizing Logins to Access Databases 9-13 

Lesson 3: Authorization Across Servers 9-22 

Lab 9: Authenticating and Authorizing Users 9-30 

Module 10: Assigning Server and Database Roles 

Lesson 1: Working with Server Roles 10-3 

Lesson 2: Working with Fixed Database Roles 10-12 

Lesson 3: Creating User-defined Database Roles 10-18 

Lab 10: Assigning Server and Database Roles 10-26 

Module 11: Authorizing Users to Access Resources 

Lesson 1: Authorizing User Access to Objects 11-3 

Lesson 2: Authorizing Users to Execute Code 11-12 

Lesson 3: Configuring Permissions at the Schema Level 11-21 

Lab 11: Authorizing Users to Access Resources 11-28 

Module 12: Auditing SQL Server Environments 

Lesson 1: Options for Auditing Data Access in SQL 12-3 

Lesson 2: Implementing SQL Server Audit 12-12 

Lesson 3: Managing SQL Server Audit 12-26 

Lab 12: Auditing SQL Server Environments 12-31 

Module 13: Automating SQL Server 2012 Management 

Lesson 1: Automating SQL Server Management 13-3 

Lesson 2: Working with SQL Server Agent 13-11 

Lesson 3: Managing SQL Server Agent Jobs 13-19 

Lab 13: Automating SQL Server Management 13-26

xviii 10775A: Administering Microsoft SQL Server 2012 Databases 

Module 14: Configuring Security for SQL Server Agent 

Lesson 1: Understanding SQL Server Agent Security 14-3 

Lesson 2: Configuring Credentials 14-13 

Lesson 3: Configuring Proxy Accounts 14-18 

Lab 14: Configuring Security for SQL Server Agent 14-24 

Module 15: Monitoring SQL Server 2012 with Alerts and Notifications 

Lesson 1: Configuration of Database Mail 15-3 

Lesson 2: Monitoring SQL Server Errors 15-11 

Lesson 3: Configuring Operators, Alerts and Notifications 15-18 

Lab 15: Monitoring SQL Agent Jobs with Alerts and Notifications 15-30 

Module 16: Performing Ongoing Database Maintenance 

Lesson 1: Ensuring Database Integrity 16-3 

Lesson 2: Maintaining Indexes 16-12 

Lesson 3: Automating Routine Database Maintenance 16-26 

Lab 16: Performing Ongoing Database Maintenance 16-30 

Module 17: Tracing Access to SQL Server 2012 

Lesson 1: Capturing Activity using SQL Server Profiler and Extended 

Events Profiler 

Lesson 2: Improving Performance with the Database Engine Tuning 

17-3 

Advisor 17-17 

Lesson 3: Working with Tracing Options 17-25 

Lab 17: Tracing Access to SQL Server 2012 17-36 

Module 18: Monitoring SQL Server 2012 

Lesson 1: Monitoring Activity 18-3 

Lesson 2: Capturing and Managing Performance Data 18-15 

Lesson 3: Analyzing Collected Performance Data 18-23 

Lab 18: Monitoring SQL Server 2012 18-32 

Module 19: Managing Multiple Servers 

Lesson 1: Working with Multiple Servers 19-3 

Lesson 2: Virtualizing SQL Server 19-9 

Lesson 3: Deploying and Upgrading Data-tier Applications 19-15 

Lab 19: Managing Multiple Servers 19-22

10775A: Administering Microsoft SQL Server 2012 Databases xix 

Module 20: Troubleshooting Common SQL Server 2012 Administrative Issues 

Lesson 1: SQL Server Troubleshooting Methodology 20-3 

Lesson 2: Resolving Service-related Issues 20-7 

Lesson 3: Resolving Login and Connectivity Issues 20-13 

Lesson 4: Resolving Concurrency Issues 20-17 

Lab 20: Troubleshooting Common Issues 20-25 

Appendix A: Core Concepts in SQL Server High Availability and Replication 

Lesson 1: Core Concepts in High Availability A-3 

Lesson 2: Core Concepts in Replication A-11 

Appendix: Lab Answer Keys 

Module 1 Lab: Introduction to SQL Server and Its Toolset L1-1 

Module 2 Lab: Preparing Systems for SQL Server L2-5 

Module 3 Lab: Installing and Configuring SQL Server L3-11 

Module 4 Lab: Working with Databases L4-17 

Module 5 Lab: Understanding SQL Server Recovery Models L5-23 

Module 6 Lab: Backup of SQL Server Databases L6-27 

Module 7 Lab: Restoring SQL Server 2012 Databases L7-31 

Module 8 Lab: Importing and Exporting Data L8-35 

Module 9 Lab: Authenticating and Authorizing Users L9-39 

Module 10 Lab: Assigning Server and Database Roles L10-41 

Module 11 Lab: Authorizing Users to Access Resources L11-43 

Module 12 Lab: Auditing SQL Server Environments L12-45 

Module 13 Lab: Automating SQL Server Management L13-49 

Module 14 Lab: Configuring Security for SQL Server Agent L14-53 

Module 15 Lab: Monitoring SQL Server 2012 with Alerts and 

Notifications L15-57 

Module 16 Lab: Performing Ongoing Database Maintenance L16-63 

Module 17 Lab: Tracing Access to SQL Server L17-67 

Module 18 Lab: Monitoring SQL Server 2012 L18-71 

Module 19 Lab: Managing Multiple Servers L19-75 

Module 20 Lab: Troubleshooting Common Issues L20-79

About This Course xxi 

About This Course 

This section provides you with a brief description of the course, audience, required prerequisites, and 

course objectives. 

Course Description 

This five-day instructor-led course provides students with the knowledge and skills to administer 

Microsoft® SQL Server® 2012 Databases. The course focuses on teaching individuals how to use SQL 

Server 2012 product features and tools related to maintaining a database. 

Audience 

The primary audience for this course is individuals who administer and maintain SQL Server databases. 

This course can also be helpful for individuals who develop applications that deliver content from SQL 

Server databases. 

Student Prerequisites 

This course requires that you meet the following prerequisites: 

• Basic knowledge of the Microsoft Windows operating system and its core functionality. 

• Working knowledge of Transact-SQL. 

• Working knowledge of relational databases. 

• Some experience with database design. 

• Completed Course 10774: Querying Microsoft SQL Server 2012.

xxii About This Course 

Course Objectives 

After completing this course, students will be able to: 

• Explain SQL Server 2012 architecture, resources requirements and perform pre-install checks of I/O 

subsystems. 

• Plan, install and configure SQL Server 2012. 

• Backup and restore databases. 

• Import and export wizards and explain how they relate to SSIS. 

• Use BCP and BULK INSERT to import data. 

• Manage security. 

• Assign, configure fixed database roles and create and assign user defined database roles. 

• Configure and assign permissions. 

• Implement SQL Server 2012 Audits. 

• Manage SQL Server 2012 Agent and Jobs. 

• Configure database mail, alerts and notifications. 

• Maintain databases. 

• Configure SQL Profiler and SQL Trace and use the Database Engine Tuning Advisor. 

• Monitor data by using Dynamic Management Views. 

• Execute multi-server queries and configure a central management server. 

• Deploy a data-tier application. 

• Troubleshoot common issues.

Course Outline 

This section provides an outline of the course: 





Module 5: Understanding SQL Server 2012 Recovery Models 

Module 6: Backup of SQL Server 2012 Databases 









Module 15: Monitoring SQL Server 2012 with Alerts and Notifications 





Module 20: Troubleshooting Common SQL Server 2012 Administrative Issues 

About This Course xxiii

xxiv About This Course 

Course Materials 

The following materials are included with your kit: 

• Course Handbook. A succinct classroom learning guide that provides all the critical technical 

information in a crisp, tightly-focused format, which is just right for an effective in-class learning 

experience. 

• Lessons: Guide you through the learning objectives and provide the key points that are critical to the 

success of the in-class learning experience. 

• Labs: Provide a real-world, hands-on platform for you to apply the knowledge and skills learned in 

the module. 

• Module Reviews and Takeaways: Provide improved on-the-job reference material to boost 

knowledge and skills retention. 

• Lab Answer Keys: Provide step-by-step lab solution guidance at your fingertips when it’s needed. 

• Lessons: Include detailed information for each topic, expanding on the content in the Course 

Handbook. 

• Labs: Include complete lab exercise information and answer keys in digital form to use during lab 

time 

• Resources: Include well-categorized additional resources that give you immediate access to the most 

up-to-date premium content on TechNet, MSDN, Microsoft Press 

• Student Course Files: Include the Allfiles.exe, a self-extracting executable file that contains all the 

files required for the labs and demonstrations. 

• Course evaluation. At the end of the course, you will have the opportunity to complete an online 

evaluation to provide feedback on the course, training facility, and instructor. 

To provide additional comments or feedback on the course, send e-mail to support@mscourseware.com. 

To inquire about the Microsoft Certification Program, send e-mail to mcphelp@microsoft.com.

About This Course xxv 

Virtual Machine Environment 

This section provides the information for setting up the classroom environment to support the business 

scenario of the course. 

Virtual Machine Configuration 

In this course, you will use Microsoft Hyper-V to perform the labs. 

The following table shows the role of each virtual machine used in this course: 

Virtual machine Role 

1077XA-MIA-DC Domain Controller 

1077XA-MIA-SQL SQL Server VM for Modules 1 - 20 

Software Configuration 

The following software is installed on each VM: 

• SQL Server 2012 (on the SQL Server VMs) 

Course Files 

There are files associated with the labs in this course. The lab files are located in the folder 

D:\10775A_Labs on the student computers. 

Classroom Setup 

Each classroom computer will have the same virtual machine configured in the same way. 

Course Hardware Level 

To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment 

configuration for trainer and student computers in all Microsoft Certified Partner for Learning Solutions 

(CPLS) classrooms in which Official Microsoft Learning Product courses are taught. This course requires 

hardware level 6.

Module 1 

Introduction to SQL Server® 2012 and Its Toolset 

Contents: 

Lesson 1: Introduction to the SQL Server Platform 1-3 

Lesson 2: Working with SQL Server Tools 1-14 

Lesson 3: Configuring SQL Server Services 1-26 

Lab 1: Introduction to SQL Server and its Toolset 1-36 

1-1

1-2 Introduction to SQL Server® 2012 and Its Toolset 

Module Overview 

Before beginning to work with Microsoft® SQL Server® in either a development or an administration 

role, it is important to understand the overall SQL Server platform. In particular, it is useful to understand 

that SQL Server is not just a database engine but it is a complete platform for managing enterprise data. 

Along with a strong platform, SQL Server provides a series of tools that make the product easy to manage 

and a good target for the application development. 

Individual components of SQL Server can operate within separate security contexts. Correctly configuring 

SQL Server services is important where enterprises are operating with a policy of least possible 

permissions. 

Objectives 

After completing this lesson, you will be able to: 

• Describe the SQL Server platform. 

• Work with SQL Server tools. 

• Configure SQL Server services.

Lesson 1 

Introduction to the SQL Server Platform 

10775A: Administering Microsoft SQL Server 2012 Databases 1-3 

SQL Server is a platform for developing business applications that are data focused. Rather than being a 

single monolithic application, SQL Server is structured as a series of components. It is important to 

understand the use of each of the components. 

More than a single copy of SQL Server can be installed on a server. Each of these copies is called an 

instance and can be separately configured and managed. 

SQL Server is shipped in a variety of editions, each with a different set of capabilities. It is important to 

understand the target business cases for each of the SQL Server editions and how SQL Server has evolved 

through a series of improving versions over many years. It is a stable and robust platform. 

Objectives 


• Describe the overall SQL Server platform. 

• Explain the role of each of the components that make up the SQL Server platform. 

• Describe the functionality provided by SQL Server instances. 

• Explain the available SQL Server editions. 

• Explain how SQL Server has evolved through a series of versions.


SQL Server Architecture 

Key Points 

SQL Server is an integrated and enterprise-ready platform for data management that offers a low total 

cost of ownership. 

Question: Which other database platforms have you worked with? 

Enterprise Ready 

While SQL Server is much more than a relational database management system, it provides a very secure, 

robust, and stable relational database management system. SQL Server is used to manage organizational 

data and to provide analysis and insights into that data. 

The database engine is one of the highest performing database engines available and regularly features in 

the top of industry performance benchmarks. You can review industry benchmarks and scores at 

http://www.tpc.org. 

High Availability 

Impressive performance is necessary but not at the cost of availability. Organizations need constant access 

to their data. Many enterprises are now finding a need to have 24 hour x 7 day access available. The SQL 

Server platform was designed with the highest levels of availability in mind. As each version of the product 

has been released, more and more capabilities have been added to minimize any potential downtime. 

Security 

Utmost in the minds of enterprise managers is the need to secure organizational data. Security is not able 

to be retrofitted after an application or a product is created. SQL Server has been built from the ground 

up with the highest levels of security as a goal.

Scalability 


Organizations have a need for data management capabilities for systems of all sizes. SQL Server scales 

from the smallest needs to the largest via a series of editions with increasing capabilities. 

Cost of Ownership 

Many competing database management systems are expensive both to purchase and to maintain. SQL 

Server offers very low total cost of ownership. SQL Server tooling (both management and development) 

builds on existing Windows knowledge. Most users tend to become familiar with the tools quite quickly. 

The productivity achieved when working with the tools is enhanced by the high degree of integration 

between the tools. For example, many of the SQL Server tools have links to launch and preconfigure other 

SQL Server tools.


SQL Server Components 

Key Points 

SQL Server is a very good relational database engine but as a data platform, it offers much more than a 

relational database engine. SQL Server is a platform comprising many components. 

Component Purpose 

Database Engine Is a relational database engine based on the SQL language. 

Analysis Services Is an online analytical processing (OLAP) engine that works with analytic 

cubes. 

Integration Services Is a tool used to orchestrate the movement of data between SQL Server 

components and external systems (in both directions). 

Reporting Services Offers a reporting engine based on web services and provides a web portal 

and end-user reporting tools. 

Master Data Services Provides tooling and a hub for managing master or reference data. 

StreamInsight Is a platform for building applications to process high-speed events. 

Data Mining Provides tooling and an inference engine for deriving knowledge and insights 

from existing OLAP data or relational data. 

Full-Text Search Allows building sophisticated search options into applications. SQL Server 

2012 adds sophisticated sematic search to the existing full-text search. 

PowerPivot Allows end-users, power users, and business analysts to quickly analyze large 

volumes of data from different locations. 

Replication Allows moving data between servers to suit data distribution needs. 

Data Quality Services Allows building or connecting to a knowledgebase for data cleansing. 

Power View Allows rapid visualization of data by end-users. 

Question: Which components of SQL Server have you worked with?

SQL Server Instances 

Key Points 


It is sometimes useful to install more than a single copy of a SQL Server component on a single server. 

Many SQL Server components can be installed more than once as separate instances. 

SQL Server Instances 

The ability to install multiple instances of SQL Server components on a single server is useful in a number 

of situations: 

• There may be a need to have different administrators or security environments for sets of databases. 

Each instance of SQL Server is separately manageable and securable. 

• Applications that need to be supported by an organization may require server configurations that are 

inconsistent or incompatible with the server requirements of other applications. Each instance of SQL 

Server is separately configurable. 

• Application databases might need to be supported with different levels of service, particularly in 

relation to availability. SQL Server instances can be used to separate workloads with differing service 

level agreements (SLAs) that need to be met. 

• Different versions or editions of SQL Server might need to be supported. 

• Applications might require different server-level collations. While each database can have different 

collations, an application might be dependent on the collation of the tempdb database when the 

application is using temporary objects. 

Question: Why might you need to separate databases by service level agreement? 

Different versions of SQL Server can often be installed side-by-side using multiple instances. This can assist 

when testing upgrade scenarios or performing upgrades.


Default and Named Instances 

Prior to SQL Server 2000, only a single copy of SQL Server could be installed on a server system. SQL 

Server was addressed by the name of the server. To maintain backward compatibility, this mode of 

connection is still supported and is known as a "default" instance. 

Additional instances of SQL Server require an instance name in addition to the server name and are 

known as "named" instances. No default instance needs to be installed before installing named instances. 

Not all components of SQL Server are able to be installed in more than one instance. A substantial change 

in SQL Server 2012 allows for multiple instance support for SQL Server Integration Services. 

There is no need to install SQL Server tools and utilities more than once. A single installation of the tools is 

able to manage and configure all instances.

SQL Server Editions 

Key Points 


SQL Server is available in a wide variety of editions, with different price points and different levels of 

capability. 

SQL Server Editions 

Each SQL Server edition is targeted to a specific business use case as shown in the following table: 

Edition Business Use Case 

Parallel Data 

Warehouse 

Uses massively parallel processing (MPP) to execute queries against vast amount of 

data quickly. Parallel Data Warehouse systems are sold as a complete "appliance" 

rather than via standard software licenses. 

Enterprise Provides the highest levels of reliability for demanding workloads. 

Business 

Intelligence 

Adds Business Intelligence to the offerings from Standard Edition. 

Standard Delivers a reliable, complete data management platform. 

Express Is a free edition for lightweight web and small server-based applications. 

Compact Is a free edition for standalone and occasionally connected mobile applications, 

optimized for a very small memory footprint.


(continued) 

Edition Business Use Case 

Developer Allows building, testing, and demonstrating all SQL Server functionality. 

Web Provides a secure, cost effective, and scalable platform for public web sites and applications. 

SQL Azure Allows building and extending SQL Server applications to a cloud-based platform. 

Question: What would be a good business case example for using a cloud-based service?

SQL Server Versions 

Key Points 


SQL Server is a platform with a rich history of innovation achieved while maintaining strong levels of 

stability. SQL Server has been available for many years, yet it is rapidly evolving new capabilities and 

features. 

Early Versions 

The earliest versions (1.0 and 1.1) were based on the OS/2 operating system. 

Versions 4.2 and later moved to the Windows operating system, initially on the Windows NT operating 

system. 

Later Versions 

Version 7.0 saw a significant rewrite of the product. Substantial advances were made in reducing the 

administration workload for the product. OLAP Services (which later became Analysis Services) was 

introduced. 

SQL Server 2000 featured support for multiple instances and collations. It also introduced support for data 

mining. SQL Server Reporting Services was introduced after the product release as an add-on 

enhancement to the product, along with support for 64-bit processors. 

SQL Server 2005 provided another significant rewrite of many aspects of the product. It introduced 

support for: 

• Non-relational data stored and queried as XML. 

• SQL Server Management Studio was released to replace several previous administrative tools. 

• SQL Server Integration Services replaced a former tool known as Data Transformation Services (DTS).


• Another key addition to the product was the introduction of support for objects created using the 

Common Language Runtime (CLR). 

• The T-SQL language was substantially enhanced, including structured exception handling. 

• Dynamic Management Views and Functions were introduced to enable detailed health monitoring, 

performance tuning, and troubleshooting. 

• Substantial high availability improvements were included in the product. Database mirroring was 

introduced. 

• Support for column encryption was introduced. 

SQL Server 2008 also provided many enhancements: 

• The "SQL Server Always On" technologies were introduced to reduce potential downtime. 

• Filestream support improved the handling of structured and semi-structured data. 

• Spatial data types were introduced. 

• Database compression and encryption technologies were added. 

• Specialized date- and time-related data types were introduced, including support for timezones 

within datetime data. 

• Full-text indexing was integrated directly within the database engine. (Previously full-text indexing 

was based on interfaces to operating system level services). 

• A policy-based management framework was introduced to assist with a move to more declarativebased 

management practices, rather than reactive practices. 

• A PowerShell provider for SQL Server was introduced. 

The enhancements and additions to the product in SQL Server 2008 R2 included: 

• Substantial enhancements to SQL Server Reporting Services. 

• The introduction of advanced analytic capabilities with PowerPivot. 

• Improved multi-server management capabilities were added. 

• Support for managing reference data was provided with the introduction of Master Data Services. 

• StreamInsight provides the ability to query data that is arriving at high speed, before storing the data 

in a database. 

• Data-tier applications assist with packaging database applications as part of application development 

projects. 

SQL Server 2012 

The enhancements and additions to the product in SQL Server 2012 included: 

• Further substantial enhancements to SQL Server Reporting Services. 

• Substantial enhancements to SQL Server Integration Services. 

• The introduction of tabular data models into SQL Server Analysis Services. 

• The migration of Business Intelligence projects into Visual Studio 2010.


• The introduction of the Always On enhancements to SQL Server High Availability. 

• The introduction of Data Quality Services. 

• Strong enhancements to the T-SQL language such as the addition of sequences, new error-handling 

capabilities, and new window functions. 

• The introduction of the FileTable. 

• The introduction of statistical semantic search. 

• Many general tooling improvements. 

Question: Which versions of SQL Server have you worked with?


Lesson 2 

Working with SQL Server Tools 

Working effectively with SQL Server requires familiarity with the tools that are used in conjunction with 

SQL Server. Before any tool can connect to SQL Server, it needs to make a network connection to the 

server. In this lesson, you will see how these connections are made, then look at the tools that are most 

commonly used when working with SQL Server. 

Objectives 


• Connect from Clients and Applications. 

• Describe the roles of Software Layers for Connections. 

• Use SQL Server Management Studio. 

• Use SQL Server Data Tools. 

• Use Books Online.

Connecting from Clients and Applications 

Key Points 


Client applications connect to endpoints. A variety of communication protocols are available for making 

connections. Also, users need to be identified before they are permitted to use the server. 

Connectivity 

The protocol that client applications use when connecting to the SQL Server relational database engine is 

known as Tabular Data Stream (TDS). It defines how requests are issued and how results are returned. 

Other components of SQL Server use alternate protocols. For example, clients to SQL Server Analysis 

Services communicate via the XML for Analysis (XML/A) protocol. However, in this course, you are 

primarily concerned with the relational database engine. 

TDS is a high-level protocol that is transported by lower-level protocols. It is most commonly transported 

by the TCP/IP protocol, the Named Pipes protocol, or implemented over a shared memory connection. 

Authentication 

For the majority of applications and organizations, data must be held securely and access to the data is 

based on the identity of the user attempting to access the data. The process of verifying the identity of a 

user (or more formally, of any principal), is known as authentication. SQL Server supports two forms of 

authentication. It can store the login details for users directly within its own system databases. These 

logins are known as SQL Logins. Alternately, it can be configured to trust a Windows authenticator (such 

as Active Directory). In that case, a Windows user can be granted access to the server, either directly or via 

his/her Windows group memberships. 

When a connection is made, the user is connected to a specific database, known as their "default" 

database.


Software Layers for Connections 

Key Points 

Connections to SQL Server are made through a series of software layers. It is important to understand how 

each of these layers interacts. This knowledge will assist you when you need to perform configuration or 

troubleshooting. 

Client Libraries 

Client applications use programming libraries to simplify their access to databases such as SQL Server. 

Open Database Connectivity (ODBC) is a commonly used library. It operates as a translation layer that 

shields the application from some details of the underlying database engine. By changing the ODBC 

configuration, an application could be altered to work with a different database engine, without the need 

for application changes. Java Database Connectivity (JDBC) is the Java based equivalent library to ODBC. 

OLEDB originally stood for Object Linking and Embedding for Databases, however, that meaning is now 

not very relevant. OLEDB is a library that does not translate commands. When an application sends a SQL 

command, OLEDB passes it to the database server without modification. 

The SQL Server Native Access Component (SNAC) is a software layer that encapsulates commands issued 

by libraries such as OLEDB, ODBC and JDBC into commands that can be understood by SQL Server and 

encapsulates results returned by SQL Server ready for consumption by these libraries. This primarily 

involves wrapping the commands and results in the TDS protocol.

Network Libraries 


SQL Server exposes endpoints that client applications can connect to. The endpoint is used to pass 

commands and data to/from the database engine. 

SNAC connects to these endpoints via network libraries such as TCP/IP, or Named Pipes. For client 

applications that are executing on the same computer as the SQL Server service, a special "shared 

memory" network connection is also available. 

SQL Server Software Layers 

SQL Server receives commands via endpoints and sends results to clients via endpoints. Clients interact 

with the Relational engine which in turn utilizes the Storage engine to manage the storage of databases. 

SQL Server Operating System (SQL OS) is a software layer that provides a layer of abstraction between the 

Relational engine and the available server resources.


SQL Server Management Studio 

Key Points 

SQL Server Management Studio (SSMS) is the primary tool supplied by Microsoft for interacting with SQL 

Server services. 

SQL Server Management Studio 

SSMS is an integrated environment that has been created within the Microsoft Visual Studio platform 

shell. SSMS shares many common features with Visual Studio. 

SSMS is used to execute queries and return results but it is also capable of helping users to analyze 

queries. It offers rich editors for a variety of document types (.sql files, .xml files, etc.). When working with 

.sql files, SSMS provides IntelliSense to assist with writing queries. 

While all SQL Server relational database management tasks can be performed using the T-SQL language, 

many users prefer graphical administration tools as they are typically easier to use than the T-SQL 

commands. SSMS provides graphical interfaces for configuring databases and servers. 

SSMS is capable of connecting to a variety of SQL Server services including the database engine, Analysis 

Services, Integration Services, Reporting Services, and SQL Server Compact Edition.

Demonstration 2A: Using SQL Server Management Studio 

Demonstration Steps 


1. Revert the virtual machines as per the instructions in D:\10775A_Labs\Revert.txt. 

2. In the virtual machine, click Start, click All Programs, click Microsoft SQL Server 2012, and click 

SQL Server Management Studio. 

3. In the Connect to Server window, ensure that Server type is set to Database Engine. 

4. In the Server name text box, type (local). 

5. In the Authentication drop-down list, select Windows Authentication, and click Connect. 

6. If required, from the View menu, click Object Explorer. 

7. In Object Explorer, expand Databases, expand AdventureWorks, and Tables. Review the database 

objects. 

8. Right-click the AdventureWorks database and choose New Query. 

9. Type the query shown in the snippet below: 

SELECT * FROM Production.Product ORDER BY ProductID; 

10. Note the use of Intellisense while entering it, and then click Execute on the toolbar. Note how the 

results can be returned. 

11. From the File menu click Save SQLQuery1.sql. Note this saves the query to a file. In the Save File As 

window click Cancel. 

12. In the Results tab, right-click on the cell for ProductID 1 (first row and first cell) and click Save 

Results As…. In the FileName textbox, type Demonstration2AResults and click Save. Note this 

saves the query results to a file.


13. From the Query menu, click Display Estimated Execution Plan. Note that SSMS is capable of more 

than simply executing queries. 

14. From the Tools menu, and click Options. 

15. In the Options pane, expand Query Results, expand SQL Server, and expand General. Review the 

available configuration options and click Cancel. 

16. From the File menu, click Close. In the Microsoft SQL Server Management Studio window, click No. 

17. In the File menu, click Open, and click Project/Solution. 

18. In the Open Project window, open the project 

D:\10775A_Labs\10775A_02_PRJ\10775A_02_PRJ.ssmssln. 

19. From the View menu, click Solution Explorer. Note the contents of Solution Explorer. SQL Server 

projects have been supplied for each module of the course and contain demonstration steps and 

suggested lab solutions, along with any required setup/shutdown code for the module. 

20. In the Solution Explorer, click the X to close it. 

21. In Object Explorer, from the Connect toolbar icon, note the other SQL Server components that 

connections can be made to: 

• Database Engine, Analysis Services, Integration Services, Reporting Services 

22. From the File menu, click New, and click Database Engine Query to open a new connection. 

23. In the Connect to Database Engine window, type (local) in the Server name text box. 


25. In the Available Databases drop-down list, click tempdb database. Note this will change the 

database that the query is executed against. 

26. Right-click in the query window and click Connection, and click Change Connection…. Note: this 

will reconnect the query to another instance of SQL Server. In the Connect to Database Engine 

window, click Cancel. 

27. From the View menu, click Registered Servers. 

28. In the Registered Servers window, expand Database Engine, right-click Local Server Groups, and 

click New Server Group…. 

29. In the New Server Group Properties window type Dev Servers in the Group name textbox and 

click OK. 

30. Right-click Dev Servers and click New Server Registration…. 

31. In the New Server Registration window, click Server name drop-down list, type (local) and click 

Save. 

32. Right-click Dev Servers and click New Server Registration…. 

33. In the New Server Registration window, click Server name drop-down list, type .\MKTG and click 

Save. 

34. In the Registered Servers window, right-click the Dev Servers group and choose New Query.

35. Type the query as shown in the snippet below and click Execute toolbar icon: 

SELECT @@version; 

36. Close SQL Server Management Studio. 

37. Click No in the SQL Server Management Studio window. 

Question: When would displaying an estimated execution plan be helpful? 

10775A: Administering Microsoft SQL Server 2012 Databases 1-21


SQL Server Data Tools 

Key Points 

The SQL Server platform comprises a number of components. Projects for several of the Business 

Intelligence related components are created and modified using SQL Server Data Tools (SSDT). 

SQL Server Data Tools 

SSDT is a series of project templates that have been added to the Microsoft Visual Studio® 2010 

environment. The templates allow the creation and editing of projects for Analysis Services, Integration 

Services, and Reporting Services. 

Visual Studio does not need to be installed before SQL Server. If an existing installation of Visual Studio 

2010 is present, SQL Server installation will add project templates into that environment. If no existing 

Visual Studio 2010 installation is present, SQL Server installation will first install the "partner" edition of 

Visual Studio 2010 and then add the required project templates. The Partner edition of Visual Studio 2010 

is essentially an empty Visual Studio shell with a template for a "blank solution".

Demonstration 2B: Using SQL Server Data Tools 



1. If Demonstration 2A was not performed, revert the virtual machines as per the instructions in 

D:\10775A_Labs\Revert.txt. 


SQL Server Data Tools. From the File menu, click New Project. Note the available project templates 

(also if other languages are installed). 

3. In the Templates pane, click Report Server Project, and click OK. 

4. In Solution Explorer, right-click Reports and click Add New Report. 

5. In the Report Wizard window, click Next. 

6. In the Select the Data Source window, click Edit. 

7. In the Connection Properties window, type (local) for the Server name and in the Connect to a 

database drop-down list, select AdventureWorks, and click OK. 

8. In the Select the Data Source window, click Next then in the Design the Query window, for the Query 

string textbox, type the following query as shown in snippet below and click Next. 

SELECT ProductID, Name, Color, Size FROM Production.Product ORDER BY ProductID; 

9. In the Select the Report Type window, click Next. 

10. In the Design the Table window, click Details four times, and click Finish>>|. 

11. In the Completing the Wizard window, click Finish.


12. In the Report1.rdl [Design]* tab, click Preview and note the report that is rendered. 

13. Click on the Design tab, from the File menu click Exit. Note if prompted do not save the changes. 

Question: Can you suggest a situation where the ability to schedule the execution of a 

report would be useful?

Books Online 

Key Points 


Books Online (BOL) is the primary reference for SQL Server. It can be installed offline (for use when 

disconnected from the Internet) and can also be used online directly from the Microsoft MSDN web site 

(via an Internet connection). The most up-to-date version is always the online version. It is also the most 

flexible version as it enables easy comparison between SQL Server versions of documentation. In SQL 

Server 2012, there is a Help Library Manager that can be used to switch between online and offline modes 

for Books Online and can also be used to install updates for the offline version. 

Books Online 

BOL should be regarded as the primary technical reference for SQL Server. 

A common mistake when installing BOL locally on a SQL Server installation is to neglect to update BOL 

regularly. To avoid excess download file sizes, BOL is not included in SQL Server service pack and 

cumulative update packages. BOL is regularly updated and a regular check should be made for updates. 

For most T-SQL commands, many users will find the examples supplied easier to follow than the formal 

syntax definition. Note that when viewing the reference page for a statement, the formal syntax is shown 

at the top of the page and the examples are usually at the bottom of the page. 

BOL is available for all supported versions of SQL Server. It is important to make sure you are working with 

the pages designed for the version of SQL Server that you are working with. Many pages in BOL provide 

links to related pages from other versions of the product.


Demonstration 2C: Using Books Online 




2. In the virtual machine, click Start, click All Programs, click Microsoft SQL Server 2012, click 

Documentation & Community, and click SQL Server Documentation. 

3. Maximize the Microsoft Help Viewer window and note the basic navigation options available. 

4. In the Virtual Machine, click Start, click All Programs, click Microsoft SQL Server 2012, and click 



6. In the Server name text box, type (local). 


8. From the File menu, click New, and click Query with Current Connection. 

9. In the SQLQuery1.sql tab, type the query as shown in the snippet below and click Execute toolbar 

icon: 

SELECT SUBSTRING('test string',2,7); 

10. Click the name of the function SUBSTRING, then hit the F1 key to open the BOL topic for 

SUBSTRING. 

11. Note the content of the page and scroll to the bottom to see the examples then close the Microsoft 

Help Viewer window. 

12. Close SQL Server Management Studio, without saving any changes.


13. If your host system has Internet access available, open Internet Explorer® in the host system and 

browse to the SQL Server Books Online page: http://go.microsoft.com/fwlink/?LinkID=233780 

and note the available online options.


Lesson 3 

Configuring SQL Server Services 

Each SQL Server service can be configured individually. The ability to provide individual configuration for 

services assists organizations that aim to minimize the permissions assigned to service accounts, as part of 

a policy of least privilege execution. SQL Server Configuration Manager is used to configure services, 

including the accounts that the services operate under, and the network libraries used by the SQL Server 

services. 

SQL Server also ships with a variety of tools and utilities. It is important to know what each of these tools 

and utilities is used for. 

Objectives 


• Use SQL Server Configuration Manager. 

• Use SQL Server Services. 

• Use Network Ports and Listeners. 

• Create Server aliases. 

• Use other SQL Server tools.

SQL Server Configuration Manager 

Key Points 


SQL Server Configuration Manager (SSCM) is used to configure SQL Server services, to configure the 

network libraries exposed by SQL Server services, and to configure how client connections are made to 

SQL Server. 

SQL Server Configuration Manager 

SSCM can be used for three distinct purposes: 

• Managing Services – Each service can be controlled (started or stopped) and configured. 

• Managing Server Protocols – It is possible to configure the endpoints that are exposed by the SQL 

Server services. This includes the protocols and ports used. 

• Managing Client Protocols – When client applications (such as SSMS) are installed on a server, there is 

a need to configure how connections from those tools are made to SQL Server. SSCM can be used to 

configure the protocols required and can be used to create aliases for the servers to simplify 

connectivity. 

Question: Why would a server system need to have a client configuration node?


SQL Server Services 

Key Points 

SQL Server Configuration Manager can be used to configure the individual services that are provided by 

SQL Server. Many components provided by SQL Server are implemented as operating system services. The 

components of SQL Server that you choose during installation determine which of the SQL Server services 

are installed. 

SQL Server Services 

These services operate within a specific Windows identity. If there is a need to alter the assigned identity 

for a service, SSCM should be used to make this change. A common error is to use the Services applet in 

the server’s administrative tools to change the service identity. While this applet will change the identity 

for the service, it will not update the other permissions and access control lists that are required for the 

service to operate correctly. When service identities are modified from within SSCM, the required 

permissions and access control lists are also modified. 

Each service has a start mode. This mode can be set to Automatic, Manual, or Disabled. Services that are 

set to the Automatic start mode are automatically started when the operating system starts. Services that 

are set to the Manual start mode can be manually started. Services that are set to the Disabled start mode 

cannot be started. 

Instances 

Many SQL Server components are instance-aware and can be installed more than once on a single server. 

When SSCM lists each service, it shows the associated instance of SQL Server in parentheses after the 

name of the service. 

In the example shown in the slide, there is a single instance of the database engine installed. 

MSSQLSERVER is the default name allocated to the default instance of the SQL Server database engine.

Network Ports and Listeners 

Key Points 


SQL Server Configuration Manager can be used to configure both server and client protocols and ports. 

Network Ports and Listeners 

SSCM provides two sets of network configurations. Each network endpoint that is exposed by an instance 

of SQL Server can be configured. This includes the determination of which network libraries are enabled 

and, for each library, the configuration of the network library. Typically, this will involve settings such as 

protocol port numbers. You should discuss the required network protocol configuration of SQL Server 

with your network administrator. 

Many protocols provide multiple levels of configuration. For example, the configuration for the TCP/IP 

protocol allows for different settings on each configured IP address if required, or a general set of 

configurations that are applied to all IP addresses. 

Client Configurations 

Every computer that has SNAC installed needs the ability to configure how that library will access SQL 

Server services. 

SNAC is installed on the server as well as on client systems. When SSMS is installed on the server, it uses 

the SNAC library to make connections to the SQL Server services that are on the same system. The client 

configuration nodes within SSCM can be used to configure how those connections are made. Note that 

two sets of client configurations are provided and that they only apply to the computer where they are 

configured. One set is used for 32-bit applications; the other set is used for 64-bit applications. SSMS is a 

32-bit application, even when SQL Server is installed as a 64-bit application.


Creating Server Aliases 

Key Points 

Connecting to a SQL Server service can involve multiple settings such as server address, protocol, and 

port. To make this easier for client applications and to provide a level of available redirection, aliases can 

be created for servers. 

Aliases 

Hard-coding connection details for a specific server, protocol, and port within an application is not 

desirable as these might need to change over time. 

A server alias can be created and associated with a server, protocol, and port (if required). Client 

applications can then connect to the alias without being concerned about how those connections are 

made. 

Each client system that utilizes SNAC (including the server itself) can have one or more aliases configured. 

Aliases for 32-bit applications are configured independently of the aliases for 64-bit applications. 

In the example shown in the slide, the alias "AdvDev" has been created for the server 

"devserver.adventureworks.com" and utilizing the TCP/IP protocol with a custom TCP port of 51550. The 

client then only needs to connect to the name "AdvDev".

Other SQL Server Tools 

Key Points 


SQL Server provides a rich set of tools and utilities to make working with the product easier. 

The most commonly used tools are listed in the following table: 

Tool Purpose 

SQL Server Profiler Trace activity from client applications to SQL Server. Supports both the 

database engine and Analysis Services. 

Database Engine Tuning 

Advisor 

Master Data Services 

Configuration Manager 

Reporting Services 

Configuration Manager 

Data Quality Services 

Client 

SQL Server Error and 

Usage Reporting 

Design indexes and statistics to improve database performance, based on 

analysis of trace workloads. 

Configure and manage SQL Server Master Data Services. 

Configure and manage SQL Server Reporting Services. 

Configure and manage Data Quality Services knowledge-bases and 

projects. 

Configure the level of automated reporting back to the SQL Server 

product team about errors that occur and on usage of different aspects of 

the product. 

PowerShell Provider Allow configuring and querying SQL Server using PowerShell. 

SQL Server Management 

Objects (SMO) 

Provide a detailed .NET based library for working with management 

aspects of SQL Server directly from application code.


Demonstration 3A: Using SQL Server Profiler 







4. In the Server name text box, type (local), in the Authentication drop-down list, select Windows 

Authentication, and click Connect. 

5. From the Tools menu, click SQL Server Profiler. 


7. In the Server name text box, type (local), in the Authentication drop-down list, select Windows 

Authentication, and click Connect. 

8. In the Trace Properties window, click Run. Note this will start a new trace with the default options. 

9. Switch to SQL Server Management Studio, click New Query toolbar icon. 

10. In the Query window, type the query as shown in the snippet below, and click Execute toolbar icon: 

USE AdventureWorks; 

GO 

SELECT * FROM Person.Contact ORDER BY FirstName; 

GO 

11. Switch to SQL Server Profiler. Note the statement trace occurring in SQL Server Profiler then from the 

File menu and click Stop Trace.


12. In the Results grid, click individual statements to see the detail shown in the lower pane. 

13. Close SQL Server Management Studio and SQL Server Profiler without saving any changes. 

Question: What could you use captured trace files for?


Lab 1: Introduction to SQL Server and Its Toolset 

Lab Setup 

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must 

complete the following steps: 

• Revert the virtual machines as per the instructions in D:\10775A_Labs\Revert.txt. 

Lab Scenario 

AdventureWorks is a global manufacturer, wholesaler and retailer of cycle products. The owners of the 

company have decided to start a new direct marketing arm of the company. It has been created as a new 

company named Proseware, Inc. Even though it has been set up as a separate company, it will receive 

some IT-related services from the existing AdventureWorks company and will be provided with a subset 

of the corporate AdventureWorks data. The existing AdventureWorks company SQL Server platform has 

been moved to a new server that is capable of supporting both the existing workload and the workload 

from the new company. In this lab, you are ensuring that the additional instance of SQL Server has been 

configured appropriately and making a number of additional required configuration changes. 

Exercise 1: Verify SQL Server Component Installation 

A new instance of SQL Server has been installed by the IT department at AdventureWorks. It will be used 

by the new direct marketing company. The SQL Server named instance is called MKTG. In the first 

exercise, you need to verify that the required SQL Server components have been installed.

The main tasks for this exercise are as follows: 


1. Check that Database Engine and Reporting Services have been installed for the MKTG instance. 

2. Note the services that are installed for the default instance. 

3. Ensure that all required services including SQL Server Agent are started and set to autostart for both 

instances. 

Task 1: Check that Database Engine and Reporting Services have been installed for the 

MKTG instance 

• Open SQL Server Configuration Manager. 

• Check the installed list of services for the MKTG instance and ensure that the database engine and 

Reporting Services have been installed for the MKTG instance. 

Task 2: Note the services that are installed for the default instance 

• Note the list of services that are installed for the default instance. 

Task 3: Ensure that all required services including SQL Server Agent are started and set 

to autostart for both instances 

• Ensure that all the MKTG services are started and set to autostart. (Ignore the Full Text Filter Daemon 

at this time). 

• Ensure that all the services for the default instance are set to autostart. (Ignore the Full Text Filter 

Daemon at this time). 

Results: After this exercise, you have checked that the required SQL Server services are installed, 

started, and configured to autostart. 

Exercise 2: Alter Service Accounts for New Instance 

Scenario 

The SQL Server services for the MKTG instance have been configured to execute under the 

AdventureWorks\SQLService service account. In this exercise, you will configure the services to execute 

under the AdventureWorks\PWService service account. 


1. Change the service account for the MKTG database engine. 

2. Change the service account for the MKTG SQL Server Agent. 

Task 1: Change the service account for the MKTG database engine 

• Change the service account for the MKTG database engine service to AdventureWorks\PWService 

using the properties page for the service. 

Task 2: Change the service account for the MKTG SQL Server Agent 

• Change the service account for the MKTG SQL Server Agent service to AdventureWorks\PWService 

using the properties page for the service and then restart the service. 

Results: After this exercise, you have configured the service accounts for the MKTG instance.


Exercise 3: Enable Named Pipes Protocol for Both Instances 

Scenario 

Client applications that are installed on the server will connect to the database engine using the named 

pipes protocol. In this exercise, you will ensure that the named pipes protocol is enabled for both 

database engine instances. 


1. Enable the named pipes protocol for the default instance. 

2. Enable the named pipes protocol for the MKTG instance. 

3. Restart database engine services for both instances. 

Task 1: Enable the named pipes protocol for the default instance 

• If necessary, enable the named pipes protocol for the default database engine instance using the 

Protocols window. 

Task 2: Enable the named pipes protocol for the MKTG instance 

• If necessary, enable the named pipes protocol for the MKTG database engine instance using the 

Protocols window. 

Task 3: Restart both database engine services 

• If necessary, restart the default database engine instance. 

• If necessary, restart the MKTG database engine instance. 

• Check to ensure that both instances have been restarted successfully. 

Results: After this exercise, you should have ensured that the named pipes protocol is enabled for both 

database engine instances. 

Exercise 4: Create an Alias for AdvDev 

Scenario 

One badly-written monitoring application has been installed on the server. Unfortunately, it requires a 

hard-coded server name of AdvDev. In this exercise, you will configure and test an alias for AdvDev that 

points to the MKTG server. Use the Named Pipes protocol. Both 32 bit and 64 bit aliases should be 

configured. You will use SQL Server Management Studio to test the alias once it has been configured. 


1. Create a 32-bit alias (AdvDev) for the MKTG instance. 

2. Create a 64-bit alias (AdvDev) for the MKTG instance. 

3. Use SQL Server Management Studio to connect to the alias to ensure it works as expected. 

Task 1: Create a 32-bit alias (AdvDev) for the MKTG instance 

• Create a 32-bit alias for the MKTG instance. Call the alias AdvDev and connect via named pipes. Use 

the servername ".\MKTG".



• Create a 64-bit alias for the MKTG instance. Call the alias AdvDev and connect via named pipes. Use 

the servername ".\MKTG". 

Task 3: Use SQL Server Management Studio to connect to the alias to ensure it works as 

expected 

• Open SQL Server Management Studio. 

• Connect to the AdvDev alias. 

Results: After this exercise, you should have created and tested an alias for the named instance. 

Challenge Exercise 5: Ensure SQL Browser Is Disabled and Configure a 

Fixed TCP/IP Port (Only if time permits) 

Scenario 

Client applications will need to connect to the MKTG database engine instance via the TCP/IP protocol. As 

their connections will need to traverse a firewall, the port used for connections cannot be configured as a 

dynamic port. The port number must not change. Corporate policy at AdventureWorks is that named 

instances should be accessed via fixed TCP ports and the SQLBrowser service should be disabled. In this 

exercise, you will make configuration changes to comply with these requirements. A firewall exception has 

already been created for port 51550, for use with the MKTG database engine instance. 


1. Configure the TCP port for the MKTG database engine instance to 51550. 

2. Disable the SQLBrowser service. 

Task 1: Configure the TCP port for the MKTG database engine instance to 51550 

• Using the property page for the TCP/IP server protocol, configure the use of the fixed port 51550. 

(Make sure that you clear the dynamic port.) 

• Restart the MKTG database engine instance. 

• Ensure that the MKTG database engine instance has been restarted successfully. 

Task 2: Disable the SQLBrowser service 

• Stop the SQLBrowser service. 

• Set the Start Mode for the SQL Browser service to Disabled. 

Results: After this exercise, you will have configured a fixed TCP port for the MKTG database engine 

instance and disabled the SQLBrowser service.


Module Review and Takeaways 

Review Questions 

1. What is the difference between a SQL Server version and an edition? 

2. What is the purpose of the SQL Server Data Tools? 

3. Does Visual Studio need to be installed before SSDT? 

Best Practices 

1. Ensure that developer edition licenses are not used in production environments. 

2. Develop using the least privileges possible, to avoid accidentally building applications that will not 

run for standard users. 

3. If using an offline version of Books Online, ensure it is kept up to date. 

4. Ensure that service accounts are provisioned with the least workable permissions.

Module 2 

Preparing Systems for SQL Server 2012 

Contents: 

Lesson 1: Overview of SQL Server Architecture 2-3 

Lesson 2: Planning Server Resource Requirements 2-17 

Lesson 3: Pre-installation Testing for SQL Server 2-29 

Lab 2: Preparing Systems for SQL Server 2-35 

2-1

2-2 Preparing Systems for SQL Server 2012 


Before you start to deploy Microsoft® SQL Server®, it is important to plan appropriately for the 

deployment. As with almost any type of project, the installation work is always easier once good planning 

has occurred. 

To understand the requirements for SQL Server, you first need to gain an understanding of its 

architecture. In this module, you will see how SQL Server is structured and the requirements it places on 

the underlying server platform. 

Rather than implementing new hardware and software in a server, installing SQL Server on them, and then 

hoping that all will work as expected, a better approach is to test the server platform before deploying 

SQL Server. In this module, you will also see how to use tools that allow you to pre-stress the server 

platform to find out if it really is capable of supporting SQL Server applications. An approach that involves 

pre-testing can help to avoid the need to sort out server platform issues once SQL Server is deployed into 

production. 

Objectives 


• Describe the SQL Server architecture. 

• Plan for server resource requirements. 

• Conduct pre-installation stress testing for SQL Server.

Lesson 1 

Overview of SQL Server Architecture 


Before you start to look at the resources that SQL Server requires from the underlying server platform, you 

need to gain an understanding of how SQL Server functions, so that you can understand why each of the 

resource requirements exists. To be able to read SQL Server documentation, you also need to become 

familiar with some of the terminology used when describing how the product functions. 

The most important resources that SQL Server utilizes from a server platform are CPU, memory, and I/O. 

In this lesson, you will see how SQL Server is structured and how it uses each of these resources. 

Objectives 


• Describe SQL Server architecture. 

• Explain CPU Usage by SQL Server. 

• Describe the role of parallelism. 

• Explain how 32 bit and 64 bit servers differ with respect to SQL Server. 

• Describe how SQL Server uses memory. 

• Describe the difference between physical and logical I/O.


SQL Server Architecture 

Key Points 

SQL Server is constructed from a series of many small components that work together. Three general 

categories of components exist within the database engine and are structured as layers: Query Execution 

(or also referred as the Relational Engine), Storage Engine, and SQL OS. 

Query Execution Layer 

As well as managing the query optimization process, the Query Execution layer manages connections and 

security. A series of sub-components help it to work out how to execute your queries: 

• The Parser checks that you have followed the rules of the T-SQL language and outputs a syntax tree, 

which is a simplified representation of the queries to be executed. The parser outputs what you want 

to achieve in your queries. 

• The Algebrizer converts the syntax tree into a relational algebra tree, where operations are 

represented by logic objects rather than words. The aim of this phase is to take the list of what you 

want to achieve, and convert it to a logical series of operations that represent the work that needs to 

be performed. 

• The Query Optimizer then considers the different ways that your queries could be executed and finds 

an acceptable plan, based on the costs of each operation. The costs are based on the required 

operation and the volume of data that needs to be processed which is calculated based upon the 

distribution statistics. For example, the Query Optimizer considers the data that needs to be retrieved 

from a table and the indexes that are available on the table, to decide how to access the data in the 

table. It is important to realize that the Query Optimizer does not always look for the lowest cost plan. 

In some situations, finding the lowest cost plan might take too long. Instead, the Query Optimizer 

finds a plan which it considers satisfactory. The Query Optimizer also manages a query plan cache so 

that it can avoid the overhead of performing all this work, when another similar query is received for 

execution.

Storage Engine Layer 


The Storage Engine layer manages the data that is held within databases. The main responsibilities of the 

Storage Engine layer are to manage how data is stored both on disk and in memory, to manage how the 

data is cached for reuse, and to manage the consistency of data through locking and transactions. The 

main sub-components of the Storage Engine layer are as follows: 

• The Access Methods component is used to manage how data is accessed. For example, the Access 

Methods component works with scans and seeks and lookups. 

• The Page Cache manages the storage of cached copies of data pages. Caching of data pages is used 

to minimize the time it takes to access data pages. The Page Cache places data pages into memory, 

so they are present when needed for query execution. 

• The Locking and Transaction Management components work together to maintain consistency of 

your data, including the maintenance of transactional integrity with the help of the database log file. 

SQL OS Layer 

SQL OS is the layer of SQL Server that provides operating system functionality to the SQL Server 

components. All SQL Server components use programming interfaces provided by SQL OS to access 

memory, to schedule tasks, or to perform I/O. 

The abstraction layer provided by SQL OS avoids the need for resource-related code to be present 

throughout the SQL Server database engine code. The most important functions provided by this layer 

are memory management and scheduling. These two aspects are discussed in more detail later in this 

lesson. 

Question: Why does SQL Server need to optimize queries? 

Question: What do you imagine that cost based optimization means and can you imagine 

other ways that queries could be optimized (apart from cost based)?


CPU Usage by SQL Server 

Key Points 

All work that is performed within the Windows® operating system is based on the execution of threads. 

Windows uses pre-emptive scheduling of threads to maintain control. Rather than requiring threads to 

voluntarily give up control of the CPU, preemptive systems have a clock that is used to interrupt threads 

when their allocated share of CPU time has completed. Threads are considered to have encountered a 

context switch when they are preempted. 

SQL Server Threads 

SQL Server retrieves threads from Windows. A SQL Server configuration setting (max worker threads) 

determines how many threads will be retrieved. SQL Server has its own internal scheduling system, 

separate from the scheduling that is performed by the operating system. Instead of using Windows 

threads directly, SQL Server creates a pool of worker threads that are mapped to Windows threads 

whenever work needs to be performed. 

Whenever a SQL Server component needs to execute code, the component creates a task which 

represents the unit of work to be done. For example, if you send a batch of T-SQL commands to the 

server, it is likely that your batch of commands will be executed within a task. 

When a task is created, it is assigned the next available worker thread that is not in use. If no worker 

threads are available, SQL Server will try to retrieve another Windows thread, up to the point that the max 

worker threads configuration limit is reached. At that point, the new task would need to wait to get a 

worker thread. 

All tasks are scheduled by the SQL Server scheduler until they are done.

Affinity Mask 


Schedulers can be enabled and disabled by setting the CPU affinity mask on the instance. The affinity 

mask is a configurable bitmap that determines which CPUs from the host system should be used for SQL 

Server, and can be changed without the need for rebooting. By default, SQL Server will assume that it can 

use all CPUs on the host system. While it is possible to configure the affinity mask bitmap directly by using 

sp_configure, use the properties window for the server instance in SSMS to modify processor affinity. 

Note Whenever the term CPU is used here in relation to SQL Server internal architecture, 

it refers to any logical CPU, regardless of whether core or hyperthreading CPUs are being 

used. Note also that SQL Server licensing is currently based on physical CPU sockets rather 

than on logical CPUs. If affinity settings are used to violate SQL Server licensing limits, the 

system detects this at startup and logs details about the violation in the event log. 

Waiting for Resources 

One concept that might be difficult to grasp at first is that most SQL Server tasks spend most of their time 

waiting for something external to happen. Most of the time, it is I/O or the release of locks that they are 

waiting for but it can be other system resources. 

When a task needs to wait for a resource, it is placed on a waiting list until the resource is available. When 

the resource is available, the task is signaled that it can continue, however it still needs to then wait for 

another share of CPU time. This allocation of CPUs to resources is a function of the SQL OS. 

SQL Server keeps detailed internal records of how long tasks spend waiting and of the types of resources 

they are waiting for. You can see these details by querying the following system views: 

sys.dm_os_waiting_tasks; 

sys.dm_os_wait_stats; 

The use of these views will be described in Module 18. 

Question: Why would analyzing waits be an important instrument for monitoring SQL Server 

performance?


Parallelism 

Key Points 

SQL Server normally executes queries using sequential plans on a single task. To reduce overall execution 

time, SQL Server can decide to distribute queries over several tasks so that it can execute the tasks in 

parallel. 

Parallel Execution Plans 

Parallel execution involves the overhead of synchronizing the tasks and monitoring the tasks. Because of 

this overhead, SQL Server only considers parallel plans for expensive queries, where the advantages 

outweigh the additional overhead. 

The Query Optimizer decides whether a parallel plan should be used, based on two aspects of the query 

and of the system configuration: 

• A value called the Maximum Degree of Parallelism (MAXDOP) determines a limit for how many CPUs 

can be used to execute a query. 

• Another value called the Cost Threshold for Parallelism determines the cost that a query must meet 

before a parallel query plan will even be considered. 

If a query is expensive enough to consider a parallel plan, SQL Server still might decide to use a sequential 

plan that is lower in overall cost.

Controlling Parallelism 


The Query Optimizer only creates a parallel plan but is not involved in deciding the MAXDOP value. The 

MAXDOP value can be configured at the server level and can also be overridden at the query level via a 

query hint. Even if the Query Optimizer creates a parallel query plan, the Execution Engine might decide 

to only use a single CPU, based on the resources available when it is time to execute the query. 

Note In earlier versions of SQL Server, it was common to disable parallel queries on 

systems that were primarily used for transaction processing. This limitation was 

implemented by setting the server setting for MAXDOP to the value 1. In current versions of 

SQL Server, this is no longer generally considered a good practice. 

Question: Why would parallel plans involve an overhead?


32 bit vs. 64 bit Servers 

Key Points 

Virtual Address Space (VAS) is the total amount of memory that an application as SQL Server could 

possibly refer to in Windows. The VAS depends upon the configuration of the server. 

32 bit Systems 

32 bit systems have a VAS of 4GB. By default, half the address space (2GB) is reserved for the system and 

is known as kernel mode address space. The other half of the VAS (2GB) is available for application to use 

and is known as the user mode address space. It is possible to change this proportion by using a /3GB 

switch in the boot.ini file of the operating system (on earlier operating systems) or by using the bcdedit 

program to edit the Boot Configuration Datastore (on more recent operating systems). Once the /3GB 

switch has been configured, 1GB of VAS is allocated for the kernel and 3GB of the VAS is allocated for 

applications. 

Note More fine grained control of the allocated space can be achieved by using the 

/USERVA switch instead of the /3GB switch. The /USERVA switch allows the configuration of 

any value between 2GB and 3GB for user applications.

64 bit Systems 


Database systems tend to work with large amounts of data and need large amounts of memory, so that 

the systems can serve large numbers of concurrent users. SQL Server needs large amounts of memory for 

caching queries and data pages. A limit of 2GB to 3GB for VAS is a major constraint on most current 

systems. As is the case with most database engines, SQL Server is best installed on a 64 bit version of 

Windows instead of a 32 bit version. 

It is best to install a 64 bit version of SQL Server on a 64 bit version of Windows. Full 64 bit systems offer a 

VAS of 8TB. 

It is possible (but less desirable) to install a 32 bit version of SQL Server on a 64 bit version of Windows. 

This configuration provides a full 4GB of VAS for the 32 bit applications and is based on the Windows on 

Windows (WOW) emulation technology. 

64 bit System Limitations 

Not all current systems can be implemented as 64 bit systems. The most common limitation is the 

availability of data providers. If special data providers are needed to connect SQL Server to other systems 

(particularly through the linked servers feature), it is important to check that the required data providers 

are available in 64 bit versions. For example, the JET engine provider is currently only available as a 32 bit 

provider. 

Question: Why is data caching so important for database engines like SQL Server?


Overview of SQL Server Memory 

Key Points 

The main memory object of SQL Server is known as the Buffer Pool. The Buffer Pool is divided into 8KB 

pages; the same size as data pages within a database. The Buffer Pool is comprised of three sections: 

• Free Pages: Pages that are not used yet and are kept to satisfy new memory requests. 

• Stolen Pages: Pages that are used (formally referred to as stolen) by other SQL Server components 

such as the Query Optimizer and the Storage Engine. 

• Data Cache: Pages that are used for caching database data pages. All data operations are performed 

in the Data Cache. If query wants to select data from a specific data page, the data page is moved 

into the Data Cache first. Also, data modification is only ever performed in memory. Modifications are 

never performed directly on the data files. Changes that are made to pages result in the pages being 

considered dirty and the dirty pages are written to the database by a background process known as a 

Checkpoint. 

The Data Cache implements a least recently used (LRU) algorithm to determine candidate pages to be 

dropped from the cache as space is needed, after they have been flushed to disk (if necessary) by the 

Checkpoint process. The process that performs the task of dropping pages is known as the Lazy Writer. 

The Lazy Writer performs two core functions. By removing pages from the Buffer Cache, the Lazy Writer 

attempts to keep sufficient free space in the Buffer Cache for SQL Server to operate. The Lazy Writer also 

monitors the overall size of the Buffer Cache to avoid taking too much memory from the Windows 

operating system.

SQL Server Memory and Windows Memory 


The memory manager within SQL OS allocates and controls the memory used by SQL Server. It does this 

by checking the available memory on the Windows system, calculating a target memory value, which is 

the maximum memory that SQL Server can use at that point in time, to avoid a memory shortage at the 

Windows operating system level. SQL Server is designed to respond to signals from the Windows 

operating system that indicate a change in memory needs. 

As long as SQL Server stays within the target memory, it requests additional memory from Windows when 

needed. If the target memory value is reached, the memory manager answers memory requests from 

components by freeing up the memory of other components. This can involve evicting pages from caches. 

The target memory value can be controlled via the Min and Max Server Memory options. 

Question: What is the purpose of an LRU algorithm?


Physical vs. Logical I/O 

Key Points 

A logical I/O occurs when a task can retrieve a data page from the Buffer Cache. When the requested 

page is not present in the Buffer Cache, it must first be read into the Buffer Cache from the database. This 

database read operation is known as a physical I/O. 

Physical I/O Minimization 

From an overall system performance point of view, two I/O aspects must be minimized: 

• You need to minimize the number of physical I/O operations. 

• You need to minimize the time taken by each I/O operation that is still required. 

Minimizing the number of physical I/O operations is accomplished by: 

• Providing enough memory for the data cache. 

• Optimizing the physical and logical database layout including indexes. 

• Optimizing queries to request as few I/O operations as possible. 

One of the major goals of query optimization is to reduce the number of logical I/O operations. The side 

effect of this is the reduction in the number of physical I/O operations. 

Note Logical I/O counts can be difficult to interpret as certain operations can cause the 

counts to be artificially inflated, due to multiple accesses to the same page. However, in 

general, lower counts are better than higher counts.

Monitoring Query I/O Operations 


Both logical and physical I/O operation counts can be seen for each query by setting the following 

connection option: 

SET STATISTICS IO ON; 

The overall physical I/O operations that are occurring on the system can be seen by querying the 

sys.dm_io_virtual_file_stats system function. The values returned by this function are cumulative from the 

point that the system was last restarted. 

Question: Why should the logical and not the physical I/O be optimized when optimizing 

queries?


Demonstration 1A: CPU and Memory Configurations in SSMS 



2. In the virtual machine, click Start, click All Programs, click Microsoft SQL Server 2012, click SQL 

Server Management Studio. In the Connect to Server window, type Proseware and click Connect. 

From the File menu, click Open, click Project/Solution, navigate to 

D:\10775A_Labs\10775A_02_PRJ\10775A_02_PRJ.ssmssln and click Open. 

3. From the View menu, click Solution Explorer. Open and execute the 00 – Setup.sql script file from 

within Solution Explorer. 

4. Open the 11 – Demonstration 1A.sql script file. 

5. Follow the instructions contained within the comments of the script file.

Lesson 2 

Planning Server Resource Requirements 


Now that you have an understanding of how SQL Server executes queries, it is time to plan appropriate 

resources to support the installation of SQL Server on a server platform. 

Installing SQL Server will be much easier if you have already planned the installation appropriately. 

Objectives 


• Describe the planning process. 

• Plan CPU requirements. 

• Plan memory requirements. 

• Plan network requirements. 

• Plan storage and I/O requirements.


Introduction to Planning Server Resource Requirements 

Key Points 

Planning server resource requirements is not an easy task. There is no easy formula that allows you to 

calculate resource requirements based on measures such as database size and the number of connections, 

even though you may see references to these at times. Some application vendors provide sizing tools that 

can provide a starting point but even these tools need to be used with caution. 

Application Provider 

As a first step it is always good to speak with the provider of the application that needs to be installed on 

the server. If the provider is an Independent Software Vendor (ISV), the provider will often have reference 

installations available that can be used as a starting point for sizing resource requirements. In particular, 

case studies are often useful as most include documentation of the server platforms that they were 

performed on. 

Simulated Production Testing 

The second phase of resource planning should include the testing of different configurations. For success 

in this phase, it is important to have defined the goals that need to be achieved. These goals should be 

defined at a business level such as "How long should it take to save a new order?" rather than at a system 

level such as "How long should an individual I/O operation take?". 

Part of this testing phase should also include testing of the predicted further growth. Do not just test the 

systems in the proposed initial configuration. Test how the systems perform with a database populated to 

the size that the database is likely to grow to, during the life of the server platform.

Monitoring Production 


The planning process should not end when the system is installed. It is important to establish a process of 

ongoing monitoring and corrective actions, to make sure that the goals that were stated are still being 

met. 

Question: Why is it important to perform tests for capacity planning?


Discussion: Previous Exposure to Resource Planning 

Key Points 

Resource Planning is an important part of new installations. 

Question: What is your experience with planning of new systems? 

Question: How successful was the planning?

Planning CPU Requirements 

Key Points 


CPU utilization largely depends upon the types of queries that are running on the system. Processor 

planning is often considered as relatively straightforward in that few system architectures provide fine 

grained control of the available processor resources. Testing with realistic workloads is the best option. 

Note Many technical whitepapers suggest that a sustained 50 percent CPU load is 

acceptable. The experience of the course authors is that average utilizations above 30 

percent lead to very sluggish systems, when combined with common workloads. Peaks that 

do not last for long are acceptable, regardless of the target percentage. 

Increasing the number of available CPUs will provide SQL Server with better options for creating parallel 

query plans. Even without parallel query plans, SQL Server workloads tend to make good use of multiple 

processors when working with simple query workloads from a large number of concurrent users. Parallel 

query plans are particularly useful when large amounts of data are being scanned within large data 

warehouses. 

Try to ensure that your server is dedicated to SQL Server whenever possible. Most servers that are running 

production workloads on SQL Server should have no other significant services running on the same 

system. This particularly applies to other server applications such as Microsoft Exchange Server.


NUMA 

Many new systems are based on Non-Uniform Memory Access (NUMA) architectures. In a traditional 

symmetric multiprocessing (SMP) system, all CPUs and memory are bound to a single system bus. The bus 

can become a bottleneck when additional CPUs are added. On a NUMA based system, each set of CPUs 

has its own bus complete with local memory. In some systems, the local bus might also include separate 

I/O channels. These CPU sets are called NUMA nodes. Each NUMA node can access the memory of other 

nodes but the local access to local memory is much faster. The best performance is achieved if the CPUs 

mostly access their own local memory. Windows and SQL Server are both NUMA aware and try to make 

use of these advantages. 

Optimal NUMA configuration is highly dependent on the hardware. Special configurations in the system 

BIOS might be needed to achieve optimal performance. It is crucial to check with the hardware vendor for 

the optimal configuration for a SQL Server on the specific NUMA based hardware.

Planning Memory Requirements 

Key Points 


You saw earlier in the module how dependent SQL Server is on available memory, when trying to achieve 

high performance. Caches are used to reduce I/O and CPU usage and to store query plans so that the cost 

of compiling queries to produce query plans can be avoided, when queries are reused. 

SQL Server also uses memory while queries are being executed. Each user that is executing a query needs 

a separate memory space known as an execution context that holds the local memory-based data for that 

user. 

A lack of memory can appear to be a lack of other resources. For example, a lack of memory could cause 

the caching mechanisms to work ineffectively. This could result in high degrees of CPU and I/O load, as 

the system constantly recompiles queries that have been evicted from the Plan Cache or as the system 

constantly re-reads data from the database, after the data pages have been evicted from the Data Cache. 

This means that a lack of available memory could appear, on the surface, to be a lack of CPU or I/O 

requirements.


Planning Memory Requirements 

Planning memory required on a system involves planning not only for the SQL Server instance, but also 

for other services running on the system. Software vendors can often supply guidelines about the memory 

requirements of their products. Every system behaves differently, even when running the same 

application, so the experiences of similar installations can only be used as guidelines. 

As mentioned earlier in the lesson, the system must be tested in a real live scenario with all other services 

running that would be installed on the production system. 

Note Some external applications might run only from time to time but request a lot of 

memory when they are first started. SQL Server Integration Services and Anti-virus scanning 

programs are common examples of these. 

Question: What are some of the potential symptoms of memory shortage?

Planning Network Requirements 

Key Points 


The required network throughput needs to be planned and tested. As mentioned with other resources, 

testing the requirements in simulated production environments is important. For many servers, a single 

network adapter will not provide sufficient throughput, so you should consider the use of multiple 

network adapters. 

Network Adapter Throughput 

When reviewing the specifications of network adapters, keep in mind that most low-level network 

protocols (such as the Ethernet protocol) work on a basis where collisions can occur but are detected and 

recovered. This means that the networks work well when lightly loaded but quickly become unusable as 

loads increase because collisions become frequent and more time is spent recovering from collisions than 

in performing network I/O. As an example, most Ethernet based networks start to saturate at around 10% 

of their stated speed.


Other Services and Applications 

Besides planning and testing the network throughput needed to the application servers and clients it is 

also important to plan for other operations that need the network on the system. Often these operations 

are forgotten while planning and evaluating new systems. But operations like performing backups to 

network shares or moving backup devices to backup storages are operations that produce high volumes 

of network I/O. This can slow down network connections to application servers and clients. If this slow 

down becomes severe, client applications can start to suffer timeouts and failures. 

Therefore such operations must also be planned for and tested. Allocating a dedicated network 

connection for such administrative purposes is an option worth considering. 

Other SQL Server features such as database mirroring and replication might also need dedicated 

connections to perform effectively. 

Note Database mirroring and replication are advanced features outside the scope of this 

course. 

Question: Why might backups interrupt or slow down user workloads?

Planning Storage and I/O Requirements 

Key Points 


Planning and testing the storage is one of the most important tasks during the planning phase. Current 

I/O systems are very complex in nature. Planning and testing will often involve a team of people, each 

with a specific skillset. The performance of SQL Server is tightly coupled to the performance of the I/O 

subsystem that it is using. 

Determining Requirements 

In the first phase of planning, the requirements of the application must be determined, including the I/O 

patterns that need to be satisfied. These I/O patterns include the frequency and size of reads and writes 

sent by the application. As a general rule, OLTP systems produce a high number of random I/O operations 

on the data files and sequential write operations on database log files. By comparison, data warehouse 

based applications tend to generate large scans on data files. 

Storage Styles 

The second planning phase involves determining the style of storage to be used. With direct attached 

storage (DAS), it is easier to get good predictable performance. On storage area network (SAN) systems, 

more work is often required to get good performance, but SAN storage typically provides a wide variety 

of management capabilities. 

One particular challenge for SQL Server administrators is that SAN administrators are generally more 

concerned with the disk space that is allocated to applications rather than the performance requirements 

of individual files. Rather than trying to discuss file layouts with a SAN administrator, try to concentrate on 

discussing your performance requirements for specific files. Leave the decisions about how to achieve 

those goals to the SAN administrator. That is, focus on what is needed in these discussions rather than on 

how it can be achieved.


RAID Systems 

In SAN based systems, you will not often be concerned about the RAID levels being used. If you have 

specified the required performance on a file basis, the SAN administrator will need to select appropriate 

RAID levels and physical disk layouts to achieve that. 

For DAS storage, become aware of different RAID levels. While other RAID levels exist, RAID levels 1, 5, 

and 10 are the most common RAID levels that are in use on SQL Server systems. 

Number of Spindles 

For most current systems, the number of drives (or spindles even though the term is now somewhat 

dated), will matter more than the size of the disk. It is easy to find large disks that will hold substantial 

databases but often a single large disk will not be able to provide sufficient I/O operations per second or 

enough data throughput (MB/sec) to be workable. Solid state drive (SSD) based systems are quickly 

changing the available options in this area. 

Drive Caching 

Read caching within disk drives is not particularly useful as SQL Server already manages its own caching 

system and it is unlikely that SQL Server will re-read a page that it has recently written, unless the system 

is low on memory. Write caches can substantially improve SQL Server I/O performance, but make sure 

that hardware caches guarantee a write, even after a system failure. Many drive write caches cannot 

survive failures and can lead to database corruptions. 

Note The placement of files on disk systems will be discussed in a later module. 

Question: Why is it better to spread a database over several disks rather than one large disk?

Lesson 3 

Pre-installation Testing for SQL Server 


One common problem that occurs in database server deployments occurs when the server platform is 

delivered and installed and immediately commissioned once SQL Server is installed on it. 

There are many subtle problems that can cause errors on server systems, particularly problems related to 

the I/O subsystems. These I/O subsystems are often very complex and the interaction between 

components of the systems can be hard to evaluate. 

A preferred option is to perform pre-installation stress testing of the systems, using activity that is similar 

to the activity generated by SQL Server. Tools such as SQLIOSIM provide the ability to generate 

representative I/O loads without the need to actually run SQL Server applications. In this lesson, you will 

see how to use SQLIOSIM for general testing and how to use another utility called SQLIO, for specific 

types of I/O testing. 

Objectives 


• Perform pre-installation testing. 

• Perform pre-checks of I/O subsystems. 

• Work with SQLIOSIM. 

• Work with SQLIO.


Overview of Pre-installation Testing 

Key Points 

Any testing that you perform prior to the commissioning of a new system should resemble the final 

production usage as closely as possible. In particular, ensure that database sizes and workloads are typical 

of what is to be expected over the life of the system. 

Planning is not a one-off activity. After the first round of tests is complete, the results need to be fed back 

into another round of planning processes. 

Documentation 

One key aspect that is often lacking in many organizations is the documentation of planning and testing 

processes. When you have a need some time in the future to work out if something about the system has 

changed, you will be glad that you documented the process and documented details of every test case 

that you ran. 

Question: Why is it important to document and archive the tests run on the system?

Perform Pre-checks of I/O Subsystems 

Key Points 


As with other aspects of pre-installation testing, it is important that the testing of the I/O subsystem is 

representative of the expected load. In particular, it is important to make sure that the types of I/O 

operations that you are expecting are part of your tests. 

Online transaction processing (OLTP) systems tend to have a large number of smaller random reads and 

writes. Online analytical processing (OLAP) systems tend to have larger and more sequential reads and 

writes than OLTP systems. 

Do not test with single files. Make sure that the number of files you use in the testing is also similar to 

your production configuration. 

Determining Saturation Points 

For most resources, the saturation point of the resource is apparent when the time taken to retrieve 

results starts to climb but the amount of work being achieved stays stationary. 

Question: Why is it better to spread a database over several disks compared to one bigger 

disk?


Introducing SQLIOSIM 

Key Points 

SQLIOSIM is an unsupported utility that can be downloaded from http://download.microsoft.com. 

SQLIOSIM is designed to simulate the activity generated by SQL Server without the need to have SQL 

Server installed. This capability makes SQLIOSIM a good tool for pre-testing of server systems that are 

targets for running SQL Server. 

SQLIOSIM is a standalone tool that can be copied onto the system and executed. It does not need to be 

installed on the target system via an installer. SQLIOSIM has both GUI and command line execution 

options. 

Note SQLIOSIM replaces a number of previous tools with names such as SQLStress and 

SQLIOStress. 

While SQLIOSIM is useful for stress testing systems, it is not useful for general performance testing. The 

tasks that it performs vary between each execution of the utility, so no attempt should be made to 

compare the output of multiple executions directly, particularly in terms of timing. 

SQLIO is designed for repeatable performance testing and should be used instead of SQLIOSIM for this 

purpose.

Introducing SQLIO 

Key Points 


SQLIO is another unsupported utility that can be downloaded from http://download.microsoft.com. 

Unlike SQLIOSIM which is used for non-repeatable stress testing, SQLIO is a tool that is designed to create 

entirely repeatable I/O patterns. A configuration file is used to determine the types of I/O operations that 

need to be tested and SQLIO then tests those types of operations specifically. 

A common way to use SQLIOSIM and SQLIO together is to use SQLIOSIM to find issues with certain types 

of I/O operations, and to then use SQLIO to generate those specific problematic types of I/O operations, 

while attempting to resolve the issues. SQLIO is also a stand-alone tool that does not require SQL Server 

to be installed on the system. Furthermore it is advised to perform these tests before installation of SQL 

Server. SQLIO only checks one I/O type at a time. This makes the interpretation of the results the most 

important task. 

Question: What types of I/O will SQL Server mainly produce against data files of a typical 

OLTP system?


Demonstration 3A: Using SQLIOSIM & SQLIO 


1. If Demonstration 1A was not performed: 


• In the virtual machine, click Start, click All Programs, click Microsoft SQL Server 2012, click 

SQL Server Management Studio. In the Connect to Server window, type Proseware and click 

Connect. From the File menu, click Open, click Project/Solution, navigate to 


• From the View menu, click Solution Explorer. Open and execute the 00 – Setup.sql script file 

from within Solution Explorer. 



Lab 2: Preparing Systems for SQL Server 

Lab Setup 







3. In Connect to Server window, type Proseware in the Server name text box. 

4. In the Authentication drop-down list box, select Windows Authentication and click Connect. 




7. From the View menu, click Solution Explorer. In Solution Explorer, double-click the query 

00-Setup.sql. When the query window opens, click Execute on the toolbar. 

Lab Scenario 

You have reviewed the additional instance of SQL Server. A system administrator at AdventureWorks has 

expressed some concerns that the existing server may not have enough memory or I/O capacity to 

support this new SQL Server instance and is reviewing a new I/O subsystem. As the database 

administrator, you need to review the available server memory and the memory allocated to each of the 

existing SQL Server instances. You need to ensure that the I/O subsystem of the new server is capable of 

running SQL Server and the required workload correctly.


Supporting Documentation 

Required Memory Configuration 

• 1.5GB reserved for operating system. 

• 60% of the remaining memory as the maximum value for the AdventureWorks server instance. 

• 40% of the remaining memory as the maximum value for the Proseware server instance. 

• Configure minimum memory as zero for both instances. 

Required SQLIOSIM Configuration 

• Drive D with a 100MB data file that grows by 20MB increments to a 200MB maximum size. 

• Drive L with a 50MB log file that grows by 10MB increments to a 100MB maximum size. 

• Cycle Duration (sec) set to 60 seconds. 

• Delete Files at Shutdown should be selected. 

Required SQLIO Tests 

• Drive to be tested is D. 

• Test 64KB sequential reads for 60 seconds. 

• Test 8KB random writes for 60 seconds. 

Exercise 1: Adjust Memory Configuration 

Scenario 

The Adventure Works Marketing server has an existing default Microsoft SQL Server 2012 instance 

installed and the new MKTG instance. You need to check the total memory available on the server and 

how much memory has been allocated to each of the two existing SQL Server instances. You should then 

decide if the memory allocation is appropriate. If not, make the required changes to the memory 

configuration. 


1. Check total server memory. 

2. Check the memory allocated to the default instance. 

3. Check the memory allocated to the MKTG instance. 

4. Decide if the memory allocation is appropriate. If not, make the required changes to the memory 


Task 1: Check total server memory 

• Retrieve the installed memory (RAM) value from the properties of the computer. 

Task 2: Check the memory allocated to the default instance 

• Using the properties of the AdventureWorks server instance in SSMS, retrieve the minimum and 

maximum server memory settings.

Task 3: Check the memory allocated to the MKTG instance 


• Using the properties of the Proseware server instance in SSMS, retrieve the minimum and maximum 

server memory settings. 

Task 4: Decide if the memory allocation is appropriate. If not, make the required 

changes to the memory configuration 

• Review the Required Memory Configuration from the Supporting Documentation. 

• Alter the Memory Configuration for both SQL Server instances as per the requirements. You will need 

to work out how much memory should be used for all SQL Server instances and apportion the 

memory based on the requirements in the Supporting Documentation. 

Note While reducing the max server memory might require restarting SQL Server, there is 

no need to restart the servers at this point in the exercise. 

Results: After this exercise, you should have configured the memory for the SQL Server Instances. 

Exercise 2: Pre-installation Stress Testing 

Scenario 

After you have reviewed allocated memory on the server, you need to test whether the new I/O 

subsystem is capable of running SQL Server successfully. In this exercise, you need to use the SQLIOSIM 

utility for stress testing to ensure the stability of SQL Server performance. 


1. Configure SQLIOSIM. 

2. Execute SQLIOSIM. 

3. Review the results from executing SQLIOSIM. 

Task 1: Configure SQLIOSIM 

• Install SQLIOSIM from the file D:\10775A_Labs\10775A_02_PRJ\sqliosimx64.exe (Make sure that you 

use the Run as administrator option). 

• Configure SQLIOSIM as per requirements in the Supporting Documentation. 

Task 2: Execute SQLIOSIM 

• Execute SQLIOSIM based upon the configured parameters. 

Task 3: Review the results from executing SQLIOSIM 

• If any errors are returned in red, review the errors. 

• Locate the final summary for each of the drives and note the average I/O duration in milliseconds. 

Results: After this exercise, you have run a stress test using SQLIOSIM.


Challenge Exercise 3: Check Specific I/O Operations (Only if time permits) 

Scenario 

You have identified a specific list of I/O workloads and plan to test their performance on the new I/O 

subsystem. In this exercise, you need to run the SQLIO utility to verify the I/O workloads. 


1. Install the SQLIO Utility. 

2. Configure and Execute the SQLIO Utility. 

Task 1: Install the SQLIO Utility 

• Install the SQLIO Utility from the file D:\10775A_Labs\10775A_02_PRJ\SQLIO.msi (Choose to install for 

all users). 

Task 2: Configure and Execute the SQLIO Utility 

• Review the Supporting Documentation for details of the SQLIO tests to be performed. 

• Configure the file C:\Program Files (x86)\SQLIO\param.txt as per the requirements in the Supporting 

Documentation. 

• Execute the sqlio.exe program from within a command window, to test the I/O types as requested in 

the Supporting Documentation. For each test, record the IOPS and throughput achieved. Also note 

the minimum, maximum and average latency for each test. 

Results: After this exercise, you should have executed the SQLIO utility to test specific I/O 

characteristics.



1. What is the main reason that causes SQL Server to need a lot of memory? 

2. Why is pre-installation planning and testing important? 


1. Understand the architecture of SQL Server. 

2. Plan memory, CPU, network and I/O requirements for the specific system. 

3. Test these requirements against the available hardware. 


2-40 Preparing Systems for SQL Server 2012

Module 3 

Installing and Configuring SQL Server 2012 

Contents: 

Lesson 1: Preparing to Install SQL Server 3-3 

Lesson 2: Installing SQL Server 3-16 

Lesson 3: Upgrading and Automating Installation 3-24 

Lab 3: Installing and Configuring SQL Server 3-32 

3-1

3-2 Installing and Configuring SQL Server 2012 


In the previous module, you saw how to pre-stress your hardware systems to ensure they can run 

Microsoft® SQL Server®. In this module, you will see the steps involved in installing SQL Server. As with 

almost all projects, good planning is critical. You will see how to prepare for an installation and then look 

at how to perform the installation. 

There is a common need in larger enterprises to install many SQL Server instances but to make sure that 

the installations are performed in consistent way. You will see options for automating the installation of 

SQL Server, which can also be useful for silent installations of the product where SQL Server needs to be 

installed in the background to support a software application. 

Objectives 


• Prepare to install SQL Server. 

• Install SQL Server. 

• Upgrade and automate the installation of SQL Server.

Lesson 1 

Preparing to Install SQL Server 


Before starting the installation process for SQL Server, it is important to have discovered how each of the 

requirements for a successful installation can be met. In this lesson, you will consider the specific 

requirements that SQL Server places on the hardware and software platforms on which it runs, determine 

where database files should be placed, and how to configure service accounts. The aim for service 

accounts is to make sure they have enough privileges to operate but to minimize the allocation of any 

other privileges to the service accounts. Applications might require specific configuration of collations. 

You will investigate how collations operate and how the choices you make for configuring a server 

collation can affect your later usage of the system. 

Objectives 


• Describe the general hardware requirements for SQL Server. 

• Explain the memory requirements for SQL Server. 

• Describe the operating system requirements for SQL Server. 

• Describe other software that is required to support SQL Server. 

• Determine where to place database files. 

• Determine appropriate permissions and privileges for SQL Server service accounts. 

• Configure collations.


Hardware Requirements - General 

Key Points 

In earlier versions of SQL Server, it was necessary to focus on minimum requirements for processor, disk 

space and memory. Nowadays, discussing minimum processor speeds and disk space requirements for the 

SQL Server components is pointless. Even the slowest processor in a new laptop is now fast enough to 

meet the minimum requirements for SQL Server. 

Processors 

In Enterprise environments, the number of processors is now a much more significant issue. While it might 

seem desirable to add as many CPUs as possible, it is important to consider that there is a tradeoff 

between the number of CPUs and license costs. Furthermore, not all computer architectures support the 

addition of CPUs. Adding CPU resources might then require architectural upgrades to computer systems, 

not just the additional CPUs. 

While support for the use of Itanium processors existed for some components in earlier versions of SQL 

Server, SQL Server 2012 does not support the use of Itanium processors. 

Disk 

The hardware requirements for SQL Server list the required disk space to install the product. These values 

are usually not relevant, however, as the size of user databases generally makes the space occupied by the 

product irrelevant.


Disk subsystem performance, however, is critical. A "typical" SQL Server system today is I/O bound, if it is 

configured and working correctly. Note that a bottleneck is, in itself, not a bad thing. Any computer 

system that has any task that it needs to perform will have a bottleneck somewhere in the system. If 

another component of the server is the bottleneck (rather than the I/O subsystem), there is usually 

another underlying issue to resolve. It could be a lack of memory or something more subtle like a 

recompilation issue (that is, a situation where SQL Server is constantly recompiling code). Memory 

requirements for SQL Server are discussed in the next topic. 

Virtualization 

There is a strong resistance to SQL Server virtualization in the marketplace. While this resistance is rapidly 

decreasing, much of the resistance is outdated and misguided. Often, the resistance is based on 

assumptions about virtualization of the entire I/O subsystem. While virtualizing the server can provide a 

good outcome, virtualizing the entire I/O subsystem would rarely be a good solution when working with 

SQL Server. Virtualization of SQL Server will be discussed in a later module. 

Question: If you need to continue to support an older SQL Server version, what would be a 

good method of supporting it?


Hardware Requirements - Memory 

Key Points 

The availability of large amounts of memory for SQL Server to use is now one of the most important 

actors when sizing systems. 

While SQL Server will operate in relatively small amounts of memory, when memory configuration 

challenges arise they tend to relate to the maximum values, not to the minimum values. For example, the 

Express Edition of SQL Server will not utilize more than 1GB of memory, regardless of how much memory 

is physically installed in the system. 

64 bit and 32 bit Systems and Memory 

The majority of servers being installed today are 64 bit servers. The 64 bit servers have a single address 

space that can directly access large amounts of memory. 

The biggest challenge with 32 bit servers is that memory outside of the 4GB "visible" address space (that is 

the memory that can be directly accessed) is accessed via Address Windowing Extensions (AWE). 

Note While earlier versions of SQL Server allowed the use of AWE-based memory for the 

caching of data pages, SQL Server 2012 no longer supports the use of AWE-based memory. 

Question: Can you suggest a reason why a 32 bit server might still need to be implemented?

Software Requirements – Operating Systems 

Key Points 


The list in the slide shows a general summary of operating systems that are supported for SQL Server. 

While a version of SQL Server can be installed on many different operating systems, not all editions of SQL 

Server can be installed on each operating system. 

Client Systems 

Even though is it possible to install versions of SQL Server on the client operating systems, such as the 

Windows 7® (SP1) and Windows Vista® (SP2), the product is really designed for use on server operating 

systems such as the Windows Server® series of operating systems. 

Version Requirements 

Many higher-end editions of SQL Server also require higher-end editions of Windows. Consult Books 

Online for a precise list of supported versions and editions. 

32 bit applications can be installed on 64 bit operating systems, via the Windows on Windows (WOW) 

emulation system that is provided on the 64 bit operating systems. It is possible to install 32 bit versions 

of SQL Server on 64 bit operating systems but installing 64 bit versions of SQL Server on 64 bit operating 

systems is preferred. 

The installation of SQL Server on Windows Server Core is now supported.


Domain Controllers 

It is strongly recommended to avoid installing SQL Server on a domain controller. If you attempt to install 

SQL Server on a domain controller, the installation is not blocked but limitations are applied to the 

installation. 

• You cannot run SQL Server services on a domain controller under a local service account or a network 

service account. 

• After SQL Server is installed on a computer, you cannot change the computer from a domain member 

to a domain controller. You must uninstall SQL Server before you change the host computer to a 

domain controller. 

• After SQL Server is installed on a computer, you cannot change the computer from a domain 

controller to a domain member. You must uninstall SQL Server before you change the host computer 

to a domain member. 

• SQL Server failover cluster instances are not supported where cluster nodes are domain controllers. 

• SQL Server Setup cannot create security groups or provision SQL Server service accounts on a readonly 

domain controller. In this scenario, Setup will fail.

Software Requirements – General 

Key Points 


In earlier versions, the installer for SQL Server would preinstall most requirements as part of the 

installation process. This is no longer the case; the .NET Framework and Powershell need to be preinstalled 

before running setup. The installer for SQL Server will install the SQL Server Native Client (SNAC) and the 

SQL Server setup support files. However, to minimize the installation time for SQL Server, particularly in 

busy production environments, it is useful to have preinstalled these components in production 

environments during any available planned downtime. Components such as the .NET Framework often 

require a reboot after installation so the pre-installation of these components can further reduce 

downtime during installations or upgrades. 

General Software Requirements 

The SQL Server installer is based on the Windows Installer 4.5 technology. You should consider installing 

Windows Installer 4.5 prior to the installation of SQL Server, to minimize SQL Server installation time. 

Several components of SQL Server have a requirement for the Internet Explorer® browser. These 

components include the Microsoft Management Console (MMC) add-in, SQL Server Management Studio 

(SSMS), Business Intelligence Design Studio (BIDS), the Report Designer in BIDS, and any use of HTML 

Help. 

SQL Server communications can be based on the Shared Memory, Named Pipes, or TCP/IP protocols. The 

VIA protocol is no longer supported.


Determining File Placement 

Key Points 

The placement of database files will be discussed further in Module 4 along with details on the use of 

filegroups but before installing SQL Server, it is useful to understand the core concepts related to file 

placement. Filegroups are names that are given to sets of files. 

Primary and Secondary Data Files 

In general, if you have tables that are frequently used together, you should put them on separate 

filegroups and physical drives. You may need to alter this recommendation if the files are not similar in 

size. 

While one large disk might be capable of holding your data, it can only perform a single I/O at a time. 

Because of this, you need to consider not only how much disk space is available but how many physical 

drives (or "spindles") are needed to achieve the number of I/O operations per second that are required for 

your applications. 

tempdb 

The tempdb database is used to hold temporary objects in a SQL Server system. Place the tempdb 

database on a fast I/O subsystem to ensure good performance. Stripe the tempdb database across 

multiple disks for better performance. If possible, make sure that the tempdb database is located on 

separate disks to user databases. While the tempdb database can be located with the data in many 

situations, larger systems that make heavy use of tempdb should consider putting tempdb on a separate 

set of disks, to achieve extra performance. 

In general, you should match the number of tempdb files to the number of processors in the system (up 

to a reasonable limit of about eight), as this avoids contention issues with system structures in the files.

Transaction Logs 


Create the transaction log on a physically separate disk or RAID array. Transaction logs are written 

sequentially; therefore, using a separate, dedicated disk allows the disk heads to stay in place for the next 

write operation. For this reason, smaller systems will do well by using a single mirrored disk for the 

transaction log. A single mirrored physical disk should support up to approximately 1,000 transactions per 

second, depending on the speed of the disk itself. Systems requiring more than that should stripe the 

transaction log across a RAID 10 array for maximum performance. 

Question: How would you plan drives and file placement for your organization?


Service Account Requirements 

Key Points 

There is no single rule for how to best configure service accounts for use with SQL Server but there are a 

general set of principles that should typically be followed. 

Principle of Least Privilege 

The overarching principle is that service accounts should not be allocated any more capability than they 

require. While it is easy to make each service a domain administrator account, it is not sensible to do this 

from a security-related perspective. If you create an account with low privilege, the SQL Server installer 

will automatically configure the account with the necessary permissions and privileges needed by the 

service account. SQL Server does this by creating groups, assigning the required permissions to the 

groups, and then adding the service accounts as members of the groups. 

Domain vs. Local Accounts 

In most cases, you should use a domain account. There are circumstances though, where a local account 

might be more appropriate. This would involve situations where you wished to specifically limit the 

account's access to the local computer. 

If you do decide to use a local account rather than a domain account, it is important to realize that the 

Local Service account is not the same as the Local System account. The Local Service account is configured 

with the same permissions as other authenticated users, whereas the Local System account has 

administrative privileges, and should generally not be used as the service account for any SQL Server 

services.

Working with Collations 

Key Points 


Microsoft SQL Server 2012 supports many collations. A collation encodes the rules governing the proper 

use of characters for either a language, such as Greek or Polish, or an alphabet, such as Latin1_General 

(the alphabet used by Western European languages). 

Server Collation Selection 

When you install SQL Server, you designate a collation and select sort order rules. The term collation 

refers to a set of rules that determines how data is compared and sorted. Character data is sorted by using 

rules that define the correct sequence of characters. You can specify the sensitivity to case, accent marks, 

kana character types, and character width when sorting data. 

For example, should the word "AdventureWorks" be sorted as though it was identical to the word 

"adventureworks"? For a slightly more subtle example, should the word "café" be sorted as though it was 

identical to the word "cafe"? 

A particular impact of incorrect collation setting occurs when working with temporary objects that are 

created in the tempdb database. If an application database is configured with a different collation to the 

server, care must be taken with the use of temporary objects such as temporary tables. In Demonstration 

1A, you will see the effect that collations can have on the ability to execute queries involving temporary 

objects. 

Changing the server collation after installation is not a simple process. Each system structure that has been 

sorted (perhaps as part of indexes) needs to be rebuilt. All system databases need to be recreated. 

While it is possible to change the default collation for a user database after it has been created, the 

existing columns and data in the table are not affected. The default collation setting will only affect new 

objects that are created. 

SQL Server supports two types of collations: Windows collations and SQL Server collations.


Windows Collations 

When you designate Windows collations, the operating system defines a set of rules for storing and 

sorting character data that is based on the rules for an associated Windows locale. Windows collation 

rules specify which alphabet or language is used when dictionary sorting is applied and the code page 

used to store non-Unicode character data. 

SQL Server Collations 

When you designate SQL Server collations, SQL Server matches the attributes of common combinations of 

code page number and sort order that may have been specified in earlier versions of SQL Server. SQL 

Server collations control the code page used for storing non-Unicode data and sort rules for both 

Unicode and non-Unicode data. 

Each SQL Server collation specifies three properties: 

• The sort order to use for Unicode data types (such as nchar, nvarchar, and nvarchar(max)). 

• The sort order to use for non-Unicode character data types (char, varchar, and varchar(max)). 

• The code page used to store non-Unicode character data. 

SQL Server collations are maintained primarily for backward compatibility. When you are designing new 

applications, choose the appropriate Windows collation. 

SQL Server 2012 also introduced some new collations that support supplementary character sets. These 

are known as SC collations and support a much wider variety of characters. The SC collations are not 

supported as server collations but can be used within databases. You can identify an SC collation as it 

name ends with an _SC suffix. 

Question: What is the difference between an accent-sensitive collation and a non-accentsensitive 

collation?

Demonstration 1A: Using Collations 













Lesson 2 

Installing SQL Server 

Once the decisions have been taken about how SQL Server should be configured, you can proceed to 

installing SQL Server. In this lesson, you will see the phases that installation proceeds through, and then 

you will see how SQL Server checks your system for compatibility using a tool known as the System 

Configuration Checker. 

For most users, the setup program will report that all was installed as expected. For the rare situations 

where this does not occur, you will also learn how to carry out post-installation checks and 


Objectives 


• Describe the phases of the SQL Server installation process. 

• Explain the role of the System Configuration Checker. 

• Conduct post-installation checks.

Overview of the Installation Process 

Key Points 


You can install the required components of SQL Server 2012 by running the SQL Server 2012 Setup 

program. The exceptions to this are StreamInsight and Master Data Services, which need to be installed 

separately. StreamInsight and Master Data Services ship with separate installer programs. 

The main SQL Server 2012 installation process consists of two core phases: the component update and the 

SQL Setup MSI package. Understanding the installation process will help you plan and perform SQL Server 

2012 installations. 

Component Update 

During the component update phase of installation, the SQL Server 2012 Setup program checks for the 

following components: 

• Windows Installer 4.5 

• The .NET Framework 

• SQL Server Native Client (sqlncli.msi) 

• Windows PowerShell 

• Other SQL Server Setup support files


SQL Setup MSI 

After the component update phase, Windows Installer is used to install the SQL Setup MSI package. 

During this phase, Setup performs the following tasks: 

• Determines the installation type (default instance or named instance). 

• Analyzes the computer using the System Configuration Checker. 

• Determines the features to be installed (including the need for automatic updates if required) and 

performs the appropriate installation. 

The Instance ID field controls the name of the directories for where the features will be installed. By 

default it is the name of the instance but it can be changed. Changing to a Named Instance does not 

automatically change the Instance ID field if you have already typed in an Instance ID. 

Server Configuration 

The BUILTIN\Administrators group no longer gets administrative control in SQL Server, as it did in earlier 

versions. It is often acceptable however to add BUILTIN\Administrators as a group that should have 

administrative permissions, which means all administrators on the computer. Analysis Services is 

configured in a similar way. 

A common request from users is for the ability to block access to SQL Server for computer administrators. 

While avoiding the inclusion of the BUILTIN\Administrators group can prevent casual attempts to access 

the server's contents, you should not assume that computer administrators will not be able to access SQL 

Server if they are determined to do so. 

During the server configuration phase, you also have the opportunity to set a number of system 

configuration options such as whether or not the filestream feature should be enabled, and the default 

folders for use with user databases.

System Configuration Checker 

Key Points 


As part of SQL Server Setup, the System Configuration Checker (SCC) scans the computer where SQL 

Server will be installed. The SCC checks for conditions that prevent a successful SQL Server installation. 

Before Setup starts running the SQL Server Installation Wizard, the SCC retrieves the status of each check 

item, compares the result with required conditions, and provides guidance for removal of blocking issues. 

If a result would not block the installation of SQL Server but would limit the capabilities of the product 

once it was installed, you would be warned about the situation. 

Software Requirements 

In the Software Requirements phase, many aspects of the software configuration are checked, including 

whether the operating system present is a supported operating system for the version and edition of SQL 

Server being installed. The operating system service pack level is also checked and any unsupported 

operating system would block the setup from proceeding. 

Also, as part of the software requirements phase, the SCC checks for the presence of the Windows 

Management Instrumentation (WMI) service. The WMI service must be available. A failed check on this 

item will also block Setup. 

Hardware Requirements 

The SCC will warn the user but will not block Setup if the minimum or recommended RAM check is not 

met. Memory requirements are for SQL Server only, and do not reflect additional memory requirements of 

the operating system. 

The SCC will warn the user but will not block Setup if the minimum or recommended processor speed 

check is not met.


Security Requirements 

The user running Setup must have administrator privileges on the computer on which SQL Server is being 

installed. 

System State Requirements 

SQL Server Setup cannot run if files required by Setup are locked by other services, processes, or 

applications. A failed check on this item will block Setup. 

Report 

After completing these checks, the SCC generates a report that can be viewed or saved. This report 

includes information about any issues that will prevent installation and recommends solutions. It also 

includes warnings and recommendations—such as recommended hotfixes or security configurations—for 

issues that will not prevent installation but might cause problems. In most scenarios, you should resolve 

these issues and run Setup again rather than attempt to resolve them after installation is complete.

Post-installation Checks 

Key Points 


Once SQL Server has been installed, the most important check is to make sure that all SQL Server services 

are running, by using the SQL Server Services node in SQL Server Configuration Manager. 

Note SQL Server services have names that differ slightly compared to their displayed 

names. You can view the actual service name for a service by looking on the properties 

page for the service. 

Administrators typically do not need to check the contents of the SQL Server setup log files, after 

installation, as the installer program will indicate errors that occur and will attempt to reverse any of the 

SQL Server setup that has been completed to that point. 

Note When errors occur during the SQL Server Setup phase, the installation of the SQL 

Server Native Access Client and the Setup Components is not reversed. 

The setup log files are located here: 

%programfiles%\Microsoft SQL Server\110\Setup Bootstrap\Log 

Administrators typically only need to look at the setup log files in two situations: 

• when trying to work out why setup is failing if not enough error information is provided by the 

installer. 

• when working with Microsoft Product Support to troubleshoot a setup failure.


The log files have details for each of the three core phases. Books Online has details on what is contained 

in each section of the log files. 

Question: If you discover after installation that you have used an incorrect or inappropriate 

service account for SQL Server, which tool do you use to correct the account?

Demonstration 2A: Using System Configuration Checker 




2. In the Virtual Machines list in Hyper-V Manager, right-click the 10775A-MIA-SQL1 virtual machine 

and click Settings. 

3. In the Settings for 10775A-MIA-SQL1 window, in the Hardware list expand IDE Controller 1, and 

click DVD Drive. 

4. In the DVD Drive properties pane, click Image file, and click browse. 

5. Navigate to the file C:\Program Files\Microsoft Learning\1077XA\Drives\10775A-MIA-SQL1 

\Virtual Hard Disks\SQLFULL_ENU.iso and click Open. 

6. In the Settings for 10775A-MIA-SQL1 window, click OK. 

7. In the Virtual Machine window, in the AutoPlay window (which should now have popped up) click 

Run SETUP.EXE and wait for SQL Server Setup to start. 

8. In the SQL Server Installation Center window, click System Configuration Checker from the list of 

available options on the Planning tab. 

9. In the Setup Support Rules window, note the list of rules which have been checked. 

10. Click on the warning in the Status column for the Microsoft .NET Application Security rule. 

11. In the Rule Check Result window, read the details of the warning and click OK. 

12. In the Setup Support Rules window, click OK.


Lesson 3 

Upgrading and Automating Installation 

Rather than installing SQL Server, the product often needs to be upgraded from earlier versions. In this 

lesson, you will see the benefits and limitations of the available methods for performing upgrades. 

Not every installation of SQL Server is performed individually by an administrator. In larger enterprises, 

there is a need to be able to install many instances of SQL Server and to be able to install the instances in 

a very consistent manner. Unattended installation options are provided for SQL Server and can be used to 

satisfy the requirements of this scenario. Unattended installations can also be performed in a silent mode. 

This allows the installation of SQL Server to be performed during the installation of other applications. 

Objectives 


• Upgrade SQL Server. 

• Apply SQL Server hotfixes, cumulative updates and service packs. 

• Perform unattended installations.

Upgrading SQL Server 

Key Points 


There are two basic ways that SQL Server upgrades can be performed. There is no single preferred way to 

perform the upgrades. Each method has benefits and limitations, and is appropriate in certain 

circumstances. 

In-place Upgrades 

In-place upgrades occur when the installed version of SQL Server is directly replaced by a new version. 

This is an easier and highly automated method of upgrading but is riskier. If an upgrade fails, it is much 

harder to return to the previous operating state. The risk of this cannot be ignored for most customers. 

Note When you are considering risk, you need to consider that it may not be the SQL 

Server upgrade that fails. Even if the SQL Server upgrade works as expected, but then the 

application fails to operate as expected on the new version of SQL Server, the need to 

recover the situation quickly will be just as important. 

In-place upgrades have the added advantage of minimizing the need for additional hardware resources 

and in-place upgrades avoid the need to redirect client applications that are configured to work with the 

existing server.


Side-by-side Upgrades 

Side-by-side upgrades are a safer alternative as the original system is left in place and can be quickly 

returned to production should an upgrade issue arise. However, side-by-side upgrades involve more work 

and more hardware resources. 

To perform a side-by-side upgrade, you will need enough hardware resources to provide for both the 

original system and the new system. Two common risks associated with side-by-side upgrades relate to 

the time taken to copy all the user databases to a new location and the space required to hold these 

copies. 

While most side-by-side upgrades are performed on separate servers, it is possible to install both versions 

of SQL Server on the same server during a side-by-side upgrade. However, side-by-side upgrades of 

versions with the same major build number (ie: SQL Server 2008 R2 and SQL Server 2008) on the same 

server are a special case. Because the major version number is identical, separate versions of the shared 

components cannot co-exist on the same server. Shared components will be upgraded. 

Not all versions of SQL Server are supported when installed side-by-side. Consult Books Online for a 

matrix of versions that are supported when installed together. 

Hybrid Options 

It is also possible to use some elements of an in-place upgrade with elements of a side-by-side upgrade. 

For example, rather than copying all the user databases, after installing the new version of SQL Server 

beside the old version, and migrating all the server objects such as logins, you could detach user 

databases from the old server instance and reattach them to the new server instance. 

Note Once user databases have been attached to a newer version of SQL Server, they 

cannot be reattached to an older version again, even if the database compatibility settings 

have not been upgraded. This is a risk that needs to be considered when using a hybrid 

approach.

SQL Server Servicing 

Key Points 


As with all software products, issues can be encountered with SQL Server over time. The product group is 

very responsive in fixing issues that are identified. If you have issues that you wish to notify Microsoft of, 

or suggestions for how the product might be improved, please visit the site http://connect.microsoft.com. 

The simplest way to keep SQL Server up to date is to enable automatic updates from the Microsoft 

Update service. Larger organizations or those with strong change processes should exert caution in 

applying automatic updates. It is likely that the updates should be applied to test or staging environments 

before being applied to production environments. 

SQL Server updates are released in several ways: 

• Hotfixes (also known as QFE or Quick Fix Engineering) are released to address urgent customer 

concerns. Due to the tight time constraints, only limited testing is able to be performed on these fixes, 

so they should only be applied to systems that are known to be experiencing the issues that they 

address. 

• Cumulative Updates (or CUs) are periodic roll-up releases of hotfixes that have received further 

testing as a group. 

• Service Packs (or SPs) are periodic releases that full regression testing has been performed on. 

Microsoft recommend applying service packs to all systems after appropriate levels of organizational 

testing. 

• SQL Server 2008 R2 and later can also have product service packs slipstreamed into the installation 

process to avoid the need to apply service packs after installation.


Unattended Installation 

Key Points 

In many organizations, script files for standard builds of software installations are created by senior IT 

administrators and used to ensure consistent installations throughout the organizations. 

Unattended installations can help with the deployment of multiple identical installations of SQL Server 

across an enterprise. Unattended installations can also provide for the delegation of the installation to 

another person. 

Unattended Installation Methods 

One option for performing an unattended installation of SQL Server 2012 is to create an .ini file 

containing the required setup information and passing it as a parameter to setup.exe at a command 

prompt. A second alternative is to pass all the required SQL Server setup details as parameters to the 

setup.exe program, rather than placing the parameters into an .ini file. You can choose to use the .ini file 

or to use the separate parameters but a combination of both is not permitted. 

In both examples on the slide, the second method has been used. The first example shows a typical 

installation command and the second example shows how an upgrade could be performed using the 

same method. 

/q Switch 

The "/q" switch shown in the examples specifies "quiet mode" – no user interface is provided. An 

alternative switch "/qs" specifies "quiet simple" mode. In the quiet simple mode, the installation runs and 

shows progress in the UI but does not accept any input.


Creating an .ini File 

An .ini file for unattended installation can be created by using any text editor, such as Notepad. The SQL 

Server installation program creates a file called ConfigurationFile.ini in a folder that is named based upon 

the installation date and time, under the folder C:\Program Files\Microsoft SQL Server\110\Setup 

Bootstrap\Log. You can use this as a starting point for creating your own .ini file. The .ini file is composed 

of a single [Options] section containing multiple parameters, each relating to a different feature or 

configuration setting.


Demonstration 3A: Creating an Unattended Installation File 










2. Open the 31 – ConfigurationFile.ini file. 

3. Review the Configuration File, in particular note the values of the following properties: 

• INSTANCEID 

• ACTION 

• FEATURES 

• QUIET 

• QUIETSIMPLE 

• INSTALLSHAREDDIR 

• INSTANCEDIR 

• INSTANCENAME

• AGTSVCSTARTUPTYPE 

• SQLCOLLATION 

• SQLSVCACCOUNT 

• SQLSYSADMINACCOUNTS 

• TCPENABLED 



Lab 3: Installing and Configuring SQL Server 

Lab Setup 






3. In the Connect to Server window, type Proseware in the Server name text box. 







8. On the host system, in the Virtual Machines list in Hyper-V Manager, right-click the 

10775A-MIA-SQL1 virtual machine and click Settings. 



10. In the DVD Drive properties pane, click Image file, and click browse.


11. Navigate to the file C:\Program Files\Microsoft Learning\10775\Drives\10775A-MIA-SQL1 



Lab Scenario 

The development group within the company has ordered a new server for the work they need to do on 

the Proseware system. Unfortunately, the new server will not arrive for a few weeks and the development 

group cannot wait that long to start work. 

The new server that was provisioned by the IT Support department already has two instances of SQL 

Server installed. The support team has determined that the new server will be able to support an 

additional instance of SQL Server on a temporary basis, until the server for the development group arrives. 

You need to install the new instance of SQL Server and if you have time, you should configure the 

memory of all three instances to balance their memory demands, and you should create a new alias for 

the instance that you install. 


Required SQL Server Instance Configuration 

Item Configuration 

Instance Name MKTGDEV 

Features Database Engine only (excluding Full Text and Replication) 

Data File Folder D:\MKTGDEV for user databases and tempdb 

Log File Folder L:\MKTGDEV for user databases and tempdb 

Service Accounts AdventureWorks\PWService for all services 

Startup Both SQL Server and SQL Server Agent should start 

automatically 

Server Collation SQL_Latin1_General_CP1_CI_AS 

Authentication Mode Mixed 

Administrative User AdventureWorks\Administrator 

Filestream Support Disabled 

Note that Pa$$w0rd is used for all passwords in the course.


Required Memory Configuration (Used in Exercise 4 only) 

• 1.0GB reserved for operating system. 

• 40% of the remaining memory as the maximum value for the AdventureWorks server instance. 

• 30% of the remaining memory as the maximum value for the Proseware server instance. 

• 30% of the remaining memory as the maximum value for the PWDev server instance. 

• Configure minimum memory as zero for all instances. 

Exercise 1: Review Installation Requirements 

Scenario 

You will review the supporting documentation that describes the required configuration for the new 

instance. You will also create the required folders to hold the data and log files for the instance. 


1. Review the supporting documentation prior to installation. 

2. Create the folders that are required for the data and log files. 

Task 1: Review the supporting documentation prior to installation 

• Review the supplied requirements in the supporting documentation for the exercise. 

Task 2: Create the folders that are required for the data and log files 

• Based on the supplied requirements, create the folders that are required for the data and log files of 

the new SQL Server instance. 

Results: After this exercise, you should have read the requirements and created the two 

folders that are required. 

Exercise 2: Install the SQL Server Instance 

Scenario 

In this exercise, you need to perform an installation of another instance of SQL Server on the existing 

server based on the supplied specifications. In the setup steps for this lab, you have mounted an ISO file 

that contains an image of SQL Server that will be used to install the instance. Pre-requisites have already 

been installed as there are existing instances of SQL Server. 

The main task for this exercise is as follows: 

1. Based on the requirements reviewed in Exercise 1, install another instance of SQL Server.


Task 1: Based on the requirements reviewed in Exercise 1, install another instance of SQL 

Server 

• Install another instance of SQL Server based on the requirements in Exercise 1. 

Note On the Server Configuration page, you should configure the service account name 

and password, the startup type for SQL Server Agent, and the collation. On the Database 

Engine Configuration page, you should configure Mixed Mode, the sa password, Add 

Current User, Data Directories tab, and the Filestream tab. 

Results: After this exercise, you should have installed another SQL Server instance. 

Exercise 3: Perform Post-installation Setup and Checks 

Scenario 

You need to make sure that the services for the new instance are running and you need to create a new 

alias for the instance you have just installed. Once the instance is created, you should connect to the 

instance using SQL Server Management Studio to make sure that the instance works. 


1. Check that the services for the new SQL Server instance are running. 

2. Configure both 32 bit and 64 bit aliases for the new instance. 

3. Connect to the new instance using SSMS. 

Task 1: Check that the services for the new SQL Server instance are running 

• Using SQL Server Configuration Manager, make sure that the newly installed services are running. 

• Make sure that the named pipes protocol is enabled for the new instance. 

Task 2: Configure both 32 bit and 64 bit aliases for the new instance 

• Configure a 32 bit alias called PWDev for the new instance using named pipes. 

• Configure a 64 bit alias called PWDev for the new instance using named pipes. 

Task 3: Connect to the new instance using SSMS 

• Start SQL Server Management Studio and connect to the new instance to make sure it is working. 

Make the connection using the PWDev alias. 

Results: After this exercise, you should have checked that the services are running, created a new alias, 

and connected using SSMS. 

Challenge Exercise 4: Configure Server Memory (Only if time permits) 

Scenario 

There are now three SQL Server instances installed on the Marketing server at AdventureWorks. In this 

exercise, you need to configure the amount of memory that is allocated to each instance.



1. Review the current memory available on the server. 

2. Determine an appropriate memory allocation for each instance. 

3. Configure each instance appropriately. 

Task 1: Review the current memory available on the server 

• Review the current memory available on the server. 

Task 2: Determine an appropriate memory allocation for each instance 

• Review the required memory proportions as specified in the supporting documentation. 

• Determine an appropriate memory allocation for each instance. 

Task 3: Configure each instance appropriately 

• Configure each instance based on the values you have calculated. 

Results: After this exercise, you should have modified the memory allocation for each SQL Server 

instance.




1. Why is the choice of collation for a server so important, when you can choose individual database 

collations anyway? 

2. Should all SQL Server services use a single domain-based service account? 

Best Practices related to a particular technology area in this module 

1. Use domain-based accounts for service accounts. 

2. Configure service accounts for the least possible privilege that lets them still operate. 

3. Use SQL Server Configuration Manager to change service accounts as it will ensure that the correct 

permissions and ACLs are configured.

3-38 Installing and Configuring SQL Server 2012

Module 4 

Working with Databases 

Contents: 

Lesson 1: Overview of SQL Server Databases 4-3 

Lesson 2: Working with Files and Filegroups 4-15 

Lesson 3: Moving Database Files 4-29 

Lab 4: Working with Databases 4-39 

4-1

4-2 Working with Databases 


One of the most important roles for database administrators working with Microsoft® SQL Server® is the 

management of databases. It is important to know how data is stored in databases, how to create 

databases, and how to move databases either within a server or between servers. 

When databases become larger, there is a need to allocate the data from the database across different 

volumes, rather than storing the data in a single large disk volume. This allocation of data is configured 

using filegroups and is used to address both performance and ongoing management needs within 

databases. 

Objectives 


• Describe the role and structure of SQL Server databases. 

• Work with files and filegroups. 

• Move database files within servers and between servers.

Lesson 1 

Overview of SQL Server Databases 


Before you begin to create databases, you need to learn about how data is stored in databases, about the 

different types of files that SQL Server can utilize, where the files should be placed, and also learn how to 

plan for ongoing file growth. This will make sure that you configure databases optimally. 

In this lesson, you will also explore the system databases that are supplied with SQL Server. One system 

database in particular, tempdb, has very specific configuration requirements as the performance of 

tempdb has the potential to affect the performance of all applications that use the server. 

Objectives 


• Describe how data is stored in SQL Server. 

• Explain the different type of files that SQL Server can use. 

• Determine appropriate file placement and number of files for SQL Server databases. 

• Ensure sufficient file capacity and allow for ongoing growth. 

• Explain the role of each of the system databases supplied with SQL Server. 

• Configure tempdb.


How Data Is Stored in SQL Server 

Key Points 

The data stored by SQL Server databases is contained within a set of files allocated for the database to 

use. There are three types of files that are used by SQL Server: primary data files, secondary data files, and 

transaction log files. 

Primary Data Files 

The primary data file is the starting point of the database. Every database has a single primary data file. As 

well as holding data in the same way that other database files do, the primary data file holds pointers to 

the other files in the database. Primary data files typically use the file extension .mdf. While the use of this 

file extension is not mandatory, using .mdf as a file extension for primary data files is highly 

recommended. 

Secondary Data Files 

Secondary data files are optional, user-defined, additional data files that can be used to spread the data 

through more files for performance and/or maintenance reasons. Secondary files can be used to spread 

data across multiple disks by putting each file on a different disk drive. Additionally, if a database exceeds 

the maximum size for a single Windows file, you can use secondary data files so the database can 

continue to grow. The recommended extension for secondary data files is .ndf.

Data File Pages 


Pages in a SQL Server data file are numbered sequentially, starting with zero for the first page in the file. 

Each file in a database has a unique file ID number. To uniquely identify a page in a database, both the 

file ID and the page number are required. Each page is 8KB in size. After allowing for header information 

that is needed on each page, there is a region of 8096 bytes remaining for holding data. Data rows can 

hold fixed length and variable length column values. All fixed length columns of a data row need to fit on 

a single page, within an 8060 byte limit. Data pages only hold data from a single database object, such as 

a table or an index. 

Extents 

Groups of 8 contiguous pages are referred to as an extent. SQL Server uses extents to simplify the 

management of data pages. There are two types of extents: 

• Uniform extents: All pages within the extent contain data from only one object. 

• Mixed extents: The pages of the extent can hold data from different objects. 

The first allocation for an object is at the page level, and always comes from a mixed extent. If they are 

free, other pages from the same mixed extent will be allocated to the object as needed. Once the object 

has grown bigger than its first extent, then all future allocations are from uniform extents. 

In both primary and secondary data files, a small number of pages is allocated to tracking the usage of 

extents within the file. 

Log Files 

Log files hold information that is used to recover the database when necessary. There must be at least one 

log file for each database. The recommended extension for log files is .ldf. 

All transactions are written to the log file using the write-ahead logging (WAL) mechanism to ensure the 

integrity of the database in case of a failure and to support rollbacks of transactions. 

When data pages need to be changed, they are fetched into memory and changed in memory. The "dirty" 

pages are then written to the transaction log in a synchronous manner. At some time later, during a 

background process known as a "checkpoint" process, the dirty pages are written to the database files. For 

this reason, the pages that are contained in the transaction log are critical to the ability of SQL Server to 

recover the database to a known committed state. Transaction logs are discussed in detail in later 

modules in this course. 

Note The log file is also used by other features within SQL Server such as transactional 

replication, database mirroring, and change data capture. These are advanced topics that 

are out of scope for this course. 

Question: In what scenarios would secondary data files be useful?


Determining File Placement and Number of Files 

Key Points 

It is important to isolate log and data files for both performance and recovery reasons. This isolation 

needs to be at the physical disk level. 

Access Patterns 

The access patterns of log and data files are very different. Data access on log files consists primarily of 

sequential, synchronous writes to log files, with occasional random disk access. Data access on data files is 

predominantly asynchronous random disk access to the data files from the database. A single physical 

drive system does not tend to provide good response times when these types of data access are 

combined. 

Recovery 

While disk subsystems are increasing in reliability, failures do still occur. If a SQL Server data file is lost, the 

database could be restored from a backup and the transaction log reapplied to recover the database to a 

recent point in time. If a SQL Server log file is lost, the database can be forced to recover from the data 

files, with the possibility of some data loss or inconsistency in the database. But if both the data and log 

files are on a single disk subsystem that is lost, the recovery options usually involve restoring the database 

from an earlier backup and losing all transactions since that time. Isolating data and log files can help to 

avoid the worst impacts of drive subsystem failures. 

Logical vs. Physical Separation 

It is best practice to do the separation on the physical level. With storage area network (SAN) systems, it is 

easy to configure storage so that it appears to be separated but the separation is only logical. The same 

underlying physical storage is being used. This is generally a poor design choice.

Data File Management 


Ideally, all data files that are defined for a database should be the same size. Data is spread evenly across 

all available data files. The main performance advantages from doing this come when the files are spread 

over different storage locations. 

A number of management advantages are gained from allocating multiple data files: 

• The main management advantage gained from allocating multiple data files is the possibility of 

moving files and part of the data later. 

• Another management advantage gained through the use of multiple data files is that if a database 

file is being restored separately, the recovery time can be minimized. This could be useful where only 

part of the data was corrupt. 

• Splitting a database across multiple data files can increase the parallelism in the I/O channel. 

• The final advantage is that if a database exceeds the maximum size for a single Windows file, you can 

use secondary data files so the database can continue to grow. 

Number of Log Files 

Unlike the way that SQL Server writes to data files, the SQL Server database engine only writes to a single 

log file at any point in time. Additional log files are only used when space is not available in the active log 

file. 

Question: Why is it important to separate data and log files on the physical level?


Ensuring Sufficient File Capacity 

Key Points 

It is important to consider capacity planning. To perform capacity planning, you should estimate the 

maximum size of the database, indexes, transaction log, and tempdb, through a predicted growth period. 

For most sites, you should aim to create database files that are large enough to handle the data expected 

to be stored in the files over a twelve month period. 

Realistic Planning 

Performance and capacity testing for SQL Server is usually accomplished through the load testing of the 

actual application(s) that will be using the SQL Server, rather than trying to estimate the requirements. 

Autogrowth vs. Planned Growth 

SQL Server can automatically expand a database according to growth parameters that were defined when 

the database files were created. While the options for autogrowth should be enabled to prevent 

downtime when unexpected growth occurs, it is important to avoid the need for SQL Server to ever 

autogrow the files. Instead, you should monitor file growth over time and ensure that files are large 

enough for many months or years. 

Many administrators are concerned that larger database files will somehow increase the time it takes to 

perform backups. The size of a SQL Server backup is not related directly to the size of the database files. 

Only used portions of the database are backed up. 

One significant issue that arises with autogrowth is that there is a tradeoff related to the size of the 

growth increments. If a large increment is specified, a significant delay can be experienced in the 

execution of the T-SQL statement that triggered the need for growth. If a too small increment is specified, 

the filesystem can become very fragmented and the database performance can suffer because the data 

files have been allocated in small chunks all over a disk subsystem.


Note The instant file initialization (IFI) option can reduce the time taken for autogrow 

operations on data files. It does not apply to log files. IFI will be discussed in the next lesson. 

Log File Growth Planning 

If the transaction log is not set up to expand automatically, the transaction log can run out of space when 

certain types of activity occur in the database. For example, performing large-scale bulk operations, such 

as bulk import or index creation, can cause the transaction log to fill rapidly. 

In addition to expanding the size of the transaction log, it is possible to truncate a log file. Truncating the 

log purges the file of inactive, committed, transactions and allows the SQL Server Database Engine to 

reuse this unused part of the transaction log. 

Note How and when the log is truncated depends on the recovery model of the database 

and will be discussed later. 

Question: When would it be appropriate to preset a maximum size for the database and 

restrict filegrowth?


System Databases Supplied with SQL Server 

Key Points 

There are five system databases that are created during installation. They are master, msdb, model, 

tempdb, and resource. These databases contain metadata and cannot be dropped. 

master 

The master database contains all system-wide information. Anything that is defined at the server instance 

level is typically stored in the master database. 

If the master database is damaged or corrupted, SQL Server will not start, so it is very important to backup 

the master database on a regular basis. 

msdb 

The msdb database holds information for the SQL Server Agent. Jobs, operators, and alerts which are 

stored in the msdb database. It is also important to perform a backup of the msdb database regularly, to 

ensure that jobs, schedules, and history for backups, restores, and maintenance plans are not lost. In 

earlier versions of SQL Server, SQL Server Integration Services (SSIS) packages were often stored within the 

msdb database also. In SQL Server 2012, these should be stored in the dedicated SSIS database instead. 

model 

The model database is the template on which all user databases are based. Any new database that is 

created uses the model database as a template. Any objects created in the model database will be present 

in all new databases that are created on the server instance. Many sites do not ever modify the model 

database. Note that even though the model database does not seem overly important, SQL Server will not 

start if the model database is not present.

tempdb 


The tempdb database holds temporary data. This database is truncated or created every time that SQL 

Server starts so there is no need to perform a backup on this database. In fact, there is no option to 

perform a backup of the tempdb database. The tempdb database is discussed further in the next topic. 

resource 

The resource database is a read-only hidden database that contains system objects that are mapped to 

the sys schema in every database. This database also holds all system stored procedures, system views and 

system functions. In SQL Server versions before SQL Server 2005 these objects were defined in the master 

database. 

Question: Suggest an example of objects that you might want to create in the model 

database so that they are already present in all newly-created databases on the server 

instance.


Overview of tempdb 

Key Points 

The tempdb database consists of the internal objects, the row version store and user objects. The 

performance of the tempdb database is critical to the overall performance of most SQL Server 

installations. 

Internal Objects 

Internal objects are objects that are used by SQL Server for its own operations. Internal objects include 

work tables for cursor or spool operations, temporary large object (LOB) storage, work files for hash join 

or hash aggregate operations, and intermediate sort results. 

Note Working with internal objects is an advanced concept outside the scope of this 

course. 

Transactions that are associated with snapshot-related transaction isolation levels can cause alternate 

versions of rows to be briefly maintained in a special row version store within tempdb. Row versions can 

also be produced by other features like online index rebuilds, Multiple Active Result Sets (MARS) and 

triggers. 

Note Transaction isolation levels are discussed in course 10776A: Developing Microsoft 

SQL Server 2012 Databases.

User Objects 


Most objects that reside in the tempdb database are user-generated objects and consist of temporary 

tables, table variables, and the result sets of multi-statement table-valued functions, and other temporary 

row sets. 

Size of tempdb 

As tempdb is used for so many purposes, it is difficult to predict the required size for tempdb in advance. 

Appropriate sizes for tempdb should be carefully tested and monitored in real live scenarios for new 

installations. 

Running out of disk space in the tempdb database can cause significant disruptions in the SQL Server 

production environment and can prevent applications that are running from completing their operations. 

You can use the sys.dm_db_file_space_usage dynamic management view to monitor the disk space that is 

used by the tempdb files. Additionally, to monitor the page allocation or deallocation activity in tempdb 

at the session or task level, you can use the sys.dm_db_session_space_usage and 

sys.dm_db_task_space_usage dynamic management views. 

By default, the tempdb database automatically grows as space is required, because the MAXSIZE of the 

files is set to UNLIMITED. Therefore, tempdb can continue growing until space on the disk that contains 

tempdb is exhausted. 

Multiple Files 

To overcome I/O restrictions but also to avoid a concept called latch contention that affects the allocation 

pages of tempdb data pages, increasing the number of files can improve the overall performance of SQL 

Server systems. Do not, however, create too many files. As a general rule it is advised to have 0.25-1 file 

per core nowadays. As a general rule it can be said that the ratio should be lower with the increase of 

cores on the system but the optimal configuration must be identified by doing real live tests. 

Question: Why could a memory bottleneck lead to higher tempdb usage?


Demonstration 1A: Working with tempdb 











Lesson 2 

Working with Files and Filegroups 


Creating databases is a core competency for database administrators working with SQL Server. As well as 

understanding how databases are created, you need to be aware of the impact of file initialization options 

and know how to alter existing databases. Altering databases will mostly involve expanding the space 

available to the databases but on rare occasions, you may need to shrink the space occupied by database 

files. 

For larger databases, filegroups provide improved manageability. You should be aware of how filegroups 

are configured. 

Objectives 


• Create user databases. 

• Explain the role of instant file initialization. 

• Alter databases. 

• Expand and shrink database files. 

• Work with filegroups.


Creating User Databases 

Key Points 

Databases can be created with either the GUI in SSMS or via the CREATE DATABASE command in T-SQL. 

The CREATE DATABASE command offers more flexible options but the GUI is easier to use. This topic will 

concentrate on the CREATE DATABASE command but is equally applicable to the options chosen in the 

GUI within SSMS. 

CREATE DATABASE 

Database names must be unique within an instance of SQL Server and comply with the rules for 

identifiers. A database name is of data type "sysname" which is currently defined as nvarchar(128). This 

means that up to 128 characters can be present in the database name and that each of the characters can 

be chosen from the double-byte Unicode character set. While database names can be quite long, you will 

find that long names become awkward to work with. 

Data Files 

As discussed earlier in this module, a database must have a single primary data file and one log file. The 

ON and LOG ON clauses of the CREATE DATABASE command specify the required files. 

In the example shown in the slide, the database named Branch is being created. It is comprised of two 

files: a primary data file located at D:\Data\Branch.mdf and a log file located at L:\Logs\Branch.ldf. 

Note Each file includes a logical file name as well as a physical file path. Logical file names 

must be unique within each database. Operations within SQL Server refer to the logical file 

name.


The primary data file has an initial file size of 100MB and a maximum file size of 500MB. It will grow by 

20% of its current size whenever autogrowth needs to occur. 

The log file has an initial file size of 20MB and has no limit on maximum file size. Each time it needs to 

autogrow, it will grow by a fixed 10MB allocation. 

Collations and Default Values 

A specific collation can be allocated at the database level if required. If not specified, the collation will 

default to the collation that was specified for the server instance during SQL Server installation. Keeping 

individual databases with the same collation as the server is considered a best practice. 

While it is possible to create a database by just providing the database name, you would create a 

database that is based on the model database and with data and log files in the default locations. It is 

unlikely to represent a best practice. 

Question: What is the logical file name?


Configuring Database Options 

Key Points 

Each database has a set of options that can be configured. These options are unique to each database and 

do not affect other databases. All database options are taken from the model database when you create a 

database and can be changed by using the SET clause of the ALTER DATABASE statement or via the 

Properties page for each database in SSMS. 

Categories of Options 

There are several categories of database options: 

• Auto options - Control certain automatic behaviors. As a general guideline, Auto Close and Auto 

Shrink should be turned off on most systems but Auto Create and Update Statistics should be turned 

on. 

• Cursor options - Control cursor behavior and scope. In general, the use of cursors when working with 

SQL Server is not recommended apart from particular applications such as utilities. Cursors are not 

discussed further in this course but it should be noted that the overuse of cursors is a common cause 

of performance issues. 

• Database Availability Options - Control whether the database is online or offline, who can connect to 

the database, and whether the database is in read-only mode.

• Maintenance and recovery options such as: 


• Recovery Model - Database recovery models will be discussed in Module 5. 

• Page Verify - Early versions of SQL Server offered an option called Torn Page Detection. This 

option caused SQL Server to write a small bitmap across each disk drive sector within a database 

page. There are 512 bytes per sector, so this means that there are 16 sectors per database page 

(8KB). This was a fairly crude yet reasonably effective way to detect a situation where only some 

of the sectors that were required to write a page, were in fact written. In SQL Server 2005, a new 

CHECKSUM verification option was added. The use of this option causes SQL Server to calculate 

and add a checksum to each page as it is written and to recheck the checksum whenever a page 

is retrieved from disk. 

Note Page checksums are only added the next time that any page is written. Enabling the 

option does not cause every page in the database to be rewritten with a checksum.


Instant File Initialization 

Key Points 

Part of the security provided by the Windows operating system is that a user is not provided with raw 

access to disk space that was previously used by another user, without first overwriting the disk space. 

Instant File Initialization 

The time taken to overwrite the space allocated to data files for use with SQL Server can be substantial. 

When a 200GB file is allocated, 200GB of data needs to be written. 

The main risk associated with not overwriting the disk space is that an administrator could read the 

previous contents of the disk. If this risk is considered minimal, SQL Server can take advantage of instant 

file initialization (IFI) to avoid the time taken when clearing existing data. 

SQL Server can request uninitialized space from the operating system but only when it has sufficient rights 

to request this. If the Perform Volume Maintenance Tasks right has been assigned to the SQL Server 

service account, SQL Server can use instant file initialization. This option was introduced in SQL Server 

2005 and only affects data files. 

Another advantage of this option is that it decreases the time it takes to restore databases as the disk 

space for the restored database does not need to be overwritten before it is reused.

Demonstration 2A: Creating Databases 














Altering Databases 

Key Points 

When databases are in operation, they may need to be modified. The most common requirement is to 

add additional space by either expanding existing files or by adding additional files. 

ALTER DATABASE 

Expanding files and adding files can both be done through the ALTER DATABASE statement or via the GUI 

in SSMS. 

Another option that you might need to implement is to drop a file. SQL Server will not allow you to drop 

a file that is currently in use within the database. Dropping a file has to be done in two steps. First the file 

has to be emptied using the EMPTYFILE option of DBCC SHRINKFILE and then it can be removed using 

the ALTER DATABASE command. 

In Demonstration 2B, you will see examples of each of these operations.

Expanding and Shrinking Database Files 

Key Points 


By default, SQL Server automatically expands a database according to growth parameters defined when 

the database files were created. You can also manually expand a database by allocating additional space 

to an existing database file or by creating a new file. You may have to expand the data or transaction log 

space if the existing files are becoming full. 

If a database has already exhausted the space allocated to it and it cannot grow a data file automatically, 

error 1105 is raised. (The equivalent error number for the inability to grow a transaction log file is 9002). 

This can happen if the database is not set to grow automatically or if there is not enough disk space on 

the hard drive. 

Adding Files 

One option for expanding the size of a database is to add files to the database. You can add files using 

either the GUI in SSMS or by the ALTER DATABASE … ADD FILE command in T-SQL. You will see an 

example that shows the addition of a file in Demonstration 2B. 

Growing Files 

When expanding a database, you must increase the size of the database by at least 1 MB. Ideally, any file 

size increase should be much larger than this. Increases of 100MB or more are common. 

When a database is expanded, the new space is immediately made available to either the data or 

transaction log file, depending on which file was expanded. When you expand a database, you should 

specify the maximum size to which the file is permitted to grow. This prevents the file from growing until 

disk space is exhausted. To specify a maximum size for the file, use the MAXSIZE parameter of the ALTER 

DATABASE statement, or use the Restrict filegrowth (MB) option when you use the Properties dialog box 

in SQL Server Management Studio to expand the database.


Transaction Log 

If the transaction log is not set up to expand automatically, the transaction log can run out of space when 

certain types of activity occur in the database. In addition to expanding the size of the transaction log, the 

log file can be truncated. Truncating the log purges the file of inactive, committed transactions and allows 

the SQL Server Database Engine to reuse this unused part of the transaction log. If there are active 

transactions, the log file might not be able to be truncated and expanding the log file might be the only 

available option. 

Shrinking a Database 

Each file within a database can be reduced in size by removing unused pages. Although the Database 

Engine will reuse space effectively, there are times when a file no longer needs to be as large as it once 

was. Shrinking the file may then become necessary but shrinking should be considered a rarely used 

option. Both data and transaction log files can be reduced, or shrunk. The database files can be shrunk 

manually, either as a group or individually, or the database can be set to shrink automatically at specified 

intervals. 

Methods for Shrinking 

You can shrink a database or specific database files using the DBCC SHRINKDATABASE and DBCC 

SHRINKFILE commands. The DBCC SHRINKFILE is preferred as it provides much more control of the 

operation than DBCC SHRINKDATABASE. 

Note Shrinking a file usually involves moving of pages within the files, which can take a 

long time. 

Regular shrinking of files tends to lead to regrowth of files. For this reason, even though SQL Server 

provides an option to automatically shrink databases, this should only be used in rare situations, as for 

most databases, enabling this option will cause substantial fragmentation issues on the disk subsystem. It 

is best practice to perform any form of shrink operation only if absolutely needed. 

TRUNCATE ONLY 

One additional available option is the TRUNCATE_ONLY option of DBCC SHRINKFILE that releases all free 

space at the end of the file to the operating system but does not perform any page movement inside the 

file. The data file is shrunk only to the last allocated extent. That option often does not shrink the file as 

effectively but is less likely to cause substantial fragmentation and is a much faster operation. 

Question: What are the two basic strategies for expanding a database manually?

Demonstration 2B: Altering Databases 











• Open the 21 – Demonstration 2A.sql script file and follow the instructions contained within it. 

2. Open the 22 – Demonstration 2B.sql script file. 



Working with Filegroups 

Key Points 

Filegroups are named collections of data files and are used to simplify data placement and administrative 

tasks such as backup and restore operations. Using files and filegroups may improve database 

performance, because it lets a database be created across multiple disks, multiple disk controllers, or RAID 

systems. 

File Placement 

Files and filegroups enable data placement, because a table or an index can be created in a specific 

filegroup. When using a statement such as CREATE TABLE, a parameter can be supplied to specify the 

filegroup that the object should be created on. This can improve performance, because the I/O for specific 

tables can be directed at specific disks. For example, a heavily used table can be put on a single file in one 

filegroup, located on one disk, and the other less heavily accessed tables in the database can be put on 

the other files in another filegroup, located on other disks. 

Note File placement is an advanced topic and if not planned and tested carefully, it is also 

possible to decrease system performance by creating new bottlenecks due to forcing I/O 

loads to specific filegroups and files. 

Proportional Fill 

Filegroups use a proportional fill strategy across all the files within each filegroup. As data is written to the 

filegroup, the SQL Server Database Engine writes an amount of data proportional to the free space in a 

file to each file within the filegroup, instead of writing all the data to the first file until full. As soon as all 

the files in a filegroup are full, the Database Engine automatically expands one file at a time in a roundrobin 

manner to allow for more data, provided that the database is set to grow automatically.

Filegroups and Other Features 


Filegroups can be used in combination with partitioned tables and indexes, which are advanced topics, 

out of scope of this course. 

One filegroup is designated as the default filegroup. When objects are created without specifying a 

filegroup, the default filegroup is used. Unless you change the default filegroup, the PRIMARY filegroup 

will be the default. 

Filegroups can also be created as read-only filegroups. Read-only filegroups provide you the following 

benefits: 

• They can be compressed (using NTFS compression). 

• During recovery, you do not need to apply logs to recover a read-only file group. 

• The data is protected from accidental modifications. 

• Archive data can be stored on cheaper storage. 

Question: What is the advantage of storing archive data on separate filegroups?


Demonstration 2C: Filegroups 










• Open and execute the 21 – Demonstration 2A.sql script file. 

2. Open the 23 – Demonstration 2C.sql script file.

Lesson 3 

Moving Database Files 


There is often a need to move databases by moving database files. Both user databases and system 

databases can be moved but each requires a slightly different approach. In this lesson, you will learn how 

to move both types of database. 

Particular caution needs to be used when moving system databases as it is possible to stop the operation 

of SQL Server if these operations are not performed properly. 

You may also need to copy a database. SSMS provides a copy database wizard for this purpose. You will 

see learn about the capabilities of this wizard. 

Objectives 


• Describe detach and attach functionality. 

• Move user database files. 

• Move system database files. 

• Explain the functions offered by the Copy Database Wizard.


Overview of Detach and Attach 

Key Points 

Databases can be detached using SSMS or sp_detach_db. Detaching a database does not remove the data 

from the data files or remove the data files. All that is removed are the metadata entries for the database. 

The detached database will no longer appear in the list of databases shown in SSMS or reported by the 

sys.databases system view. The detached data files can be moved or copied to another instance and 

reattached. 

UPDATE STATISTICS 

SQL Server maintains a set of statistics on the distribution of data within tables and indexes. As part of the 

detach process, an option is provided to perform an UPDATE STATISTICS operation on table and index 

statistics prior to the detach. While this might be useful if the database is to be reattached as a read-only 

database, in general it is not a good option to use while detaching a database. 

Detachable Databases 

Not all databases can be detached. Databases that are replicated, mirrored or in a suspect state cannot be 

detached. 

Note Replicated and mirrored databases are advanced topics out of scope for this course. 

A more common problem that makes a database unable to be detached is that connections are open to 

the database at the time the detach operation is attempted. All connections must be dropped before 

detaching the database. SQL Server Management Studio offers an option to force connections to be 

dropped during this operation.

Attaching Databases 


SSMS offers an option to attach databases. Databases can also be attached using the CREATE DATABASE 

… FOR ATTACH command. 

Note You may find many references for the use of the sp_attach_db command and the 

sp_attach_single_file_db command. These are older syntax that is replaced by the FOR 

ATTACH option to the CREATE DATABASE command. Note also that there is no equivalent 

replacement for the sp_detach_db procedure. 

A common problem when databases are reattached is that database users can become "orphaned". You 

will see how to deal with this problem in a later module. 

Question: Why might updating all statistics not be a good option before detaching a 

database?


Moving User Database Files 

Key Points 

Moving the files of a database requires the database to be taken offline. Moving a database should be 

performed in a maintenance window. 

Options for Moving Databases 

In SSMS, the only option available for moving database files is to detach the database, move the data files 

to their new location, and then attach them back into the instance. While using detach and attach to 

move user database files can be used, the ALTER DATABASE can also be used to move database files and 

is preferred, unless the database is being moved to another server instance. 

The process of moving user database files requires the use of the logical names of the database files. You 

can see the logical names of existing files by executing the following code: 

SELECT * FROM sys.database_files; 

The use of detach and attach for moving user database files across instances will be shown in the next 

demonstration. 

Question: Why is ALTER DATABASE preferred over detaching and attaching the database?

Demonstration 3A: Detach and Attach 














Moving System Database Files 

Key Points 

All system databases can be moved to new locations, to help balance I/O load, except the resource 

database. The process for moving the master database is different from the process for other databases. 

Moving the master Database 

The steps involved in moving the master database are as follows: 

1. Open SQL Server Configuration Manager. 

2. In the SQL Server Services node, right-click the instance of SQL Server and choose Properties and click 

the Startup Parameters tab. 

3. Edit the Startup Parameters values to point to the planned location for the master database data (-d 

parameter) and log (-l parameter) files. 

4. Stop the instance of SQL Server. 

5. Move the master.mdf and mastlog.ldf files to the new location. 

6. Restart the instance of SQL Server.

Moving Other System Databases 


Other system databases (except the resource database which cannot be moved) are moved by this 

process: 

1. For each file to be moved, execute ALTER DATABASE … MODIFY FILE as for user databases. 

2. Stop the instance of SQL Server. 

3. Move the files to the new location. 

4. Restart the instance of SQL Server. 

In the next demonstration, you will see how to move the tempdb database and how to increase the 

number of files that it is using. 

Question: What is the biggest concern when performing these tasks?


Copying Databases 

Key Points 

There are several ways to copy databases to other locations, including to other instances: 

• You can detach a database, copy the files to new locations, reattach both the original and new 

database files. 

• You can backup a database and then restore it using the same database name (on a different server 

instance) or using another database name (on the same server instance). 

• You can use the copy database wizard. 

The main disadvantage of detaching and attaching and backup and restore is that only the database is 

copied and the DBA needs to take care of all dependent objects like logins, jobs, user-defined error 

messages and so on. 

Restoring a database on another instance has the advantage that backups should be created regularly 

anyway and can therefore be restored easily without affecting the source system. Performing the 

restoration is itself a good test of the current backup strategy. Also the source database stays online 

during the whole operation. Restoring a database also has the issue related to recovering dependent 

objects.

Copy Database Wizard 


The Copy Database Wizard is a good way to work around this restriction. It provides an easy to use wizard 

that can move or copy the database with all dependent objects without the need for additional scripting. 

In addition it is possible to schedule the copy operation. 

The wizard provides two methods for copying or moving the database. It can be configured to use detach 

and attach (which is the fastest option) but has the downside that the source database needs to be offline 

while the detach/copy/attach is occurring. The second method uses the SQL Server Management Objects 

(SMO) programming library methods to create the objects and transfer the data, which is slower but has 

the advantage that the source database can kept online while copying. 

Running the Copy Database Wizard requires sysadmin privileges on both instances and a network 

connection must be present. 

Question: What might be the main disadvantage copying a database using detach and 

attach of the database?


Demonstration 3B: Moving and Reconfiguring tempdb 



a. Revert the virtual machines as per the instructions in D:\10775A_Labs\Revert.txt. 

b. In the virtual machine, open the 10775A_04_PRJ SQL Server script project within SQL Server 

Management Studio. 

c. From the View menu, click Solution Explorer. Open and execute the 00 – Setup.sql script file 




Lab 4: Working with Databases 

Lab Setup 














Lab Scenario 

Now that the Proseware instance of SQL Server has been installed and configured on the server, a number 

of additional database configurations need to be performed. As the database administrator, you need to 

perform these configuration changes. 

You need to create a new database on the server, based on requirements from an application vendor’s 

specifications. A client has sent you a database that needs to be installed on the Proseware instance. 

Instead of sending you a backup, they have sent a detached database and log file. You need to attach the 

database to the Proseware instance.


A consultant has also provided recommendations regarding tempdb configuration that you need to 

review and implement if appropriate. 


tempdb Size Requirement (For Exercise 1) 

File Size (in MB) 

Data 30 

Log 10 

RateTracking Database Specification 

Item Requirement 

DatabaseName RateTracking 

Primary Data File Logical name = RateTracking_dat 

File name = RateTracking.mdf 

Folder = D:\MKTG 

Initial size = 10MB 

Maximum file size = 100MB 

Autogrowth amount = 10MB 

Filegroup = PRIMARY 

Log File Logical name = RateTracking_log 

File name = RateTracking.ldf 

Folder = L:\MKTG 


Maximum file size = unlimited 


Filegroup = Not Applicable 

Secondary Data File #1 Logical name = RateTracking_dat_1 

File name = RateTracking_1.ndf 





Filegroup = USERDATA 







Filegroup = USERDATA

(continued) 

Item Requirement 







Filegroup = ARCHIVE 







Filegroup = ARCHIVE 

Default Filegroup USERDATA 

tempdb Requirements From The Consultant (For Exercise 4) 

1. Move the tempdb primary data file to the folder D:\MKTG. 

2. Move the tempdb log file to the folder L:\MKTG. 

3. Add three additional files to tempdb as per the following table: 

Filename Requirements 

Secondary Data File #1 Logical name = tempdev2 

File name = tempdb_file2.ndf 



















Exercise 1: Adjust tempdb Configuration 

Scenario 

You will adjust the current configuration of the tempdb database. 


1. Adjust the size of tempdb. 

2. Check that the tempdb size is still correct after a restart. 

Task 1: Adjust the size of tempdb 

• Review the requirement for tempdb size in the Supporting Documentation. 

• Adjust the tempdb size based on the requirement in the supporting documentation. 

Task 2: Check that the tempdb size is still correct after a restart 

• Restart the Proseware server using SQL Server Configuration Manager. 

• Check that tempdb is still the correct size. 

Results: After this exercise, you should have inspected and configured the tempdb database. 

Exercise 2: Create the RateTracking Database 

Scenario 

You will create a new database named RateTracking as per a supplied set of specifications. 


1. Create the database. 

2. Create the required filegroups and files. 

3. Change the default filegroup for the database. 

Task 1: Create the database 


• Create a new RateTracking database based on the requirements. 

Task 2: Create the required filegroups and files 

• Review the supplied requirements in the supporting documentation for the required files and 

filegroups. 

• Create the required filegroups and files. 

Task 3: Change the default filegroup for the database 

• Review the supplied requirements in the supporting documentation for the default filegroup. 

• Modify the default filegroup. 

Results: After this exercise, you should have created a new RateTracking database with multiple 

filegroups.

Exercise 3: Attach the OldProspects Database 

Scenario 


A client has sent you a database that needs to be installed on the Proseware instance. Instead of sending 

you a backup, they have sent a detached database and log file. You need to attach the database to the 

Proseware instance. 


1. Copy the database files. 

2. Attach the database to the MKTG instance. 

Task 1: Copy the database files 

• Copy the files to new folders as per the table below: 

Filename Source Folder Destination Folder 

OldProspects.mdf D:\10775A_Labs\10775A_04_PRJ D:\MKTG 

OldProspects.ldf D:\10775A_Labs\10775A_04_PRJ L:\MKTG 

Task 2: Attach the database to the MKTG instance 

• Attach the OldProspects database to the MKTG instance. 

Results: After this exercise, you should have attached a database to a client’s server. 

Challenge Exercise 4: Add Multiple Files to tempdb (Only if time permits) 

Scenario 

A consultant has also provided recommendations regarding tempdb configuration that you need to 

review and implement. 


1. Review the tempdb file requirements. 

2. Move existing files. 

3. Add new files. 

4. Restart the server and check file locations. 

Task 1: Review the tempdb file requirements 

• In the Supporting Documentation review the tempdb Requirements From The Consultant section. 

Task 2: Move existing files 

• Move the existing tempdb data and log files to the required locations as specified in the supporting 

documentation. 

Task 3: Add new files 

• Add the additional tempdb files as required in the supporting documentation.


Task 4: Restart the server and check file locations 

• Restart the Proseware server. 

• View the Properties of the tempdb database and ensure the list of files match the requirements. 

Results: After this exercise, you should have reconfigured tempdb as per the requirements.



1. Why is it typically sufficient to have one log file in a database? 


2. Why should no data except temporary data should be stored in tempdb system database? 

3. What operations can be performed online on database files? 


1. Plan and test your file layout carefully. 

2. Separate data and log files on the physical level. 

3. Keep the data files of a database at the same size. 

4. Create the database in an appropriate size that it doesn’t have to be expanded too often. 

5. Shrink files only if absolutely necessary.

4-46 Working with Databases

Module 5 

Understanding SQL Server 2012 Recovery Models 

Contents: 

Lesson 1: Backup Strategies 5-3 

Lesson 2: Understanding SQL Server Transaction Logging 5-12 

Lesson 3: Planning a SQL Server Backup Strategy 5-22 

Lab 5: Understanding SQL Server Recovery Models 5-32 

5-1

5-2 Understanding SQL Server 2010 Recovery Models 


One of the most important aspects of a database administrator's role is ensuring that organizational data 

is backed up reliably, so that it is possible to recover the data if (or perhaps when), a failure occurs. 

Even though the computing industry has known about the need for reliable backup strategies for 

decades, and discussed the needs at great length, tragic stories regarding data loss are still commonplace. 

A further problem is that even when the strategies that have been put in place work as they were 

designed, the outcomes still regularly fail to meet organizational operational requirements. 

In this module, you will consider how to create a strategy that is aligned with organizational needs and 

see how the transaction logging capabilities of Microsoft® SQL Server® can help you to achieve an 

appropriate outcome. 

Objectives 


• Describe the critical concepts surrounding backup strategies. 

• Explain the transaction logging capabilities within the SQL Server database engine. 

• Plan a SQL Server backup strategy.

Lesson 1 

Backup Strategies 


This lesson is the first in a series of lessons that provide you with the knowledge you need to plan and 

implement an appropriate backup strategy for your organizational data that is stored in SQL Server. 

After discussing your existing experiences with backup strategies, you will consider the key criteria that 

should be part of a backup strategy. You will also consider how long backups should be retained, how the 

backups should be tested, and what types of media the backups should be held upon. 

Objectives 


• Determine an appropriate backup strategy. 

• Choose appropriate backup media. 

• Design a retention policy for backups.


Discussion: Previous Experience with Backup Strategies 

Key Points 

In this discussion, members of your class will share their experiences with backup strategies. In particular, 

consider (but do not limit yourself to) the following questions: 

• What types of backup have you used? 

• How often do you perform backups? 

• Who is responsible for planning and executing a backup strategy? 

• How often are your backups tested? 

• Do you use third party tools for backups? 

• What type of backup media do you use?

Determining an Appropriate Backup Strategy 

Key Points 


SQL Server provides a variety of backup types. No single backup type will usually be sufficient for the 

needs of an organization when forming a backup strategy. More commonly, a combination of backup 

types is required to achieve an appropriate outcome. Later in this module, and in the next module, you 

will learn about the specific types of backups that SQL Server provides. 

Key Criteria 

When designing a backup strategy, there is always a tradeoff between the level of safety that is 

guaranteed and the cost of the solution. If you ask any business about how much data they can afford to 

lose, you will almost certainly be told that they cannot afford to lose any data, in any circumstances. Yet, 

while zero data loss is an admirable goal, it is not an affordable or realistic goal. For this reason, there are 

two objectives that need to be established when discussing a backup strategy: a recovery time objective 

(RTO) and a recovery point objective (RPO). Part of the strategy might also involve the retrieval of data 

from other locations where copies of the data are stored. 

Recovery Time Objective 

There is little point in having perfectly recoverable data if the time taken to recover the data is too long. A 

backup strategy needs to have a recovery time objective (RTO). 

For example, consider the backup requirements of a major online bank. If the bank was unable to access 

any of the data in their systems, how long could the bank tolerate this situation? 

Now imagine that the bank was making full copies of all its data, yet a full restore of the data would take 

two weeks to complete. What impact would a two week outage have on the bank? The more important 

question is how long would an interruption to data access need to be, before the bank ceased to be 

viable as a bank?


The key message with RTO is that a plan that involves quick recovery with a small data loss might be more 

palatable to an organization than a plan that reduces data loss but takes much longer to implement. 

Another key issue is that the time taken to restore data might also involve finding the correct backup 

media, finding a person with the authority to perform the restore, finding documentation related to the 

restore, and so on. 

Recovery Point Objective 

Once a system has been recovered, hopefully in a timely manner, the next important question relates to 

how much data will have been lost. This is represented by the recovery point objective (RPO). 

For example, while a small business might conclude that restoring a backup from the previous night, with 

the associated loss of up to a day's work is an acceptable risk tradeoff, a large business might see the 

situation very differently. It is common for large corporations to plan for zero committed data loss. This 

means that work that was committed to the database must be recovered but that it might be acceptable 

to lose work that was in process at the time a failure occurred. 

Mapping to Business Strategy 

The most important aspect of creating a backup strategy is that the backup strategy must be designed in 

response to the business requirements and strategy. The backup strategy also needs to be communicated 

to the appropriate stakeholders within the organization. It is important to make sure that the expectations 

of the business users are managed, in line with the agreed strategy. 

Organizations often deploy large numbers of databases. The RPO and RTO for each database might be 

different. This means that database administrators will often need to work with different backup strategies 

for different databases that they are managing. Most large organizations have a method of categorizing 

the databases and applications in terms of importance to the core functions of the organization. 

The business requirements will determine all aspects of the backup strategy, including how frequently 

backups need to occur, how much data is to be backed up each time, the type of media that the backups 

will be held upon, and the retention and archival plans for the media. 

Question: What would be the likely RPO and RTO requirements for the most important 

databases in your organization?

Choosing Appropriate Backup Media 

Key Points 


A backup set contains the backup from a single, successful backup operation performed by SQL Server. 

One or more backup sets are written to a media set, which is represented by a file at the operating system 

or device level. 

It is important to realize that, because a single file (or media set) can contain more than one backup, when 

it is time to restore a backup, you need to ensure that you are restoring the intended backup from within 

the file. 

Physical Backup Devices 

SQL Server supports the creation of backups to disk files. UNC file paths are supported for disk locations 

so that backups can be written to network file shares. 

Earlier versions supported writing backups directly to tape but that option is now deprecated and should 

not be used for new development. It is generally considered better practice to write a backup to disk first, 

and to later copy the disk backup to tape if required. 

The backups that SQL Server creates are encoded in a format known as Microsoft Tape Format (MTF) 

which is a common format that is used by other Microsoft products in addition to SQL Server. This means 

that SQL Server backups can be combined with other backups, such as operating system backups, on the 

same media sets. 

Note Compressed SQL Server backups cannot share media with other types of backup.


Logical Backup Devices 

It is possible to specify an operating system filename that a backup should be written to, directly in the 

BACKUP command or in the GUI within SSMS. SQL Server also though, allows a degree of indirection by 

the creation of logical backup devices. A logical backup device is an optional user-defined name that 

refers to a specific output location. 

By using logical backup devices, an application can be designed to always send backups to the logical 

backup device, instead of to a specific physical location. 

For example, an HR application could be designed to create backups on a logical backup device named 

HRBackupDevice. A database administrator could then later determine where the backups should be 

physically sent. The administrator could later decide the name of a file that should hold the backups from 

the HR application. No changes would need to be made to the HR application to accommodate the 

change in backup file location, as the application would always back up to the same logical backup 

device. 

Backup Mirroring and Striping 

A single backup can target more than one backup device. Up to 64 devices are supported for a single 

media set. If more than one backup device is used, the backups can be mirrored or striped. 

With a mirrored backup (only available in Enterprise edition), the same backup data is written to each 

backup device concurrently. This option provides for redundancy of the physical backup device. Only one 

of the devices needs to be present during a restore process. 

Note While mirrored backups help provide fault tolerance regarding media failure after 

the backup completes, mirrored backups are actually a fault-intolerant option during the 

backup process. If SQL Server cannot write to one of the mirrored devices, the entire backup 

fails. 

Striping of backups causes a single backup to be written across a set of backup devices. Each backup 

device receives only part of the backup. All backup devices need to be present when a restore of the data 

is required. 

Required Privileges 

The ability to back up a SQL Server database requires certain permissions that are discussed in Modules 10 

and 11. 

Question: What might be the purpose of striping backups to more than one backup device 

on a disk?

Determining a Retention and Testing Policy for Backups 

Key Points 


A backup strategy must include plans for retention of backups, and for the locations that the media or 

backups should be retained in. 

It is too common for organizations to regularly perform backup operations, but when the time comes to 

restore the backups, a restore is not possible. Most of these problems would be alleviated by a good 

retention and testing plan. 

In the paragraphs below, examples are provided of the most common problems that are seen and the 

appropriate avoidance measure: 

Insufficient Copies of Backups 

Your organization will be dependent on the quality of backups should the need arise to restore the 

backups. The more copies of backups that you hold, and the more pieces of media that are holding all the 

required data, the better the chance you have of being able to recover. 

The worst offence is generally regarded as creating a backup over your most recent backup. If the system 

fails during the backup, you will often then have lost both your data and your backup. 

As a good example of this, Database Administrator A recently posted on a Microsoft SQL Server forum, 

seeking help. Her last backup was one year ago and she had inadvertently performed a restore operation 

instead of a backup operation using this one year old file. There was little that anyone could do to assist at 

that point. 

Avoidance strategy: Multiple copies of backups.


Insufficient Data on the Backups 

Company A performed regular backups, yet no testing of recovery was ever made and the first time that a 

real recovery was attempted, it was discovered that not all files that needed to be backed up were in fact 

being backed up. 

Avoidance strategy: Regular reconstruction of data from backup recovery testing. 

Unreadable Backups 

Company B performed regular backups but did not test them. When recovery was attempted, none of the 

backups were readable. This is often caused by hardware failures but it can be caused by inappropriate 

storage of media. 

Avoidance strategy: Regular backup recovery testing. 

Unavailable Hardware 

Company C purchased a special tape drive to perform their backups. When the time came to restore the 

backups, that special device no longer worked and no other device within the organization could read the 

backups, even if the backups were valid. 

Avoidance strategy: Regular backup recovery testing. 

Old Hardware 

Company D performed regular backups and retained their backups for an appropriate retention period. 

When the time came to restore the backups, the company no longer possessed equipment that was 

capable of restoring the backups. 

Avoidance strategy: Regular backup recovery testing, combined with recovery and backup onto current 

devices. 

Misaligned Hardware 

Company E performed regular backups and even tested that they could perform restore operations from 

the backups. However, because they tested the restores on the same device that performed the backups, 

they did not realize that the device was misaligned and that it was the only device that could read those 

backups. At the time that a restore was needed, the device that the backups were performed on had 

failed. 

Avoidance strategy: Regular backup recovery testing on a separate system and separate physical device. 

General Considerations 

When a backup strategy calls for multiple types of backups to be performed, it is important to work out 

the combination of backups that will be required when a restore is required. 

Organizations might need to fulfill legal or compliance requirements regarding the retention of backups. 

In most cases, full database backups are kept for a longer period of time than other backup types. 

Checking the consistency of databases by using DBCC CHECKDB is a crucial part of database 

maintenance, and is discussed later in the course.


As well as deciding how long backups need to be kept, you will need to determine where they are kept. 

Part of the RTO needs to consider how long it takes to obtain the physical backup media if it needs to be 

restored. 

You also need to make sure that backups are complete. Are all files that are needed to recover the system 

(including external operating system files) being backed up?


Lesson 2 

Understanding SQL Server Transaction Logging 

The transaction log is the key to the consistency of the SQL Server database engine. There are many 

configurations that can be made to the server that affect how the transaction log will operate. It is 

important for you to learn how the transaction log operates and how to configure the transaction log to 

meet your organization recovery requirements. The first critical configuration that you need to consider is 

the recovery model that is selected for each database. The second critical configuration is the space 

required for transaction log activity. Making good choices for both of these configurations will 

significantly increase the chance of your systems being able to meet database recovery requirements. 

Objectives 


• Explain how the SQL Server transaction log operates. 

• Configure database recovery models. 

• Implement capacity planning for transaction logs. 

• Configure checkpoint options.

Overview of SQL Server Transaction Logs 

Key Points 


Two of the common requirements for transaction management in database management systems are 

atomicity and durability of transactions. Atomicity requires that an entire transaction is committed or that 

no work at all is committed. Durability requires that once a transaction is committed that it will survive 

system restarts, including those caused by system failures. SQL Server uses the transaction log to ensure 

both the atomicity and durability of transactions. 

The transaction log can be used to roll back transactions that have been partially completed, to ensure 

that transactions are not left in a partially completed state. Rolling back a transaction could occur because 

of a request from a user or client application (such as the execution of a ROLLBACK TRANSACTION 

statement), or because a transaction may have been partially completed at the time of a system failure. 

Write Ahead Logging 

When SQL Server needs to modify the data in a database page, SQL Server checks whether or not the 

page is present in the buffer cache. If the page is not present, it must first be read into the buffer cache. 

SQL Server then modifies the page in memory and then writes redo and undo information to the 

transaction log. While this write is occurring, the "dirty" page in memory is locked using a simple shortterm 

locking mechanism called a latch, until the write to the transaction log is completed. Later, a 

background checkpoint process flushes the dirty pages to the database. This process is known as Write 

Ahead Logging (WAL) as all log records are written to the log before affected dirty pages are written to 

the data files or the transaction is committed. 

The WAL protocol ensures that the database can always be set to a consistent state after a failure. This 

recovery process will be discussed in detail in Module 7, but the effect of the process is that transactions 

that were committed before the failure occurred are applied to the database and those transactions that 

were "in flight" at the time of the failure, where work is partially complete, are undone. 

Writing all changes to the log file in advance also makes it possible to rollback transactions if requested.


Transaction Log File Structure 

Key Points 

SQL Server needs to make sure that enough information is available in the transaction logs to process 

rollback requests from users or applications, and to recover the database. SQL Server also needs to keep 

sufficient log file entries to satisfy the needs of other SQL Server features that need to access the database 

engine, such as replication, and change data capture. 

Transaction Log Structure and Virtual Log Files 

Transaction logs are written in chronological order in a circular way. Because the transaction log might 

need to grow, rather than being structured as a single log file, internally the log file is divided into a set of 

virtual log files (VLFs). Virtual log files have no fixed size, and there is no fixed number of virtual log files 

for a physical log file. The Database Engine chooses the size of the virtual log files dynamically while it is 

creating or extending log files, based upon the size of the growth that is occurring, as per the values in 

the following table: 

Growth Increment Number of VLFs 

Growth Increment Growth Increment


While overwriting the previous contents of the log file, if a point is reached where it would be necessary 

to overwrite data that must be retained, SQL Server needs to grow the size of the log file. If the log file 

has not been configured to allow automatic growth or if the disk volume that the log file is contained on 

is full, SQL Server will fail the transaction and return an error indicating that the log file is full. 

When it is possible to grow the log file, SQL Server will allocate new virtual log files, depending upon the 

autogrowth size increment that has been chosen in the configuration of the log file. 

Note Instant File Initialization (IFI) cannot be used with transaction log files. This means 

that transactions can be blocked while the log file growth occurs. 

Log File Truncation 

There are two ways that a transaction log file can be truncated. Transaction logs are normally truncated as 

part of the process of backing up the transaction log. The second option is that a database recovery 

model that automatically truncates the contents of the log file may have been selected. 

Each time the log file is truncated, only data up to the start of the oldest active transaction can be 

truncated. Entries in the log file are logically ordered by a value known as the Log Sequence Number 

(LSN). The starting point of the oldest active transaction in the log file is referred to as the MinLSN value. 

All log entries with a sequence value greater than the MinLSN value cannot be truncated as they might be 

needed for potential recovery. At each truncation, only data up to the start of the virtual log file that 

contains the minimum of starting point of the last checkpoint operation, MinLSN, and oldest transaction 

that is yet not replicated (only when using replication) is truncated. 

Note Replication is beyond the scope of this course but it is important to be aware that 

the configuration and state of replicated data can affect transaction log truncation. 

Question: Why is the write performance to the log file so important for the transaction 

performance of a database?


Working with Recovery Models 

Key Points 

SQL Server has three database recovery models. All models will preserve data in the event of a disaster but 

there are important differences that need to be considered by the database administrator when selecting 

a model for their database. 

Choosing the appropriate recovery model is an important part of your recovery strategy. The recovery 

model that you select for your database will determine many factors including: 

• Maintenance processing overhead. 

• Exposure to potential loss. 

• Which backup types are available to you. 

When choosing a recovery model for your database, you will need to consider the size of the database, 

the potential maintenance overhead, and the level of acceptable risk with regards to potential data loss. 

Simple Recovery Model 

The simple recovery model minimizes administrative overhead for the transaction log, because the 

transaction log is not backed up. The simple recovery model risks significant work-loss exposure if the 

database is damaged. Data is only recoverable to the point of the most recent backup of the database 

that has been lost. Therefore, under the simple recovery model, the backup intervals should be short 

enough to prevent the loss of significant amounts of data. However, the intervals should be long enough 

to keep the backup overhead from affecting production work. The inclusion of differential backups into a 

backup strategy based on the simple recovery model can help reduce the overhead.


In earlier versions of SQL Server, simple recovery model was referred to as "truncate log on checkpoint". 

The name was changed to provide a focus on the recovery options rather than on the process involved in 

implementing the option. Each time a checkpoint process occurs, SQL Server will automatically truncate 

the transaction log up to the end of the VLF before the VLF that contains the MinLSN value. This means 

that the only role that the transaction log ever plays is the provision of active transaction log data during 

the recovery of a database. 

Full Recovery Model 

The Full recovery model provides the normal database maintenance model for databases where durability 

of transactions is necessary. Full recovery model is the default recovery model when SQL Server is 

installed. The recovery model for new databases is based on the recovery model of the model database, 

which could be changed for sites that wish to use a different default recovery model. 

With full recovery model, log backups are required. This recovery model fully logs all transactions and 

retains the transaction log records until after they are backed up. The full recovery model allows a 

database to be recovered to the point of failure, assuming that the tail of the log can be backed up after 

the failure. The full recovery model also supports an option to restore individual data pages or to restore 

to a specific point in time. 

Bulk-logged Recovery Model 

This recovery model can reduce the transaction logging requirements for many bulk operations. It is 

intended solely as an adjunct to the full recovery model. For example, while executing certain large-scale 

bulk operations such as bulk import or index creation, a database can be switched temporarily to the 

bulk-logged recovery model. This temporary switch can increase performance by only logging extent 

allocations and reduce log space consumption. 

Transaction log backups are still required when using bulk-logged recovery model. Like the full recovery 

model, the bulk-logged recovery model retains transaction log records until after they are backed up. The 

tradeoffs are bigger log backups and increased work-loss exposure because the bulk-logged recovery 

model does not support point-in-time recovery. 

Note One potentially surprising outcome is that the log backups can often be larger than 

the transaction logs. This is because SQL Server retrieves the modified extents from the data 

files while performing a log backup for minimally-logged data. 

Question: What type of organization might find the simple recovery model to be adequate?


Capacity Planning for Transaction Logs 

Key Points 

The recovery model that you choose for a database will have a big impact on how large the log file for 

the database will need to be. 

In the simple recovery model, SQL Server truncates the log after each checkpoint. In the full and bulklogged 

recovery models, the log is truncated after each log backup, to ensure that an unbroken chain of 

backup log files exists. The truncation of a log file happens after a log backup. There is a common 

misconception that a full database backup breaks this chain of log file backups but this is not true. 

Determining Log File Size 

It is very difficult to calculate the size requirements for log files. As with planning other aspects of SQL 

Server, monitoring during realistic testing is the best indicator. 

There is another common misconception that the log file of a database in simple recovery model will not 

grow. This is also not the case. In simple recovery model, the transaction log needs to be large enough to 

hold all details from the oldest active transaction. Large transactions or long running transactions can 

cause the log file to need additional space. 

One of the most common questions asked by users on SQL Server forums is about how to truncate a log 

file. As an example, a user might mention that they have a 20GB database but a 300GB log file. This 

situation is typically caused by creating databases in full recovery model and failing to ever manage the 

database logs. Because of this lack of management, the log files will simply continue to grow in size. Often 

the user will have also attempted (unsuccessfully) to truncate the transaction log. Log backups followed 

by a log shrink would have corrected the situation.

Inability to Truncate a Log 


Other SQL Server features can also prevent you from truncating log files. For example, database mirroring, 

transactional replication, and change data capture can all affect the ability for the database engine to 

truncate log files. 

Note Database mirroring, transactional replication, and change data capture are out of 

scope for this course. 

If you are wondering why a transaction log cannot be truncated, executing the following query can assist: 

SELECT name, log_reuse_wait_desc FROM sys.databases; 

The current values that can be returned for the log_reuse_wait_desc column are: 

0 = Nothing 

1 = Checkpoint 

2 = Log backup 

3 = Active backup or restore 

4 = Active transaction 

5 = Database mirroring 

6 = Replication 

7 = Database snapshot creation 

8 = Log Scan 

9 = Other (transient) 

After resolving the reason that is shown, perform a log backup (if you are using full recovery model), to 

truncate the log file, and then use DBCC SHRINKFILE to reduce the filesize of the log file. 

Note If the log file does not reduce in size when using DBCC SHRINKFILE as part of the 

steps above, the active part of the log file must have been at the end of the log file at that 

point in time. 

Question: What would be the most common reason for excessive log file growth?


Working with Checkpoint Options 

Key Points 

SQL Server has four types of checkpoint operation: 

• Automatic is issued automatically in the background to meet the upper time limit suggested by the 

recovery interval server configuration option. Automatic checkpoints run to completion. Automatic 

checkpoints are throttled based on the number of outstanding writes and whether the Database 

Engine detects an increase in write latency above 20 milliseconds. 

• Indirect is issued in the background to meet a user-specified target recovery time for a given 

database. The default target recovery time is 0, which causes automatic checkpoint settings to be 

used on the database. If you have used ALTER DATABASE to set TARGET_RECOVERY_TIME to value 

greater than zero, this value is used, rather than the recovery interval specified for the server instance. 

• Manual is issued when you execute a Transact-SQL CHECKPOINT command. The manual checkpoint 

occurs in the current database for your connection. By default, manual checkpoints run to 

completion. The optional checkpoint duration parameter specifies a requested amount of time, in 

seconds, for the checkpoint to complete. 

• Internal is issued by various server operations such as backup and database snapshot creation to 

guarantee that disk images match the current state of the log. 

You can control the target duration of a checkpoint operation by executing the CHECKPOINT statement 

as shown: 

CHECKPOINT 5;

Demonstration 2A: Logs and Full Recovery 













Lesson 3 

Planning a SQL Server Backup Strategy 

Now that you have an understanding of SQL Server transaction logs and database recovery models, it is 

time to consider the types of backups that are available with SQL Server. 

In addition to learning in general about all the available types of backup, it is important to learn about the 

three most common types of backups in greater detail. These types are full database backups, differential 

backups, and transaction log backups. 

To effectively plan a backup strategy, you need to align your chosen combination of backup types to the 

business recovery requirements. Most organizations will need to use a combination of backup types rather 

than relying solely on a single type of backup. 

Objectives 


• Detail the available Microsoft SQL Server backup types. 

• Describe full database backups. 

• Describe differential backups. 

• Describe transaction log backups.

Overview of Microsoft SQL Server Backup Types 

Key Points 


Before exploring any of the backup types in detail, it is important to be familiar with all the backup types 

that are available in SQL Server. Not all backup types are available for all database recovery models. For 

example, transaction log backups cannot be made for a database that is in simple recovery model. 

Full Backups 

A full backup of a database includes the data files and the active part of the transaction log. The first step 

in the backup is that a CHECKPOINT operation is performed. The active part of the transaction log 

includes all details from the oldest active transaction forward. A full backup represents the database at the 

time that the data reading phase of the backup was completed and serves as your baseline in the event of 

a system failure. Full backups do not truncate the transaction log. 

Differential Backups 

A differential backup is used to save the data that has been changed since the last full backup. Differential 

backups are based on the data file contents rather than on log file contents and contain extents that have 

been modified since the last full database backup. Differential backups are generally faster to restore than 

transaction log backups but they have less options available. For example, point in time recovery is not 

available unless differential backups are also combined with log file backups. 

Partial Backups 

A partial backup is similar to a full backup, but a partial backup does not contain all of the filegroups. 

Partial backups contain all the data in the primary filegroup, every read/write filegroup, and any specified 

read-only files. A partial backup of a read-only database contains only the primary filegroup. 

Note Working with partial backups is an advanced topic that is out of scope for this 

course.


Transaction Log Backups 

Transaction log backups record any database changes by backing up the log records from the transaction 

log. Point in time recovery is possible with transaction log backups and they are generally much smaller 

than full database backups. The smaller size of transaction log backups means they can be run much more 

frequently. After the transaction log is backed up, the log records that have been backed up and that are 

not in the currently active portion of the transaction log are truncated. Transaction log backups are not 

available in the simple recovery model. 

Tail-log Backups 

A transaction log backup that is taken just before a restore operation is called a tail-log backup. Typically, 

tail-log backups are taken after a disk failure that affects data files only. From SQL Server 2005 onwards, 

SQL Server has required that you take a tail-log backup before it will allow you to restore a database, to 

protect against inadvertent data loss. 

Tail-log backups are often also possible even when the data files from the database are no longer 

accessible. 

File or Filegroup Backups 

If performing a full database backup on very large databases is not practical, you can perform database 

file or filegroup backups. 

Note Working with file and filegroup backups is an advanced topic that is out of scope for 

this course. 

Copy-only Backups 

SQL Server 2005 and later versions supports the creation of copy-only backups. Unlike other backups, a 

copy-only backup does not impact the overall backup and restore procedures for the database. Copy-only 

backups can be used to create a copy of the backup to take offsite to a safe location. Copy-only backups 

are also useful when performing some online restore operations. All recovery models support copy-only 

data backups. 

Question: What type of database would benefit from partial backups?

Full Database Backup Strategies 

Key Points 


A full database backup strategy involves regular full backups to preserve the database. If a failure occurs, 

the database can be restored to the state of the last full backup. 

Full Database Backups 

A full database backup backs up the whole database and also backs up the portion of the transaction log 

that covers changes that occurred while reading the data pages. 

Full database backups represent a copy of the database as at the time the data-reading phase of the 

backup finished, not as at the time that the backup started. Backups can be taken while the system is 

being used. At the end of the backup, SQL Server writes transaction log entries that cover the period 

during which the backup was occurring into the backup. 

Common Scenarios 

For a small database that can be backed up quickly, the best practice is to use full database backups. 

However, as a database becomes larger, full backups take more time to complete and require more 

storage space. Therefore, for a large database, you might want to supplement full database backups with 

other forms of backup. 

Under the simple recovery model, after each backup, the database is exposed to potential work loss if a 

disaster was to occur. The work-loss exposure increases with each update until the next full backup, when 

the work-loss exposure returns to zero and a new cycle of work-loss exposure begins.


Scenarios that might be appropriate for using a full database backup strategy include: 

• Test systems. 

• Data warehouses where the data could be recovered from a source system and where the data in the 

data warehouse does not change regularly. 

• Systems where the data can be recovered from other sources. 

Example on the Slide 

On the example shown in the slide, a full backup is performed on Sunday, Monday, and Tuesday. This 

means that during the day on Monday, up to a full day of data is exposed to risk until the backup is 

performed. The same amount of exposure happens on Tuesday. After the Tuesday backup is carried out, 

the risk increases every day until the next Sunday backup is carried out. 

Question: Might a small database be a good candidate for a full database backup strategy?

Transaction Log Backup Strategies 

Key Points 


A backup strategy that involves transaction log backups must be combined with a full database strategy 

or a strategy that combines the use of full and differential database backups. 

Transaction Log Backups 

Transaction log backups save all data since the last log backup. Rather than reading database pages, 

transaction log backups are based on reading data from the transaction log. A backup strategy based on 

transaction log backups is appropriate for databases with frequent modifications. 

When it is necessary to recover a database, the latest full database backup needs to be restored, along 

with the most recent differential backup (if one has been performed). After the database has been 

restored, transaction logs that have been backed up since that time are also then restored, in order. 

Because the restore works on a transactional basis, it is possible to restore a database to a specific point in 

time, within the transactions stored in the log backup. 

In addition to providing capabilities that let you restore the transactions that have been backed up, a 

transaction log backup truncates the transaction log. This enables VLFs in the transaction log to be reused. 

If you do not back up the log frequently enough, the log files can fill up. 


In the example shown on the slide, nightly full database backups are supplemented by periodic 

transaction log backups during the day. If the system fails, recovery could be made to the time of the last 

transaction log backup. If, however, only the database data files failed, and a tail-log backup could be 

performed, no committed data loss would occur.


Combinations of Backup Types 

Transaction log backups are typically much smaller than other backups, especially when they are 

performed regularly. Potential data loss can be minimized by a backup strategy that is based on 

transaction log backups in combination with other backup types. 

As log backups typically take longer to restore than other types of backup, it is often advisable to 

combine transaction log backups with periodic differential backups. During a recovery, only the 

transaction log backups that were taken after the last differential backup, need to be restored. 

Question: On the slide, which transactions would be contained in the first log backup on 

Monday morning?

Differential Backup Strategies 

Key Points 


Differential backups are a good way to reduce potential work loss and to reduce maintenance overhead. 

When the proportion of a database that is changed between backup intervals is much smaller than the 

entire size of the database, a differential backup strategy might be useful. However, if you have a very 

small database then differential backups may not save much time. 


From the time that a full backup occurs, SQL Server maintains a map of extents that have been modified. 

In a differential backup, SQL Server backs up those extents that have been changed. It is important to 

realize though, that after the differential backup is performed, SQL Server does not clear that map of 

modified extents. The map is only cleared when full backups occur. This means that a second differential 

backup performed on a database will include all changes since the last full backup, not just those changes 

since the last differential backup. 

Useful Scenarios for Differential Backups 

Because they only save the data that has been changed since the last full database backup, differential 

backups are typically much faster and occupy less disk space than transaction log backups for the same 

period of time. 

Differential database backups are especially useful when a subset of a database is modified more 

frequently than the remainder of the database. In these situations, differential database backups enable 

you back up frequently without the overhead of full database backups.



In the example on the slide, a full database backup is taken at midnight on Sunday night (early Monday 

morning). Differential backups are then taken at midnight each other night of the week. The differential 

backup taken on Monday night would include all data changed during Monday. The differential backup 

taken on Tuesday night would include all data changed on Monday and Tuesday. The differential backup 

taken on Friday night would include all data that changed on Monday, Tuesday, Wednesday, Thursday, 

and Friday. This means that differential backups can substantially grow in size between each full backup 

interval. 

Combinations of Backups 

Differential backups must be combined with other forms of backup. As a differential backup saves all data 

changed since the last full backup was taken, a differential backup cannot be taken unless a full backup 

has been taken. 

Another important aspect to consider is that when a recovery is needed, multiple backups need to be 

restored to bring the system back online, rather than a single backup. This increases the risk exposure for 

an organization and must be considered when planning a backup strategy. 

Differential backups can also be used in combination with both full backups and transaction log backups. 

Question: How could you estimate the size of a differential backup?

Discussion: Meeting Business Recovery Requirements 


Question: Imagine that you need to create a backup strategy for an online store front. 

Before you could design the strategy, what questions would you need to ask?


Lab 5: Understanding SQL Server Recovery Models 

Lab Setup 













Lab Scenario 

You need to implement a database recovery strategy. The business unit from Proseworks, Inc. has 

provided you with the availability needs for the databases on the new Proseware SQL Server instance. You 

need to plan how you will meet the requirements and then implement your strategy.


If you have time, there is another issue that your manager would like you to work on. There is another 

instance of SQL Server installed for supporting Customer Service operations. There is concern that existing 

databases on the CustomerService server instance are configured inappropriately and have invalid backup 

strategies, based on their RPO and RTO requirements. In this exercise, you need to review the database 

recovery models and backup strategies for the databases on the CustomerService instance and provide 

recommended changes. 


Business Database Continuity Requirements for Databases on the Proseware Server 

Instance (for Exercises 1 and 2) 

Recovery Time Objectives 

1. The MarketDev database must never be unavailable for longer than eight hours. 

2. The Research database must never be unavailable for longer than two hours. 

Recovery Point Objectives 

1. When the MarketDev database is recovered from a failure, no more than 30 minutes of transactions 

may be lost. 

2. When the Research database is recovered from a failure, all transactions that were completed up to 

the end of the previous weekday must be recovered. 

Projected Characteristics 

Characteristic Estimated Value 

MarketDev database size 20GB 

Research database size 200MB 

Total backup throughput 100MB per minute 

Total restore throughput 80MB per minute 

Average rate of change to the MarketDev database during office 

hours 

1GB per hour 

Average rate of change to the Research database during office hours 10MB per hour 

Percentage of the MarketDev database changed each day (average) 1.2% 

Percentage of the Research database changed each day (average) 80% 

Office hours (no full database backups permitted during these hours) 8am to 6pm


Business Database Continuity Requirements for Databases on the CustomerService 

Server Instance (for Exercises 3) 

Recovery Time Objectives 

1. The CreditControl database must never be unavailable for longer than two hours. 

2. The PotentialIssue database must never be unavailable for longer than one hour. 

Recovery Point Objectives 

1. When the CreditControl database is recovered from a failure, no more than five minutes of 

transactions may be lost. 

2. When the PotentialIssue database is recovered from a failure, no more than 30 minutes of 

transactions may be lost. 

Projected Characteristics 

Characteristic Estimated Value 

CreditControl database size 20GB 

PotentialIssue database size (at the start of each week after 

archiving activity is complete) 

200MB 

Total backup throughput 100MB per minute 

Total restore throughput 80MB per minute 

Average rate of change to the CreditControl database during office 

hours 

Average rate of change to the PotentialIssue database (constant all 

week long 24 hours per day) 

Percentage of the CreditControl database changed each day 

(average) 

Percentage of the PotentialIssue database changed each day 

(average) 

Office hours (no full database activity permitted during these 

hours) 

500MB per hour 

10MB per hour 

60% 

50% 

8am to 7pm

Existing Backup Strategy For CreditControl Database 

Recovery Model: Full 

Type of Backup Schedule 

• Full • Saturday at 6AM, 

Wednesday at 6AM 

• Differential • Sunday at 10PM, 

Monday at 10PM, 

Tuesday at 10PM, 

Thursday at 10PM, 

Friday at 10PM 

• Log • Every 60 minutes on the hour 

Existing Backup Strategy For PotentialIssue Database 

Recovery Model: Full 


• Full • Sunday at 10PM 

• Log • Every 15 minutes starting at 10 minutes pas 

the hour 

Exercise 1: Plan a Backup Strategy 


Scenario 

You need to plan a backup strategy for the two databases on the new Proseware instance. You have been 

provided with RPO (recovery point objectives) and RTO (recovery time objectives) for both databases, as 

part of a business continuity statement. 


1. Review the business requirements. 

2. Determine an appropriate backup strategy for each database. 

Task 1: Review the business requirements 

• Review the supplied business requirements in the supporting documentation for the exercise. 

Task 2: Determine an appropriate backup strategy for each database 

• Determine an appropriate backup strategy for each database. 

• For the MarketDev database: 

• Which recovery model should be used?


• Complete the following table for the backup schedule: 


• • 

• • 

• • 

• For the Research database: 

• Which recovery model should be used? 

• Complete the following table for the backup schedule: 


• • 

• • 

• • 

Results: After this exercise, you should have created a plan to backup two databases. 

Exercise 2: Configure Recovery Models 

Scenario 

You have reviewed the database recovery models and identified that the current database recovery 

models do not meet the availability needs of the business. In this exercise, you need to set the recovery 

models for the databases that do not meet the requirements. 


1. Review and adjust the current database recovery models. 

Task 1: Review and adjust the current database recovery models 

• Review the recovery models that you decided were required in Exercise 1, check whether or not the 

existing recovery models for the MarketDev and Research databases match your recommendations. If 

not, change the recovery models as per your recommendations. 

Results: After this exercise, you should have reviewed and modified the database 

recovery models where required.


Challenge Exercise 3: Review Recovery Models and Strategy (Only if time 

permits) 

Scenario 

There is another instance of SQL Server installed for supporting Customer Service operations. There is 

concern that existing databases on the CustomerService server instance are configured inappropriately 

and have invalid backup strategies, based on their RPO and RTO requirements. In this exercise, you need 

to review the database recovery models and backup strategies for the databases on the CustomerService 

instance and provide recommended changes. 


1. Review the RPO and RTO requirements for the databases. 

2. Review the existing recovery models and backup strategies. 

3. Indicate whether or not the strategy would be successful. 

Task 1: Review the RPO and RTO requirements for the databases 

• The supporting documentation includes details of the business continuity requirements for the 

databases. You need to review this documentation. 

Task 2: Review the existing recovery models and backup strategies 

• The supporting documentation also includes details of the backup strategy for the databases. You 

need to review this documentation. 

Task3: Indicate whether or not the strategy would be successful 

• You need to assess whether or not the current backup strategy and recovery model configuration is 

capable of supporting the business continuity requirements. If not, explain why it would not work. 

Results: After this exercise, you should have assessed the strategy.




1. What are the unique features of transaction log restores? 

2. When might a full database backup strategy be adequate? 

3. What might prevent transaction log truncation? 


1. Plan your backup strategy carefully. 

2. Plan the backup strategy in conjunction with the business needs. 

3. Choose the appropriate database recovery model. 

4. Plan your transaction log size based on the transaction log backup frequency. 

5. Consider differential backups to speed up recovery.

Module 6 

Backup of SQL Server 2012 Databases 

Contents: 

Lesson 1: Backing up Databases and Transaction Logs 6-3 

Lesson 2: Managing Database Backups 6-14 

Lesson 3: Working with Backup Options 6-20 

Lab 6: Backup of SQL Server Databases 6-26 

6-1

6-2 Backup of SQL Server 2012 Databases 


Ensuring reliable backups of corporate data is one of the most important roles for database 

administrators. You have seen that Microsoft® SQL Server® provides many types of backups. In this 

module, you will explore most of these backup types in more depth, and learn to implement the backups. 

Apart from learning to perform full database backups, differential database backups, and transaction log 

backups, you will also see how to apply options that affect the way that the backups work. Automating 

and scheduling backups will be covered in later modules. 

Objectives 


• Back up databases and transaction logs. 

• Manage database backups. 

• Work with more advanced backup options.

Lesson 1 

Backing up Databases and Transaction Logs 


In the previous module, you saw how to plan a backup strategy for a SQL Server system. This lesson shows 

how to perform the most common forms of SQL Server backup: full database backups, differential 

database backups, and transaction log backups. 

Objectives 


• Perform a full database backup. 

• Work with backup sets. 

• Use backup compression. 

• Perform differential backups. 

• Perform transaction log backups.


Performing a Full Database Backup 

Key Points 

Full database backups can be made using the BACKUP DATABASE command in T-SQL or using the GUI in 

SSMS. A full database backup saves all the data pages in the database, and also saves the active portion of 

the transaction log. 


In the example on the slide, a full database backup is being made of the AdventureWorks database, to a 

disk file L:\SQLBackups\AW.bak. The option INIT that has been included in the command, instructs SQL 

Server to create the file if it does not already exist, and to overwrite the file if it does already exist. 

The default initialization option, NOINIT, tells SQL Server to create the file if it does not already exist, and 

to append to the file if it already contains a SQL Server backup. The BACKUP DATABASE command 

includes many other options. The most important options will be discussed throughout this module. 

Backup Timing 

An important consideration when making a backup is to understand the timing associated with the 

contents of the backup. The database may be in use while the backup is occurring. 

For example, if a backup starts at 10PM and finishes at 1AM, does the backup contain a copy of the 

database as it was at 10PM, a copy of the database as it was at 1AM, or a copy of the database from a 

time between the start and finish? 

In early versions of SQL Server, the backup process wrote data pages to the backup device in sequence. 

However, if a user needed to modify a data page, SQL Server pushed that data page to the beginning of 

the backup page queue, and made the user wait for the page to be written to the backup device. In those 

versions of SQL Server, the backup made was a copy of the database at the time the backup was started. 

To reduce the impact on users, later versions of SQL Server write all data pages to the backup device in 

sequence, but uses the transaction log to track any pages that are modified while the backup is occurring.


SQL Server then writes the relevant portion of the transaction log to the end of the backup. This process 

makes the backups slightly larger than in earlier versions, particularly if heavy update activities are 

happening at the same time as the backup. This altered process also means that the backup contains a 

copy of the database as at a time just prior to the completion of the backup, not as at the time the 

backup was started. 

Question: What happens when you do not specify either INIT or NOINIT and a backup 

already exists on the backup device?


Working with Backup Sets 

Key Points 

Users are often confused by the fact that more than a single SQL Server backup can be contained within a 

single operating system file. The most common error related to this is to restore the first backup from a 

file, while assuming that it is the latest backup in the file. 

A single backup is called a backup set, and is written to a media set, which itself can contain up to 64 

backup devices. A backup device can be a disk or tape device. Tape devices must be locally attached and 

backups written to tape can be combined with Windows backups. 

Note Tape drives that are mapped across a network cannot be used directly with SQL 

Server backup. Further, the ability for SQL Server to backup directly to tape is deprecated 

and will be removed in a future version of SQL Server. 

Disk-based devices are the most commonly used. If a media set spans several backup devices, the backups 

will be striped across the devices. 

Note No parity device is used while striping. If two backup devices are used together, 

each receives half the backup. Both must also be present when attempting to restore the 

backup. 

Every backup operation to a media set must write to the same number and same types of backup devices. 

The Enterprise Edition of SQL Server also supports mirroring of media sets to improve the probability of 

being able to restore the backup. The same backup image is written to multiple locations.


Media sets and the backup devices are created the first time a backup is attempted on them. Media sets 

can also be named at the time of creation. 

Backups created on a single non-mirrored device or a set of mirrored devices in a media set are referred 

to as a media family. The number of backup devices used for the media set determines the number of 

media families in a media set. For example, if a media set uses two non-mirrored backup devices, the 

media set contains two media families. 

FORMAT Option 

SQL Server has been designed to minimize the chance of inadvertent data loss. 

As an example, consider a full database backup that has been written to two files, using the command: 

BACKUP DATABASE AdventureWorks 

TO DISK = 'D:\SQLBackups\AW_1.bak', 

DISK = 'L:\SQLBackups\AW_2.bak' 

WITH INIT; 

The two disk files that are listed make up a media set. The data from the backup is striped across the two 

files. Another backup could be made at a later time, to the same with a command such as the following: 

BACKUP DATABASE AdventureWorks 

TO DISK = 'D:\SQLBackups\AW_1.bak', 

DISK = 'L:\SQLBackups\AW_2.bak' 

WITH NOINIT; 

The data from the second backup would again be striped across the two files and the header of the media 

set updated to indicate that it now contains the two backups. 

However, if a user then tries to create another backup with a command such as: 

BACKUP DATABASE AdventureWorksDW 

TO DISK = 'D:\SQLBackups\AW_1.bak'; 

SQL Server would return an error. Before the member of the media set could be overwritten, the FORMAT 

option would need to be added to the WITH clause in the backup command: 


TO DISK = 'D:\SQLBackups\AW_1.bak' 

WITH FORMAT, INIT; 

Use the FORMAT option to overwrite the contents of a backup file and split up the media set, but use the 

FORMAT option very carefully. Formatting one backup file of a media set renders the entire backup set 

unusable. 

Question: What advantage could striping backups to more than one backup device on a 

disk provide?


Using Backup Compression 

Key Points 

A number of compression-related technologies were introduced into SQL Server in SQL Server 2008. 

Backup compression trades off some CPU performance against a potentially large reduction in the size of 

a backup and increased backup and restore performance. Backup compression can be configured as a 

server option or as part of a T-SQL BACKUP command as shown: 


TO DISK = 'D:\SQLBackups\AW_1.bak' 

WITH FORMAT, COMPRESSION; 

Performance Impact of Compressed Backups 

Because a compressed backup is smaller than an uncompressed backup of the same amount of data, 

compressing a backup typically reduces the amount of device I/O required and decreases duration of 

backups significantly. 

Any form of compression tends to increase CPU usage, and the additional CPU resources that are 

consumed by the compression process could adversely impact concurrent operations on systems that are 

CPU bound. Most current SQL Server systems are I/O bound, rather than CPU bound. The benefit received 

from the reduction in I/O usually outweighs the increase in CPU requirements by a significant factor. 

Note In systems where CPU load is a concern, it is also possible to create a low-priority 

session for creating compressed backups by limiting CPU usage with the SQL Server 

Resource Governor. The use of Resource Governor is an advanced topic that is out of scope 

for this course.

Recovery Time 


While a reduction in the time taken to perform backups is beneficial, backups are usually performed while 

the system is being used. However, compression benefits not only the backup process but also the restore 

process, and can significantly improve the ability to meet RTO requirements. 

Compression Percentages 

The degree of compression that is achieved depends entirely upon how compressible the data in the 

database is. Some data compresses well: other data does not compress well. A reduction in I/O and 

backup size of 30 to 50 percent is not uncommon in typical business systems. 

Note While backup compression can be used on a database that has been encrypted 

using Transparent Database Encryption (TDE), the compression rate will be minimal. TDE is 

an advanced topic that is out of scope for this course. 

Restrictions on Backup Compression 

The following restrictions apply to compressed backups: 

• Compressed and uncompressed backups cannot co-exist in a media set. 

• Previous versions of SQL Server cannot read compressed backups but lower editions of the product 

can restore compressed backups, even though the lower editions cannot create compressed backups. 

• Windows-based backups cannot share a media set with compressed SQL Server backups. 

• The default setting for backup compression can be set by the server configuration option ‘backup 

compression default’. 

• SQL Server 2008 R2 introduced the creation of compressed backups to the Standard Edition of SQL 

Server. 

Question: Why would both backup and restore time generally decrease when backup 

compression is used?


Performing Differential Backups 

Key Points 

While full database backups are ideal, there often is not enough time to perform full database backups. 

For situations where a relatively small percentage of the database is modified, compared to the overall 

database size, differential backups are a good option to consider. 


You can perform a differential backup using SQL Server Management Studio, or by adding the 

DIFFERENTIAL option to the BACKUP DATABASE T-SQL command. 

SQL Server maintains a map of modified extents called the differential bitmap page. One page is 

maintained for every 4GB section of every data file. Each time a full database backup is created, SQL 

Server clears the map. As the data in the data files is modified, SQL Server updates this map. A differential 

backup saves all extents that have been modified since the last full database backup, not only those 

modified since the last differential backup. 

Note You cannot create a differential database backup unless a full database backup has 

been taken first. 

A differential backup also saves the active portion of the transaction log, in exactly the same way that a 

full database backup does. 

The syntax for the differential backup is identical to the syntax for full database backups, apart from the 

addition of the DIFFERENTIAL option. All other options that are available for full database backups are 

also available for differential backups. 

Question: Does a differential backup truncate the transaction log?

Performing Transaction Log Backups 

Key Points 


You can perform a Transaction Log Backup using SQL Server Management Studio or by using the BACKUP 

LOG T-SQL statement. Before a transaction log backup can be performed, the database must be in either 

full or bulk-logged recovery model. In addition, a transaction log backup can only occur when a full 

database backup has been taken at some time prior. 

A transaction log backup does not save any data pages from the database, except when the database is 

set to bulk logged recovery model. A transaction log backup finds the MaxLSN of the last successful 

transaction log backup, and saves all log entries beyond that point to the current MaxLSN. The transaction 

log is then truncated as far as is possible. The longest running active transaction must be retained, in case 

the database needs to be recovered after a failure. 

Log Record Chains 

Before a database can be restored using transaction log backups, an unbroken chain of log records must 

be available since the last full database backup to the desired point of restoration. If the chain is broken, it 

is only possible to restore up to the point where the backup chain was broken. 

For example, imagine a scenario where a database is created, and at a later time, a full backup of the 

database is performed. At that point, the database could be recovered. If the recovery model of the 

database was then changed to simple, and subsequently changed back to full, a break in the log file chain 

would have occurred. Even though a previous full database backup had occurred, the database could only 

be recovered up to the point where the last transaction log backup was made (if any) prior to the change 

to simple recovery model. 

After switching from simple to full recovery model, a full database backup needs to be performed to 

create a starting point for transaction log backups.


Log Truncation 

While the default action is to truncate the transaction log as a result of a transaction log backup, this 

truncation is not performed if the COPY_ONLY option is used. The COPY_ONLY option is discussed in 

Lesson 3 of this module.

Demonstration 1A: Backing up Databases 













Lesson 2 

Managing Database Backups 

In Module 5, several example scenarios were presented where users performed backups but at the time 

the backups needed to be restored, the restore was not possible. The most basic check that should be 

performed on a backup is to verify that it is readable. The option to verify a backup and other options for 

ensuring backup integrity are discussed in this lesson. 

It is also important to know how to find information about backups that have been performed. SQL Server 

keeps a history of backup operations in the msdb database. In this lesson, you will see how to query the 

tables that hold this information, and also see how to retrieve the header information from backup 

devices. 

Objectives 


• Describe options for ensuring backup integrity. 

• View backup information.

Options for Ensuring Backup Integrity 

Key Points 


A great deal of effort can be expended in performing backups. This effort can be entirely wasted if the 

backups that are produced are not usable when the time comes to restore them. SQL Server includes 

several options to help avoid an inability to restore backups. 

Mirrored Media Sets 

A mirrored media set is a copy of the backup media set optionally created in parallel during the backup 

operation, on the Enterprise Edition of SQL Server. 

A mirrored media set consists of two to four device mirrors; each mirror contains the entire media set. 

Each mirror must be configured with the same number of backup devices and the backup devices must 

be of the same device type. 

Mirroring a media set increases availability based on the assumption that it is better to have multiple 

copies of a backup, rather than a single copy. However it is important to realize that mirroring a media set 

exposes your system to a higher level of hardware failure risk, as a failure of any of the backup devices, 

causes the entire backup operation to fail. 

A mirrored backup set is created by using the MIRROR TO option as shown in the following command: 


TO DISK = 'D:\SQLBackups\AW.bak' 

MIRROR TO DISK = 'L:\SQLBackups\AW_M.bak' 

WITH FORMAT, INIT;


WITH CHECKSUM Option 

SQL Server 2005 introduced the option to perform a checksum operation over an entire backup stream. 

This option consumes slightly more CPU resources than backups without the calculation of a checksum. 

The WITH CHECKSUM option validates the page-level information (checksum or torn page if either is 

present) as well as the one checksum for the backup stream. The checksum value is written to the end of 

the backup and can be checked during restore operations or during backup verification operations made 

with the RESTORE VERIFYONLY command. 

A backup checksum is enabled by using the CHECKSUM option as shown in the following command: 


TO DISK = 'D:\SQLBackups\AW.bak' 

WITH CHECKSUM; 

Note The COMPRESSION option also enables the CHECKSUM option automatically. 

Backup Verification 

For backup verification, a RESTORE VERIFYONLY command exists that checks the backup for validity. It 

performs the following tests: 

• Backup set is complete. 

• All volumes are readable. 

• Page identifiers are correct (to the same level as if it were about to write the data). 

• Checksum is valid (if present on the media). 

• Sufficient space exists on destination devices. 

The checksum value can only be validated if the backup was performed with the WITH CHECKSUM 

option. Without the CHECKSUM option during backup, the verification options only check the metadata 

and not the actual backup data. 

Verification can also be performed through an option in the backup database task in SSMS, and as part of 

SQL Server Maintenance plans. 

Note Consider verifying backups on a different system to the one where the backup was 

performed, to eliminate the situation where a backup is only readable on the source 

hardware. 

Note Make sure that you create your backups on different disks than the ones holding 

your database files. Avoid ever overwriting your most recent backup. 

Question: Can you guarantee that a database could be recovered, if a backup of the 

database can be verified?

Viewing Backup Information 

Key Points 

SQL Server tracks all backup activity in a set of tables in the msdb database: 

• backupfile 

• backupfilegroup 

• backupmediafamily 

• backupmediaset 

• backupset 


These tables can be queried to retrieve information about backups that have been performed. In 

Demonstration 2A, you will see how to perform these queries. 

SSMS also has options to retrieve details of backup operations on databases and logs. In Demonstration 

2A, you will also see an example report that is launched from within SSMS and that shows relevant backup 

information. 

Deleting Backup History 

Backup history can be deleted using system stored procedures. Consider the following command: 

EXEC sp_delete_backuphistory @oldest_date = '20090101'; 

This command deletes all history prior to the date provided. The date provided is the oldest date to keep. 

Also consider the following command: 

EXEC sp_delete_database_backuphistory @database_name = 'Market';


This command deletes the history for a database named Market. 

If a database is restored onto another server, the backup information is not restored with the database, as 

it is held in the msdb database of the original system. 

Retrieving Backup Metadata 

Information about a specific media set is available by executing the RESTORE command with the 

following options: 

Command Description 

RESTORE LABELONLY Returns information about the backup media on a 

specified backup device 

RESTORE HEADERONLY Returns all the backup header information for all 

backup sets on a particular backup device 

RESTORE FILELISTONLY Returns a list of data and log files contained in a 

backup set 

Question: In what situations would SQL Server not have complete information on the 

backups of a database stored in msdb?

Demonstration 2A: Viewing Backup History 














Lesson 3 

Working with Backup Options 

Now that you have seen the most common options related to backing up databases and transactions 

logs, it is important to consider general considerations surrounding the creation of backups, along with 

some of the less commonly used, but useful, options related to backups. 

Objectives 


• Highlight backup considerations. 

• Perform copy-only backups. 

• Perform tail-log backups.

Backup Considerations 

Key Points 


SQL Server backups can be created while other users are working with the system. Other users might, 

however, be impacted by the I/O load placed on the system by the backup operation. SQL Server also 

places some limitations on the types of commands that can be executed while a backup is being 

performed. For example, the ALTER DATABASE command cannot be used with ADD FILE or REMOVE FILE 

options and shrinking a database is not permitted during a backup. 

The BACKUP command cannot be included in either an explicit or an implicit transaction. You cannot 

ROLLBACK a BACKUP. 

Databases can only be backed up when they are online but it is still possible to perform a backup of the 

transaction log when a database is damaged, assuming the log file itself is still intact. This is a key reason 

that it is important to separate data and log files onto separate physical media. 

VSS and VDI 

The Windows Volume Shadow Copy Service (VSS) and the Virtual Device Interface (VDI) programming 

interface are available for use with SQL Server. The main use for these interfaces is so that third party 

backup tools can work with SQL Server. 

In very large systems, it is common to need to perform disk to disk imaging while the system is in 

operation, as standard SQL Server backups might take too long to be effective. The VDI programming 

interface allows an application to freeze SQL Server operations momentarily while a consistent snapshot 

of the database files is created. This form of snapshot is commonly used in geographically distributed SAN 

replication systems.


Copy-only Backups 

Key Points 

A copy-only backup is a SQL Server backup that is independent of the sequence of conventional SQL 

Server backups. Usually, taking a backup changes the database and affects how later backups are 

restored. 

There may, however, be a need to take a backup for a special purpose without affecting the overall 

backup and restore procedures for the database. 

Copy-only backups can be made of either the database or of the transaction logs. Restoring a copy-only 

full backup is the same as restoring any full backup. 

Question: Can you suggest a scenario where you might use a Copy-only backup?


Key Points 


SQL Server 2005 and later versions require that you take a tail-log backup before you start a restore over 

an existing database. This requirement is intended to avoid a common data loss scenario where a 

database has not been fully backed up before a restore of the database occurs. The requirement ensures 

that, by default, all transactions must have been written to at least one backup, before they can be 

overwritten. The tail-log backup prevents work loss and keeps the log chain intact. 

WITH NORECOVERY 

The WITH NORECOVERY option is normally applied to restore operations and is discussed in detail in 

Module 7. However, users are often surprised to see that the command to create a tail-log backup also 

has a WITH NORECOVERY option. This option backs up the transaction log and then immediately changes 

the database into a recovering state. The most common reason for the use of this option is in conjunction 

with log shipping, when a server is changing roles from a primary server to a secondary server. 

Note Log Shipping is an advanced option that is out of scope for this course. 


When you are recovering a database to the point of a failure, the tail-log backup is often the last backup 

of interest in the recovery plan. It is a standard type of transaction log backup. If you cannot back up the 

tail of the log, you can only recover a database to the end of the last backup that was created before the 

failure. 

Not all restore scenarios require a tail-log backup. You do not need to have a tail-log backup if the 

recovery point is contained in an earlier log backup, or if you are moving or replacing (overwriting) the 

database and do not need to restore it to a point of time after the most recent backup.


Use the CONTINUE_AFTER_ERROR option if you are backing up the tail of a damaged database. 

If you are unable to back up the tail of the log using the NO_TRUNCATE option when the database is 

damaged, you can attempt a tail-log log backup by specifying CONTINUE_AFTER_ERROR instead of 

NO_TRUNCATE. 

The NO_TRUNCATE option is available and is equivalent to the use of the COPY_ONLY and 

CONTINUE_AFTER_ERROR options together. It should be attempted for damaged databases. It causes the 

database engine to attempt the backup regardless of the state of the database. This means that a backup 

taken while using the NO_TRUNCATE option might have incomplete metadata. Without the 

NO_TRUNCATE database option, the database must be online. 

Question: What is the biggest advantage of being able to perform tail-log backups even 

when data files are damaged?

Demonstration 3A: Tail-log Backup 














Lab 6: Backup of SQL Server Databases 

Lab Setup 













Lab Scenario 

You have reviewed and updated the recovery models. As the database administrator, you need to 

implement a database backup strategy. You have been provided with details of the required backup 

strategy for a number of databases on a SQL Server instance. You need to complete the required 

backups.

Exercise 1: Investigate Backup Compression 

Scenario 


The size of the database backups has been increasing with the number of orders being placed. You want 

to investigate the amount of space that can be saved by using backup compression. In this exercise, you 

need to investigate the effectiveness of backup compression when backing up the MarketDev database 

on the Proseware instance. You will perform a full database backup with backup compression disabled. 

You will then perform another full database backup with backup compression enabled. You will compare 

the backup files produced to identify the possible space savings. 


1. Create a database backup without compression. 

2. Create a database backup with compression. 

3. Compare the file sizes created. 

Task 1: Create a database backup without compression 

• Using Windows Explorer, create a new folder L:\SQLBackups. 

• Perform a full backup of the MarketDev database with compression disabled to the file 

L:\SQLBackups\MarketDev_Full_Uncompressed.BAK. 

Task 2: Create a database backup with compression 

• Perform a full backup of the MarketDev database with compression enabled to the file 

L:\SQLBackups\MarketDev_Full_Compressed.BAK. 

Task 3: Compare the file sizes created 

• Calculate the space savings provided by compression as: 

SpaceSavings=(Uncompressed size–Compressed size)*100/Uncompressed size 

Results: After this exercise, you have calculated the space saved by using backup compression on the 

MarketDev database. 

Exercise 2: Transaction Log Backup 

Scenario 

Part of the ongoing management of the MarketDev database is a series of transaction log backups to 

provide point in time recovery. In this exercise, you need to back up the transaction log. 


1. Execute a script to introduce workload to the MarketDev database. 

2. Backup the transaction log on the MarketDev database. 

Task 1: Execute a script to introduce workload to the MarketDev database 

• Open and execute the script file 61 – Workload File.sql from Solution Explorer.


Task 2: Backup the transaction log on the MarketDev database 

• Backup the transaction log of the MarketDev database to the file 

L:\SQLBackups\MarketDev_Log_Compressed.BAK. Use backup compression during the backup. 

Results: After this exercise, you should have completed a transaction log backup. 

Exercise 3: Differential Backup 

Scenario 

There is a concern that the data volumes in the MarketDev database will be so large that daily full 

backups will not be possible. In this exercise, you need to perform a differential backup to assist to 

manage the size of the database backups. 


1. Execute a script to introduce workload to the MarketDev database. 

2. Create a differential backup of the MarketDev database. 


• Open and execute the script file 61 – Workload File.sql from Solution Explorer. 

Task 2: Create a differential backup of the MarketDev database 

• Create a differential backup of the MarketDev database to the file 

L:\SQLBackups\MarketDev_Differential_Compressed.BAK. Use backup compression during the backup. 

• Using Windows Explorer, note the size of the Differential backup compared to the Full backup. 


• Open and execute the script file 61 – Workload File.sql from Solution Explorer. 

Task 4: Append a differential backup to the previous differential backup file 

• Append a differential backup of the MarketDev database to the file 

L:\SQLBackups\MarketDev_Differential_Compressed.BAK. 

• Using Windows Explorer, note that the size of the Differential backup has increased. The file now 

contains two backups. 

Results: After this exercise, you should have completed two differential backups. 

Exercise 4: Copy-only Backup 

Scenario 

Another team periodically needs a temporary copy of the MarketDev database. It is important that these 

copies do not interfere with the backup strategy that is being used. In this exercise, you need to perform a 

copy-only backup and verify the backup.



1. Create a copy-only backup of the MarketDev database, ensuring to choose to verify the backup. 

Task 1: Create a copy-only backup of the MarketDev database, ensuring to choose to 

verify the backup 

• Create a copy-only backup of the MarketDev database to the file 

L:\SQLBackups\MarketDev_Copy_Compressed.BAK. Make sure you choose to: 

• Verify the backup while creating it. 

• Use backup compression. 

• Choose to create a new media set called MarketDev Copy Backup. 

• For the media set description use MarketDev Copy Backup for Integration Team. 

Results: After this exercise, you should have completed a copy-only backup. 

Challenge Exercise 5: Partial Backup (Only if time permits) 

Scenario 

On the Proseware instance, there is a database called RateTracking that has two filegroups. The ARCHIVE 

filegroup is set to read-only and both the default filegroup USERDATA and the PRIMARY filegroup are 

read-write. In this exercise, you need to back up the read-write filegroups only, using T-SQL commands. 


1. Perform a backup of the read-write filegroups on the RateTracking database. 

Task 1: Perform a backup of the read-write filegroups on the RateTracking database 

• Perform a backup of the read-write filegroups (USERDATA and PRIMARY) on the RateTracking 

database. Write the backup to the file L:\SQLBackups\RateTracking_ReadWrite.BAK. Use the 

CHECKSUM and INIT options. 

Results: After this exercise, you should have completed a partial backup.




1. Which backup types can be performed in simple recovery model? 

2. How can backup information be read? 


1. Consider using CHECKSUM to create a checksum over your backup files. 

2. Use backup compression to increase backup and restore performance and safe storage space. 

3. Consider mirroring your backups to increase safety. 

4. Check if differential backup can speed up your restore process in full recovery mode. 

5. Use COPY_ONLY for out of sequence backups.

Module 7 

Restoring SQL Server 2012 Databases 

Contents: 

Lesson 1: Understanding the Restore Process 7-3 

Lesson 2: Restoring Databases 7-8 

Lesson 3: Working with Point-in-time recovery 7-19 

Lesson 4: Restoring System Databases and Individual Files 7-27 

Lab 7: Restoring SQL Server 2012 Databases 7-34 

7-1

7-2 Restoring SQL Server 2012 Databases 


In the previous module, you saw how to create backups of Microsoft® SQL Server® 2012 databases. A 

backup strategy might involve many different types of backup. This means that it is important for you to 

understand the process required when restoring databases. Often when database restores are required, an 

urgent situation exists. Unfortunately, database administrators often make errors of judgment when 

placed into urgent recovery situations. The first rule when dealing with a bad situation should always be 

to "do no further harm". In urgent situations, it is more important than ever to have a clear plan for how 

to proceed. A good understanding of the process required and a good plan can help avoid making the 

situation worse. 

Not all database restores are related to system failures. With most system failure situations, there is a need 

to return the system to as close as possible to the state that it was in prior to the failure. Some failures are 

related to human errors. In those cases, you may wish to recover the system to a point prior to the failure. 

The point-in-time recovery features of SQL Server 2012 can help you to achieve this. 

User databases are more likely to be affected by system failures than system databases as user databases 

are typically much larger than system databases. However, system databases can be affected by failures, 

and special care needs to be taken when recovering system databases. In particular, you need to 

understand how each system database should be recovered as not all system databases can be recovered 

using the same process. 

Objectives 


• Understand the restore process. 

• Restore databases. 

• Work with Point-in-time Recovery. 

• Restore system databases and individual files.

Lesson 1 

Understanding the Restore Process 


You have seen that there are many types of backup that can be created with SQL Server 2012. Similarly, 

there are different types of restore processes that can be required. 

It was mentioned earlier that when it is time to recover a database, a good plan is required, to avoid 

causing further damage. Once the preliminary step of attempting to create a tail-log backup has been 

carried out, the most important decision that needs to be taken is the determination of which database 

backups need to be restored, and in which order. 

Objectives 


• Describe the different types of restores. 

• Decide which backups to restore and in which order.


Types of Restores 

Key Points 

Restoring a database in SQL Server 2012 is a two-step process. The first step involves restoring data pages 

from one or more backups. Once the data pages have been restored, the database is potentially in an 

inconsistent state. To correct this situation, in the second step of the restore process, the available details 

from the transaction log are used to recover the database. The restore scenarios available for a database 

depend on the recovery model of the database and the edition of SQL Server. 

Complete Database Restore in Simple Recovery model 

The most basic restore strategy for SQL Server databases is to restore and recover a full database backup. 

If a differential backup of the database is available, the latest differential backup could be restored after 

the restore of the full database backup but before the recovery process for the database. 

In most cases that use simple recovery model, no differential backups are performed, in which case only 

the last full database backup will be restored and the database would be returned to the state it was in at 

the time just prior to the full database backup being completed. 

Complete Database Restore in Full Recovery model 

The most common restore strategy requires full or bulk-logged recovery model and involves restoring full, 

differential (if present), and log backups. 

To restore to the last available point in time: 

1. Try to perform a tail-log backup. This step might or might not be possible, depending upon the type 

of failure that has occurred. 

2. Restore the last full database backup.


3. Restore the most recent differential backup if a differential backup had been created. 

4. Restore all transaction log backups performed after the point of the most recent differential backup 

(or full backup if no differential backup was created) in the same sequence as they were created. If a 

tail-log backup was successfully created, it would be restored as the most recent transaction log 

backup. 

While the aim of the restore would normally be to recover the database to the latest point in time 

possible, options do exist to restore the database to earlier points in time. These options will be discussed 

in Lesson 3 of this module. 

Note Even if differential backups and transaction log backups were created, you can 

choose not to apply them, if you wish to return the database state to an earlier point in 

time. 

System Database Restore 

Restoring system databases is possible but requires special processes to avoid further issues from 

occurring. For example, if a master database is left in an inconsistent state, SQL Server will refuse to start 

until the master database is recovered. The recovery of system databases will be discussed in Lesson 4 of 

this module. 

File Restore 

If individual files in a database have become corrupted or have been lost, the ability to restore individual 

files has the potential to substantially reduce the overall time to recover the database. The recovery of 

individual files is only supported for read-only files when operating in simple recovery model, but can be 

used for read-write files when using the bulk-logged or full recovery models. The recovery of individual 

files uses a process that is similar to the complete database restore process and will be discussed in Lesson 

4 of this module. 

Online Restore 

Online restore involves restoring data while the database is online. This is the default option for File, Page, 

and Piecemeal restores. In SQL Server 2012, online restore is only available in the Enterprise edition. 

Piecemeal Restore 

A piecemeal restore is used to restore and recover the database in stages, based on filegroups, rather than 

restoring the entire database at a single time. The first filegroup that must be restored is the primary 

filegroup. In SQL Server 2012, piecemeal restore is only available in the Enterprise edition. 

Page Restore 

Another advanced option is the ability to restore an individual data page. If an individual data page is 

corrupt, users will usually see either an 823 error or an 824 error when they execute a query that tries to 

access the page. An online page restore could be used to try to recover the page. Once the restore has 

commenced, if a user query tries to access the page, the error that the user would see is error 829, which 

indicates "page is restoring". If the page restore is successful, user queries that access the page would 

again return results as expected. Page restores are supported under full and bulk-logged recovery models 

but are not supported under simple recovery model. In SQL Server 2012, online page restore is only 

available in the Enterprise edition. Offline page restore is available in lower editions.


Preparations for Restoring Backups 

Key Points 

In critical situations, users often make inappropriate choices about the actions that should be taken. It is 

important to avoid any action that will make the situation worse than necessary. Before restoring any 

database, it is important to attempt a tail-log backup, unless you are intending to replace the current 

state of the database. The tail-log backup can often be performed, even when damage has occurred to 

the data files of the database. The tail-log backup is critical when you need to restore the database to the 

latest point in time possible. 

Identifying Backups to Restore 

The recovery of any database depends upon restoring the correct backups in the correct order. The 

normal process for restoring a database is: 

1. Restore the latest full database backup as a base to work from. (If only individual files are damaged or 

missing, you may be able to restore only those files). 

2. If differential backups have been created, only the latest differential backup is needed. (Differential 

backups save all database extents that have been modified since the last full database backup. 

Differential backups are not incremental in nature. 

3. If transaction log backups have been created, all transaction log backups since the last differential 

backup are required. You also need to include the tail-log backup created at the start of the restore 

process, if the tail-log backup was successful. (This step does not apply to databases in simple 

recovery model).

Discussion: Determining Required Backups to Restore 

Discussion 

The example on the slide describes the backup schedule for an organization. 


Question: If a failure occurs at Thursday at 10:30AM, what is the restore process that should 

be undertaken?


Lesson 2 

Restoring Databases 

It is important to understand the phases that SQL Server 2012 uses when restoring a database. Once a 

decision has been made to restore a database, you need to know how to implement the restore process. 

The restore process might involve both database and transaction log backups. When multiple backups 

need to be restored in a single process, you need to control the point at which the recovery of the 

database occurs. If database recovery occurs too early in the process, you will not be able to complete the 

entire restore process. 

Objectives 


• Describe the different phases of the restore process. 

• Restore a database from a full database backup or a differential backup. 

• Restore a transaction log backup. 

• Control database recovery by using the WITH RECOVERY option. 

• Allow read-only access to a recovering database by using the WITH STANDBY option.

Phases of the Restore Process 

Key Points 


The restore of a SQL Server 2012 database passes through three phases: Data Copy, Redo, and Undo. The 

combination of the Redo and the Undo phases is commonly referred to as the recovery of a database. 

Data Copy 

The data copy phase is typically the longest phase in a database restore. The data files from the database 

need to be recovered from the backups. Before any data pages are restored, the header of the backup is 

read and SQL Server recreates the required data and log files. If instant file initialization (IFI) has not been 

enabled by granting rights to the SQL Server service account, the rewriting of the data files can take a 

substantial amount of time. 

Once the data and log files are recreated, the data files are restored from the full database backup. Data 

pages are retrieved from the backup in order and written to the data files. 

The log files need to be zeroed out before they can be used. IFI is not used for log files. This process can 

also take a substantial time if the log files are large. 

If a differential backup is also being restored, SQL Server overwrites the extents in the data files with the 

ones that are contained in the differential backup. 

Redo Phase 

Details from the transaction log are then retrieved. In simple recovery model, these details would only be 

retrieved from either the full database backup or the differential backup, if a differential backup is also 

being restored. In full or bulk-logged recovery model, these log file details will be supplemented by the 

contents of any transaction log backups that were taken after the full and differential database backups. 

In the redo phase, SQL Server rolls into the database pages all changes that are contained within the 

transaction log details, up to the recovery point. The recovery point is typically the latest time for which 

transactions are contained in the log.


Undo Phase 

Note that the transaction log details will likely include details of transactions that were not committed at 

the recovery point, which is typically the time of the failure. In the undo phase, SQL Server rolls back any 

uncommitted transactions. 

Because the action of the undo phase involves rolling back uncommitted transactions and placing the 

database online, subsequent backups cannot be restored. 

During the undo phase, the Enterprise edition of SQL Server 2012 will allow the database to come online 

and will allow users to begin to access the database. This capability is referred to as the fast recovery 

feature. Queries that attempt to access data that is still being undone are blocked until the undo phase is 

complete. This could potentially cause transactions to time out. 

Question: Why does SQL Server need to redo and undo transactions when only restoring a 

full database backup?

WITH RECOVERY Option 

Key Points 


In general, a database cannot be brought online until it has been recovered. The one exception to this is 

the fast recovery option that was mentioned in the last topic. The fast recovery option allows users to 

access the database while the undo phase is continuing. 

Recovery Events 

Note that recovery does not only occur during the execution of RESTORE commands. If a database is 

taken offline and then placed back into an ONLINE state, recovery of the database will occur. The same 

recovery process occurs when SQL Server 2012 restarts. 

Note Other events that lead to database recovery include clustering or database 

mirroring failovers. Failover clustering and database mirroring are advanced topics that are 

out of scope for this course. These events are listed here for completeness. 

The recovery process in SQL Server is critical to the maintenance of transactional integrity that requires 

that all transactions that had committed are recorded in the database and that all transactions that had 

not committed are rolled back. 

Recovery Options 

Each RESTORE command includes an option to specify WITH RECOVERY or WITH NORECOVERY. The 

WITH RECOVERY option is the default action and does not need to be specified. 

It is important to choose the correct option (WITH RECOVERY or WITH NORECOVERY) when executing a 

RESTORE command. The process is straightforward in most cases. All restores must be performed WITH 

NORECOVERY except the last restore which has to be performed WITH RECOVERY.


There is no way to restore additional backups after a restore WITH RECOVERY. If a backup has been 

performed WITH RECOVERY by accident the restore sequence has to be restarted. 

If the last backup of a set was inadvertently also restored WITH NORECOVERY, the database can be forced 

to recover by executing the following command: 

RESTORE LOG databasename WITH RECOVERY; 

Question: Why is it not possible to restore additional backups to a recovered database?

Restoring a Database 

Key Points 


You can restore a database using either the GUI in SSMS or by using the RESTORE DATABASE command 

in T-SQL. 

If a single database backup is being restored, the WITH RECOVERY option can be used, as no later 

backups need to be restored. You can also omit the WITH RECOVERY option as it is the default for the 

RESTORE DATABASE command. 

Differential Restore 

The command for restoring a differential backup is identical to the command for restoring a full database 

backup. Differential backups might be appended to the same file as the full database backup. In that case, 

you need to specify the file from the media set that you need to restore. 

Consider the following command: 

RESTORE DATABASE AdventureWorks 

FROM DISK = 'D:\SQLBackups\AW.bak' 

WITH FILE = 1, NORECOVERY; 

RESTORE DATABASE AdventureWorks 

FROM DISK = 'D:\SQLBackups\AW.bak' 

WITH FILE = 3, RECOVERY; 

In this example, the database AdventureWorks is restored from the first file in the media set. The media 

set is stored in the operating system file D:\SQLBackups\AW.bak. In this case, the second file that was 

contained in the media set was the first differential backup that was performed on the database. The third 

file in the media set was the second differential backup that was performed on the database. Because the 

second differential backup was the latest differential backup that was performed, the second RESTORE 

command in the example shows how to restore the latest differential backup from that media set.


WITH REPLACE 

SQL Server 2012 will not allow you to restore a database backup over an existing database if you have not 

performed a tail-log backup on the database. If you attempt to do this using SQL Server Management 

Studio, SQL Server 2012 will provide a warning and will automatically attempt to create a tail-log backup 

for you first. If you need to perform the restore operation and you do not have a tail-log backup, you 

must specify the WITH REPLACE option. 

Note The WITH REPLACE option needs to be used with caution as it can lead to data loss. 

WITH MOVE 

When you restore a database from another server, you might need to place the database files in different 

locations than those that are recorded in the backup from the original server. You might also need to do 

this if you are copying a database by a process of backup and restore. The WITH MOVE option allows you 

to specify new file locations. Consider the following command: 

RESTORE DATABASE Spatial 

FROM DISK = 'D:\SQLBackups\Spatial.bak' 

WITH MOVE 'Spatial_Data' TO 'D:\MKTG\Spatial.mdf', 

MOVE 'Spatial_Log' TO 'L:\MKTG\Spatial.ldf'; 

In the example shown, the database named Spatial is being restored from another server. As well as 

specifying the source location for the media set, in the command, new locations for each database file 

have been specified. Note that the MOVE option requires the specification of the logical file name, rather 

than the original physical file path.

Restoring a Transaction Log 

Key Points 


You can restore the transaction logs for a database using either the GUI in SSMS or by using the RESTORE 

LOG command in T-SQL. All log files apart from the last log should be restored WITH NORECOVERY. The 

last log file (which is often the tail-log backup) is then restored WITH RECOVERY. 

Transaction Log Restores 

All transaction logs created after the last full or differential backup must be restored in chronological 

order with no break in the chain of backups. A break in the chain of transaction logs will cause the restore 

process to fail. The restore process cannot be continued after a failure and would need to be restarted. 

While the database is in recovering mode, Object Explorer shows it with the words "(Restoring…)" after the 

name of the database, as shown in the slide example. 

Question: Why is it faster to restore differential and log backups instead of restoring all log 

backups since the last full database backup?


WITH STANDBY Option 

Key Points 

SQL Server 2012 provides the ability to view the contents of a database that has not been recovered, by 

using the option WITH STANDBY, instead of the WITH NORECOVERY option. 

Further transaction log backups can be applied to a database that has been restored WITH STANDBY. 

There are two common reasons for using the WITH STANDBY option. 

WITH STANDBY and Log Shipping 

One widely used high availability feature maintains a standby server that can be brought online quickly. 

This feature is called Log Shipping. The basic operation of Log Shipping is to automate the process of 

backing up log files on one computer, copying the log files to another computer, and restoring the log 

files on that other computer. The database on the second server would be nearly complete yet unusable if 

the restores were performed using WITH NORECOVERY. The database cannot be recovered to allow for 

read-only use as more transaction logs would need to be restored at a later time. 

Note Log shipping is an advanced topic beyond the scope of this course but an 

introduction to log shipping is provided in Appendix A. 

WITH STANDBY was designed to help in this situation, by performing a modified version of recovery that 

copies the transactions that would have been deleted by the undo phase, to an operating system file. 

When the next transaction log restore operation is required, SQL Server automatically reapplies the 

transactions from that file to the log before continuing with the log restore.

WITH STANDBY for Inspection 


Imagine that a user error has caused the inadvertent deletion of some data. You may not be aware of 

when the error occurred. When restoring the database, you may not then know which log file contains the 

deletion. You can use the WITH STANDBY option on each log file restore and inspect the state of the 

database after each restore operation. 

Question: What would be a reason to provide read-only access to a database? 

Question: What would be a limitation of the WITH STANDBY option when used to permit 

reporting on the second standby database in a log shipping environment?


Demonstration 2A: Restoring Databases 








within Solution Explorer. Note: The setup script for this module is intended to throw an error 

regarding missing files; this is normal. 



Lesson 3 

Working with Point-in-time Recovery 


In the previous lesson, you have seen how to recover a database to the latest point in time possible. 

However, there are occasions when there is a need to recover the database to an earlier point in time. You 

have seen that you could stop the restore process after any of the backups are restored, and initiate the 

recovery of the database. While stopping the restore process after a restore provides a coarse level of 

control over the recovery point, SQL Server 2012 provides additional options that allow for more fine 

grained control over the recovery point. 

Objectives 


• Describe Point-in-time Recovery. 

• Implement the stop at time restore option. 

• Explain the complexities surrounding the synchronization of multiple databases. 

• Implement the stop at mark restore option.


Overview of Point-in-time Recovery 

Key Points 

Recovery of a database to the most recent point in time is the most commonly requested option. 

However, there can also be a need to restore a database to an earlier point in time. 

SQL Server 2012 allows the restore of a database to stop at a specified point in time and to then 

commence recovery. The point in time can be specified in two different ways. A datetime value can 

specify the exact time for the recovery point. Keep in mind that computer times tend to be approximate 

and that computer systems can perform a large amount of work in a short period of time. A datetime 

value might then not be precise enough for specifying a recovery point. 

The other option provided by SQL Server 2012 is to specify a named transaction (referred to as a 

transaction log mark) as the recovery point. 

For either of these options to work, the database needs to be in full or bulk-logged recovery model. SQL 

Server can only stop at points in the transaction log chain when the database is in full recovery model. If a 

database changes from full recovery model to bulk-logged recovery model to process bulk transactions, 

and is then changed back to full recovery model, the recovery point cannot be in the time that the 

database was in bulk-logged recovery model. If you attempt to specify a recovery point during which the 

database was in bulk-logged recovery model, the restore will fail and an error will be returned. 

Question: What other restore option might be useful if the point in time is not known 

exactly and no mark was set?

STOPAT Option 

Key Points 


The STOPAT option is used to specify a recovery point that is based on a datetime value. Because the DBA 

might not know in advance which transaction log backup contains the time where the recovery needs to 

occur, the syntax of the RESTORE LOG command allows the RECOVERY option to be specified for each log 

restore command in the sequence. 

Consider the following restore sequence: 

RESTORE DATABASE database_name FROM full_backup 

WITH NORECOVERY; 

RESTORE DATABASE database_name FROM differential_backup 

WITH NORECOVERY; 

RESTORE LOG database_name FROM first_log_backup 

WITH STOPAT = time, RECOVERY; 

… (additional log backups could be restored here) 

RESTORE LOG database_name FROM final_log_backup 

WITH STOPAT = time, RECOVERY; 

Note that the RECOVERY option is specified on each of the RESTORE LOG commands, not just on the last 

command.


The behavior of the STOPAT and RECOVERY options is as follows: 

• If the specified time is earlier than the first time in the transaction log backup, the restore command 

fails and returns an error. 

• If the specified time is contained within the period covered by the transaction log backup, the restore 

command recovers the database at that time. 

• If the specified time is later than the last time contained in the transaction log backup, the restore 

command restores the logs, sends a warning message, and the database is not recovered so that 

additional transaction log backups can be applied. 

With the behavior described above, the database is recovered up to the requested point, even when 

STOPAT and RECOVERY are both specified with every restore as long as the requested point is not before 

the restore sequence. 

Question: Why might you need to recover a database to a specific point in time?

Discussion: Synchronizing Recovery of Multiple Databases 

Discussion 


An application might use data in more than a single database, including data in multiple SQL Server 

instances. 

Question: Do you use any multi-database applications? 

Question: What problems might occur when the databases need to be restored? 

Question: Why might restoring up to a point in time not be sufficient?


STOPATMARK Option 

Key Points 

If more precise control over the recovery point is required, the STOPATMARK option can be useful. The 

GUI in SSMS has no options for working with transaction log marks during restore operations. This process 

must be carried out using T-SQL. 

Marking a Transaction 

If you know in advance that you might need to recover to the point of a specific operation, you can place 

a mark in the transaction log to record that precise location. Consider the following command: 

BEGIN TRAN UpdPrc WITH MARK 'Start of nightly update process'; 

In this command, a transaction is commenced but the transaction is also given the name UpdPrc, and a 

transaction mark with the same name as the transaction is created. The value after the WITH MARK clause 

is only a description and is not used in the processing of the transaction mark. 

If you do not know the name of a transaction that was marked, you can query the dbo.logmarkhistory 

table in the msdb database. 

Mark-Related Options 

The STOPATMARK option is similar to the STOPAT option for the RESTORE command. SQL Server will stop 

at the named transaction mark and include the named transaction in the redo phase. 

If you wish to exclude the transaction (that is restore everything up to the beginning of the named 

transaction), you can specify the STOPBEFOREMARK option instead. 

If the transaction mark is not found in the transaction log backup that is being restored, the restore 

completes and the database is not recovered so that other transaction log backups can be restored.

Multi-database Applications 


The main use for the stop at mark feature is to restore an entire set of databases to a mutually consistent 

state, at some earlier point in time. If you need to perform a backup of multiple databases so that they 

can be recovered to a consistent point, consider marking all the transaction logs before commencing the 

backups. 

Question: Why might STOPAT not be a good choice for synchronizing the restore of several 

databases and that STOPATMARK might be preferred?


Demonstration 3A: Using STOPATMARK 









from within Solution Explorer. Note: The setup script for this module is intended to throw an 

error regarding missing files; this is normal. 

2. Open and execute the 31 – Demonstration 3A.sql script file from within Solution Explorer. 

3. Follow the instructions contained within the comments of the script file


Lesson 4 

Restoring System Databases and Individual Files 

User databases are restored much more regularly than system databases, as the user databases are 

typically much larger, and thus more exposed to failure as they are often spread across many devices. 

However, failures can affect system databases and they may need to be restored. Restoring a system 

database is not identical to restoring user databases. 

The master database is the most critical database for a SQL Server system and recovery of the master 

database involves more steps than the recovery of other databases. 

Rather than restoring entire databases, situations can arise where only a single file or filegroup needs to 

be restored. This can speed up the overall restore process. 

Objectives 


• Recover System databases. 

• Restore the master database. 

• Restore a file or filegroup from a backup.


Recovering System Databases 

Key Points 

The recovery process for all system databases is not identical. Each system database has specific recovery 

requirements: 

master 

The master database holds all system level configurations. SQL Server requires the master database before 

a SQL Server instance can run at all. A special procedure needs to be followed to restore the master 

database. The process for restoring the master database is discussed in the next topic. 

model 

The model database is the template for all databases that are created on the instance of SQL Server. When 

the model database is corrupt, the instance of SQL Server cannot start. This means that a normal restore 

command cannot be used to recover the model database if it becomes corrupted. In the case of a corrupt 

model database, the instance must be started with the -T3608 trace flag as a command-line parameter. 

This trace flag only starts the master database. Once SQL Server is running, the model database can be 

restored using the normal RESTORE DATABASE command. 

msdb 

The msdb database is used by SQL Server Agent for scheduling alerts and jobs, and for recording details 

of operators. The msdb database also contains history tables, such as the history tables that record details 

of backup and restore operations. If the msdb database becomes corrupt, SQL Server Agent will not start. 

msdb can be restored like user databases, using the RESTORE DATABASE command and then the SQL 

Server Agent service can be restarted.

esource 


The resource database is a read-only database that contains copies of all system objects that ship with 

Microsoft SQL Server 2012. No backup operations can be performed on this database, and it is a hidden 

database. It can, however, be corrupted by failures in areas such as I/O subsystems or memory. If the 

resource database is corrupt, it can be restored by a file-level restore in Windows or by running the setup 

program for SQL Server. 

tempdb 

The tempdb database is a workspace for holding temporary or intermediate result sets. This database is 

re-created every time an instance of SQL Server is started. When the server instance is shut down, any 

data in tempdb is deleted permanently. No backup operations can be performed on the tempdb 

database but as it is recreated with every restart of the instance, a restart of the instance is enough to 

recover the tempdb in case of corruption.


Restoring the master Database 

Key Points 

The master database is integral to the operation of SQL Server. As SQL Server will not start if the master 

database is missing or corrupt, you cannot execute a standard RESTORE DATABASE command to restore 

the master database in the case of a missing or corrupt database. 

Recovering the master Database 

Before starting this process, some version of a master database must exist so that the SQL Server instance 

will start at all. If your master database becomes corrupted, a temporary master database must be created 

first. This temporary master database doesn’t need to have the correct configuration as it will be only used 

to start up the instance. The correct master database will be restored afterwards using the process 

described on the slide. 

There are three ways to obtain a temporary master database. You can use the SQL Server setup program 

to rebuild the system databases, either from the location that you installed SQL Server from, or by running 

the setup program found at: Microsoft SQL Server\110\Setup\Bootstrap\SQL11\setup.exe. (This path is 

approximate and may change in future). 

Note The setup program will overwrite all system databases and all will need to be 

restored later.


Another way to obtain a temporary master database is to use file-level backup of the master database 

files to restore the master database. This file-level backup must have been taken when the master 

database was not in use, that is, when SQL Server was not running, or by using the VSS service. 

Note Copying the master database from another instance is not supported. The VSS 

service is out of scope for this course. 

The final option is to locate a master.mdf database from the Templates folder located in the MSSQL\Binn 

folder for each instance. 

Once a temporary master database has been put in place, use the following procedure to recover the 

correct master database: 

• Start the server instance in single-user mode. (SQL Server configuration manager can be used to start 

SQL Server in single user mode by using the –m startup option). 

• Use a RESTORE DATABASE statement to restore a full database backup of master. (In single-user 

mode, it is recommended that you enter the RESTORE DATABASE statement using the sqlcmd utility). 

• After the master database is restored, the instance of SQL Server will shut down and terminate your 

sqlcmd connection. 

• Remove the single-user startup parameter. 

• Restart SQL Server.


Restoring a File or Filegroup from a Backup 

Key Points 

Restoring individual files or filegroups from backups, instead of restoring entire databases, can often be a 

much faster option when corruption has occurred or when files or filegroups are missing. 

Note While it is possible to backup only files or filegroups, there is no need to have 

performed file or filegroup backups before restoring individual files or filegroups. SQL 

Server can extract specific database files out of a full backup or a differential backup. 

Restore Process 

1. Create a tail-log backup of the active transaction log. (If you cannot do this because the log has been 

damaged, you must restore the whole database or restore to an earlier point-in-time). 

2. Restore each damaged file from the most recent file backup of that file. 

3. Restore the most recent differential file backup, if any, for each restored file. 

4. Restore transaction log backups in sequence, starting with the backup that covers the oldest of the 

restored files and ending with the tail-log backup created in step 1. 

5. Recover the database. 

You must restore the transaction log backups that were created after the file backups to bring the 

database back to a consistent state. The transaction log backups can be rolled forward quickly, because 

only the changes that apply to the restored files or filegroups are applied. Undamaged files are not copied 

and then rolled forward. However, the whole chain of log backups still needs to be processed.

Demonstration 4A: Restoring a File 










from within Solution Explorer. Note: The setup script for this module is intended to throw an 

error regarding missing files; this is normal. 

2. Open and execute the 41 – Demonstration 4A.sql script file from within Solution Explorer. 



Lab 7: Restoring SQL Server 2012 Databases 

Lab Setup 













Note The setup script for this module is intended to throw an error regarding missing 

files. This is normal.

Lab Scenario 


You have been provided with a series of backups taken from a database on another server that you need 

to restore to the Proseware, Inc. server with the database name MarketYields. The backup file includes a 

number of full, differential, and log backups. You need to identify backups contained within the file, 

determine which backups need to be restored, and perform the restore operations. When you restore the 

database, you need to ensure that it is left as a warm standby, as additional log backups may be applied 

at a later date. 

If you have time, you should test the standby operation. 

Exercise 1: Determine a Restore Strategy 

Scenario 

You need to restore a database backup from another instance to the Proseware instance. You have been 

provided with a backup file containing multiple full, differential, and log backups. In this exercise you 

need to determine which backups are contained within the file and determine which backups need to be 

restored and in which order. 


1. Review the backups contained within the backup file. 

2. Determine how the restore should be performed. 

Task 1: Review the backups contained within the backup file 

• Use the HEADERONLY option of the RESTORE command to identify the backups that are contained 

within the file D:\MSSQLSERVER\MarketYields.bak. 

Task 2: Determine how the restore should be performed 

• Determine which backup need to be restored and in which order. 

Results: After this exercise, you should have identified the backups that need to be restored. 

Exercise 2: Restore the Database 

Scenario 

You have determined which backups need to be restored. You now need to restore the database 

MarketYields to the Proseware instance from the backups that you have decided upon. You will leave the 

database in STANDBY mode. 


1. Restore the database. 

Task 1: Restore the database 

• Using SSMS, restore the MarketYields database using the backups that you determined were 

needed in Exercise 1. Make sure you use the STANDBY option with a STANDBY filename of 

L:\MKTG\Log_Standby.bak. You will need to move the mdf file to the folder D:\MKTG and the ldf file 

to the folder L:\MKTG.


• In Object Browser refresh the list of databases and check the status of the MarketYields database on 

the Proseware instance. 

Results: After this exercise, you should have restored the database in STANDBY 

mode. 

Challenge Exercise 3: Using STANDBY Mode (Only if time permits) 

Scenario 

In this exercise, you will ensure that the STANDBY mode works as expected. You will access the database 

and then restore another log file to make sure the database can continue to be restored. 


1. Execute queries against the STANDBY database to ensure it is accessible. 

2. Restore another log file, leaving the database in STANDBY mode. 

Task 1: Execute queries against the STANDBY database to ensure it is accessible 

• Open a query window against the MarketYields database on the Proseware instance. 

• Select a count of the rows in the LogData table. 

• Close the query window. 

Task 2: Restore another log file, leaving the database in STANDBY mode 

• Restore the log file D:\MSSQLSERVER\MarketYields_log.bak. Ensure you leave the database in 

STANDBY mode. 

• In Object Browser refresh the list of databases and check the status of the MarketYields database on 

the Proseware instance. 

Results: After this exercise, you should have tested the STANDBY capability.



1. What are the three phases of the restore process? 

2. What is always performed before a database starts up and goes ONLINE? 



1. Don’t forget to backup the tail of the log before starting a restore sequence. 

2. Use differential restore to speed up the restore process if available. 

3. Use file level restore to speed up restores when not all database files are corrupt. 

4. Perform regular database backups of master, msdb and model system databases. 

5. Create a disaster recovery plan for your SQL Server and test restoring databases regularly.

7-38 Restoring SQL Server 2012 Databases

Module 8 

Importing and Exporting Data 

Contents: 

Lesson 1: Transferring Data To/From SQL Server 8-3 

Lesson 2: Importing & Exporting Table Data 8-15 

Lesson 3: Inserting Data in Bulk 8-20 

Lab 8: Importing and Exporting Data 8-29 

8-1

8-2 Importing and Exporting Data 


While a great deal of data that resides in a Microsoft® SQL Server® system may be entered directly by 

users that are running application programs, there is also a need to move data in other locations to and 

from SQL Server. 

SQL Server provides a set of tools that can be used to transfer data in and out of SQL Server. Some of 

these tools, such as the bcp utility and SQL Server Integration Services are external to the database 

engine, and other tools such as the BULK INSERT statement, and the OPENROWSET function, are 

implemented within the database engine. In this module, you will briefly explore each of these tools. 

On occasions, large amounts of data need to be imported into SQL Server. While the default settings in 

SQL Server can be used while importing the data, higher performance can be achieved by exerting control 

over how constraints, triggers, and indexes are used during the import process. 

Objectives 


• Transfer data to and from SQL Server. 

• Import and export table data. 

• Insert data in bulk and optimize the bulk insert process.

Lesson 1 

Transferring Data To/From SQL Server 


The first step in learning to transfer data in and out of SQL Server is to become familiar with the processes 

involved and with the tools that SQL Server provides to implement data transfer. 

When large amounts of data need to be inserted into SQL Server tables, the default settings for 

constraints, triggers, and indexes are not likely to provide the best performance possible. You may achieve 

higher performance by controlling when the checks that are made by constraints are carried out and by 

controlling when the index pages for a table are updated. 

Objectives 


• Explain core data transfer concepts. 

• Describe the tools that SQL Server provides for data transfer. 

• Improve the performance of data transfers. 

• Disable and rebuild indexes. 

• Disable and re-enable constraints.


Overview of Data Transfer 

Key Points 

Not all data can be entered row by row by database users. Often data needs to be imported from external 

data sources such as other database servers or from operating system files. Users often also request that 

data from tables in databases is exported to operating system files. In earlier modules, you have seen how 

collations can cause issues when misconfigured. Correcting the collation of a database also often requires 

the export and re-import of the data from the database. 

Data Transfer Steps 

Although not all data transfer requirements are identical, there is a standard process that most data 

transfer tasks follow. The main steps of this process are: 

• Extracting data from a given data source. 

• Transforming the data in some way to make it suitable for the target system. 

• Loading the data into the target system. 

Together, these three steps are commonly referred to as an Extract, Transform, Load (ETL) process. Tools 

that implement these processes are commonly referred to as ETL tools. 

Note In some situations, an Extract, Load, Transform (ELT) process might be more 

appropriate. For example, you may decide to perform data transformations once the data 

has been loaded into the database engine rather than before it is loaded.

Extracting Data 


While there are other options, extracting data typically involves the execution of queries on a source 

system to retrieve the data, or opening and reading operating system files. Another option would involve 

the querying of views provided by the source system. 

During the extraction process, there are two common aims: 

• Avoid excessive impact on the source system. For example, do not read entire tables of data when 

you only need to read selected rows. Also, do not continually re-read the same data, and avoid the 

execution of statements that block users of the source system in any way. 

• Ensure consistency of the data extraction. For example, do not include one row from the source 

system more than once in the output of the extraction. 

Transforming Data 

The transformation phase of an ELT process will generally involve several steps, such as the following: 

• Data might need to be cleansed. For example, you might need to remove erroneous data or provide 

default values for missing columns. 

• Lookups might need to be performed. For example, the input data might include the name of a 

customer, but the database might need an ID for the customer. 

• Data might need to be aggregated. For example, the input data might include every transaction that 

occurred on a given day, but the database might need only daily summary values. 

• Data might need to be de-aggregated. This is often referred to as data allocation. For example, the 

input data might include quarterly budgets, but the database might need daily budgets. 

In addition to these common operations, data might need to be restructured in some way. One common 

requirement is that the data might need to be pivoted or unpivoted. For example, the input data might 

reside in a table such as the following: 

Object Attribute Value 

1 FirstName David 

1 Age 64 

1 Gender M 

1 LastName Pelton 

2 FirstName Erin 

2 Age 47 

2 Gender F 

2 LastName Hagens 

The database might, however, require the same data in this format: 

PersonID FirstName Age Gender LastName 

1 David 64 M Pelton 

2 Erin 47 F Hagens 

This transformation is an example of pivoting data, where rows become columns or columns become 

rows.


Loading Data 

Once data is in an appropriate format, it can be loaded into the target system. Instead of performing row 

by row insert operations for the data, special options for loading data in bulk might be used. In addition, 

temporary configuration changes may be made to improve the performance of the load operation. 

Question: What other types of aggregation might need to be performed on data during the 

transformation phase?

Available Tools for Data Transfer 

Key Points 


SQL Server provides a set of tools for performing data transfer tasks. It is important to understand where 

to use each of the tools. 

Bulk Copy Program (bcp) 

The Bulk Copy Program (bcp) can be used to import large numbers of new rows from an operating 

system data file into a SQL Server table, or to export data from a SQL Server table to an operating system 

file. Although the bcp utility can be used with a T-SQL queryout option, which specifies the rows to be 

exported, the normal use of bcp does not require T-SQL knowledge. 

BULK INSERT 

The BULK INSERT statement is a T-SQL command that is used to import data directly from an operating 

system data file into a database table. The BULK INSERT statement differs from bcp in a number of ways. 

First, the BULK INSERT statement is executed from within T-SQL whereas the bcp utility is a command line 

utility. Also, while the bcp utility can be used for both import and output, the BULK INSERT statement can 

only be used for data import. 

OPENROWSET (BULK) 

OPENROWSET is a table-valued function that is used to connect to and retrieve data from OLE-DB data 

sources. Full details of how to connect to the data source need to be provided as parameters to the 

OPENROWSET function. OPENROWSET can be used to connect to other types of database engine. 

SQL Server provides a special OLE-DB provider called BULK that can be used with the OPENROWSET 

function. The BULK provider allows the import of entire documents from the file system.


Import/Export Wizard 

SQL Server Integration Services (SSIS) is an ETL tool that is supplied with SQL Server. SSIS is capable of 

connecting to a wide variety of data sources and destinations and is capable of performing complex 

transformations on data. SSIS provides many tasks and transformations out of the box and can also be 

extended by the use of custom .NET components and scripts. SQL Server also provides the Import/Export 

Wizard, which is a simple method of creating SSIS packages, without the need to use the SSIS design 

tools. 

XML Bulk Load 

The XML Bulk Load provider can be used to import XML data as a binary stream within a T-SQL 

statement. The data can be inserted directly into a column in an existing row of a database table. 

Question: When would you choose SSIS over bcp?

Improving the Performance of Data Transfers 

Key Points 


If constraints, indexes, and triggers are enabled on the tables that are the targets of data transfers, the 

data values need to be checked for every row that is imported. This constant checking can substantially 

slow down SQL Server data transfers. 

Disabling Constraints, Indexes, and Triggers 

Rather than checking each value that is imported, or updating each index for every row that is inserted, 

higher overall performance can often be achieved by disabling the process of checking or index updating, 

until all the data is loaded, and then performing that work one time at the end of the import process. 

For example, consider a FOREIGN KEY constraint that is used to ensure that the relevant customer does in 

fact exist, whenever a customer order is inserted into the database. While this reference could be checked 

for each customer order, consider that a customer might have thousands of customer orders. Instead of 

checking each value as it is inserted, the customer reference could be checked as a single lookup after the 

overall import process, to cover all customer orders that refer to that customer. 

Only CHECK and FOREIGN KEY constraints can be disabled. The process for disabling and re-enabling 

constraints will be discussed later in this lesson. 

Similar to the way that avoiding lookups for FOREIGN KEY constraints during data import can improve 

performance, avoiding constant updating of indexes can also improve performance. In many cases, 

rebuilding the indexes after the import process is complete will be much faster than updating the indexes 

as the rows are imported. The exception to this situation is when there is a much larger number of rows 

already in the table than are being imported. 

Triggers are commands that are executed when data is modified. It is important to decide if the 

processing that the triggers perform would also be better processed in bulk after the import, rather than 

as each insert occurs.


Control the Locking Behavior 

By default, SQL Server manages the granularity of the locks it acquires during the execution of commands. 

SQL Server starts with row level locking and only tries to escalate when a significant number of rows are 

locked within a table. Managing large numbers of locks occupies resources which could be used to 

minimize the execution time for queries. As the data in tables that are the target of bulk-import 

operations are normally only accessed by the process that is importing the data, the advantage of rowlevel 

locking is often not present. For this reason, it may be advisable to lock the entire table by using a 

TABLOCK query hint during the import process. 

Use Minimal Logging Whenever Possible: 

The operation of the transaction log was discussed in Module 5. Minimal logging is a special operation 

that can provide substantial performance improvements in some operations such as bulk-imports. As well 

as making the operations faster, minimal logging helps avoid excessive log growth during large import 

operations. 

Not all commands can use minimal logging. While not an exhaustive list, the items below indicate the 

types of restrictions that must be met for minimal logging to be applied: 

• The table is not being replicated. 

• Table locking is specified (using TABLOCK). 

• If the table has no clustered index but has one or more nonclustered indexes, data pages are always 

minimally logged. How index pages are logged, however, depends on whether the table is empty. 

• If the table is empty, index pages are minimally logged. 

• If table is non-empty, index pages are fully logged. 

• If the table has a clustered index and is empty, both data and index pages are minimally logged. 

• If a table has a clustered index and is non-empty, data pages and index pages are both fully logged 

regardless of the recovery model. 

Note Index types including clustered and nonclustered indexes are discussed in course 

10776A: Developing Microsoft SQL Server 2012 Databases. 

Question: What would the main problem with the transaction log be, if full logging occurs 

during a bulk-import operation?

Disabling & Rebuilding Indexes 

Key Points 


Prior to SQL Server 2005, indexes needed to be dropped to prevent them from being updated as the data 

in the table was updated. The problem with dropping the index, is that when you need to put the index 

back in place by recreating it, you would need to know exactly how the index was configured. 

Disabling an Index 

Since SQL Server 2005, an option exists to disable an index. Rather than totally dropping the index details 

from the database, disabling an index leaves the metadata about the index in place, and stops the index 

from being updated. Queries that are executed by users will not use disabled indexes. 

The major advantage of disabling an index instead of dropping it is that the index can be put back into 

operation by a rebuild operation. When you rebuild an index, you do not need to know details of how it is 

configured. This makes it much easier to create administrative scripts that stop indexes being updated 

while large import or update operations are taking place, and that put the indexes back into operation 

after those operations have completed. 

Note One special type of index known as a clustered index relates to how the table is 

structured, rather than to a separate index that speeds up the location of rows within the 

table. If a clustered index is disabled, the table becomes unusable until the index is rebuilt. 

Question: What is the main advantage of disabling and enabling indexes compared to 

dropping and recreating an index during bulk-imports?


Disabling & Enabling Constraints 

Key Points 

PRIMARY KEY constraints define the column or columns that uniquely identify each row in a table. 

UNIQUE constraints ensure that a column or columns do not contain duplicate values. SQL Server creates 

indexes to help it to enforce these constraints. 

Disabling PRIMARY KEY or UNIQUE Constraints 

To disable a PRIMARY KEY or UNIQUE constraint, you need to disable the index that is associated with the 

constraint. This is typically only useful with nonclustered PRIMARY KEY constraints. When the constraint is 

re-enabled, the associated indexes are rebuilt automatically. If duplicate values are found during the 

rebuild, the re-enabling of the constraint will fail. For this reason, if you disable these constraints while 

importing data, you need to be sure that the data that is being imported will not violate the rules that the 

constraints enforce. 

Note If a table has a primary key enforced with a clustered index, disabling the index 

associated with the constraint would prevent access to any data in the table. 

FOREIGN KEY constraints are used to make sure that those entities in one table that are referred to by 

entities in another table, actually exist. For example, a supplier must exist before a purchase order could 

be entered for the supplier. FOREIGN KEY constraints use PRIMARY KEY or UNIQUE constraints while 

checking the references. If you disable the PRIMARY KEY or UNIQUE constraint that a FOREIGN KEY 

reference points to, the FOREIGN KEY constraint will also automatically be disabled. However, when you 

re-enable the PRIMARY KEY or UNIQUE constraint, FOREIGN KEY references that use these constraints will 

not also be automatically re-enabled.

Disabling FOREIGN KEY and CHECK Constraints 


CHECK constraints are used to limit the values that can be contained in a column or the relationship 

between the values in multiple columns in a table. 

Note Constraints are described in course 10776A: Developing Microsoft SQL Server 2012 

Databases. 

Both FOREIGN KEY and CHECK constraints can be disabled and enabled using the CHECK and NOCHECK 

options of the ALTER TABLE statement. For example, consider the following code sample that disables a 

CHECK constraint named SalaryCap on a table called Person.Salary: 

ALTER TABLE Person.Salary NOCHECK CONSTRAINT SalaryCap; 

The following code is used to re-enable the constraint: 

ALTER TABLE Person.Salary CHECK CONSTRAINT SalaryCap; 

Question: Why do referencing foreign key constraints get disabled when the referenced 

PRIMAY KEY or UNIQUE constraints get disabled?


Demonstration 1A: Disabling & Enabling Constraints 











Lesson 2 

Importing & Exporting Table Data 


SQL Server Integration Services (SSIS) is a powerful ETL tool that can be used in conjunction with SQL 

Server. SSIS is capable of performing complex transformations on data from one or many sources and 

loading that data into one or many destinations. 

While SSIS is a very capable and complex tool, configuring SSIS for simple import and export processes 

has been made much easier because SQL Server also provides the Import/Export Wizard. This wizard 

presents simple configuration dialogs to users and creates an SSIS package based on the selections that 

the user has made. 

Objectives 


• Describe SQL Server Integration Services. 

• Use SQL Server Import/Export wizard.


Overview of SQL Server Integration Services 

Key Points 

SQL Server Integration Services (SSIS) is an ETL tool that is provided with SQL Server, in Standard and 

higher editions. SSIS allows the definition of complex data flows and transformations. The main purpose 

of SSIS is to create reusable and easily deployable packages that perform data transfers. 

Packages 

The result of building a set of tasks and transformations in SSIS is referred to as a package. Packages are 

also the unit of deployment for SSIS and contain a number of objects: Data Sources, Data Destinations, 

Control Flow, and Data Flows. 

Each package has a single Control Flow that contains a set of tasks that need to be executed. The 

workflow that needs to be followed when executing the tasks is defined by a set of precedence 

constraints. If data needs to be moved within an SSIS package, a Data Flow task is added to the set of 

tasks in the Control Flow. Each Data Flow task is individually configured to specify where data should 

come from, how it should be transformed, and where it should be sent to. 

One goal of SSIS is to perform all data transformation steps of the ETL process in a single operation 

without the need to stage data before transforming it. 

Packages are built using SQL Server Data Tools (SSDT). The SQL Server Import/Export Wizard also creates 

SSIS packages without the need for users to work with SSDT. 

Question: When it will useful to use SSIS instead of other data transfer options?

Demonstration 2A: Working with SSIS 





• In the virtual machine, open the 10775A_08_PRJ SQL Server script project within SQL Server 


• Open and execute the 00 – Setup.sql script file from within Solution Explorer. 




SQL Server Import/Export Wizard 

Key Points 

The SQL Server Import and Export Wizard can copy data to and from any data source for which a 

managed .NET Framework data provider or a native OLE-DB provider is available. 

The wizard has some limitations, but can be used with SQL Server, flat files, Microsoft Office Access®, 

Microsoft Office Excel®, and a wide variety of other database engines. 

Although it leverages SQL Server Integration Services, the SQL Server Import and Export Wizard provides 

minimal transformation capabilities. Except for setting the name, the data type, and the data type 

properties of columns in new destination tables and files, the SQL Server Import and Export Wizard 

supports no column-level transformations. 

Question: If additional transformations are needed above what is provided with the 

Import/Export Wizard, how could these be created?

Demonstration 2B: Using the Import/Export Wizard 














Lesson 3 

Inserting Data in Bulk 

There are three common options that are used to process the insertion of data in bulk with SQL Server. 

The bcp utility can be used from the command line to perform both input and output operations. 

BULK INSERT is a T-SQL command that can be used to import data in bulk and OPENROWSET is a tablevalued 

function that retrieves data from a variety of sources and returns it as a table that can be queried. 

OPENROWSET can be used in conjunction with an INSERT…SELECT statement to insert data in bulk. 

Objectives 


• Use the bcp utility. 

• Use the BULK INSERT statement. 

• Use the OPENROWSET function.

cp Utility 

Key Points 


The bcp utility is used to bulk copy data between an instance of Microsoft SQL Server 2012 and a data file 

in a user-specified format. The bcp utility can be used to import large numbers of new rows into SQL 

Server tables or to export data out of tables into data files. Except when used with the queryout option, 

the utility requires no knowledge of T-SQL. 

Format Files 

To import data into a table, you must either use a format file created for that table or provide that 

information to bcp interactively. Two types of format files are supported. Current versions of SQL Server 

use XML-based format files but are able to work with the older text-based format files. 

You can use the bcp utility to create a format file that can then be consumed by the bcp utility. In the first 

example on the slide, the bcp utility is being used to create a format file, based on the column layout of 

the Adv.Sales.Currency table.


The main parameters that have been specified have the following meanings: 

Parameter Description 

format Create a format file 

-T Integrated security is used to connect to the server 

-c Character data type is used for the export. Character data type provides 

the highest compatibility between different types of system. An 

alternative option –n would use the SQL Server native format, which is a 

more compact format but which can only be used for import/export to 

other SQL Server systems. 

-f The name of the format file 

-x The format file should be created as XML file 

In this example, bcp would connect to the default instance on the local server. If it is necessary to connect 

to another instance or another server, the –S parameter can be used to supply a server name or a server 

name and an instance name. 

Exporting Data 

In the second example on the slide, bcp is being used to export the current contents of the 

Adv.Sales.Currency table to the file Cur.dat. The one parameter that is different to the previous example is 

the "out" parameter that is used to specify the output file name. 

Importing Data 

In the third example on the slide, bcp is being used to import the contents of a file Cur.dat into the 

tempdb.Sales.Currency2 table. Two further uses of parameters are of interest in this example. The "in" 

parameter is being used to name the file that should be read. The parameter "-f" is being used to specify 

the format file Cur.xml so that SQL Server understands the format of the input file. 

Question: How could you improve the import speed of a bcp operation?

Demonstration 3A: Working with bcp 














BULK INSERT Statement 

Key Points 

BULK INSERT loads data from a data file into a table. This functionality is similar to that provided by the 

"in" option of the bcp command; however, the data file is read by the SQL Server process, not by an 

external utility. The BULK INSERT statement executes within a T-SQL batch. Because the data files are 

opened by a SQL Server process, data is not copied between client process and SQL Server processes. By 

comparison, the bcp utility runs in a separate process which produces a higher load on the server when 

run on the same system. 

Constraints and Triggers 

The BULK INSERT statement offers the CHECK_CONSTRAINTS and FIRE_TRIGGERS options that can be 

used to tell SQL Server to check constraints and triggers. Unlike the bcp utility, the default operation of 

the BULK INSERT statement is to not check CHECK and FOREIGN KEY constraints, or to fire triggers on the 

target table during import operations. 

Also unlike bcp, the BULK INSERT can be executed from within a user-defined transaction, which gives the 

ability to group BULK INSERT with other operations in a single transaction. Care must be taken however, 

to ensure that the size of the data batches that are imported within a single transaction are not excessive, 

or significant log file growth might occur, even when the database is in simple recovery model. 

Question: How does the BULK INSERT statement differ from bcp?

Demonstration 3B: Working with BULK INSERT 












3. Follow the instructions contained within the comments of the script file. 

Question: Why does the first message show 199 and messages after that show 200?


OPENROWSET Function 

Key Points 

OPENROWSET can be used to access data using an OLE-DB provider. For OLE-DB providers to be usable 

in OPENROWSET, a system configuration option "Ad Hoc Distributed Queries" must be enabled and a 

registry entry for the OLE-DB provider called DisallowAdhocAccess must be explicitly set to 0. This registry 

key is typically located here: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers\MSDASQL. 

When these options are not set, the default behavior does not allow for the ad hoc access that is required 

by the OPENROWSET function when working with external OLE-DB providers. 

BULK Provider 

Since SQL Server 2005, a special OLE-DB provider called BULK has been provided which allows the 

specification of operating system files that will be returned. The same format files that are used with bcp 

and BULK INSERT can be used with this provider. 

In addition to the import of typical data rows, the BULK provider offers three special options that allow 

the BULK provider to read entire file contents into a single column of a table. These special options are: 

Option Description 

SINGLE_CLOB Reads an entire single-byte character-based file as a single value of data 

type varchar(max). 

SINGLE_NCLOB Reads an entire double-byte character-based file as a single value of data 

type nvarchar(max). 

SINGLE_BLOB Reads an entire binary file as a single value of data type varbinary(max).

For example, consider the following code sample: 


INSERT INTO Sales.Documents(FileName, FileType, Document) 

SELECT 'JanuarySales.txt' AS FileName, 

'.txt' AS FileType, 

* 

FROM OPENROWSET(BULK N'K:\JanuarySales.txt', SINGLE_BLOB) AS Document; 

In this code sample, the file K:\JanuarySales.txt is being inserted into the Document column of the 

Sales.Documents table, along with its filename and filetype. 

Two key advantages of OPENROWSET compared to bcp are that it can be used in a query with a WHERE 

clause (to filter the rows that are loaded), and that it can be used in a SELECT statement that is not 

necessarily associated with an INSERT statement. 

Question: When will it make sense to use OPENROWSET instead of bcp or BULK INSERT?


Demonstration 3C: Working with OPENROWSET 










2. Open the 33 – Demonstration 3C.sql script file. 


Lab 8: Importing and Exporting Data 

Lab Setup 













00-Setup.sql. When the query window opens, click Execute on the toolbar.


Lab Scenario 

Proseware regularly receives updates of currencies and exchange rates from an external provider. One of 

these files is provided as an Excel spreadsheet, the other file is provided as a comma-delimited text file. 

You need to import both these files into tables that will be used by the Direct Marketing team within 

Proseware. 

Periodically the Marketing team requires a list of prospects that have not been contacted within the last 

month. You need to create and test a package that will extract this information to a file for them. 

You are concerned about the import performance for the exchange rate file and you are considering 

disabling constraints and indexes on the exchange rate table during the import process. If you have time, 

you will test the difference in import performance. 


Exercise 1 

Item Description 

Output table DirectMarketing.Currency 

Output columns CurrencyID int not null 

CurrencyCode nvarchar(3) not null 

CurrencyName nvarchar(50) not null 

Input file D:\10775A_Labs\10775A_08_PRJ\10775A_08_PRJ\Currency.xls 

Exercise 1: Import the Excel Spreadsheet 

Scenario 

You need to load a file of currency codes and names from an Excel spreadsheet. In this exercise, you will 

use the import wizard to perform the data load. 


1. Import the data using the Import Wizard. 

Task 1: Import the data using the Import Wizard 

• Import the spreadsheet Currency.xls into a table in the MarketDev database called 

DirectMarketing.Currency. If the table already exists, delete the table first. Refer to the Supporting 

Documentation for the file location and output table format. 

• Query the DirectMarketing.Currency table to see that the data that was loaded. 

Results: After this exercise, you should have imported the DirectMarketing.Currency table.

Exercise 2: Import the CSV File 

Scenario 


You have also been provided with a comma-delimited file of exchange rates. You need to import these 

exchange rates into the existing DirectMarketing.ExchangeRate table. The table should be truncated 

before the data is loaded. 


1. Import the CSV file. 

Note Make sure that you record how long the command takes to execute. Warning: it will 

take several minutes to complete. Use this time to prepare for the next Exercise. 

Task 1: Import the CSV file 

• Truncate the DirectMarketing.ExchangeRate table. 

• Review the ExchangeRates.xml format file in the Solution Explorer. 

• Using BULK INSERT T-SQL command import the ExchangeRates.csv file into the table 

DirectMarketing.ExchangeRate. The ExchangeRates.csv file can be found in the following location: 

D:\10775A_Labs\10775A_08_PRJ\10775A_08_PRJ\ExchangeRates.csv. 

• Use ExchangeRates.xml as the format file and a batch size of 10,000, and use the option to skip the 

first row as it contains headings. 

Results: After this exercise, you should have imported the ExchangeRate table using T-SQL BULK 

INSERT statement. 

Exercise 3: Create and Test an Extraction Package 

Scenario 

Periodically the Marketing team requires a list of prospects that have not been contacted within the last 

month. You need to create and test a package that will extract this information to a file for them. 


1. Create and test an extraction package. 

Task 1: Create and test an extraction package 

• Using the Export Wizard, export the Marketing.Prospect table to a text file in the following location: 

D:\MKTG\ProspectsToContact.csv. Column Names should be included in the first row. The extraction 

query should be as shown in the snippet below: 

SELECT ProspectID, FirstName, LastName, CellPhoneNumber, 

WorkPhoneNumber,EmailAddress, LatestContact 

FROM Marketing.Prospect 

WHERE LatestContact < DATEADD(MONTH,-1,SYSDATETIME()) 

OR LatestContact IS NULL 

ORDER BY ProspectID;


Note Save the SSIS package that is created by the Export Wizard to SQL Server in the 

package root location. 

Results: After this exercise, you should have created and tested an extraction package. 

Challenge Exercise 4: Compare Loading Performance (Only if time permits) 

Scenario 

You are concerned about the import performance for the exchange rate file and you are considering 

disabling constraints and indexes on the exchange rate table during the import process. If you have time, 

you will test the difference in import performance. 


1. Re-execute load with indexes disabled. 

Task 1: Re-execute load with indexes disabled 

• Alter your script from Exercise 2 to disable any non-clustered indexes on the 

DirectMarketing.ExchangeRate table before loading the data and to rebuild the indexes after the load 

completes. 

• Execute your modified script and compare the duration to the value recorded in Exercise 2. 

Results: After this exercise, you should have compared the load performance with indexes 

disabled.



1. When would you use SSIS instead of other data transfer utilities? 

2. Why are minimally logged operations faster than fully logged operations? 



1. Choose the right tool for bulk-imports. 

2. Use SSIS for complex transformations. 

3. Use bcp or BULK INSERT for fast imports and exports. 

4. Use OPENROWSET when data needs to be filtered before it gets inserted. 

5. Try to achieve minimal logging to speed up data import.

8-34 Importing and Exporting Data

Module 9 

Authenticating and Authorizing Users 

Contents: 

Lesson 1: Authenticating Connections to SQL Server 9-3 

Lesson 2: Authorizing Logins to Access Databases 9-13 

Lesson 3: Authorization Across Servers 9-22 

Lab 9: Authenticating and Authorizing Users 9-30 

9-1

9-2 Authenticating and Authorizing Users 


Securing Microsoft® SQL Server® can be viewed as a series of steps, involving four areas: the platform, 

authentication, objects (including data), and applications that access the system. Well-planned security is 

important for protecting your organization’s sensitive information. 

In this module you will be introduced to securing SQL Server. You will learn how SQL Server authenticates 

users and how it authorizes the users to access databases. Not all resources reside on a single server. In 

this module, you will also see how distributed authorization is configured; that is, where more than one 

SQL Server system is involved. 

Objectives 


• Describe how SQL Server authenticates connections. 

• Describe how logins are authorized to access databases. 

• Explain the requirements for authorization across servers.

Lesson 1 

Authenticating Connections to SQL Server 


The first layer of security within SQL Server is authentication of users. Before any other security settings 

can be examined, SQL Server needs to verify the identity of the user. 

Authentication is the process of identifying users and of verifying their identity. In this lesson, you will 

learn about the options available for authenticating users, about the available types of logins to the server 

and about how policies are managed in relation to SQL Server logins. 

Objectives 


• Describe SQL Server security. 

• Implement SQL Server authentication options. 

• Provide access to SQL Server for Windows® users and groups. 

• Provide access to SQL Server for other users.


Overview of SQL Server Security 

Key Points 

A user can gain permission to connect to SQL Server in one of four ways: 

• They can be a user that SQL Server manages directly. These users become known as SQL Server 

logins. 

• They can be a user that Windows has authenticated and SQL Server has been configured to allow the 

user to connect. These users become known as Windows logins. 

• They can be a Windows user that is a member of a Windows group. SQL Server has been configured 

to allow members of the group to connect. These users also become known as Windows logins. 

• They can be a database user that is assigned a password directly where the user is not associated with 

a login. 

Note It is also possible for logins to be created from certificates and keys but the creation 

of these is an advanced topic, outside the scope of this course. 

Logins vs. Database Users 

The distinction between logins and database users is important. The term "Login" is applied to a principal 

(or process) that has been granted access to SQL Server via one of the three methods mentioned above. 

Note Having access to the server does not indicate (in itself) that a login has any access to 

user databases on the server.


Logins can be granted permission to access one or more databases. A mapping can exist between a login 

(either Windows Login or a SQL Server Login) and a "Database User" in a particular database. Database 

users often have the same name as the logins that they are mapped to but the names can be different. A 

login can even be mapped to different user names in each database. 

Note Keeping login and database user names the same is considered a best practice. 

Permissions 

Even once a login is granted access to a database by the creation of a database user, the database user 

will need to be granted permissions within the database before they can access securable objects such as 

tables, views, functions, and stored procedures. 

Note Some logins have permissions across all databases because they are added to roles 

at the server level, such as the sysadmin role, but these are exceptions to the general 

situation. 

There are two ways that database users can be granted permission to access securable objects. The 

database users can be granted permissions on the objects. Alternatively, roles can be created within the 

database. Roles are granted permissions on the securable objects and the database users are added as 

members of the roles. Database users inherit all permissions that are associated with any roles that they 

are members of, along with any permissions that have been directly assigned to them. 

Question: Apart from Windows users, what other types of users might want to connect to 

SQL Server?


SQL Server Authentication Options 

Key Points 

Authentication is the process of verifying that an identity is valid. If the identity is a user, is the user who 

they claim to be? There are two basic ways this can occur. 

• SQL Server trusts the Windows operating system to verify the identity of a Windows login. Windows 

might use different methods such as password-checking, biometric checks (for example, fingerprint 

scanning) or certificates to validate a user's identity. It might even use a combination of such 

methods. In SQL Server, Windows logins are often referred to as "trusted logins". 

• SQL Server can directly verify the identity of a SQL Server login by checking that they know the 

password associated with that login. 

Question: If you call your bank by phone, how do they verify your identity before speaking 

to you about your account details? 

Server Configuration 

SQL Server can be configured in two modes 

• Windows Authentication mode. 

• SQL Server and Windows Authentication mode. 

Windows Authentication mode was formerly known as Integrated Mode. In Windows Authentication 

mode, only users that the Windows operating system has authenticated are permitted to connect to the 

server. 

In SQL Server and Windows Authentication mode, both users that have been authenticated by the 

Windows operating system and users that SQL Server has directly authenticated are permitted to connect 

to the server. This mode is often called Mixed Mode.


The choice between these two modes is made at the SQL Server instance level during the installation of 

SQL Server and can easily be changed. The instance needs to be restarted after changing the 


Note The configuration can be made using the GUI tooling in SSMS but it is in fact only a 

single registry key that is being changed. This registry key could be configured via a group 

policy within Windows. 

If SQL Server and Windows Authentication mode is enabled, a SQL Server login called "sa" is then active. It 

is important to set an appropriate (and complex) password for the "sa" login and record it somewhere. 

When SQL Server is installed as Windows Authentication Only, the "sa" account is disabled by default. If 

SQL Server is installed in Mixed Mode, then "sa" is enabled by default. Changing the server's 

authentication mode does not change the enabled/disabled state of the "sa" login. 

Protocols for Authentication 

Windows authentication is typically performed via the Kerberos protocol. The Kerberos protocol is 

supported with SQL Server over the TCP/IP, Named Pipes, and Shared Memory network protocols. 

(Support for Kerberos over Named Pipes and Shared Memory was introduced in SQL Server 2008. SQL 

Server 2005 supported Kerberos on the TCP/IP network protocol).


Managing Windows Logins 

Key Points 

Logins can be created directly using T-SQL code or via the GUI provided in SSMS. While the GUI option 

can be used, creating logins is a common operation and if many logins need to be created, you will find it 

much faster, more repeatable, and accurate to use a script. 

CREATE LOGIN 

Logins can be created in two ways. To create a login in SSMS, expand the Security node at the server 

instance level and then right-click Logins to choose New Login. 

Alternatively, logins can be created using the CREATE LOGIN statement as shown in the slide example. 

Note Windows user and group names must be enclosed within square brackets as shown 

in the slide example, primarily because they contain a backslash character. 

Windows logins can be created for individual users or for Windows groups. The first example in the slide 

shows the creation of a login for an individual user. Note that a default database and a default language 

are assigned. 

When a default database is not assigned directly, the master database will be assigned by SQL Server. 

When a default language is not assigned directly, the default language of the server instance will be 

assigned by SQL Server.

Windows Groups 


The second example in the slide is for a Windows group. Members of the group 

AdventureWorks\Salespeople will be permitted to connect to the server without the need for individual 

logins. 

Note Windows users and groups can both refer to local or domain users and groups. 

Removing Logins 

Logins are removed with the DROP LOGIN statement. Note that you cannot drop a login if the user is 

currently logged in. Should you need to do this, you will need to locate their session ID in the SSMS 

Activity Monitor (by viewing the list of processes) and kill the session first. Avoid deleting logins where the 

database users associated with the logins own objects within databases. (Object ownership is discussed in 

Module 11). 

Question: Why would you create logins based on groups in preference to logins based on 

users?


Managing SQL Server Logins and Policies 

Key Points 

SQL Server logins are created for individual identities and are created using the same tools as Windows 

logins. 

Security of SQL Server Logins 

For many years, the use of SQL Server logins was considered a poor security practice. There were several 

reasons for this, including: 

• Unencrypted authentication. 

• Lack of account policy. 

The concern with encryption was that during the authentication phase, the traffic on the network was not 

encrypted. This means that an attacker that "sniffed" network packets would have been able to detect 

enough information to access the system via the SQL Server login. 

The concern with account policy was that even though the SQL Server system might have been part of a 

domain that implemented detailed account policy, the policy did not apply to SQL Server logins. Both of 

these issues were addressed in SQL Server 2005.

Encrypted Authentication 


The upgraded SQL Server Native Access Client (SNAC) that was provided with SQL Server 2005 was 

enhanced to provide encrypted authentication. If SQL Server did not have a Secure Sockets Layer (SSL) 

certificate installed by an administrator, SQL Server would generate and self-sign a certificate to be used 

for encrypting authentication traffic. 

Note Encrypted authentication only applied to clients running the SQL Server 2005 

version of SNAC or later. If an earlier client that did not understand encrypted 

authentication tried to connect, by default SQL Server would allow this. There is a 

configurable property for each supported protocol in SQL Server Configuration Manager 

that can be used to disallow unencrypted authentication from down-level clients if this is a 

concern. 

Account Policy 

The implementation of account policy is based on the ability to read policy details from the operating 

system. Windows Server 2003 and later operating systems introduced an API that allowed applications to 

read details of account policy. 

SQL Server is supported on some operating systems (such as Windows XP) that do not support this API. 

For those operating systems, account policy is replaced by a basic set of password complexity rules. 

The full application of account policy is not always desirable. For example, some applications use fixed 

logins to connect to the server. Often, these applications do not support regular changing of login 

passwords. In these cases, it is common to disable policy checking for those logins. 

Password Changing and Login Expiry 

Passwords can be reset using the GUI in SSMS or via the ALTER LOGIN statement. If logins are not being 

used for a period of time, they can be disabled and later re-enabled. If there is any chance that a login will 

be needed again in the future, it would be better to be disabled rather than dropped. Disabling the login 

is achieved by executing the ALTER LOGIN statement as shown in the code below: 

ALTER LOGIN James DISABLE; 

Question: Can you suggest a type of account policy that Windows provides?


Demonstration 1A: Authenticating Logons and Logon Tokens 











Lesson 2 

Authorizing Logins to Access Databases 


Once the identity of a login has been verified, it is necessary to provide that login with access to the 

databases that the login needs to work with. This access is provided by granting the login access to a 

database and then by providing the login with sufficient permissions within the database to perform the 

necessary work. 

In this lesson, you will see how to grant access to a database to a login and see details of special forms of 

access to databases. 

Objectives 


• Describe the SQL Server authorization process. 

• Grant access to databases. 

• Manage dbo and guest access. 

• Configure users with passwords for partially contained databases.


Authorization Overview 

Key Points 

A very common error when discussing security is to confuse the concepts of authentication and 

authorization. You can think of authentication as proving who you are and you can think of authorization 

as determining what you are allowed to do. 

Formal Terminology 

It is important to be familiar with common security-related formal terminology as shown in the following 

table: 

Term Description 

Principal An entity that can request access to a resource 

Securable A resource that can be secured or an object that you can control access to 

Authentication Ensuring that the principal is who they say they are 

Authorization Providing controlled access to a securable, for a principal. That is, 

determining the permissions that a principal has on a securable 

Role A container for principals that can be used to assign permissions indirectly 

A role is a name that is given to a group of principals. Roles are created to make it easier to grant 

permissions to many principals that need similar levels of access. Roles in SQL Server are similar to groups 

within the Windows operating system. 

Permissions are controlled by the GRANT, REVOKE, and DENY commands and will be discussed in 

Module 11. 

Question: Would you imagine that a login is a principal or a securable?

Granting Access to Databases 

Key Points 


Logins are granted access to databases through the creation of database users. A database user is a 

principal within a database that is mapped to a login at the server. 

Database users can be created through the SSMS GUI or via T-SQL commands. To create a new database 

user via the GUI, expand the relevant database, expand the Security node, right-click the Users node and 

choose the option for New User. 

Note There are special types of database users that are created directly from certificates 

and are not associated with logins. The creation of these is an advanced topic beyond the 

scope of this course. 

CREATE USER / DROP USER 

Once a login exists, it can be linked to a new database user with the CREATE USER statement of T-SQL. 

The DROP USER statement is used to remove these users. 

Consider the examples shown on the slide: 

• The first example creates a database user named SecureUser for an existing SQL Server login also 

named SecureUser. 

• The second example creates a database user named Student for a Windows login named 

AdventureWorks\Student.


• The third example creates a database user HRApp for a SQL Server login named HRUser. Note that 

the database user has been given a different name than the name of the login. 

Note The names of Windows logins (either users or groups) must be enclosed in square 

brackets.

Managing dbo and guest Access 

Key Points 

Each SQL Server database includes two special database users: dbo and guest. 

dbo 


dbo is a special user that has implied permissions to perform all activities in the database. Any member of 

the sysadmin fixed server role (including the "sa" user) who uses a database, is mapped to the special 

database user called dbo inside each database. The dbo database user cannot be deleted and is always 

present in every database. 

Database Ownership 

Like other objects in SQL Server, databases also have owners. The owner of a database is also mapped to 

the dbo user. The database owner can be modified using the ALTER AUTHORIZATION statement, as 

shown in the following code: 

ALTER AUTHORIZATION ON DATABASE::MarketDev 

TO [ADVENTUREWORKS\Administrator]; 

Any object that is created by any member of the sysadmin fixed server role will also automatically have 

dbo as its owner. Owners of objects have full access to the objects and do not require explicit permissions 

before they can perform operations on the objects.


guest 

The guest user account allows logins that are not mapped to a database user in a particular database to 

gain access to that database. Login accounts assume the identity of the guest user when the following 

conditions are met: 

• The login has access to SQL Server but does not have access to the database through its own 

database user mapping. 

• The guest account has been enabled. 

The guest account can be added to a database to allow anyone with a valid login to access the database. 

The guest username is automatically a member of the public role. (Roles will be discussed in the next 

module). 

A guest user works as follows: 

• SQL Server checks to see whether the login is mapped to with a database user in the database that 

the login is trying to access. If so, SQL Server grants the login access to the database as the database 

user. 

• SQL Server checks to see whether a guest database user is enabled. If so, the login is granted access 

to the database as guest. If the guest account does not exist or is not enabled, SQL Server denies 

access to the database. 

The guest user cannot be dropped but you can prevent it from accessing a database by executing the 

following command: 

REVOKE CONNECT FROM guest; 

The guest account can be enabled by executing the following command: 

GRANT CONNECT TO guest; 

Note The guest user is used to provide access to the master, msdb, and tempdb 

databases. You should not attempt to revoke guest access to these databases. 

Question: What is the guest user useful for?

Demonstration 2A: Authorizing Logins and User Tokens 











• Open and execute the 11 – Demonstration 1A.sql script file from within Solution Explorer. 




Creating Users for a Specific Database 

Key Points 

Until SQL Server 2012, for a user to connect to a database, they first needed to have a login created in the 

master database on the server. 

Users can now be created within a database without any entries being made in the master database for 

the users. A database must be partially contained before it can be used for users without logins. 

Containment is a property of a database. 

There are three types of users that can be authenticated by the database rather than by the server: 

• A Windows user can be authenticated at the database level based upon their Windows user 

credentials. 

• Members of a Windows group can be authenticated at the database level. 

• SQL Server users can be assigned passwords and authenticated at the database level, without the 

need for a SQL Server login. 

Users that are authenticated by the database cannot access other databases except as guest users.

Demonstration 2B: Configuring Users with Passwords 















Lesson 3 

Authorization Across Servers 

Not all resources reside within a single server. It is common to need to access resources on other servers. 

There are two common issues that arise in relation to working across servers. One is referred to as the 

"double-hop" problem and it relates to the difference between impersonation and delegation. In this 

lesson, these concepts will be explained. The second common problem is referred to as the "mismatched 

SID" problem that occurs when restoring or attaching a database from another server that was using SQL 

Server logins. You will also see approaches for dealing with this issue in this lesson. 

Objectives 


• Describe the typical "Double-Hop" problem. 

• Explain the difference between impersonation and delegation. 

• Work with security IDs.

Typical "Double-Hop" Problem 

Key Points 


There is a very common issue that arises when working across multiple servers. The problem occurs as 

shown on the slide: 

1. A user starts an application. This might involve starting a web application from a corporate web 

server. The application either logs the user onto another Windows identity or, more commonly, 

impersonates the user's identity. 

2. At this point, the application can perform tasks as though it was the user performing the tasks 

directly. The web server process might be executing as a low-privilege account but it is performing 

functions as though it was the Windows user. For example, the user would be able to access business 

functions within the application, based on the user's identity. A bank manager might be able to 

access the "Delete Bank Account" functionality while a bank teller might be denied access to do this. 

3. The application needs to connect to a database to retrieve business data. If the database server is 

installed on the same server as the web server, access to the database server is made using the same 

impersonation details. Within the SQL Server, the user would still have the correct Windows identity. 

The user would have permissions that have been assigned directly to the user and permissions that 

have been assigned to roles that the user is a member of. 

4. If, however, the database server is residing on another server, a problem occurs. When the identity of 

the user in SQL Server is checked, it is found to be the identity of the web server service, such as the 

low-privilege account, instead of the identity of the original user. 

This is a very typical "double-hop" problem caused by the default action of the Windows operating 

system that permits impersonation but not delegation. Database administrators are often asked why this 

is occurring. A significant security hole would be opened if this type of access was permitted between 

servers by default.


What often causes confusion is that the application may have worked as expected in a development 

environment where the web server and the database server were both on the same server but then fails to 

work as expected once the application is deployed to a production environment where this is no longer 

the case. 

In the next topic, you will see how impersonation and delegation differ. 

Question: If you have seen this problem with a web server, what was the user account that 

often appears to be connecting to SQL Server instead of the user?

Impersonation vs. Delegation 

Key Points 


By default, when a user connects to a Windows server, the user is impersonated on that server. That does 

not, however, give a process on the server the right to impersonate that user across the network. This 

impersonation across a network is known as delegation. This can apply to any Windows server that is 

connecting to a separate SQL Server and it also applies to one SQL Server system connecting to another 

SQL Server system. 

Delegation Requirements 

To illustrate the requirements for delegation between two SQL Server systems, consider the following 

scenario: 

• A user logs on to a client computer that connects to a server that is running an instance of SQL 

Server, SQLSERVER1. 

• The user wants to run a distributed query against a database on another server, SQLSERVER2. 

• This scenario, in which one computer connects to another computer to connect to a third computer, 

is an example of a "double-hop". 

Each server or computer that is involved in delegation needs to be configured appropriately. 

Requirements for the Client 

• The Windows authenticated login of the user must have access permissions to SQLSERVER1 and 

SQLSERVER2. 

• The user Active Directory property "Account is sensitive and cannot be delegated" must not be 

selected. 

• The client computer must be using TCP/IP or named pipes network connectivity.


Requirements for the First/Middle Server (SQLSERVER1) 

• The server must have a Server Principal Name (SPN) registered by the domain administrator. 

• The account under which SQL Server is running must be trusted for delegation. 

• The server must be using TCP/IP or named pipes network connectivity. 

• The second server, SQLSERVER2, must be added as a linked server. This can be done by executing the 

sp_addlinkedserver stored procedure or by configurations within SSMS. For example: 

EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server‘ 

• The linked server logins must be configured for self-mapping. This can be done by executing the 

sp_addlinkedsrvlogin stored procedure. For example: 

EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true' 

Requirements for the Second Server (SQLSERVER2) 

• If using TCP/IP network connectivity, the server must have an SPN registered by the domain 

administrator. 

• The server must be using TCP/IP or named pipes network connectivity.

Working with Mismatched Security IDs 

Key Points 


Another very common issue that relates to the use of multiple servers is referred to as the "mismatched 

SIDs" problem. 

Mismatched SIDs 

When a SQL Server login is created, the login is allocated both a name and a Security ID (SID). When a 

database user is created for the login, details of both the name and the SID for the login are entered into 

the database. 

If the database is then backed up and restored onto another server, the database user entry is still present 

within the database but there is no login on the server that matches it. 

Database administrators often then create the new login and map it as a user in the database and they 

find that this fails. When the login is created, it might have the same name and even the same password 

as the original login on the other server, but by default SQL Server will allocate it a new SID. 

The new login will be unable to be added to the database. This can be a source of frustration because the 

error that is returned explains that the database user already exists, yet a check on the list of database 

user mappings for this login in SSMS will not show this entry. This is a good example of a situation where 

an understanding of T-SQL coding is helpful in SQL Server administration, rather than just an 

understanding of how to use the GUI in SSMS.


Resolving Mismatched SIDs 

In earlier versions of SQL Server, the option provided to deal with this situation was a system stored 

procedure sp_change_users_login. 

Starting with Service Pack 2 of SQL Server 2005, a new alternative was provided: 

ALTER USER dbuser WITH LOGIN = loginname; 

The problem with either of these methods is that they "fix" the SID of the database user to match the SID 

of the login. The next time the database is restored (as often happens), the same problem occurs again. 

Avoiding the Issue 

A better way of dealing with mis-matched SIDs is to avoid the problem in the first place. 

The CREATE LOGIN statement has a WITH SID option. If you supply the SID from the original server while 

creating the login on the second server, you will avoid the problem occurring at all. The sp_helprevlogin 

stored procedure is another option that can be used to help with scripting SQL Server logins and it 

includes the value of the SID. Logins that are created using the scripts generated by this procedure will 

also not suffer from the mis-matched SIDs problem. Details of the sp_helprevlogin procedure (along with 

the source code of the procedure) are provided on the support.microsoft.com web site. 

Note While SQL Server Integration Services includes a task for transferring logins, the tool 

disables the logins and assigns them a random password. 

You will see an example of the mismatched SIDs problem in Demonstration 3A.

Demonstration 3A: Working with Mismatched SIDs 


1. If Demonstration 1A or 2A was not performed: 



• In the virtual machine, click Start, click All Programs, click Microsoft SQL Server 2012, click SQL 

Server Management Studio. In the Connect to Server window, type Proseware and click 



• From the View menu, click Solution Explorer. Open and execute the script files 

00 – Setup.sql, 11 – Demonstration 1A.sql , and 21 – Demonstration 2A.sql from within 

Solution Explorer. 

2. Open the 31 – Demonstration 3A.sql script file and follow the instructions contained within the 

comments of the script file.


Lab 9: Authenticating and Authorizing Users 

Lab Setup 













Lab Scenario 

You need to configure the security for the Marketing database prior to the business accessing the system. 

You need to configure security so that organizational users are able to connect to SQL Server but are only 

to access resources that they are permitted to access. Most users will connect using their Windows group 

credentials. Some users however will need to use individual Windows logins. An application requires the 

use of a SQL Server login.


If you have time there is a problem with the LanguageDetails database that you should try to solve. 

Note The changes you make will later be migrated to the production environment. You 

should use T-SQL commands to implement the required changes. 


Existing Windows User and Group Structure 

ITSupport SalesPeople CreditManagement HumanResources CorporateManagers 

David.Alexander X X 

Jeff.Hay X 

Palle.Petersen X 

Terry.Adams X 

Darren.Parker X X 

Mike.Ray X 

April.Reagan X 

Jamie.Reding X 

Darcy.Jayne X 

Naoki.Sato X 

Bjorn.Rettig X X 

Don.Richardson X 

Wendy.Kahn X 

Neil.Black X X 

Madeleine.Kelly X


Pre-existing Security Configuration 

• The SQL Login PromoteApp has been created. 


Note: this list of security requirements applies to several modules. For this module, you only need to 

consider those requirements that can be satisfied by topics covered in this module and the assigned tasks 

in the lab instructions. 

1. The senior DBA Jeff Hay should have full access to and control of the entire Proseware server instance. 

2. All ITSupport group members should have full access to and control of the MarketDev database. 

3. Proseware uses an application called DBMonitor from Trey Research. This application requires a SQL 

login called DBMonitorApp, which requires the ability to read but not update all objects in the 

MarketDev database. It does not require access to other databases. 

4. All CorporateManagers group members perform periodic Strength, Weakness, Opportunity, and 

Threat (SWOT) analysis. For this they need to be able to both read and update rows in the 

DirectMarketing.Competitor table. 

5. All SalesPeople group members should be able to read data from all tables in the DirectMarketing 

schema, except April Reagan who is a junior work experience student. 

6. Only ITSupport group members and members of the CreditManagement group should be able to 

update the Marketing.CampaignBalance table directly. 

7. Within the company members of the SalesPeople group, the CreditManagement group, and the 

CorporateManagers group are referred to as sales team members. 

8. All sales team members should be able to read rows in the Marketing.CampaignBalance table. 

9. All sales team members should be able to read rows in the DirectMarketing.Competitor table. 

10. The Sales Manager should be able to read and update the Marketing.SalesTerritory table. 

11. All HumanResources group members should be able to read and update rows in the 

Marketing.SalesPerson table. 

12. The Sales Manager should be able to execute the Marketing.MoveCampaignBalance stored 

procedure. 

13. All sales team members should be able to execute all stored procedures in the DirectMarketing 

schema. 

Exercise 1: Create Logins 

Scenario 

You have been provided with the security requirements for the MarketDev database. In this exercise you 

need to create individual Windows logins, Windows group logins, and SQL logins that are required to 

implement the security requirements. 


1. Review the requirements. 

2. Create the required logins.

Task 1: Review the requirements 

• Review the supplied security requirements in the supporting documentation. 

Task 2: Create the required logins 


• Create the logins that you have determined are required for the system. This will include Windows 

logins, Windows group logins, and SQL logins. 

Results: After this exercise, you have created the required Windows and SQL logins. 

Exercise 2: Correct an Application Login Issue 

Scenario 

The Adventure Works IT department has implemented a new web application called Promote. The 

Promote application requires a SQL login called PromoteApp. The SQL login needs to operate with a fixed 

password. The application has been operating for some time but has now stopped working. It appears the 

application is unable to log on to the Proseware server. You need to reset the password for the 

PromoteApp user and disable policy checking for the login. 


1. Correct an Application Login Issue. 

Task 1: Correct an application login issue 

• Reset the password for the PromoteApp SQL login to “Pa$$w0rd”. 

• Disable policy checking for the application login. 

Results: After this exercise, you have corrected an application login issue. 

Exercise 3: Create Database Users 

Scenario 

You have created the required logins for the Proseware server as per the security requirements that you 

have been supplied. You need to create database users for those logins in the MarketDev database. 



2. Create the required database users. 



Task 2: Create the required database users 

• Create the database users that you have determined are required for the MarketDev database. 

Results: After this exercise, you should have created the required database users.


Challenge Exercise 4: Correct Access to Restored Database (Only if time 

permits) 

Scenario 

A junior DBA has been trying to restore the LanguageDetails database and grant access to a SQL login 

named LDUser. He was able to restore the database and to create the login but he has been unable to 

create the database user. He suspects that something in the existing database is preventing this as he can 

create and assign other SQL logins without issue. You need to restore the LanguageDetails database, 

create the LDUser login, create the LDUser database user, and test that the user can access the database. 


1. Correct Access to a Restored Database. 

Task 1: Correct Access to a restored database 

• Restore the LanguageDetails database from the file 

D:\10775A_Labs\10775A_09_PRJ\LanguageDetails.bak to the Proseware server instance. 

• Create the login LDUser with policy checking disabled and a password of “Pa$$w0rd”. 

• Correct access to the LanguageDetails database for the LDUser database user. 

• Test that the LDUser login can access the database and can select the rows from the dbo.Language 

table. 

Results: After this exercise, you should have resolved the situation.



1. How does SQL Server take advantage of Windows password Policy? 

2. What account policy is applied on Windows XP? 


1. Minimize the number of SQL Server logins. 


2. Ensure that expiry dates are applied to logins that are created for temporary purposes. 

3. Disable logins rather than dropping them if there is any chance that they will be needed again. 

4. Configure Kerberos delegation when a Windows user identity needs to be passed between systems.

9-36 Authenticating and Authorizing Users

Module 10 

Assigning Server and Database Roles 

Contents: 

Lesson 1: Working with Server Roles 10-3 

Lesson 2: Working with Fixed Database Roles 10-12 

Lesson 3: Creating User-defined Database Roles 10-18 

Lab 10: Assigning Server and Database Roles 10-26 

10-1

10-2 Assigning Server and Database Roles 


Once a login has been authenticated by the server, and mapped to a database user, you need to assign 

permissions to the login or database user. Permissions can be assigned directly to the login or database 

user. In the next module, you will see how permissions are directly assigned but while it is possible to do 

so, where sets of permissions potentially apply to multiple users, roles can be used to provide the 

permissions instead. 

SQL Server® has a set of fixed roles at both the server and database levels and user-defined roles can also 

be created at both levels. The fixed roles have a specified set of permissions but user-defined roles have a 

user-defined set of permissions applied to them. A login or database user is assigned the permissions 

associated with any role that the login or database user is a member of. 

Objectives 

After completing this module, you will be able to: 

• Work with server roles. 

• Work with fixed database roles. 

• Create user-defined database roles.

Lesson 1 

Working with Server Roles 


The first type of role that you will investigate is a Server Role. Server Roles have permissions that span the 

entire server instance. While Server Roles are very powerful, they should be used rarely. 

The most powerful Server Role is the sysadmin role. You should be cautious about assigning logins to this 

role as members of this role have complete access to the entire server. 

In this lesson, you will also investigate the public role. public can be used to assign instance-level 

permissions to all logins. 

Objectives 


• Describe server-scoped permissions. 

• Describe permissions that might typically be assigned at the server level. 

• Explain the use of fixed server roles. 

• Explain the purpose of the public server role. 

• Configure user-defined server roles.


Server-scoped Permissions 

Key Points 

Permissions that are allocated at the server level are very powerful. They apply to the entire server and all 

databases on the server. For this reason, you should avoid allocating server-scoped permissions and try to 

assign more specific permissions instead. 

Fixed server-scoped roles have been part of SQL Server for many versions and are mostly maintained for 

backward compatibility. 

Slide Examples 

On this slide, two examples are provided of granting server-level permissions. The first example shows 

how to grant a specific permission. The Windows login AdventureWorks\Holly is being granted the 

permission to alter the login HRApp. 

The second example shows how to use the ANY option. ANY can be applied to many object types, 

including objects that are scoped to the server level. The use of the ANY option allows for permissions to 

be assigned on specific classes of object without the need to create large numbers of individual 

permissions. Note that as well as granting AdventureWorks\Holly the ability to alter any existing 

databases, this permission grant would also apply to any future databases that are created on the server. 

The full syntax of the GRANT statement is complex. More details on the GRANT statement will be 

provided in Module 11.

Assignment Using the GUI 

SQL Server securables are any objects that can be protected via permissions. 


Note If no securable is shown on the tab in SSMS, do not assume that no permissions are 

assigned to any securable. Most times, the securable that needs to be viewed or changed 

needs to be added manually.


Typical Server-scoped Permissions 

Key Points 

On this slide, you can see a list of server-scoped permissions that are commonly assigned. As mentioned, 

very few permissions are typically assigned at the server level. 

These permissions cannot be assigned unless the current database is the master database. Otherwise, an 

error will be returned. 

The sys.server_permissions view is used to query the currently assigned server-scoped permissions. You 

will see an example of it being used in Demonstration 1A.

Overview of Fixed Server Roles 

Key Points 


On this slide, you can see the list of fixed server roles, a general description of what they are used for and 

a list of the major permissions that are associated will each of the roles. 

Note The list of permissions shown is not an exhaustive list. For full details, consult Books 

Online. 

These server-level roles are referred to as fixed server roles because you cannot change the permissions 

associated with these roles. 

Populating Fixed Server Roles 

You can add logins into server-level roles. One behavior that might not be expected is that each member 

of a fixed server role can add other logins to that same role. 

Roles vs. Permissions 

Being assigned the same permissions as those that are assigned to a role is not the same as being a 

member of the role.


For example, granting CONTROL SERVER permission to a login is not the same as making the login a 

member of the sysadmin fixed server role. sysadmin members are automatically assigned to the dbo user 

in a database. This does not happen for logins that have been only been granted CONTROL SERVER 

permission. 

Note Securityadmin is almost functionally equivalent to the sysadmin role and should be 

granted with caution. 

To change the membership of fixed server roles, use the ALTER SERVER ROLE command. You will see an 

example of this in Demonstration 1A. 

Question: Why would the securityadmin role be powerful?

public Server Role 

Key Points 


public is a special role that is also scoped to the server level. It is not considered a fixed server role as it is 

possible to alter the permissions that are assigned to the public role. All logins are automatically members 

of the public role, so this is another role that should be assigned permissions with caution. 

VIEW ANY DATABASE 

Many SQL Server tools, utilities and applications assume that the list of databases can be viewed, even if 

the user that is viewing the list does not have permission to perform any actions on or in the database. 

This is achieved by the public role having VIEW ANY DATABASE permission. While it is possible to stop the 

ability to view databases that you do not have access to, be cautious about doing so. SSMS, in particular, 

becomes very slow to use if you do this, as it then needs to check your permissions within every database. 

One possible use case for this would be hosted databases, where the provision of a database for a user 

should not enable the user to view all the other databases on the server. Test the behavior and 

performance of your database tooling and applications before deciding to change this. 

Connect Permissions 

By default, the public role has been granted CONNECT permission on the endpoints for the Shared 

Memory, TCP, Named Pipes, and VIA protocols. This allows users to connect to the server using any of 

these protocols.


User-defined Server Roles 

Key Points 

New to SQL Server 2012 is the ability to create user-defined roles at the server level. 

In general, you should avoid using fixed server roles as they tend to provide users with more permissions 

than required to do their assigned tasks. User-defined server roles allow you to configure a specific set of 

server-level permissions that are required for members of the role.

Demonstration 1A: Assigning Server Roles 













Lesson 2 

Working with Fixed Database Roles 

In addition to the roles provided at the server level, SQL Server provides a set of fixed roles at the 

database level. These fixed database roles are similar in concept to the fixed server roles but they relate to 

access to database objects or access to the database itself, rather than access to all databases on the 

server. 

Objectives 


• Explain the available database-scoped permissions. 

• Describe fixed database roles. 

• Assign users to roles. 

• Describe the concept of the database owner.

Database-scoped Permissions 

Key Points 

There are three ways that permissions can be assigned at the database level: 


• Fixed database roles are very similar to fixed server roles, apart from the objects that they apply to 

and that the scope is database level rather than server level. 

• Similar to server roles, it is possible to create user-defined database roles and to assign a user-defined 

set of permissions to each role. 

• Database-scoped permissions can be individually assigned. 

Try to avoid assigning fixed database roles as they usually provide more capabilities than those that are 

required for most users. Assign much more specific permissions instead of the fixed database role 

membership. 

Slide Example 

In the first example on the slide, the database user HRManager is being granted permission to create 

tables within the database. It is important to understand that several permissions might be required to 

perform an action. In this example, HRManager would also require ALTER SCHEMA permission to 

successfully create tables. 

In the second example on the slide, the database user James is being assigned permission to view the 

definitions of objects within the database. This permission grant is common for users that need to perform 

documentation but who are not permitted to alter the design of the database.


Overview of Fixed Database Roles 

Key Points 

The slide shows the available fixed database roles and a description of the purpose they are intended to 

fill. 

In practice, fixed database roles should be assigned very selectively. Instead of assigning fixed database 

roles, consider assigning much more specific permissions. 

For example, instead of assigning the db_datareader role to a user, consider assigning SELECT permission 

on the objects that the user needs to be able to SELECT. This avoids situations where additional tables are 

added to a database and the user already has permissions on those tables. Even if the user needs 

permission to SELECT all objects in the database, it would be preferable to assign SELECT permissions at 

the database level than to assign the user membership of the db_datareader role. One reason for this is 

that it is easier to review the permission assignments using views such as sys.database_permissions. 

Similar to fixed server roles, fixed database roles exist largely for backward compatibility. 

Note Similar to the securityadmin fixed server role, adding users to the db_securityadmin 

role should be performed with caution as the permission is almost functionally equivalent to 

the dbo user.

Assigning Users to Roles 

Key Points 


Users can be assigned to roles either using the GUI in SSMS or by using T-SQL commands. 

GUI 

To assign a role to a user using SSMS, expand the server, expand the Security node, expand the Logins 

node, then right-click the login and click Properties. In the Properties window for the login, click on the 

User Mapping tab to see the list of databases that the login has been mapped to. As you select each 

database in the upper pane, a list of database roles appears in the lower pane. You can then select the 

roles that the login should be assigned to. 

You can also assign role membership from the perspective of the role. To assign or remove users from a 

role using SSMS, expand the relevant database, expand the Security node, expand the Roles node, expand 

the Database Roles node, then right-click the relevant role and click Properties. From the Properties 

screen for the role, you can add and delete users from that database. 

Managing Role Membership via T-SQL 

In the example on the slide, you can see the use of the ALTER ROLE statement. The user James is being 

added to the db_datareader fixed database role. 

The DROP MEMBER clause of the ALTER ROLE statement removes members from roles. 

Question: Can you think of an example of a command that could be executed by a member 

of the db_ddladmin role?


Database Owner 

Key Points 

It was mentioned in the last module that there are two special users: dbo and guest. Guest was described 

in the last module, along with an introduction to dbo. 

dbo 

A dbo user has implied permissions to perform all activities in the database. The "sa" login and any 

member of the sysadmin fixed server role that uses a database are automatically mapped to the dbo user. 

Like other objects in SQL Server, databases have owners. The owner of the database is also mapped to the 

dbo user. 

Note Schema-scoped objects are automatically owned by the owner of the schema, 

regardless of who creates them. Non-schema-scoped objects are automatically owned by 

the database principal that created them. For any principal with db_owner rights, the owner 

would be dbo. 

dbo cannot be deleted and is present in every database. Equivalence to dbo is special in that once SQL 

Server finds that a user is mapped to dbo, no other permission checks are made within the database. This 

means that you cannot later DENY a permission within the database to a user with dbo equivalence.

Demonstration 2A: Managing Roles and Users 















Lesson 3 

Creating User-defined Database Roles 

In the first two lessons in this module, you have seen how to work with to both fixed and user-defined 

server roles and with fixed database roles. Similar to user-defined server roles, SQL Server provides you 

with an option to create user-defined database roles. You should consider user-defined database roles 

rather than fixed database roles in most situations. The appropriate design of user-defined database roles 

is critical when designing a security architecture for your database. 

Objectives 


• Work with user-defined database roles. 

• Apply roles in common scenarios. 

• Define application roles.

Working with User-defined Database Roles 

Key Points 

User-defined database roles are created using the CREATE ROLE statement. 


In the example shown on the slide, a new role called MarketingReaders is being created. Note that like 

other objects in SQL Server, roles have owners. Owners of roles have full control of the role. In the 

example on the slide, dbo is being assigned as the owner of the MarketingReaders role. 

Roles and Permissions 

Once user-defined database roles are created, they are assigned permissions in the same way that 

permissions are assigned to database users. 

In the example shown on the slide, SELECT permission is being granted on the Marketing schema to 

members of the MarketingReaders role. From that point on, any users that are added to the 

MarketingReaders role will have permission to SELECT any object that is contained within the Marketing 

schema. (The assignment of permissions on objects including schemas is covered in the next module).


Applying Roles in Common Scenarios 

Key Points 

It is important to apply a prescriptive process when applying roles in typical business applications. 

1. You should start by defining any administrative roles at the server or database level and determining 

an appropriate dbo user. There should be few users who are equivalent to dbo. 

2. You should consider the types of access that each user needs. This may involve considering how the 

requirements overlap with their Windows group membership. Where a number of users (including 

group users) need common permissions, define the permission groups as roles. 

3. If all users need a set of permissions, consider the use of the public role within the database. For 

example, formatting functions would be good examples of code that any user could potentially be 

permitted to execute. 

4. For remaining permission groups, create appropriate roles and assign the permissions to those roles. 

5. Add the users that need the groups of permissions to the roles that provide those permissions. 

Note that unlike Windows domain groups that are typically named after the users that are members of 

them (such as Salespeople), roles should be named based on the permissions that they provide. They are 

more like Windows local groups in this regard.

Testing for Role Membership in T-SQL Code 


While you may decide to allow members of a role to execute T-SQL code (such as a stored procedure) or 

not, it is also possible to place limits within the code module. 

For example, you may decide that BankManagers and BankTellers can both transfer funds but BankTellers 

might have a lower limit on the transfer amounts. 

The IS_SRVROLEMEMBER function tests for server role membership, and the IS_MEMBER function tests for 

database role membership. IS_MEMBER can also test for Windows group membership. 

In the code fragment shown in the slide, an operation is being rolled back if the user is not a member of 

the BankManagers group.


Demonstration 3A: Working with User-defined Database Roles 








• From the View menu, click Solution Explorer. Open and execute the script files 00 – Setup.sql, 

11 – Demonstration 1A.sql , and 21 – Demonstration 2A.sql from within Solution Explorer. 


3. Follow the instructions contained within the comments of the script file to execute each T-SQL batch 

contained in the file.

Defining Application Roles 

Key Points 


Application roles are used to enable permissions for users only when they are running particular 

applications. 

For example, imagine that you might want a user to be able to update rows in a table while using an 

application. You might not, however, want the same user to be able to open the table in SSMS and edit 

the rows, or to connect to the table from Microsoft Excel. 

Application Roles 

Application roles are one solution to this scenario. Application roles contain no members. They are a 

special type of role that is assigned permissions. 

A user will typically connect to an application using a low-privilege account. The application then calls the 

sp_setapprole system stored procedure to "enter" the application role. At that point, the user permissions 

for the existing connection are replaced by those from the application role. 

Note The permissions of the application role are not added to the permissions of the user. 

The permissions of the application role replace the permissions of the user. 

Reverting from an Application Role 

In versions of SQL Server prior to SQL Server 2005, there was no way to revert to the original security 

context. From SQL Server 2005 onwards, the sp_setapprole system stored procedure creates a cookie. The 

application can store the cookie and later pass the cookie back to the sp_unsetapprole system stored 

procedure, to revert to the original security context.


Password and Encryption 

To stop other applications and users from entering the application role, each application role is assigned a 

password. The application must provide the password when calling sp_setapprole. 

To avoid exposure to network packet sniffing an option is provided to send the password in an encrypted 

form, to avoid it being visible in network traces. Be cautious about depending upon this behavior entirely 

as the encryption method used is not particularly strong.

Demonstration 3B: Working with Application Roles 


1. If Demonstration 1A, 2A or 3A was not performed: 







• From the View menu, click Solution Explorer. Open and execute the script files 00 – Setup.sql, 

11 – Demonstration 1A.sql , 21 – Demonstration 2A.sql, and 31 – Demonstration 3A.sql 






Lab 10: Assigning Server and Database Roles 

Lab Setup 













Lab Scenario 

You have created the SQL Server logins and Database users. You now need to assign the logins and users 

to the required roles based upon the security requirements for the MarketDev database. You should 

assign the minimum level of access that will allow each user to perform their job. This will require a 

combination of server, fixed database, and user defined database roles. 

Do not be concerned with object and schema permissions as these will be assigned in Module 11 but you 

do need to consider the role requirements that will be required at that time. 

Note The changes you make will later be migrated to the production environment. You 

should use T-SQL commands to implement the required changes.






Jeff.Hay X 


Terry.Adams X 


Mike.Ray X 



Darcy.Jayne X 

Naoki.Sato X 



Wendy.Kahn X 


Madeleine.Kelly X



• The following Windows group logins and database users have been created: 

• AdventureWorks\ITSupport 

• AdventureWorks\SalesPeople 

• AdventureWorks\CreditManagement 

• AdventureWorks\HumanResources 

• AdventureWorks\CorporateManagers 

• The following Windows logins and database users have been created: 

• AdventureWorks\Jeff.Hay 

• AdventureWorks\April.Reagan 

• AdventureWorks\Darren.Parker 

• The following SQL logins have been created: 

• PromoteApp 

• DBMonitorApp 









DirectMarketing.Competitor table. 









10. The Sales Manager should be able to read and update the Marketing.SalesTerritory table.





procedure. 


schema. 

Exercise 1: Assign Server Roles 

Scenario 

You need to implement any required server roles that are needed to support the supplied security 

requirements. 



2. Assign any required server roles. 



Task 2: Assign any required server roles 

• Assign any server roles that are required to support the security requirements for the MarketDev 

database. 

Results: After this exercise, you should have assigned any required server roles. 

Exercise 2: Assign Fixed Database Roles 

Scenario 

You have been provided with a set of requirements detailing the access that each login needs to the 

MarketDev database. Some of these requirements might be met by fixed database roles but it is 

important to not provide permissions that are not specifically required. If you consider there is a need for 

user-defined database roles these will be created in the next exercise. 



2. Assign any required fixed database roles. 



Task 2: Assign any required fixed database roles 

• Assign any fixed database roles that are required to support the security requirements for the 


Results: After this exercise, you have assigned fixed database roles as required.


Exercise 3: Create and Assign User-defined Database Roles 

Scenario 

You have been provided with a set of requirements detailing the access that each login needs to the 

MarketDev database. In Exercise 2, you assigned fixed database role membership. Other requirements 

might be best supported by user-defined database roles. In this exercise you will create and assign 

required user-defined database roles. 



2. Create and assign any required user-defined database roles. 



Task 2: Create and assign any required user-defined database roles 

• Create and assign any user-defined database roles that are required to support the security 

requirements for the MarketDev database. 

Results: After this exercise, you have created and assigned user-defined database 

roles as required. 

Challenge Exercise 4: Check Role Assignments (Only if time permits) 

Scenario 

You have created logins and database users, assigned server and database roles, and created and assigned 

user-defined database roles. It is important to check that the role assignments are operating as expected. 

In this exercise you will use the sys.login_token and sys.user_token system views to check the available 

tokens for Darren Parker. 


1. Check the role assignments for Darren Parker. 

Task 1: Check the role assignments for Darren Parker 

• Using the EXECUTE AS statement, change your security context to the login 

AdventureWorks\Darren.Parker. 

• Query the sys.login_token and sys.user_token system functions to check the available tokens for 

Darren Parker. 

• Change your security context back using the REVERT command. 

Results: After this exercise, you should have tested the role assignments for 

Darren Parker.



1. Is it possible to create new database roles in SQL Server 2012? 


2. Which function allows you to determine in T-SQL code whether or not a user is a member of a 

Windows group? 


Avoid granting more permissions than are necessary. It is very common to see SQL Server systems where 

excessive permissions have been granted. Often the installers for applications will assume the need for 

much higher level permissions than should be necessary. Users should push back on vendors who do this. 

Even better, make appropriate security and permissions configuration a criterion for vendors to meet.

10-32 Assigning Server and Database Roles

Module 11 

Authorizing Users to Access Resources 

Contents: 

Lesson 1: Authorizing User Access to Objects 11-3 

Lesson 2: Authorizing Users to Execute Code 11-12 

Lesson 3: Configuring Permissions at the Schema Level 11-21 

Lab 11: Authorizing Users to Access Resources 11-28 

11-1

11-2 Authorizing Users to Access Resources 


In the previous two modules, you have seen how Microsoft® SQL Server® security is organized and how 

sets of permissions can be assigned at the server and database level via fixed server roles, user-defined 

server roles, fixed database roles, user-defined database roles, and application roles. 

The final step in authorizing users to access SQL Server resources is the authorization of users and roles to 

access server and database objects. In this module, you will see how these object permissions are 

managed. As well as access permissions on database objects, SQL Server provides the ability to determine 

which users are allowed to execute code, such as stored procedures and functions. 

In many cases, these permissions and the permissions on the database objects are best configured at the 

schema level rather than at the level of the individual object. Schema-based permission grants can 

simplify your security architecture. You will explore the granting of permissions at the schema level in the 

final lesson in this module. 

Objectives 


• Authorize user access to objects. 

• Authorize users to execute code. 

• Configure permissions at the schema level.

Lesson 1 

Authorizing User Access to Objects 


Before moving on to managing permissions on code, you need to consider how permissions are managed 

on database objects. SQL Server has a fine-grained security model that allows you to grant the minimum 

permissions to users that will allow them to do their work. In particular, permissions can be granted at the 

column-level, not just at the table and view level. You will also see how you can delegate the work of 

granting permissions to other users. 

Objectives 


• Explain the role of principals. 

• Explain the role of securables. 

• Use the GRANT, REVOKE, and DENY commands. 

• Secure tables and views. 

• Implement column-level security. 

• Delegate the ability to assign permissions by using WITH GRANT OPTION.


What Are Principals? 

Key Points 

In the previous two modules, you have seen a number of security principals. 

Principals are entities that can request and can be granted access to SQL Server resources. Like other 

components of the SQL Server authorization model, principals can be arranged in a hierarchy. This slide 

summarizes the principals that have been discussed and places them into their appropriate locations 

within the hierarchy. 

At the Windows® level, principals include users and groups. These users and groups can be domainbased 

if the server is part of a Windows domain. Local accounts can be used from servers, whether the 

server is a member of a domain or not. 

At the SQL Server level, logins can be created for users that are either not Windows users or for users that 

are part of non-trusted Windows environments, such as users in other Windows domains where no trust 

relationship is in place with the domain containing the SQL Server system. Also at the SQL Server level, 

fixed and user-defined server roles are a form of principal that contains other principals. 

At the database level, you have seen database users, fixed and user-defined database roles and 

application roles. 

Every principal has two numeric IDs associated with it: a principal ID and a security identifier (SID).

What Are Securables? 

Key Points 


Securables are the resources to which the SQL Server Database Engine authorization system regulates 

access. Some securables can be contained within others, creating nested hierarchies called scopes that can 

themselves be secured. The securable scopes are server, database, and schema. 

It is important to understand the different securable scopes in SQL Server to plan your security model. 

Question: Can you suggest a reason why a Login is a securable? What types of permissions 

would be needed on a Login?


GRANT, REVOKE, DENY 

Key Points 

Permissions are managed via the GRANT, DENY, and REVOKE T-SQL commands. Most permissions (but 

not all permissions) can also be managed via the GUI in SSMS. 

GRANT and REVOKE 

A user that has not been granted a permission is unable to perform the action related to the permission. 

For example, users have no permission to SELECT data from tables if they have not been granted 

permission at some level. Some other database engines consider this an implicit form of denial. 

The GRANT command is used to assign permissions to database users. The REVOKE command is used to 

remove those same permissions. 

DENY 

ANSI SQL does not provide a DENY command. If a user does not have permission to perform an action, 

they cannot perform the action. 

What is different about Windows-based systems is group membership. ANSI SQL has no concept of 

groups. In SQL Server, a Windows user can receive permissions directly but can also receive permissions 

through membership in Windows groups or receive permissions through membership in roles. 

The DENY command allows you to deny a permission to a user that has been granted permission by 

membership in a group or role that has permission. This is very similar to how deny permissions work in 

Windows. For a Windows example, consider that you could decide that all members of the Salespeople 

group can access a Color printer, except Holly (who is a member of Salespeople) because she causes 

problems with it. You grant access to the Salespeople group then deny access to Holly.

SQL Server and DENY 


SQL Server works this same way. You could grant SELECT permission on a table to every Salesperson but 

deny Holly access to that table. 

As with Windows, you should use DENY sparingly. A need to DENY many permissions tends to be 

considered a "code-smell" that indicates a potential problem with your security design. 

What does tend to confuse new users is that the REVOKE command is also used to remove a DENY, not 

just to remove a GRANT. This means that it could cause a user to have access that they did not have 

before the REVOKE command was issued. For example, if you revoke the DENY permission from Holly, she 

would then be able to access the table. 

Question: If a user cannot perform an action without permission, why is there any need to 

DENY a permission?


Securing Tables and Views 

Key Points 

The permissions to access data that apply to tables and views are SELECT, INSERT, UPDATE, DELETE, and 

REFERENCES. 

In the example shown on the slide, SELECT permission on the Marketing.Salesperson object (which is likely 

to be a table or view) is being granted to the HRApp user within the MarketDev database. 

Optional Components of GRANT 

Note that two forms of the command are shown. While the full terminology involves OBJECT:: as a 

prefix, this prefix is optional. In the second example, the same GRANT is shown without the OBJECT:: 

prefix. 

It is not necessary to specify the schema for the table or view but doing so is highly recommended. If the 

schema name is not specified, the default schema for the user that is granting the permission is used. If 

the object is not found in the user's default schema, the dbo schema is used instead. 

REFERENCES 

While the meaning of the SELECT, INSERT, UPDATE, and DELETE permissions will likely be obvious to you, 

the meaning and purpose of the REFERENCES permission might not be. The REFERENCES permission is 

necessary before a foreign key relationship can specify the object as a target, and is only required if no 

other permissions exist on the object. 

Question: Why would there be a need for a permission to refer a table in a foreign key 

reference?

Column-level Security 

Key Points 


While they are not implemented as often as table or view level permissions, column-level permissions can 

also be assigned. This provides an even finer grain of security control than is provided by controlling 

access to tables and views. 

You do not need to execute separate GRANT statements for every column that you wish to assign 

permissions on. Where a set of columns needs to be controlled in the same way, a list of columns can be 

provided in a single GRANT statement. In the first example shown on the slide, SELECT permission on the 

Marketing.Salesperson table is being granted to James but access to the entire table is not being granted. 

Only permission to the SalespersonID and EmailAlias columns is permitted. 

Table-level DENY and Column-level GRANT 

There is an anomaly in the SQL Server security model that you need to be aware of. 

A table-level DENY does not take precedence over a column-level GRANT. This is acknowledged as an 

inconsistency but needed to be preserved for backward compatibility. There is a plan to remove this 

inconsistency in the future. Do not depend upon it in new development work. 

This anomaly is demonstrated in the second example on the slide. Holly is denied permission to SELECT 

from the Salesperson table but is then granted permission to SELECT specific columns in the table. The 

result (probably an unexpected result) is that Holly would still be permitted to SELECT from those columns 

in the table.


WITH GRANT OPTION 

Key Points 

When a principal is granted a permission, it is also possible to grant the principal the right to re-grant the 

permission to other principals. This further right is assigned by use of the WITH GRANT OPTION clause. 

This mechanism allows you to delegate responsibility for managing permissions but needs to be used with 

caution. In general, WITH GRANT OPTION should be avoided. 

In the first example on the slide, James is granted permission to update the Marketing.Salesperson table. 

In addition, James is granted the right to grant this same permission to other database users. 

CASCADE 

The challenge of the WITH GRANT OPTION clause comes when you need to REVOKE or DENY the 

permission that was granted to James using WITH GRANT OPTION. You do not know which other users 

James has already granted the permission to. 

When revoking or denying a permission that has been granted, the CASCADE option revokes or denies 

the permissions that James had granted as well.

Demonstration 1A: Authorizing User Access to Objects 













Lesson 2 

Authorizing Users to Execute Code 

In addition to providing you with control over who accesses data in your database or the objects in your 

server, SQL Server allows you to control which users can execute your code. Appropriate security control 

of code execution is an important aspect of your security architecture. 

In this lesson, you will see how to manage the security of stored procedures and functions. You will also 

learn how to manage security for code that lives in .NET managed code assemblies that are used with SQL 

CLR integration. Finally, you will see how ownership chains affect the security relationship between code 

and database objects. 

Objectives 


• Secure stored procedures. 

• Secure user-defined functions. 

• Secure managed code. 

• Manage ownership chains.

Securing Stored Procedures 

Key Points 


By default, users cannot execute stored procedures that you (or any user) create. Users need EXECUTE 

permission before they can execute a stored procedure. They may also need permissions to access the 

objects that the stored procedure uses. You will see more about this issue later in the lesson. 

In the example shown on the slide, the database user Mod11User is being granted the permission to 

execute the stored procedure Reports.GetProductColors. 

Managing Stored Procedures 

Two other permissions are related to the management of stored procedures: 

• The ALTER permission allows a user to change the definition of a stored procedure. 

• The VIEW DEFINITION permission was added in SQL Server 2005. In earlier versions, a user needed 

ALTER permission on a stored procedure before they could view its definition. This represented an 

unnecessary permission grant for users involved in documenting systems. The VIEW DEFINITION 

permission was introduced to remove the need for such a high level permission when only 

documentation access was needed. 

Note You cannot use SSMS to grant permissions on system stored procedures. SSMS can 

be used to grant permissions on other stored procedures.


Securing User-defined Functions 

Key Points 

User-defined functions (UDFs) also require permissions before they can be used. 

• Scalar UDFs return a single value. Users accessing these functions require EXECUTE permission on the 

UDF. 

• Table-valued UDFs (which are TVFs) return a table of results rather than a single value. Accessing a 

TVF requires SELECT permission rather than EXECUTE permission, similar to the permissions on a 

table. 

While it is uncommon to directly update a table-valued function, it is possible to assign INSERT, UPDATE, 

and DELETE permissions on one form of TVF known as an inline TVF, as this particular form of TVF can be 

updated in some cases. 

REFERENCES 

REFERENCES permission is required for: 

• Functions that are used in CHECK constraints. 

• To calculate values for DEFAULT constraints. 

• To calculate values for computed columns.

public Role and Functions 


Functions often provide very basic capabilities within systems and with low risk. Because of this, it is fairly 

common practice to grant permissions on basic functions that are contained in a database to the public 

role of the database. This allows any user within the database to use those functions without the need for 

further permission grants. 

Note While this is common for basic functions, this is rarely done (or even appropriate) for 

stored procedures.


Securing Managed Code 

Key Points 

Managed code is .NET code that is provided in assemblies. While assemblies are contained within DLL or 

EXE files, only assemblies contained within DLL files can be loaded into SQL Server via SQL Server CLR 

integration. 

After an assembly is catalogued, procedures, functions, and other managed code objects that are 

contained within the assembly are also catalogued. These objects then appear as standard objects within 

SQL Server and the standard T-SQL object permissions also apply. For example, a user requires EXECUTE 

permission on a stored procedure, whether it is written in managed code or in T-SQL. 

Permission Sets 

No matter what .NET code is included in an assembly, the actions it is allowed to take are determined by 

the permission set it is catalogued under. 

The SAFE permission set strictly limits the actions that the assembly can perform. It is the default 

permission set. 

The EXTERNAL_ACCESS permission set is needed to access local and network resources, environment 

variables, and the registry. EXTERNAL_ACCESS is even necessary for accessing the same SQL Server 

instance if a connection is made through a network interface. This permission set is not necessary for 

direct internal connections from the managed code to SQL Server, as a separate direct access path (called 

a context connection) is provided for access to the local instance, without using a network interface. 

The UNSAFE permission set relaxes many standard controls over code and should be avoided.

Recommendations 


In general, SQL Server DBAs should find the use of SAFE assemblies to be acceptable; they should require 

some discussion before EXTERNAL_ACCESS assemblies are used; and they should need particularly solid 

justifications (which should be rare) for any UNSAFE assemblies. UNSAFE is the permission set with the 

most capabilities. 

Configuration 

The EXTERNAL_ACCESS and UNSAFE permission sets also require additional setup. You cannot specify the 

need for an EXTERNAL_ACCESS permission set when executing the CREATE ASSEMBLY statement. Either 

the database needs to be flagged as TRUSTWORTHY (which is easy but not recommended) or an 

asymmetric key needs to be created from the assembly file in the master database, a login created that 

maps to the key and the login granted EXTERNAL ACCESS ASSEMBLY permission on the assembly. 

Note This last option is clearly an advanced topic that is beyond the scope of the course 

and is only mentioned for completeness. 

Question: Which permission set should be rarely allowed?


Managing Ownership Chains 

Key Points 

All database objects have owners. Schema-scoped objects are owned by the schema owner and the 

principal_id (owner) property for new objects is NULL by default. An object with a NULL principal_id 

inherits its ownership from the schema it is contained in. The best practice is to have all objects owned by 

the schema object owner. 

When an object such as a stored procedure references another object, an ownership chain is established. 

An unbroken ownership chain exists when each object in the chain has the same owner. When an 

unbroken ownership chain exists, access is permitted to the underlying objects when access is permitted 

to the top level objects. 

Ever since SQL Server 2005 introduced the concept of schemas, it has been widely misconstrued that SQL 

Server objects no longer have owners. This is not true. Objects still have owners. 

Having the same owner for all objects in a schema (which itself also has an owner) of a database keeps 

permission management easier but it is important to understand that ownership chain problems can still 

occur even though they are much less common now.

Slide Example 


Ownership chaining applies to stored procedures, views, and functions. The slide shows an example of 

how ownership chaining applies to views or stored procedures. 

1. John has no permissions on the table owned by Nupur. 

2. Nupur creates a view that accesses the table and grants John permission to access the view. Access is 

granted as Nupur is the owner of both the top level object and of the underlying object (that is her 

table). 

3. Nupur than creates a view that accesses a table that is owned by Tim. Even if Nupur has permission to 

access the table, and grants John permission to use the view, John will be denied access. This is 

because of the broken chain of ownership from the top level object to the underlying object. 

4. However, if John is given permissions directly on the underlying table owned by Tim, he can then 

access the view that Nupur created to access that table. 

The problem with step #4 is that one of the main reasons for creating views or stored procedures is to 

prevent the need for users to have permissions on the underlying objects.


Demonstration 2A: Authorizing Users to Execute Code 












Lesson 3 

Configuring Permissions at the Schema Level 


SQL Server 2005 introduced a change to how schemas are used. Since that version schemas are used as 

containers for objects such as tables, views, and stored procedures. Schemas can be particularly helpful in 

providing a level of organization and structure when large numbers of objects are present in a database. 

Security permissions can also be assigned at the schema level rather than individually on the objects 

contained within the schemas. Doing this can greatly simplify the design of system security requirements. 

Objectives 


• Describe user-schema separation. 

• Describe the role of object name resolution. 

• Grant permissions at the schema level.


Overview of User-schema Separation 

Key Points 

Schemas are used to contain objects and to provide a security boundary for the assignment of 

permissions. 

Schemas 

In SQL Server, schemas are essentially used as containers for objects, somewhat like a folder is used to 

hold files at the operating system level. Since their change of behavior in SQL Server 2005, schemas can 

be used to contain objects such as tables, stored procedures, functions, types, views, etc. Schemas are 

created with the CREATE SCHEMA statement and schemas form a part of the multi-part naming 

convention for objects. In SQL Server, an object is formally referred to by: 

Server.Database.Schema.Object 

Security Boundary 

Schemas can be used to simplify the assignment of permissions. An example of applying permissions at 

the schema level would be to assign the EXECUTE permission on a schema to a user. The user could then 

execute all stored procedures within the schema. This simplifies the granting of permissions as there is no 

need to set up individual permissions on each stored procedure. 

Upgrading Older Applications 

If you are upgrading applications from SQL Server 2000 and earlier versions, it is important to understand 

that the naming convention changed when schemas were introduced. Previously, names were of the form: 

Server.Database.Owner.Object


Objects still have owners but the owner's name does not form a part of the multi-part naming convention 

from SQL Server 2005 onwards. When upgrading databases from earlier versions, SQL Server will 

automatically create a schema with the same name as existing object owners, so that applications that use 

multi-part names will continue to work. 

Each user can be assigned a default schema that is used when a user refers to an object without specifying 

a schema name. 

Built-in Schemas 

dbo and guest have been discussed in the last module. dbo has an associated schema. The sys and 

INFORMATION_SCHEMA schemas are reserved for system objects. You cannot create objects in the sys 

and INFORMATION_SCHEMA schemas and you cannot drop those schemas.


Object Name Resolution 

Key Points 

It is important to use at least two-part names when referring to objects in SQL Server code such as stored 

procedures, functions, and views. 

Object Name Resolution 

When object names are referred to in the code, SQL Server must determine which underlying objects are 

being referred to. For example, consider the following statement: 

SELECT ProductID, Name, Size FROM Product; 

More than one Product table could exist in separate schemas with the database. When single part names 

are used, SQL Server must then determine which Product table is being referred to. 

Most users have default schemas assigned but not all users are assigned a default schema. Default 

schemas are not assigned to users based on certificates but they do apply to users created from standard 

Windows and SQL Server logins. SQL Server 2012 introduced the ability to assign a default schema to a 

Windows Group. Users without default schemas assigned to them have the dbo schema as their default 

schema. 

Note Users created from certificates is an advanced topic that is out of scope for this 

course but mentioned for completeness.

Locating Objects 


When locating an object, SQL Server will first check the user's default schema. If the object is not found, 

SQL Server will then check the dbo schema to try to locate the object. 

It is important to include schema names when referring to objects instead of depending upon schema 

name resolution, such as in this modified version of the previous statement: 

SELECT ProductID, Name, Size FROM Production.Product; 

Apart from rare situations, using multi-part names leads to more reliable code that does not depend upon 

default schema settings.


Granting Permissions at the Schema Level 

Key Points 

Instead of assigning individual permissions on tables, views, and stored procedures, permissions can be 

granted at the schema level. 

Slide Example 

In the first example on the slide, EXECUTE permission on the Marketing schema is granted to Mod11User. 

This means that Mod11User could then execute all stored procedures and scalar functions within the 

schema. 

In the second example on the slide, SELECT permission on the DirectMarketing schema is granted to 

Mod11User. This means that Mod11User could then select from all tables, views, and table-valued 

functions in the schema. 

Question: Why would granting permissions at the schema level be easier to manage?


Demonstration 3A: Configuring Permissions at the Schema Level 








• From the View menu, click Solution Explorer. Open and execute the 00 – Setup.sql and 

21 – Demonstration 2A.sql script files from within Solution Explorer. 



Question: The user has EXECUTE at the schema level and DENY at the procedure level. 

Should execution be permitted?


Lab 11: Authorizing Users to Access Resources 

Lab Setup 













Lab Scenario 

You have created the SQL Server logins and Database users and assigned them to appropriate roles. You 

now need to grant permissions to the database users and roles so that users can access the resources they 

need within the MarketDev database, based on the supplied security requirements.






Jeff.Hay X 


Terry.Adams X 


Mike.Ray X 



Darcy.Jayne X 

Naoki.Sato X 



Wendy.Kahn X 


Madeleine.Kelly X



• The following Windows group logins and database users have been created: 

• AdventureWorks\ITSupport 

• AdventureWorks\SalesPeople 

• AdventureWorks\CreditManagement 

• AdventureWorks\HumanResources 

• AdventureWorks\CorporateManagers 

• The following Windows logins and database users have been created: 

• AdventureWorks\Jeff.Hay 

• AdventureWorks\April.Reagan 

• AdventureWorks\Darren.Parker 

• The following SQL logins have been created: 

• PromoteApp 

• DBMonitorApp 

• The following server role assignment has been made: 

• Jeff Hay sysadmin 

• The following fixed database roles member assignments have been made: 

• AdventureWorks\ITSupport db_owner 

• DBMonitorApp db_datareader 

• The following user-defined database roles member assignments have been made: 

• AdventureWorks\SalesPeople SalesTeam 

• AdventureWorks\CreditManagement SalesTeam 

• AdventureWorks\CorporateManagers SalesTeam 

• AdventureWorks\Darren.Parker SalesManagers 









DirectMarketing.Competitor table.










10. The Sales Manager should be able to read and update the Marketing.SalesTerritory table. 




procedure. 


schema. 

Exercise 1: Assign Schema-level Permissions 

Scenario 

You have been supplied with a list of security requirements. Some of these requirements can be met using 

permissions assigned at the schema level. Even though it is easy to grant substantial permissions at the 

schema level, you should be careful to only grant permissions that are required. 


1. Review the security requirements that have been updated from the previous module. 

2. Assign the required permissions. 

Task 1: Review the security requirements that have been updated from the previous 

module 


• Determine the permissions that should be assigned at the schema level. 

Task 2: Assign the required permissions 

• Assign the required permissions at the schema level. 

Results: After this exercise, you should have assigned the required schema-level permissions.


Exercise 2: Assign Object-level Permissions 

Scenario 

You have been supplied with a list of security requirements. Some of these requirements need to be met 

using permissions assigned at the object level. In this exercise you will assign the required level object 

permissions. 


1. Review the security requirements. 

2. Assign the required permissions. 

Task 1: Review the security requirements 


• Determine the permissions that should be assigned at the object level. This would include permissions 

on tables, views, stored procedures, and functions where required. 

Task : Assign the required permissions 

• Assign the required permissions at the object level. 

Results: After this exercise, you should have assigned the required object-level permissions. 

Challenge Exercise 3: Test Permissions (Only if time permits) 

Scenario 

You need to test some of your permission assignments. In particular you need to test that salespeople can 

select rows from the Marketing.CampaignBalance table. However you will also need to test that the work 

experience student April Reagan cannot select rows from that table even though she is a member of the 

SalesPeople group. 


1. Design and execute a test. 

Task 1: Design and execute a test 

• Design and execute a test to show that Darcy Jayne can select rows from the 

Marketing.CampaignBalance table. 

• Design and execute a test to show that April Reagan cannot select rows from the 

Marketing.CampaignBalance table. 

Results: After this exercise, you should have tested the required permissions.




1. What permission needs to be assigned to a function before it can be used in a CHECK constraint? 

2. What permission should be assigned to a schema to allow a user to read the data in all the tables, 

views and table-valued functions? 


1. Always assign the least possible privileges that users need. 

2. Test code as a standard user instead of testing as an administrator. 

3. Use EXECUTE AS and REVERT for quick testing of user permissions.

11-34 Authorizing Users to Access Resources

Module 12 

Auditing SQL Server Environments 

Contents: 

Lesson 1: Options for Auditing Data Access in SQL 12-3 

Lesson 2: Implementing SQL Server Audit 12-12 

Lesson 3: Managing SQL Server Audit 12-26 

Lab 12: Auditing SQL Server Environments 12-31 

12-1

12-2 Auditing SQL Server Environments 


One of the most important aspects of configuring security for Microsoft® SQL Server® systems is 

ensuring that auditing and compliance requirements are met. Organizations may need to meet a variety 

of compliance goals. Choosing the appropriate configuration for SQL Server will often be a key 

component in meeting those goals. 

SQL Server 2008 introduced the SQL Server Audit feature in the Enterprise edition. (Some audit features 

are part of all editions of SQL Server 2012). The audit feature provides that ability to perform types of 

auditing that were not possible in earlier versions of the product. In this module, you will see the available 

options for auditing within SQL Server, see how to implement the SQL Server Audit feature and learn to 

manage that feature. 

Objectives 


• Describe the options for auditing data access in SQL Server. 

• Implement SQL Server Audit. 

• Manage SQL Server Audit.


Lesson 1 

Options for Auditing Data Access in SQL Server 

Prior to SQL Server 2008, a variety of auditing options were available in SQL Server. These options are still 

available in SQL Server 2012 and may form part of your auditing strategy. In general, no one feature 

provides all possible auditing requirements and a combination of features often needs to be used. In this 

lesson, you will learn about the options available. 

Objectives 


• Describe the need for auditing. 

• Use C2 audit mode. 

• Describe the Common Criteria Audit Option. 

• Configure triggers for auditing. 

• Describe the use of SQL trace for auditing.


Discussion: Auditing Data Access 

Key Points 

Question: Why is auditing required? 

Question: What methods have you used for auditing? 

Question: What are the limitations of the methods you have used? 

Question: Which standards that require auditing does your organization need to comply 

with?

Using C2 Audit Mode 

Key Points 


C2 refers to a set of security policies that define how a secure system operates. Certification applies to a 

particular installation, including the hardware, software, and the environment that the system operates in. 

Products do not become C2 certified. Sites become C2 certified. 

C2 Certification 

The Windows NT® operating system (server and workstation) were first listed on the National Security 

Agency (NSA) Evaluated Products List (EPL) in 1995. This means that it was acknowledged that those 

products could be configured in a way that would enable sites using them to become certified. Windows 

systems have a long history of being able to be configured in a compliant manner. 

C2 is one of a series of security ratings, involving A, B, C, and D level secure products. These ratings were 

published by the National Computer Security Center (NCSC) in a document called the Trusted Computer 

System Evaluation Criteria (TCSEC). This document was commonly referred to in the industry as the 

"orange book". 

Note As a curious side-note, the "orange book" was part of the "rainbow series". 

The security policy in C2 is known as Discretionary Access Control. Users of the system: 

• Own objects. 

• Have control over the protection of the objects they own. 

• Are accountable for all their access-related actions. 

By today’s standards, the C2 requirements are relatively easy for sites to attain.


SQL Server and C2 

SQL Server can be configured to meet C2 requirements. A system configuration option ‘c2 audit mode’ 

can be enabled using the sp_configure system stored procedure. While easy to configure, this option is 

now rarely used or even appropriate to use. Enabling the C2 audit option can have a negative 

performance impact on the server through the generation of large volumes of event information. 

Most customers that configure this option do so without realizing what they are enabling and eventually 

(sometimes sooner rather than later) end up running out of disk space. 

For practical purposes, C2 has now been superseded by Common Criteria compliance, which is described 

in the next topic.

Common Criteria Audit Option 

Key Points 


C2 ratings were U.S. based. Common Criteria is an international standard that was ratified by more than 

twenty nations in 1999 and has superseded C2 rating as a requirement in most standards. 

It is also maintained on an ongoing basis by over twenty countries and was adopted by the International 

Standards Organization (ISO) as standard 15408. 

‘common criteria compliance enabled’ Option 

SQL Server provides a server option ‘common criteria compliance enabled’ that can be set using the 

sp_configure system stored procedure. It is available in the Enterprise edition for production use. (It is also 

available in the Developer and Evaluation editions for non-production use). In addition to enabling the 

common criteria compliance enabled option, you also must download and run a script that finishes 

configuring SQL Server to comply with Common Criteria Evaluation Assurance Level 4+ (EAL4+). You can 

download this script from the Microsoft SQL Server Common Criteria Web site. 

When this option is enabled, three changes occur to how SQL Server operates: 

Issue Description 

Residual Information Protection 

(RIP) 

Memory is always overwritten with a known bit pattern before 

being reused 

Ability to view login statistics Auditing of logins is automatically enabled 

Column GRANT does not override 

table DENY 

Changes the behavior of the permission system


The implementation of RIP increases security but will negatively impact on the performance of the system. 

Question: Why is there a need to make a change for GRANT as the column-level overriding 

DENY at the table-level?

Using Triggers for Auditing 

Key Points 


Triggers can play an important role in auditing. Prior to SQL Server 2008, many actions could only be 

audited via triggers. 

SQL Server 2005 SP2 introduced logon triggers. These allowed tracking more details of logons and also 

allowed rolling back logons based on business or administrative logic. 

Triggers are not perfect though: 

• Performance of the system is impacted by triggers. Prior to SQL Server 2005, the inserted and deleted 

virtual tables in triggers were implemented in a similar manner to views over the transaction log. They 

did not offer high performance. From SQL Server 2005 onwards, the internal structure of these 

internal tables changed. They are now based on a row version table that resides in the tempdb 

database. Triggers that use these tables operate much more quickly than in prior versions but there 

can be a significant impact on the performance of the tempdb database that needs to be considered. 

• Triggers can be disabled. This is a significant issue for auditing. 

• Users were requesting SELECT triggers. They did not only want to track data modifications. Many 

users in high security environments wanted to see not only the commands that were executed to 

retrieve data but also the data that was retrieved. 

• Triggers have a nesting limit of thirty-two levels beyond which they do not work. 

• Recursive triggers can be disabled. 

• Only limited ability to control trigger firing order is provided. Auditing would normally need to be the 

last trigger that fires to make sure that it captures all the changes made by other triggers. 

Question: What would you imagine that the term "recursive trigger" might refer to?


Using SQL Trace for Auditing 

Key Points 

Many users have attempted to use SQL Server Profiler for auditing because it allows tracing commands 

that are sent to SQL Server and tracing the errors that are returned. SQL Server Profiler can have a 

significantly negative performance impact when it is run interactively on production systems. 

SQL Trace is a set of system stored procedures that are utilized by SQL Server Profiler. Executing these 

procedures to manage tracing offers a much more lightweight method of tracing, particularly when the 

events are well-filtered. 

SQL Trace can then have a role in auditing. Because it has the ability to capture commands that are sent 

to the server, it can be used to audit those commands. 

Since SQL Server 2005, SQL Trace uses a server-side tracing mechanism that guarantees that no events are 

lost, as long as there is space available on the disk and that no write errors occur. If the disk fills or write 

errors occur, the trace stops. SQL Server continues unless c2 audit mode is also enabled. The possibility of 

missing events needs to be considered when evaluating the use of SQL Trace for auditing purposes.

Demonstration 1A: Using DML Triggers for Auditing 












Question: Can DML triggers be used to audit the reading of data in a table?


Lesson 2 

Implementing SQL Server Audit 

SQL Server 2008 introduced the SQL Server Audit feature. It was based on a new eventing engine called 

Extended Events. In this lesson, you will learn about the core terminology used by Extended Events and 

how SQL Server Audit has been created as a specific package within Extended Events. 

Preparing SQL Server Audit for use requires the configuration of a number of objects. In this lesson, each 

of these objects is introduced, along with details of how they are configured. Finally, you will see the 

dynamic management views (DMVs) and system views that have been introduced to support the SQL 

Server Audit feature. 

Objectives 


• Describe the Extended Events infrastructure. 

• Describe SQL Server Audit. 

• Configure SQL Server Audit. 

• Detail the roles of audit actions and action groups. 

• Define audit targets. 

• Create audits. 

• Create server audit specifications. 

• Create database audit specifications. 

• Use audit-related DMVs and system views.

Introduction to Extended Events 

Key Points 


A wide variety of events occurs within the SQL Server database engine. For example, a user could execute 

a query, the database engine could need to request additional memory, or permissions could be checked. 

SQL Server 2008 introduced a new feature called Extended Events that allows you to define actions that 

should be taken when events occur. As SQL Server executes its internal code, it checks to see if an external 

user has defined an action that should be taken at that point in the code. If an action is defined, an event 

is fired and details of the event are sent to a target location. Targets can be operating system files, 

memory-based ring buffers or Windows event logs. 

Extended Events is considered to be a lightweight eventing engine as it has very little performance impact 

on the database engine that it is monitoring. Extended events can be used for many purposes that SQL 

Trace is currently used for. 

Extended Events are important as SQL Server Audit is based on the extended events infrastructure. The 

eventing engine that is provided by Extended Events is not tied to particular types of events. The engine is 

written in such a way that it can process any type of event. 

Configurations of Extended Events are shipped in .exe or .dll files that are called "packages". Packages are 

the unit of deployment and installation for Extended Events. A package is a container for all objects that 

are part of a particular Extended Events configuration. SQL Server Audit is a special package within 

Extended Events. You cannot change how it is internally configured. You can change other packages.


Extended Events uses specific terminology for describing the objects that it uses: 

Object Description 

Events Points of interest during the execution of code 

Targets Places that the trace details are sent to (such as files) 

Actions Responses that can be made to events (for example, one type of 

action captures execution plans to include in the trace) 

Types Definitions of the objects that Extended Events works with 

Predicates Dynamic filters that are applied to the event capture 

Maps Mapping of values to strings. (An example would be the 

mapping of codes to descriptions)

Introduction to SQL Server Audit 

Key Points 


SQL Server Audit was introduced in SQL Server 2008 to address compliance issues. The Enterprise edition 

of SQL Server 2012 provides full functionality and other editions provide basic functionality and are 

limited to defining server audit specifications. 

SQL Server Audit 

It is important to be aware that SQL Server Audit is the name of the feature and the name of one of the 

objects that are part of the feature. 

An audit is a definition of where the results of the auditing process are sent. This might seem counterintuitive 

at first, given that the name sounds like an action that you perform, not a location for the results 

of the action. An audit is created at the instance level and multiple audits can be created per instance. 

The results of an audit are sent to a target. 

Note The term "target" has the same meaning for SQL Server Audit as it does for 

Extended Events. 

Audit Specifications 

Server and database audit specifications determine the actions to audit. There are predefined sets of 

actions called "action groups". The use of these action groups avoids the need to configure large number 

of individual audit actions.


Configuring SQL Server Audit 

Key Points 

Configuring SQL Server Audit is a multi-step process: 

Step Description 

Creating an audit Determines how the results will be processed. For example, 

when configuring an audit, you will decide what to do if the 

disk space runs out. You will also decide how long SQL 

Server can buffer audit results before writing them to the 

target. 

Defining the target Determines where the output will be sent. 

Creating an audit specification Determines the actions to be audited. These actions can be 

at the server or database level. 

Enabling the audit and audit 

specification 

Is the step where the objects are enabled. (Audits are 

created in a disabled state and audit specifications are 

created in a disabled state by default). 

Read the output events Relates to extracting the output details from the audits. 

Several options exist for reading the output events after they are captured: 

• Windows event/log file viewers allow reading event log details 

• The sys.fn_get_audit_file function returns file-based output as a table that can be queried in T-SQL.

Audit Actions and Action Groups 

Key Points 


Actions are the events that occur that are of interest to the audit. Actions can occur at three levels: server, 

database, and audit. 

Action Groups 

To avoid the need for many individual actions, action groups are provided. This makes setup and 

management of audits easier as it avoids the need to set up large numbers of individual actions for 

auditing. 

Examples of action groups are: 

• BACKUP_RESTORE_GROUP 

• DATABASE_MIRRORING_LOGIN_GROUP 

• DATABASE_OBJECT_ACCESS_GROUP 

• DBCC_GROUP 

• FAILED_LOGIN_GROUP 

• LOGIN_CHANGE_PASSWORD_GROUP 

Note that a state change of any audit is always audited. This cannot be disabled. 

SQL Server 2012 introduced a new group called USER_DEFINED_AUDIT_GROUP. Applications can cause 

audit events to be written to that group by calling the sp_audit_write system stored procedure. 

Question: Why would no option exist for disabling the auditing of audit changes?


Defining Audit Targets 

Key Points 

Audits can be sent to three targets in the current version. 

• Results can be sent to a file. File output provides the highest performance and is the easiest option to 

configure. 

• Results can be sent to the Windows application event log. Avoid sending too much detail to this log 

as network administrators tend to dislike applications that write too much content to any of the event 

logs. 

Note Be cautious about using the Windows application event log as an output target for 

sensitive information as any authenticated user can read the contents of that log. 

• Results can be sent to the Windows security event log. The security event log is a secure output 

option but requires the SQL Server service account to be added to the "Generate Security Audits" 

policy before it can be used. 

Note If it is important for SQL Server administrators to have access to the contents of the 

audit, consider whether the use of the security event log is appropriate. 

Question: Why would many SQL Server DBAs have difficulty working with audit entries in 

the Windows security event log?

Creating Audits 

Key Points 


When you create an audit, you make decisions about how SQL Server will process the results that are sent 

to the audit target. Audits can be created using the GUI in SSMS or via the CREATE SERVER AUDIT 

command in T-SQL. 

Audit Configuration Options 

The name of an audit will often relate to details of what the audit will contain, or the date and time when 

the audit was created or a combination of both. 

After configuring a name, configuring a queue delay is particularly important. The queue delay indicates 

(in milliseconds) how long SQL Server can buffer the audit results before flushing them to the target. 

Note The value chosen for queue delay is a trade-off between security and performance. 

If a server failure occurs, results that are in the buffer and not yet flushed to the target can 

be lost. A value of zero for queue delay will cause synchronous writes as events occur. This 

avoids the chance of losing events on failure but can impact performance significantly. 

For serious production auditing, the option to shut down the server on audit failure should be selected. 

SQL Server 2012 introduced a new option to fail the operation that fired the audit, rather than shutting 

down the entire server instance. 

Note If the shutdown option is chosen, SQL Server may fail to initiate if auditing cannot 

function. In the next lesson, you will see how to deal with this situation.


You need to choose a target for the output of your audit. The available audit targets were discussed in a 

previous topic. 

Note On Windows® XP, the security event log is not available as a destination. 

Note Each audit can be the target of at most one server audit specification and one 

database audit specification. 

Question: Why is it recommended to select the option to shut down server on audit failure?

Creating Server Audit Specifications 

Key Points 


Creating a server audit specification can be performed with the GUI or T-SQL. Server audit specifications 

are created in a disabled state by default. Audit objects, including audit specifications, are usually left 

disabled until all audit objects have been created. 

Server Audit Specification 

A server audit specification details the actions to be audited. You can choose either action groups or 

individual actions and objects. In the example shown in the slide, a server audit specification is being 

created using the CREATE SERVER AUDIT SPECIFICATION statement. The configuration of the same 

specification using the GUI is also shown. 

The name of the specification is FailedLoginSpec and the data collected from the specification will be sent 

to the Audit-20121222-171544 audit. The action group to be audited is the FAILED_LOGIN_GROUP. 

Question: Why would enabling logging of failed logins have potential risks to availability?


Creating Database Audit Specifications 

Key Points 

Creating a database audit specification can also be performed with the GUI or T-SQL. Database audit 

specifications are also created in a disabled state by default. Database audit specifications can only be 

created in Enterprise edition. 

Database Audit Specification 

A server audit specification details the actions to be audited. You can choose either action groups or 

individual actions and objects. 

In the example shown in the slide, a database audit specification is being created using the CREATE 

DATABASE AUDIT SPECIFICATION statement. The configuration of the same specification using the GUI is 

also shown. 

The name of the specification is BackupRestoreSpec and the data collected from the specification will be 

sent to the Audit-20121222-171544 audit. The action group to be audited is the 

BACKUP_RESTORE_GROUP.

Audit-related DMVs and System Views 

Key Points 


SQL Server provides a number of dynamic management views (DMVs) and system views that can help you 

manage SQL Server Audit. 

The following DMVs and system views are available: 

DMV/View Description 

sys.dm_server_audit_status Returns a row for each server audit indicating the 

current state of the audit 

sys.dm_audit_actions Returns a row for every audit action that can be 

reported in the audit log and every action group 

that can be configured as part of an audit 

sys.dm_audit_class_type_map Returns a table that maps the class types to class 

descriptions 

sys.server_audits Contains one row for each SQL Server audit in a 

server instance 

sys.server_file_audits Contains extended information about the file 

audit type in a SQL Server audit 

sys.server_audit_specifications Contains information about the server audit 

specifications in a SQL Server audit


(continued) 

DMV/View Description 

sys.server_audit_specification_details Contains information about the server audit 

specification details (actions) in a SQL Server audit 

Sys.database_audit_specifications Contains information about the database audit 

specifications in a SQL Server audit 

Sys.database_audit_specification_details Contains information about the database audit 

specifications in a SQL Server audit 

A number of the system views will be used in the upcoming demonstrations.

Demonstration 2A: Using SQL Server Audit 













Question: What are the three possible event targets for SQL Server Audit?


Lesson 3 

Managing SQL Server Audit 

It is important to be able to retrieve the results from the audits and to understand a few aspects of 

ongoing management of SQL Server Audit. In particular you will investigate issues related to migrating 

databases between servers and see how to restart servers if SQL Server refuses to start due to an audit 

failure. 

Objectives 


• Retrieve audits. 

• Work with the audit record structure. 

• Identify potential SQL Server audit issues.

Retrieving Audits 

Key Points 


No special configuration is needed to view audits sent to event logs. SSMS provides a log reader for these 

targets. 

Retrieving File Output 

For logs that are sent to a file, SQL Server provides a function that returns the contents of the file-based 

logs as a table that you can query with T-SQL. 

Note The filename that you provide to the FILEPATH parameter when creating a server 

audit is actually the name of a folder. 

The folder that contains the audit logs often contains multiple audit files. The sys.fn_get_audit_file 

function is used to retrieve those files. It takes three parameters: the file_pattern, the initial_file_name, and 

the audit_record_offset. The file_pattern provided can be in one of three formats: 

Format Description 

\* Collects all audit files in the specified 

location 

\LoginsAudit_{GUID} Collect all audit files that have the specified 

name and GUID pair 

\LoginsAudit_{GUID}_00_29384.sqlaudit Collect a specific audit file


Working with the Audit Record Structure 

Key Points 

The audit record structure is detailed in Books Online under the topic "sys.fn_get_audit_file 

(Transact-SQL)". 

Audit records need to be able to be stored in system event logs as well as in files. Because of this 

requirement, the record format is limited in size by the rules related to those event logging systems. 

Character fields will be split into 4000 character chunks and the chunks will be spread across a number of 

entries. 

This means that a single event could generate multiple audit entries. A sequence_no column is provided 

to indicate the order of multiple row entries.

Potential SQL Server Audit Issues 

Key Points 

There are a number of potential issues to consider with SQL Server audit. 


• Each audit is identified by a GUID. When a database is restored or attached on a server, an attempt is 

made to match the GUID in the database with the GUID of the audit on the server. If no match 

occurs, auditing will not work until the situation is corrected by executing the CREATE SERVER AUDIT 

command to set the appropriate GUID. 

• If databases are attached to editions of SQL Server that do not support the same level of audit 

capability, the attach works but the audit is ignored. 

• Mirrored servers introduce a similar issue to mis-matched GUIDs. The mirror partner must have a 

server audit with the same GUID. You can create this by using the CREATE SERVER AUDIT command 

and supplying the GUID value to match the value on the primary server. 

• In general, the performance impact of audit writes must be considered. If disk space fills up, SQL 

Server may not start. If so, you may need to force entry to it via a single user startup and the –f 

startup parameter. 

Question: Why would audits be identified by a GUID as well as a name?


Demonstration 3A: Viewing the Output of a File-based Audit 












Question: Why are there two entries in the audit log?

Lab 12: Auditing SQL Server Environments 

Lab Setup 














Lab Scenario 

You have authorized users to access the Proseware instance. Your Compliance Department has provided 

you with details of the auditing requirements for both the Proseware server instance and for the 

MarketDev database. The auditing requirements include the need to audit the activities against tables in 

the MarketDev database that contain sensitive information. In this lab, you will implement a strategy to 

enable appropriate auditing. 

If you have sufficient time, you need to test the audit strategy and write a query to extract audit records.



Audit Requirements from the Compliance Department 

1. All audit records should be written to the folder C:\Audit\AuditLog. 

2. Audit records should be written as quickly as possible however a tolerance of two seconds of audit 

records is the maximum permitted loss in the event of failure. 

3. The server instance should not continue to operate if auditing is not occurring. 

4. The name of the audit should be Proseware Compliance Audit. 

5. There is no limit to the number of audit files that may be created however each audit file should be 

limited to 1 GB in size. 

6. At the server level, the following items need to be audited: 

• Failed login attempts 

• Changes to the membership of server roles 

• Any changes to server logins (principals) 

• Any changes to passwords 

7. At the MarketDev database level, the following items need to be audited: 

• Changes to the membership of database roles 

• Backups and restores of the database 

• Changes to any permissions within the database 

• Any changes to database users (principals) 

• Any change of database ownership 

• Any updates to the Marketing.CampaignBalance table 

• Any executions of the Marketing.MoveCampaignBalance stored procedure 

Exercise 1: Determine Audit Configuration and Create Audit 

Scenario 

You need to determine the configuration of a server audit, based on the business security requirements. In 

this exercise, you will create the required Server Audit. 



2. Create the server audit. 


• Review the supplied requirements in the supporting documentation for the exercise.

Task 2: Create the server audit 

• Determine the configuration of the required server audit. 

• Create the server audit using SQL Server Management Studio. 

• Enable the server audit. 

Results: After this exercise, you should have created the required server audit. 

Exercise 2: Create Server Audit Specifications 

Scenario 


You need to determine which of the business requirements can be met via server audit specifications. You 

will then determine the required Server Audit Specifications and create them. 



2. Create the server audit specifications. 



Task 2: Create the server audit specifications 

• Determine the required server audit specifications. 

• Create the server audit specifications using SQL Server Management Studio. 

• Enable the server audit specifications. 

Results: After this exercise, you should have created the required server audit specification. 

Exercise 3: Create Database Audit Specifications 

Scenario 

Some of the audit requirements will require database audit specifications to be created. In this exercise, 

you will determine which of the audit requirements could be met by database audit specifications. You 

will then create those database audit specifications. 



2. Create the database audit specifications. 


• Review the requirements.


Task 2: Create the database audit specifications 

• Determine the required database audit specifications. 

• Create any required database audit specifications using SQL Server Management Studio. 

• Enable any database audit specifications that you created. 

Results: After this exercise, you should have created the required database audit specifications. 

Challenge Exercise 4: Test Audit Functionality (Only if time permits) 

Scenario 

You need to check that the auditing you have set up is functioning as expected. You will execute a test 

workload script and then review the captured audit using both the GUI is SSMS and T-SQL. 


1. Execute the workload script. 

2. Review the captured audit details. 

Task 1: Execute the workload script 

• From Solution Explorer open and execute the workload script 81 – Lab Exercise 4a.sql. 

Task 2: Review the captured audit details 

• Review the captured audit details using the View Audit Logs option in SQL Server Management 

Studio. (This is a right-click option from the Server Audit). 

• Write a query to retrieve the audit log details using T-SQL. 

Results: After this exercise, you should have checked that the auditing works as expected.



1. What are the three targets for SQL Server audits? 


2. When common criteria compliance is enabled in SQL Server, what changes about column-level 

permissions? 

3. You may wish to audit actions by a DBA. How would you know if the DBA stopped the audit while 

performing covert actions? 


1. Choose the option to shut down SQL Server on audit failure. There is usually no point in setting up 

auditing and then having situations where events can occur but are not audited. This is particularly 

important in higher-security environments. 

2. Make sure that file audits are placed on drives with large amounts of free disk space and make sure 

that the available disk space is monitored on a regular basis.

12-36 Auditing SQL Server Environments

Module 13 

Automating SQL Server 2012 Management 

Contents: 

Lesson 1: Automating SQL Server Management 13-3 

Lesson 2: Working with SQL Server Agent 13-11 

Lesson 3: Managing SQL Server Agent Jobs 13-19 

Lab 13: Automating SQL Server Management 13-26 

13-1

13-2 Automating SQL Server 2012 Management 


The tools provided with Microsoft® SQL Server® make administration easy when compared with other 

database engines. Even when tasks are easy to perform though, it is common to need to repeat a task 

many times. Efficient database administrators learn to automate repetitive tasks. Automating tasks can 

help avoid situations where an administrator forgets to execute a task at the required time. Perhaps more 

important though, is that the automation of tasks helps to ensure that tasks are performed consistently, 

each time they are executed. 

SQL Server Agent is the service that is provided in all editions of SQL Server 2012 (except SQL Server 

Express Edition) that is responsible for the automation of tasks. A set of tasks that need to be performed is 

referred to as a SQL Server Agent job. It is important to learn how to create and manage these jobs. 

Objectives 


• Automate SQL Server Management. 

• Work with SQL Server Agent. 

• Manage SQL Server Agent jobs.

Lesson 1 

Automating SQL Server Management 


There are many benefits that can be gained from the automation of SQL Server management. Most of the 

benefits center on the reliable, consistent execution of routine management tasks. SQL Server is a flexible 

platform that provides a number of ways to automate management but the most important tool for 

automation of management is the SQL Server Agent. All database administrators that work with the SQL 

Server need to be very familiar with the configuration and ongoing management of SQL Server Agent. 

Objectives 


• Explain the benefits of automating SQL Server management. 

• Describe the available options for automating SQL Server management and the framework that is 

provided with SQL Server Agent. 

• Describe SQL Server Agent.


Benefits of Automating SQL Server Management 

Key Points 

All efficient database administrators automate their routine administrative tasks. Some of the benefits that 

can be gained from the automation of SQL Server management are as follows: 

Reduced Administrative Load 

Unfortunately, some administrators that work with SQL Server, Windows®, and other tools, see their roles 

in terms of a constant stream of repetitive administrative tasks. For example, a Windows administrator at a 

University department might receive regular requests to create a large number of user accounts. The 

administrator might be happy to create each of these accounts one by one, using the standard tooling. A 

more efficient administrator would learn to write a script to create users and execute the script instead of 

manually creating the users. 

The same sort of situation occurs with routine tasks in SQL Server. While these tasks can be performed 

individually or manually, efficient database administrators do not do this. They automate all their routine 

and repetitive tasks. Automation removes the repetitive workload from the administrators and allows the 

administrators to manage larger numbers of systems or to perform higher-value tasks for the 

organization. 

Reliable Execution of Routine Tasks 

When routine tasks are performed manually, there is always a chance that a vital task might be 

overlooked. For example, a database administrator could forget to perform database backups. 

Automation allows administrators to focus on exceptions that occur during the routine tasks rather than 

focusing on the execution of the tasks.

Consistent Execution of Routine Tasks 


Another problem that can occur when routine tasks are performed manually is that the tasks may not be 

performed the same way each time. Imagine a situation where a database administrator is required to 

archive some data from a set of production tables, into a set of history tables every Monday morning. The 

new tables need to have the same name as the original tables with a suffix that includes the current date. 

While the administrator might remember to perform this task every Monday morning, what is the 

likelihood that one of the following errors would occur? 

• Copy the wrong tables 

• Copy only some of the tables 

• Forget what the correct date is when creating the suffix 

• Format the date in the suffix incorrectly 

• Copy data into the wrong archive table 

Anyone that has been involved in ongoing administration of systems would tell you that these and other 

problems would occur from time to time, even when the tasks are executed by experienced and reliable 

administrators. Automating routine tasks can assist greatly in making sure that they are performed 

consistently each time they are executed. 

Proactive Management 

Once routine tasks are automated, it is easy for a situation where the routine execution of the tasks fails 

but no administrator ever notices that the task is failing. For example, there are many tragic tales on the 

SQL Server community support forums from administrators that automated the backup of their databases, 

and where they did not notice that the backups had been failing for a long time, until they needed one of 

the backups. 

As well as automating your routine tasks, you need to ensure that you create notifications that tell you 

when the tasks fail, even if you cannot imagine a situation where the tasks could fail. For example, you 

may have created a backup strategy that creates database backups in a given folder. The job may run 

reliably for years until another administrator inadvertently deletes or renames the target folder. You need 

to know as soon as this problem occurs so that you can rectify the situation. 

A more proactive administrator will try to detect potential problems before they occur. For example, 

rather than receiving a notification that a job failed because a disk was full, an administrator might 

schedule regular checks of available disk space and make sure that a notification is received when 

available free space is starting to get too low. SQL Server provides alerts on system and performance 

conditions. 

Question: What tasks need to be automated on the systems in your organization?


Available Options for Automating SQL Server Management 

Key Points 

The primary method for automation of management, administrative, and other routine tasks when 

working with SQL Server 2012 is to use SQL Server Agent. 

Framework for SQL Server Agent 

The management framework that is supplied by SQL Server Agent is based on two core objects: 

• Jobs that are used to automate tasks 

• Alerts that are used to respond to events 

Jobs can be used to schedule a wide variety of task types, including tasks that are required for the 

implementation of other SQL Server features. For example, the Replication, Change Data Capture (CDC), 

Data Collection, and Policy Based Management (PBM) features of SQL Server create SQL Server Agent 

jobs. (Data Collection will be discussed in Module 18). 

Note Replication, CDC, and PBM are advanced topics that are out of scope for this course. 

The alerting system that is provided by SQL Server Agent is capable of responding to a wide variety of 

alert types, including SQL Server Error Messages, SQL Server Performance Counter Events, and Windows 

Management Instrumentation (WMI) Alerts. 

In response to an alert, an action can be configured, such as the execution of a SQL Server Agent job or 

sending a notification to an administrator. In SQL Server Agent, administrators that can be notified are 

called operators. Operators are commonly notified by the use of SMTP based email. (Alerts are discussed 

in Module 15).


Note that there are other SQL Server features that can be used to automate complex monitoring 

requirements. The Extended Events feature is an example of this but is out of the scope of this training. 

Question: Can you think of events that might occur on a SQL Server system that you would 

want to be alerted about?


Overview of SQL Server Agent 

Key Points 

As mentioned earlier in this module, SQL Server Agent is the component of SQL Server that is responsible 

for automating SQL Server administrative tasks. SQL Server Agent runs as a Windows service. 

Starting SQL Server Agent 

For SQL Server Agent to perform its main role of executing jobs and firing alerts, SQL Server Agent needs 

to be running constantly. Because of this, SQL Server Agent is typically configured to start automatically 

when the operating system starts. Note that the default option during SQL Server installation is for SQL 

Server Agent to be started manually. The design of the SQL Server installation process ensures that 

services and components are not installed or started unless they are required. This means that the default 

installation option needs to be changed if there is a need for SQL Server Agent to be running on your 

system. 

The start mode for SQL Server Agent is configured in the properties of the SQL Server Agent service in 

SQL Server Configuration Manager as shown on the slide. Note that three start modes are configurable: 

Start Mode Description 

Automatic The service will start when the operating system starts. 

Disabled The service will not start, even if you attempt to start it manually. 

Manual The service needs to be manually started.


In addition, you can configure the SQL Server Agent service to restart automatically if it stops 

unexpectedly. The automatic restart option is set in the properties page for the SQL Server Agent in SSMS, 

as shown below: 

To restart automatically, the SQL Server Agent service account must be a member of the local 

Administrators group for the computer that SQL Server is installed on but this is not considered a best 

practice. A better option would be to use an external monitoring tool such as System Center Operations 

Manager to monitor and restart the SQL Server Agent service if necessary. 

Question: Why should SQL Server Agent service be always configured to start up 

automatically?


Demonstration 1A: Working with SQL Server Agent 











Lesson 2 

Working with SQL Server Agent 


You have seen that SQL Server Agent is the primary tool for automating tasks within SQL Server. Database 

administrators need to be proficient at creating and configuring SQL Server Agent jobs. Jobs can be 

created to implement a variety of different types of task and can be categorized for ease of management. 

Creating a job involves creating a series of steps that the job will execute, along with the workflow that 

determines which steps should be executed, and in which order. 

Once the steps that a job needs to take have been determined, you need to determine when the job will 

be executed. Most SQL Server Agent jobs are run on defined schedules. SQL Server provides the ability to 

create a flexible set of schedules that can be shared between jobs. 

It is important to learn to script jobs that have been created. The scripting of jobs allows the jobs to be 

quickly recreated if a failure occurs, and allows the jobs to be recreated in other environments. For 

example, the jobs may have been created in a test environment but need to be executed in a production 

environment. 

Objectives 


• Define jobs, job types and job categories. 

• Create job steps. 

• Schedule jobs for execution. 

• Script jobs.


Defining Jobs, Job Step Types and Job Categories 

Key Points 

SQL Server Agent jobs are comprised of a series of operations that need to be performed in order. In most 

jobs, the steps are performed sequentially but an administrator can exercise control over the order of the 

steps. 

By configuring the action to occur on the success and failure of each job step, a workflow can be created 

that determines the overall logic flow of the job. 

Job Step Types 

Note that every job step has an associated type that defines the kind of operation to run. The most 

commonly used types are: 

• Executing a command line script, batch of commands, or application. 

• Executing a T-SQL statement. 

• Executing a Windows PowerShell® script. 

• Executing a SQL Server Integration Services Package 

• Executing Analysis Services commands and queries. 

Note While the ability to execute ActiveX® scripts has been retained for backwards 

compatibility, this option is deprecated and should not be used for new development. 

Note Other specialized job step types are used by features of SQL Server such as 

Replication. Replication is an advanced topic that is out of scope for this course.

Job Schedules 


One or more schedules can be defined for every job. Schedules can be defined as recurring, but also other 

schedule types provide for one time execution or for execution when SQL Server Agent first starts. 

You may need to create multiple schedules for a job when the required recurrence pattern for the job is 

complex and cannot be accommodated within a single job schedule. 

While each schedule can also be shared between many jobs, it is important to avoid having too many jobs 

starting at the same time. 

Creating Jobs 

You can use SQL Server Management Studio to create jobs or you can execute the sp_add_job system 

stored procedure. Creating a job requires the execution of a number of additional system stored 

procedures, to add steps and schedules to the job. 

The job definition is stored in the msdb database, along with all of SQL Server Agent configuration. 

Job Categories 

Jobs can be placed into categories. SQL Server has a number of built-in categories as shown below but 

you can add your own categories; 

Job categories can be useful when you need to perform actions that are associated with jobs in a specific 

category. For example, it would be possible to create a job category called "SQL Server 2005 Policy Check" 

and to write a PowerShell script to execute all the jobs in that category against your SQL Server 2005 

servers. 

Note A detailed discussion on the use of PowerShell is an advanced topic that is out of 

scope for this course. 

Note It is also important to consider the security account that each type of job step 

requires for execution. Module 14 discusses security for SQL Server Agent. 

Question: Can you think of a use for job categories?


Creating Job Steps 

Key Points 

Use SQL Server Management Studio or execute the sp_add_jobstep system stored procedure to define 

each job step that is required to automate a task. Only one execution type can be defined for each job 

step, but each step of a job can have a different type. 

Job Step Workflow 

Every step has an outcome that defines whether the step has succeeded or failed. Note the list of job 

steps and the "On Success" and "On Failure" options for each step in the following job: 

By default, SQL Server advances to the next job step upon success and stops upon failure of a job step but 

job steps can continue with any step defined in the job upon success or failure, to define a special 

workflow.


In the Advanced properties of each job step, an action can be configured for both success and failure as 

shown below: 

By configuring the action to occur on the success and failure of each job step, a workflow can be created 

that determines the overall logic flow of the job. Note that as well as each job step having a defined 

outcome, the overall job reports an outcome. This means that even though some job steps might succeed, 

the overall job might still report failure. 

Retrying Job Steps 

You can specify the number of times that SQL Server should attempt to retry execution of a job step if the 

step fails. You also can specify the retry intervals (in minutes). For example, if the job step requires a 

connection to a remote server, you could define several retry attempts in case the connection fails. 

Question: Which operations should not be grouped together in a job?


Scheduling Jobs for Execution 

Key Points 

Schedules are used to start jobs at requested times. One or more schedules can be associated with a job. 

Schedules are assigned names and schedules can be shared across multiple jobs. Apart from standard 

recurring schedules, a number of special recurrence types are also defined: 

• One time execution. 

• Start automatically when SQL Server Agent starts. 

• Start whenever the CPU becomes idle. 

Even though a job may have multiple schedules, SQL Server will limit the job to a single concurrent 

execution. If you try to run a job manually while it is running as scheduled, SQL Server Agent refuses the 

request. If a job is still running when it is scheduled to run again, SQL Server Agent refuses to run it again. 

Question: What could be changed if the database in the example above does not need 

hourly backups during weekend?

Scripting Jobs 

Key Points 


Jobs are typically first created in SSMS as there are a several system stored procedures that need to be 

executed to define a single job. However, it is important that existing jobs be scripted in T-SQL for the 

following reasons: 

• Scripts of jobs can be used in documentation and can be archived into source code control systems. 

• Jobs can easily be recreated after a failure if necessary, if scripts of the jobs have been created. 

• There is also a common requirement to be able to create a job in one environment (such as a test 

environment) and to deploy the job in another environment (such as a production environment). The 

ability to script jobs allows for easier deployment of the jobs. 

• Scripts of jobs could be used when performing side by side upgrades of SQL Server systems. 

Note More than one job can be selected in Object Explorer Details when scripting. 

Other more advanced options are available for scripting jobs, such as the use of SQL Server Management 

Objects (SMO). SMO can be used in conjunction with .NET programming in languages such as Microsoft 

Visual Basic® or C#, and can be used in conjunction with PowerShell. 

Question: In which scenarios might it be useful to script more than one job at a time?


Demonstration 2A: Scripting Jobs 












Lesson 3 

Managing SQL Server Agent Jobs 


While the automation of routine administrative and other tasks is important, it is equally important to 

ensure that those tasks continue to execute as expected. SQL Server provides detail regarding previous 

and failed executions by maintaining history in tables that are contained in the msdb database. This lesson 

will show you how to query the history tables and provide you with an approach for troubleshooting jobs 

that fail or that do not perform as expected. 

Objectives 


• View job history. 

• Query SQL Server Agent-related system tables and views. 

• Troubleshoot failed jobs.


Viewing Job History 

Key Points 

SQL Server Agent keeps track of job outcomes in system tables in the msdb database. As well as recording 

the outcome of entire jobs, SQL Server Agent records the outcome of each job step. 

You can choose to write job outcomes to the Windows Application log and to the SQL Server log by 

setting notification properties for each job. The history tables in msdb are always written regardless of the 

configuration for log output. 

Viewing Job History 

Each job and each job step has an outcome. If a job fails, the failing job step outcome needs to be 

reviewed to see the reason why the job step failed. The history for each job can be viewed in SSMS but 

can also be retrieved programmatically by directly querying the system tables. Writing queries to retrieve 

job history will be shown in the next topic in this lesson. 

The most recent 1000 entries for job history are retained by default but the retention period for job 

history entries can be configured based on either age or the total size of the job history data, using the 

property window for the SQL Server Agent service.


Object Explorer in SSMS also provides a Job Activity Monitor. The Job Activity Monitor offers a view of 

currently executing jobs and of data showing the results of the previous execution along with the 

scheduled time for the next execution of the job. An example of the data provided by the Job Activity 

Monitor is shown below: 

Question: How would a corrupt msdb database affect SQL Server Agent?


Querying SQL Server Agent-related System Tables and Views 

Key Points 

As mentioned earlier in this module, information about the configuration of SQL Server Agent and its 

objects such as jobs, alerts, schedules and operators is written to system tables in the msdb database. 

These objects are contained in the dbo schema and can be directly queried from there. 

Job history is written to the dbo.sysjobhistory table and a list of jobs is written to the dbo.sysjobs table. 

Example Query 

In the example shown on the slide, the date and time that a job was last run, and the outcome are 

queried from the dbo.sysjobhistory table in msdb. The query joins to the dbo.sysjobs table to retrieve the 

name of the job. 

Note that the WHERE clause specifies a step_id of zero. Job steps begin at one, not zero, but an entry in 

the dbo.sysjobhistory table is made with a job step_id of zero to record the overall outcome of the job. 

The outcome of individual job steps can be obtained by querying step_id values greater than zero. 

Question: Why would querying the job history tables be important?

Troubleshooting Failed Jobs 

Key Points 


Jobs do not always execute as expected and sometimes they will fail to execute at all. It is important to 

follow a consistent process when attempting to work out why a job is failing. 

There are four basic steps that need to be followed when troubleshooting jobs: checking SQL Server 

Agent status, reviewing job history, checking job execution, and checking access to dependencies. 

Checking SQL Server Agent Status 

If SQL Server Agent is not running, no jobs will be executed. Make sure the service is set to start 

automatically and attempt to start the service manually. If the service still will not start, check the 

following: 

• Make sure that the service account for the service is valid, that the password for the account has not 

changed, and that the account is not locked out. If any of these items are incorrect, the service will 

not start but details about the problem will be written to the System event log on the computer. 

• Check that the msdb database is online. If the msdb database is corrupt, suspect or offline, SQL Server 

Agent will not start. 

Review Job History 

Review the job outcome to identify the last step run. If the job failed because a job step failed, which is 

the most common situation, the error of the job step cannot be seen at this level. It is necessary to then 

review the individual job step outcome for the failed job.


Checking Job Execution 

If SQL Server Agent is running but an individual job will not execute, check the following items: 

• Make sure that the job is enabled. Disabled jobs will not run. 

• Make sure that the job is scheduled. Perhaps the schedule is incorrect or the time for the next 

scheduled execution has not occurred yet. 

• Make sure that the schedule is enabled. Both jobs and schedules can be disabled. A job will not run 

on a schedule that is disabled. 

Check Access to Dependencies 

Verify that all dependent objects such as databases, files, and procedures are available. In Demonstration 

2A, you saw a situation where the job on the second SQL Server instance did not run because the objects 

required to run the job were not present. 

Jobs often run in a different security context to the user that creates them. Incorrect security settings are a 

common problem that causes job execution to fail. The security context for job steps is discussed in more 

detail in Module 14. 

Question: When migrating a job from test to production, what else would be required apart 

from moving the job itself?


Demonstration 3A: Viewing Job History and Resolving Failed Jobs 








• Open and execute the 00 – Setup.sql script file from within Solution Explorer. 

• From the View menu, click Solution Explorer. Open the script file 21 – Demonstration 2A.sql 

and follow the steps in the script file. 




Lab 13: Automating SQL Server Management 

Lab Setup 













Lab Scenario 

There are a number of routine tasks to be performed on the Proseware instance. Previously these tasks 

have been performed manually and the lack of consistency in performing these tasks has caused issues for 

the organization. On the new instance, you need to automate these tasks using SQL Server Agent. 

There is also a report about an existing SQL Server Agent job that is not performing as expected. If you 

have time, you need to resolve the issues with the job.

Exercise 1: Create a Data Extraction Job 

Scenario 


In Module 8 you created an SSIS data extraction package. The extraction process identifies prospects that 

have not been contacted recently. The output of this extraction process is used for planning marketing 

activities during the week. You need to create a job to execute the SSIS package. 


1. Create the required job. 

2. Test that the job executes without error. 

Task 1: Create the required job 

• Create the required job. Call the job “Extract Uncontacted Prospects”. The job needs to execute the 

SSIS package “Weekly Extract of Prospects to Contact” which is located on the Proseware server 

instance. 

Task 2: Test that the job executes without error 

• Using Object Explorer, start the job and make sure it executes correctly. 

Results: After this exercise, you should have created the data extraction job. 

Exercise 2: Schedule the Data Extraction Job 

Scenario 

You have created a job to perform the extraction of prospects that need to be contacted. The information 

provided by this job is used two times during the week. A meeting is held at 9AM each Monday morning 

to plan the marketing activities for the week. A second planning meeting is held at 7PM on Tuesday 

evenings. You need to make sure that an updated list is available shortly before each meeting. You should 

schedule the extraction job to run each Monday at 8:30AM and each Tuesday at 6:30PM. 


1. Schedule the data extraction job. 

Task 1: Schedule the data extraction job 

• Create a new job schedule for each Monday at 8.30AM. 

• Create a new job schedule for each Tuesday at 6.30PM. 

• Assign the schedule to the data extraction job. 

Results: After this exercise, you should have applied multiple schedules to the data extraction job.


Challenge Exercise 3: Troubleshoot a Failing Job (Only if time permits) 

Scenario 

On the Proseware server, a new SQL Server Agent job called Extract Long Page Loads was recently 

created. The job retrieves details of web pages that took a long time to load from the Marketing.WebLog 

table for further analysis by the web development team. The job is intended to run every Monday at 6AM. 

The job was implemented last week but no data retrieval appears to have occurred this week. You need to 

investigate and correct any issues with this job. 


1. Troubleshoot the failing job. 

Task 1: Troubleshoot the failing job 

• Review the job history for the failing job and identify the cause of the failure. 

• Correct the problem that is preventing the job from executing successfully. 

• Test that the job now runs. 

• Ensure that the job is correctly scheduled. 

Results: After this exercise, you should have resolved the issues with the failing job.




1. What functions do you currently perform manually that could be placed in a job? 

2. How long is the job history kept in msdb? 


1. Use SQL Agent jobs to schedule routine jobs. 

2. Create custom categories to group your jobs. 

3. Script your jobs for remote deployment. 

4. Use job history to review job and job step outcomes. 

5. Use Job Activity Monitor to real time monitor jobs.

13-30 Automating SQL Server 2012 Management

Module 14 

Configuring Security for SQL Server Agent 

Contents: 

Lesson 1: Understanding SQL Server Agent Security 14-3 

Lesson 2: Configuring Credentials 14-13 

Lesson 3: Configuring Proxy Accounts 14-18 

Lab 14: Configuring Security for SQL Server Agent 14-24 

14-1

14-2 Configuring Security for SQL Server Agent 


In earlier modules, you have seen the need to minimize the permissions that are granted to users, so that 

the users have only the permissions that they need to perform their tasks. The same logic applies to the 

granting of permissions to SQL Server Agent. While it is easy to execute all jobs in the context of the SQL 

Server Agent service account, and to configure that account as an administrative account, a poor security 

environment would result from doing this. It is important to understand how to create a minimal privilege 

security environment for jobs that run in SQL Server Agent. 

Objectives 


• Explain SQL Server Agent security. 

• Configure credentials. 

• Configure Proxy accounts.

Lesson 1 

Understanding SQL Server Agent Security 


SQL Server Agent can be called upon to execute a wide variety of tasks. Many of the tasks that are 

executed by SQL Server Agent are administrative in nature but many other tasks that are executed by SQL 

Server Agent are performed on behalf of users. The need to be able to execute a wide variety of task types 

leads to the need for flexible security configuration. 

Jobs need to be able to access many types of objects. As well as objects that reside inside SQL Server, jobs 

often need to access external resources such as operating system files and folders. These operating system 

(and other) dependencies also require a configurable and layered security model, to avoid the need to 

grant too many permissions to the SQL Server Agent service account. 

Objectives 


• You will be able to SQL Server Agent security. 

• Describe SQL Server Agent roles. 

• Assign security contexts to SQL Server Agent job steps. 

• Troubleshoot SQL Server Agent security.


Overview of SQL Server Agent Security 

Key Points 

Like all services, the SQL Server Agent service has an identity within the Microsoft® Windows® operating 

system. The service startup account defines the Windows account in which the SQL Server Agent runs. The 

account that is used defines the permissions that the SQL Server Agent service has when accessing 

network resources. 

Agent Service Account 

For the SQL Server Agent service, you can use the built-in Local Service or Network Service account. 

Preferably, another specified Windows domain account can be used. 

Note The Local System account option is provided for backward compatibility only and 

the Network Service is also not recommended for security reasons. Network Service has 

more capabilities than are required for the service account. An account with only the 

required permissions should be created and used instead. 

A Windows domain account should be used and should be configured with the least possible privileges 

that will still allow operation. During the installation of SQL Server, a local group is created with a name in 

the following format: 

SQLServerSQLAgentUser$$ 

This group is granted all the access privileges needed by the SQL Server Agent account. Note that this 

only includes the bare minimum permissions that the account needs for SQL Server Agent to function. 

When SQL Server Agent needs to access other resources in job steps, additional permissions are necessary.


When SQL Server Configuration Manager is used to assign an account to the service (which is the 

preferred and supported method for changing service accounts), SQL Server Configuration Manager 

places the account into the correct group. No additional special permission grants need to be made. 

Note The SQL Server Agent account cannot use SQL Server Authentication for its 

connection to the SQL Server database engine. 

SQL Server Agent jobs are executed in the context of the service account by default. The alternative is to 

create Proxy Accounts that will be used for job execution. Proxy Accounts will be described later in this 

module. 

Question: What would cause a SQL Server Agent service account to need sysadmin 

privileges on the SQL Server instance?


SQL Server Agent Roles 

Key Points 

By default, only members of the sysadmin fixed server role can administer SQL Server Agent. As the SQL 

Server Agent job system can perform tasks that require access not only to SQL Server, but potentially also 

access to Windows and other network resources, it is important to control who can administer it. It is not 

considered good practice to make a login a member of the sysadmin fixed server role, if the only reason 

for their membership of that role is to administer SQL Server Agent. 

Fixed Database Roles for SQL Server Agent 

Fixed database roles in the msdb database are used to control access for non-sysadmin users. SQL Server 

2012 includes fixed database roles for working with SQL Server Agent. The available roles, listed in order 

of increasing capability, are as follows: 

• SQLAgentUserRole 

• SQLAgentReaderRole 

• SQLAgentOperatorRole 

When users who are not members of one of these roles are connected to SQL Server® in SSMS, the SQL 

Server Agent node in Object Explorer is not visible. A user must be a member of at least one of these fixed 

database roles or they must be a member of the sysadmin fixed server role, before they can use SQL 

Server Agent.

SQLAgentUserRole 


SQLAgentUserRole is the least privileged of the SQL Server Agent fixed database roles. Members of 

SQLAgentUserRole have permissions only on the local jobs and job schedules that they own. They cannot 

run multi-server jobs (master and target server jobs), and they cannot change job ownership to gain 

access to jobs that they do not already own. SQLAgentUserRole members can also view a list of available 

proxies in the Job Step Properties dialog box of SSMS. 

SQLAgentReaderRole 

SQLAgentReaderRole includes all the SQLAgentUserRole permissions as well as permissions to view the list 

of available multiserver jobs, their properties, and their history. Members of this role can also view the list 

of all available jobs and job schedules and their properties, not just the jobs and job schedules that they 

own. SQLAgentReaderRole members cannot change job ownership to gain access to jobs that they do not 

already own. 

SQLAgentOperatorRole 

SQLAgentOperatorRole is the most privileged of the SQL Server Agent fixed database roles. It includes all 

the permissions of SQLAgentUserRole and SQLAgentReaderRole. Members of this role can also view 

properties for operators and proxies, and enumerate the available proxies and alerts on the server. 

SQLAgentOperatorRole members have additional permissions on local jobs and schedules. They can 

execute, stop, or start all local jobs, and they can delete the job history for any local job on the server. 

They can also enable or disable all local jobs and schedules on the server. To enable or disable local jobs 

or schedules, members of this role must use the sp_update_job and sp_update_schedule stored 

procedures, specifying the job name or schedule identifier parameter and the enabled parameter. If any 

other parameters are specified, execution of these stored procedures fails. SQLAgentOperatorRole 

members cannot change job ownership to gain access to jobs that they do not already own. 

Question: Why should you be careful giving access to non sysadmin fixed roles members?


Discussion: SQL Server Agent Job Dependencies 

Discussion Topics 

Question: What SQL Server resources would SQL Server Agent Jobs potentially depend 

upon? 

Question: What resources outside of SQL Server might SQL Server Agent jobs depend upon? 

Question: What identity is needed for accessing the external resources?

Assigning Security Contexts to Agent Job Steps 

Key Points 


Each job step can be assigned a security context. Job steps that execute T-SQL code need to be 

considered separately from other types of job steps. 

T-SQL Job Steps 

T-SQL job steps do not use SQL Server Agent proxies. When a T-SQL job step is executed, SQL Server 

Agent impersonates the owner of the job, except in the situation where the owner of the job step is a 

member of the sysadmin fixed server role. In that case, the job step will run in the security context of the 

SQL Server Agent service, unless the sysadmin chooses to have the step impersonate another user. 

Members of the sysadmin fixed server role can specify that the job step should impersonate another user. 

Other Job Step Types 

For job step types that are not T-SQL based, a different security model is used. For members of the 

sysadmin fixed server role, by default, other job step types still use the SQL Server Agent service account 

to execute job steps. Because many different types of job steps can be executed within SQL Server Agent, 

it is undesirable to execute them using this account. To provide for tighter control, a proxy system was 

introduced.


Proxy Accounts 

A proxy account is used to associate a job step with a Windows identity, via an object called a Credential. 

Proxy accounts can be created for all available subsystems, except for T-SQL job steps. The use of proxy 

accounts means that different Windows identities can be used to perform the different tasks required in 

jobs and provides tighter security by avoiding the need for a single account to have all the permissions 

required to execute all jobs. 

Credentials are discussed in Lesson 2 of this module and Proxy Accounts are discussed in Lesson 3. 

Question: Why should a proxy account be used, even when the owner of the step is a 

member of the sysadmin fixed server role?

SQL Server Agent Security Troubleshooting 

Key Points 


When SQL Server Agent jobs are not running as expected, security issues are a common cause of 

problems. To troubleshoot SQL Server Agent jobs, you should follow these steps: 

1. Make sure that the job is in fact running. Look in the Job Activity log and check to see when the job 

has run. For each failure of a job that is indicated by a red X (as shown in the example on the slide), 

expand the job and find the job steps that are failing. The failing job steps will also have a red X icon. 

2. Check the security account. When you click on the job step that is failing, at the bottom right hand 

side of the window, there is an indication of the security context that the job step ran under. Check 

the group membership for the account to make sure that the account should have all required 

permissions. 

3. Check the tasks that the job step needs to perform. This includes any T-SQL objects that need to be 

accessed and any Windows files or resources that need to be accessed. 

4. Check for each failing step, that the account that is being used to execute the step is able to access 

the resources that you have determined as necessary for the step. 

Note Another very common problem that occurs is that job steps might specify local file 

paths instead of UNC paths. In general, jobs should use UNC paths to ensure they are 

sufficiently portable. That is, a job should be able to be migrated to another server if 

required. 

Question: What might be the cause of a job that runs perfectly well on a test system but 

then fails when run on a production system?


Demonstration 1A: Assigning a Security Context to Job Steps 












Lesson 2 

Configuring Credentials 


For SQL Server job steps to be able to access resources outside of SQL Server, the job steps must be 

executed in the security context of a Windows identity that has permission to access the required 

resources. Windows identities are separate from SQL Server identities, even though SQL Server can utilize 

Windows logins and groups. For a job step to be able to use a separate Windows identity, the job step 

needs to be able to logon as that identity and to be able to logon, the Windows user name and password 

needs to be stored somewhere. Credentials are SQL Server objects that are used to store Windows user 

names and passwords. 

Objectives 


• Describe credentials. 

• Configure credentials. 

• Manage credentials.


Overview of Credentials 

Key Points 

A credential is a SQL Server object that contains the authentication information required to connect to a 

resource outside SQL Server. Most credentials contain a Windows user name and password. 

Credentials 

A SQL Agent Proxy that can be used for job execution maps to a credential in SQL Server. In Lesson 3, you 

will see how to map a Proxy account to a credential. 

SQL Server creates some system credentials that are associated with specific endpoints automatically. 

These automatically created credentials are called system credentials and have names that are prefixed 

with two hash signs (##). 

Question: How does SQL Server accesses resources outside SQL Server, when the user is 

connected using a Windows login?


Key Points 


Credentials can be created using the T-SQL CREATE CREDENTIAL statement or by using the GUI in SSMS. 


The password for a credential is called a secret and is strongly encrypted and stored in the master 

database. When SQL Server first needs to perform any type of encryption, the SQL Server service 

generates a service master encryption key. The service master key is also used to protect the master keys 

for each database. (Not all databases have master keys). 

Often an organization will have a policy that requires encryption keys to be replaced on a regular basis. If 

the service master key is regenerated, the secrets that are stored for credentials are automatically 

decrypted and re-encrypted using the new service master key. 

Note Encryption in SQL Server is an advanced topic that is out of scope for this course. 

Note also that the encryption of secrets for credentials by an Extensible Key Management 

(EKM) Provider is also supported but also out of scope for this course.


Managing Credentials 

Key Points 

SQL Server provides the sys.credentials system view to provide catalog information about existing 

credentials. Consider the following query: 

SELECT * FROM sys.credentials; 

When executed, this query returns information similar to the following results: 

Modifying Credentials 

The password for a Windows account could change over time. You can update a credential with new 

values by using the ALTER CREDENTIAL statement. In the example on the slide, notice how the 

Agent_Export credential is being updated. Both the user name and password (that is, the secret) are 

supplied in the ALTER CREDENTIAL statement. The ALTER CREDENTIAL command always updates both 

the identity and the secret. 

Credentials are removed by the DROP CREDENTIAL statement. 

Question: What happens when the Windows user password that a credential maps to 

changes or expires?

Demonstration 2A: Configuring Credentials 














Lesson 3 

Configuring Proxy Accounts 

You saw in the last lesson that Credentials are used in SQL Server to store identities that are external to 

SQL Server. Mostly, these are Windows identities and Credentials are used to store their Windows user 

names and passwords. To enable a job step in a SQL Server Agent job to use a Credential, the job step is 

mapped to the Credential using a Proxy Account. There is a set of built-in Proxy Accounts and you can 

create Proxy Accounts manually. 

Objectives 


• Describe Proxy Accounts. 

• Work with built-in Proxy Accounts. 

• Manage Proxy Accounts.

Overview of Proxy Accounts 

Key Points 


A SQL Server Proxy Account is used to define the security context that is used for a job step. A Proxy 

Account is typically used to provide SQL Server Agent with access to the security credentials for a 

Microsoft Windows user. Each Proxy Account can be associated with one or more subsystems. 

A job step that uses the Proxy Account can access the specified subsystems by using the security context 

of the Windows user. Before SQL Server Agent runs a job step that uses a Proxy Account, SQL Server 

Agent impersonates the credentials defined in the Proxy Account, and then runs the job step by using 

that security context. 

Note The Windows user that is specified in the credential must have the "Log on as a 

batch job" right on the computer on which SQL Server is running. 

The creation of a Proxy Account does not change existing permissions for the Windows account that is 

specified in the credential. For example, you can create a Proxy Account for a Windows account that does 

not have permission to connect to an instance of SQL Server. Job steps that use that Proxy Account would 

be unable to connect to SQL Server. 

Note that a user must have permission to use a Proxy Account before they can specify the Proxy Account 

in a job step. By default, only members of the sysadmin fixed server role have permission to access all 

Proxy Accounts.


Permissions to access a Proxy Account can be granted to three types of security principals: 

• SQL Server logins 

• Server roles 

• Roles within the msdb database. 

Question: When should Proxy Accounts be used?

Working with Built-in Proxy Accounts 

Key Points 


SQL Server Proxy Accounts are utilized by subsystems. A subsystem is a predefined object that represents 

a set of functionality available within SQL Server. Each Proxy Account can be associated with more than 

one subsystem. 

Subsystems assist in providing security control because they segment the functions that are available to a 

Proxy Account. Earlier in this module, you saw that each job step runs in the context of a Proxy Account, 

except for T-SQL job steps. T-SQL job steps use the EXECUTE AS command to set the security context. 

SQL Server Agent checks subsystem access for a Proxy Account each and every time that a job step runs. If 

the security environment has changed and the Proxy Account no longer has access to the subsystem, the 

job step fails. 

Question: Why should Proxy Accounts not be assigned to all subsystems as a general rule?


Managing Proxy Accounts 

Key Points 

The configuration for SQL Server Agent is stored in the msdb database. Proxy Accounts are part of the 

SQL Server Agent, so the configuration for the Proxy Accounts is also stored in the msdb database. 

Details of the current Proxy Account configuration can be obtained through a set of system views that are 

shown in the following table: 

System View Description 

dbo.sysproxies Returns one row per proxy defined in SQL Server Agent 

dbo.sysproxylogin Returns which SQL Server logins are associated with each SQL Server 

Agent Proxy Account. Note that no entry for members of the 

sysadmin role is stored or returned 

dbo.sysproxyloginsubsystem Returns which SQL Server Agent subsystems are defined for each 

Proxy Account 

dbo.syssubsystems Returns information about all available SQL Server Agent proxy 

subsystems 

You saw earlier that Credentials can be viewed via the sys.credentials system view. Credentials are stored 

in the master database, not in the msdb database. 

Question: Why would Credentials be stored in the master database instead of the msdb 

database?

Demonstration 3A: Configuring Proxy Accounts 


1. If Demonstrations 2A were not performed: 









• Open the 21 – Demonstration 2A.sql script file from within Solution Explorer and follow the 

instructions contained within the file. 




Lab 14: Configuring Security for SQL Server Agent 

Lab Setup 













Lab Scenario 

You have deployed a job that extracts details of prospects that have not been contacted recently. You 

have also scheduled the job to run before each of the two marketing planning meetings that occur each 

week. The marketing team has deployed new functionality in Promote application to improve the 

planning processes. Rather than having the job scheduled, it is necessary for the Promote application to 

execute the job on demand.


The Promote application connects as a SQL login called PromoteApp. One of the other DBAs Terry Adams 

has attempted to configure SQL Server so that the PromoteApp login can execute the job. However he is 

unable to resolve why the job still will not run. In this lab you need to troubleshoot and resolve the 

problem. 


Actions that have already been taken by Terry Adams 

1. Created a database user for the PromoteApp login in the msdb database. 

2. Granted the PromoteApp database user permission to execute the msdb.dbo.sp_start_job stored 

procedure. 

3. Added the PromoteApp database user to the SQLAgentOperatorRole database role. 

4. Modified the Extract Uncontacted Prospects job to set the PromoteApp login as the owner of the job. 

5. Created a Windows user called ExtractUser with a password of Pa$$w0rd. 

6. Added the Windows user ExtractUser to the db_ssisoperator role within the msdb database. 

Exercise 1: Troubleshoot Job Execution Failure 

Scenario 

You need to review the action that Terry Adams has already taken then also review the history log for the 

failing job. You need to determine why the job is failing. 


1. Troubleshoot job execution failure. 

Task 1: Troubleshoot job execution failure 

• Review the previous actions taken by Terry Adams as detailed in the supporting documentation for 

the exercise. 

• View History log for the Extract Uncontacted Prospects job. 

• Determine from the history the reason that the job is failing. 

Results: After this exercise, you should have determined the reason that they job is failing. 

Exercise 2: Resolve the Security Issue 

Scenario 

You have determined that a proxy account is required for the correct execution of the failing job step. You 

need to create and assign the proxy account then test to see if all issues have been resolved. 


1. Create and assign proxy account. 

2. Test to see if all problems have been resolved.


Task 1: Create and assign proxy account 

• Using SQL Server Management Studio, create a SQL Server credential called ExtractIdentity that is 

associated with the Windows user 1077XA-MIA-SQL\ExtractUser and with a password of Pa$$w0rd. 

• Create a SQL Server proxy account called ExtractionProxy that is associated with the ExtractIdentity 

credential and which is active in the SQL Server Integration Services Package subsystem. Ensure that 

you grant permission to the PromoteApp login to use this credential. 

• Assign the proxy account to the Extract Uncontacted Prospects job. 

Task 2: Test to see if all problems have been resolved 

• Attempt to execute the Extract Uncontacted Prospects job. 

• If the job fails, continue to Exercise 3 if you have time. 

Results: After this exercise, you should have corrected a security issue with a job. 

Challenge Exercise 3: Perform Further Troubleshooting (Only if time 

permits) 

Scenario 

After creating and assigning a proxy account to the job, the initial problem where SQL Server refused to 

execute job steps without a proxy has been resolved. However, the job still does not operate successfully. 

You should attempt to resolve the final issue. 


1. Perform further troubleshooting. 

Task 1: Perform further troubleshooting 

• Locate and resolve further issues that are preventing the job from running successfully. 

• Test that the job now runs successfully. 

Results: After this exercise, you should have identified and resolved the remaining issues.



1. What account types can be used to start SQL Server Agent service? 

2. What can credentials be used for? 



1. Use a Windows domain user to start SQL Server Agent service account. 

2. Use an account with least privileges. 

3. Create Proxy Accounts with least permissions assigned for job execution.

14-28 Configuring Security for SQL Server Agent

Module 15 

Monitoring SQL Server 2012 with Alerts and Notifications 

Contents: 

Lesson 1: Configuring Database Mail 15-3 

Lesson 2: Monitoring SQL Server Errors 15-11 

Lesson 3: Configuring Operators, Alerts and Notifications 15-18 

Lab 15: Monitoring SQL Agent Jobs with Alerts and Notifications 15-30 

15-1

15-2 Monitoring SQL Server 2012 with Alerts and Notifications 


Many database administrators work in a reactive mode where they respond when users complain that 

errors or problems are occurring. It is important to try to move from a reactive mode of operation to a 

more proactive mode. 

One key aspect of managing Microsoft® SQL Server® in a proactive manner is to make sure that you are 

aware of events that occur in the server, as they happen. At first you might consider that this would still be 

a reactive approach. However, there are many types of issues that can arise that are not directly apparent 

to users of the database applications. SQL Server logs a wealth of information about issues and you can 

configure SQL Server to advise you automatically when these issues occur via alerts and notifications. 

The most common way that SQL Server database administrators receive details of events of interest is via 

email. SQL Server can be configured to send mail via an existing SMTP mail server. 

Objectives 


• Configure database mail. 

• Monitor SQL Server errors. 

• Configure operators, alerts and notifications.

Lesson 1 

Configuring Database Mail 

Administering Microsoft SQL Server 2012 Databases 15-3 

SQL Server needs to be able to advise administrators when issues arise that require the attention of the 

administrators. Electronic mail (email) is the most commonly used mechanism for notifications from SQL 

Server. The Database Mail feature of SQL Server is used to connect to an existing SMTP server, when SQL 

Server needs to send email. 

SQL Server can be configured with multiple email profiles and configured to control which users can 

utilize the email features of the product. It is important to be able to track and trace emails that have 

been sent. SQL Server allows you to configure a policy for the retention of emails. 

Objectives 


• Describe database mail. 

• Configure database mail profiles. 

• Configure database mail security. 

• Configure database mail retention.


Overview of Database Mail 

Key Points 

Database Mail sends email through a Simple Mail Transport Protocol (SMTP) server. There must be an 

available SMTP server on the network that accepts the mail. 

Configuring Database Mail 

To enable and configure Database Mail accounts and profiles, use the Database Mail Configuration 

Wizard. 

While the configuration details for Database Mail are stored in the msdb database along with all other 

SQL Server Agent configuration data, SQL Server Agent caches profile information in memory, so that it is 

possible for SQL Server Agent to send email in situations where the SQL Server database engine is no 

longer available. 

Database Mail can be used to send email as part of a SQL Server Agent job, in response to an alert being 

raised, or on behalf of a user by the execution of the sp_send_dbmail system stored procedure. 

SQL Mail 

Note that for backwards compatibility, earlier versions of SQL Server included a feature called SQL Mail. 

SQL Mail was a Messaging Application Programming Interface (MAPI)–based email feature that you could 

use to configure SQL Server to send and receive email via Microsoft Exchange Server or other MAPI-based 

email servers. SQL Mail is not supported on SQL Server 2012.

SMTP Relay 


Most SMTP servers today are configured, by default, to deny all email relay. A server that is configured to 

permit relay is willing to accept email from another server even though the target for the email is not in 

the mail server's domain. The mail server then forwards the email to its final destination. 

The refusal to relay email is important for avoiding spam related issues. Email servers that do not have this 

protection are called "open relay" servers and are a target for misuse. Blacklists for email servers that 

regularly send spam are maintained by many companies. By relaying email via other servers, it appears 

that those other servers are sending the spam, not the server that initially sent the spam. Because the 

most common configuration for mail servers is to deny all relaying activity, the SMTP server must be 

configured to permit the relay of emails from SQL Server if necessary. 

Question: Why must mail administrators be included in discussions, when planning a 

database mail configuration?


Database Mail Profiles 

Key Points 

A Database Mail profile is a collection of Database Mail accounts. At least one Database Mail account is 

required. If more than one Database Mail account is defined for a profile, the accounts are used in a 

predefined order in the attempt to send mails. The level of redundancy provided by the use of multiple 

email profiles can help to improve overall reliability. 

Profiles can be private or public. Private profiles are strictly controlled and are only available to specified 

users or roles. By comparison, public profiles can be used by any user or role that has been given 

permission to use the profile. 

Multiple Profiles 

It is possible to create multiple configurations by the use of different profiles. For example a profile can be 

created to send mail to an internal SMTP server, using an internal email address, for mails sent by SQL 

Server Agent. A second profile could be created for use by a database application that needs to send 

external email notifications to customers. 

Each database user might have access to several profiles. If no profile is specified when sending a mail, the 

default profile will be used. If both private and public profiles exist, precedence is given to a private 

default profile over a public default profile. If no default profile is specified or if a non-default profile 

should be used, the profile name must be specified as a parameter to the sp_send_dbmail system stored 

procedure as shown in the following code: 

EXEC msdb.dbo.sp_send_dbmail 

@profile_name = 'Proseware Administrator', 

@recipients = 'admin@AdventureWorks.com', 

@body = 'Daily backup completed successfully.', 

@subject = 'Daily backup status'; 

Question: If a user has access to several profiles, which profile is used when no profile is 

specified?

Database Mail Security 

Key Points 


The choice of service account for the SQL Server service is important when configuring Database Mail. If 

SQL Server is configured to run as the Local Service account, it does not have permission to make 

outgoing network connections. In this case, Database Mail cannot contact an email server located on a 

different computer. 

Database Mail Stored Procedures 

To minimize the security surface of SQL Server, the system extended stored procedures that are used for 

Database Mail are disabled by default. When you run the Database Mail Configuration Wizard, the 

procedures are enabled for you. If you wish to configure Database Mail manually, you can enable the 

Database Mail system extended stored procedures by setting the sp_configure option "Database Mail XPs" 

to the value 1. 

Security and Attachment Limitations 

Not all SQL Server users are permitted to send emails. The ability to send emails is limited to members of 

the database role called DatabaseMailUserRole in the msdb database. Members of the sysadmin fixed 

server role can also send database mail. 

You can also limit both the types and size of attachments that can be included in emails that are sent by 

Database Mail. This limitation can be configured using the Database Mail Configuration Wizard or by 

calling the dbo.sysmail_configure_sp system stored procedure in the msdb database. 

Question: Why can't database mail be used with a remote SMTP server when using the Local 

Service account for the database engine?


Database Mail Logs and Retention 

Key Points 

SQL Server logs messages in internal tables in the msdb database. Log messages can be viewed by 

querying the dbo.sysmail_log table. The level of logging that is carried out by SQL Server can be 

configured to one of following three levels: 

Logging Level Description 

Normal Only errors are logged 

Extended Errors, warnings, and informational messages are logged 

Verbose As per Extended plus success messages and a number of 

internal messages 

You can configure the Logging Level parameter by using the Configure System Parameters dialog box of 

the Database Mail Configuration Wizard, or by calling the dbo.sysmail_configure_sp stored procedure in 

the msdb database. 

Verbose level should only be used for troubleshooting purposes as it can generate a large volume of log 

entries.

Database Mail Tables and Views 


Internal tables in the msdb database are used to hold the email messages and the attachments that are 

sent from Database Mail, together with the current status of each message. Database Mail updates these 

tables as each message is processed. 

You can track the delivery status of an individual message by viewing information in the following views: 

• dbo.sysmail_allitems 

• dbo.sysmail_sentitems 

• dbo.sysmail_unsentitems 

• dbo.sysmail_faileditems 

To see details of email attachments, query the dbo.sysmail_mailattachments view. 

Retention Policy 

Database Mail retains outgoing messages and their attachments in the msdb database. This means that 

there is a need to plan a retention policy for email messages and log entries. If the volume of Database 

Mail messages and related attachments is high, plan for substantial growth of the msdb database. 

Periodically delete messages to regain space and to comply with your organization's document retention 

policies. For example, the example in the slide shows how to delete messages, attachments, and log 

entries that are more than one month old. You could schedule these commands to be executed 

periodically by creating a SQL Server Agent job.


Demonstration 1A: Configuring Database Mail 











Lesson 2 

Monitoring SQL Server Errors 


It is important to understand the core aspects of errors as they apply to SQL Server. In particular, you need 

to consider: 

• The nature of errors. 

• The locations where errors can occur when T-SQL code is being executed. 

• The data that is returned by errors. 

• The severities that errors can exhibit. 

Severe SQL Server errors are recorded in the SQL Server Error Log. It is important to know how to 

configure the log. 

Objectives 


• Describe what an error is. 

• Describe error severity levels. 

• Configure the SQL Server error log.


What Is in an Error? 

Key Points 

An error is itself an object and has properties as shown in the table. 

Error Attributes 

It might not be immediately obvious that a SQL Server error (or sometimes called an exception) is itself an 

object. Errors return a number of useful properties (or attributes). 

Error numbers are helpful when trying to locate information about the specific error, particularly when 

searching online for information about the error. 

You can view the list of system-supplied error messages by querying the sys.messages catalog view: 

SELECT * FROM sys.messages 

ORDER BY message_id, language_id; 

When executed, this command returns the following: 

Note that there are multiple messages with the same message_id. Error messages are localizable and can 

be returned in a number of languages. A language_id of 1033 is the English version of the message. You 

can see an English message in the third line of the output above. 

Severity indicates how serious the error is. It is described further in the next topic.


State is defined by the author of the code that raised the error. For example, if you were writing a stored 

procedure that could raise an error for a missing customer and there were five places in the code that this 

message could occur, you could assign a different state to each of the places where the message was 

raised. This would help later to troubleshoot the error. 

Procedure name is the name of the stored procedure that that error occurred in and Line Number is the 

location within that procedure. In practice, line numbers are not very helpful and not always applicable. 

Question: In which language is an error raised?


Error Severity 

Key Points 

The severity of an error indicates the type of problem encountered by SQL Server. Low severity values are 

informational messages and do not indicate true errors. Error severities occur in ranges. 

Values from 0 to 10 

Values from 0 to 9 are purely informational messages. When queries that raise these are executed in SQL 

Server Management Studio, the information is returned but no error status information is provided. For 

example, consider the following code executed against the AdventureWorks database: 

SELECT COUNT(Color) FROM Production.Product; 

When executed, it returns a count as expected. However, if you look on the Messages tab in SQL Server 

Management Studio, you will see the following: 

Warning: Null value is eliminated by an aggregate or other SET operation. 

(1 row(s) affected) 

Note that no error really occurred but SQL Server is warning you that it ignored NULL values when 

counting the rows. Note that no status information is returned. 

Severity 10 is the top of the informational messages. 


Values from 11 to 16 are considered errors that the user can correct. Typically they are used for errors 

where SQL Server assumes that the statement being executed was in error.

Here are a few examples of these errors: 

Error Severity Example 

11 indicates that an object does not exist 

13 indicates a transaction deadlock 

14 indicates errors such as permission denied 

15 indicates syntax errors 



Values from 17 to 19 are considered serious software errors that the user cannot correct. For example, 

severity 17 indicates that SQL Server has run out of resources (memory, disk space, locks, etc.). 

Values above 19 

Values above 19 tend to be very serious errors that normally involve errors with either the hardware or 

SQL Server itself. It is common to ensure that all errors above 19 are logged and alerts generated on 

them. 

Question: In which of the error number ranges shown on the slide, would you expect to see 

a syntax error?


Configuring the SQL Server Error Log 

Key Points 

Important messages (particularly those that would be considered as severe error messages) are logged to 

both the Windows Application Event Log and SQL Server Error Log. The sys.messages view shows the 

available error messages and indicates which messages will be logged by default. You can control the 

logging behavior of individual messages by using the sp_altermessage system stored procedure. 

The SQL Server Error Log is located by default in the folder: 

Program Files\Microsoft SQL Server\MSSQL11.\MSSQL\LOG\ERRORLOG 

The log files are named ERRORLOG.n where n is the log file number. The log files are text files and can be 

viewed using any text editor or by using the Log Viewer provided in SSMS. 

By default, SQL Server retains backups of the previous six logs and gives the most recent log backup the 

extension .1, the second most recent the extension .2, and so on. The current error log has no extension. 

The number of log files that should be retained can be configured in SSMS using the right-click Configure 

option from the SQL Server Logs node in Object Explorer. 

Recycling Log Files 

The log file cycles with every restart of the SQL Server instance. On occasions, you might want to remove 

excessively large log files. By using the system stored procedure sp_cycle_errorlog, you can close the 

existing log file and open a new log file on demand. If there is a regular need to recycle the log file, you 

could create a SQL Server Agent job to execute the sp_cycle_errorlog system stored procedure on a 

schedule. Cycling the log can let you stop the current error log becoming too large.

Demonstration 2A: Cycling the Error Log 

Demonstration Setup 













Lesson 3 

Configuring Operators, Alerts and Notifications 

Earlier in this module, you have seen that it is important for SQL Server to be able to send messages to an 

administrator when events that need administrative attention occur. 

Many SQL Server systems will have a number of administrators. SQL Server Agent allows you to configure 

Operators that are associated with one or more administrators and to determine when each of the 

operators should be contacted, along with the method that should be used for contacting the operator. 

SQL Server can also detect many situations that might be of interest to administrators. You can configure 

Alerts that are based on SQL Server errors or on system events such as low disk space availability. SQL 

Server can then be configured to notify you of these situations. 

Objectives 


• Describe the role of Operators in SQL Server Agent. 

• Implement SQL Server alerts. 

• Create alerts. 

• Configure actions that need to occur in response to alerts. 

• Troubleshoot alerts and notifications.

SQL Server Agent Operator Overview 

Key Points 


An Operator in SQL Server Agent is an alias for a person or a group of people that can receive electronic 

notifications when jobs complete or when alerts are raised. 

Note Operators do not need to be Windows logins, SQL Server logins, or database users. 

For example, you could create an operator that is a reference to a pager address. 

SQL Server Agent jobs can be configured to send messages when a job completes, when a job completes 

successfully, or when a job fails. 

You can define new operators using either SSMS or the dbo.sp_add_operator system stored procedure. 

Once an operator is defined, the definition for the operator is visible through the dbo.sysoperators system 

table in the msdb database. 

Contacting An Operator 

You can configure three types of contact methods for each operator: 

• Email: SMTP email address that notifications should be sent to. It is desirable to use group email 

addresses rather than individual email addresses where possible. It is possible to list multiple email 

addresses by separating them with a semicolon. 

• Pager Email: SMTP email address that a message is sent to during specified times (and days) during a 

week.


• Net Send address: Messenger address that a message is sent to. 

Note The use of Net Send for notifications is deprecated and should not be used for new 

development as it will be removed in a future version of SQL Server. The Net Send option is 

not useful as it depends upon the Messenger service in Microsoft Windows®. That service is 

generally disabled on current systems. 

A fail-safe operator can be defined to respond to an alert when pager notifications to other operators fail 

because of time limitations that have been configured. For example, if all operators are off duty when an 

alert is fired, the fail-safe operator will be contacted. 

Existing Active Directory® users and groups can be used as operator groups if they are mail enabled 

groups.


Demonstration 3A: Configuring SQL Server Agent Operators 













Overview of SQL Server Alerts 

Key Points 

There are many events that can occur in a SQL Server system that are of interest to administrators. An 

Alert is a SQL Server object that defines a condition that requires attention and a response that should be 

taken when the event occurs. You can define alerts to execute a job or to notify an operator when a 

particular event occurs or even when a performance threshold is exceeded. 

SQL Server Alerts 

Events are generated by SQL Server and entered into the Windows Application Event Log. On startup, SQL 

Server Agent registers itself as a callback service with the Windows Application Event log. This means that 

SQL Server Agent will be directly notified by the application log when events of interest occur. This 

callback mechanism operates efficiently as it means that SQL Server Agent does not need to continuously 

read (or more formally "poll") the application log to find events of interest. 

When SQL Server Agent is notified of a logged event, it compares the event to the alerts that have been 

defined. When SQL Server Agent finds a match, it fires an alert, which is an automated response to an 

event. 

Note The error message must be written to the Windows Application Log to be used for 

SQL Server Agent Alerts.

Alerts Actions (Responses) 


You can create alerts to respond to individual error numbers or to respond to all errors of a specific 

severity level. You can define the alert for all databases or for a specific database. You can define the time 

delay between responses. 

Note It is considered good practice to configure notifications for all error messages with 

Severity Level 19 and above. 

System Events 

In addition to monitoring SQL Server events, SQL Server Agent can also monitor conditions that can be 

detected via Windows Management Instrumentation (WMI) events. The WQL queries that are written to 

retrieve the performance data are executed a few times each minute. As a result, it can take a few seconds 

for these alerts to fire. 

Performance condition alerts can also be configured on any of the performance counters that SQL Server 

exposes. 

Question: What events are you familiar with that should have a configured alert?


Create an Alert 

Key Points 

Alerts are created using the GUI in SSMS or by calling the dbo.sp_add_alert system stored procedure. 

When defining an alert, you can also specify a SQL Server Agent job that should be started when the alert 

occurs. In the example on the slide, the Job ID of a SQL Server Agent job that has already been created 

has been added to the definition of the alert. The job will be started when the alert fires. 

The action that SQL Server Agent takes in response to the event or performance condition may include 

contacting an operator. 

Logged Events 

You have seen that alerts will only fire for SQL Server errors if the error messages are written to the 

Microsoft Windows Application Event log. In general, error severity levels from 19 to 25 are automatically 

written to the application log but this is not always the case. To check which messages are automatically 

written to the log, query the is_event_logged column in the sys.messages table. 

Most events with severity levels less than 19 will only trigger alerts if you have used one of the following 

options: 

• Modified the error message using the dbo.sp_altermessage system stored procedure to make the 

error message a logged message. 

• Raised the error in code using the RAISERROR WITH LOG option. 

• Used the xp_logevent system extended stored procedure to force entries to be written to the log. 

Question: What type of alert would be needed to monitor free space in file the system?

Configuring Alert Actions 

Key Points 


When an alert fires, there are two actions that can be configured to respond to the alert: 

• Execute a Job 

• Notify Operators 

Execute a Job 

The execution of a SQL Server Agent job can be configured as a response to an alert. Only one job can be 

started. However, if you need to start multiple jobs when an alert occurs, create a new job that executes 

the other jobs and then configure the new job to respond to the alert. 

The job to be executed can be configured when first creating the alert using dbo.sp_add_alert or by 

calling the dbo.sp_update_alert system stored procedure after the alert has already been created. 

Notify Operators 

Unlike the configuration of a job to run as part of the configuration of an alert, the list of operators to be 

notified when an alert fires is defined using the dbo.sp_add_notification system stored procedure.


When sending messages to operators about alerts, it is important to be able to provide the operator with 

sufficient context about the alert so that they can determine the appropriate action to take. Tokens can be 

included in messages to add detail to the message. The special tokens available for working with alerts are 

shown in the following table: 

Token Description 

A-DBN Database Name 

A-SVR Server Name 

A-ERR Error Number 

A-SEV Error Severity 

A-MSG Error Message 

Note that for security reasons this feature is disabled by default and can be enabled in the properties of 

SQL Server Agent. 

Question: If notifications should be sent to a pager email address, what else should be 

configured?

Troubleshooting Alerts and Notifications 

Key Points 


When troubleshooting alerts and notifications, use the following process to identify the issues: 


Ensure that SQL Server Agent is 

running 

Check that the error message is 

written to Application Log. 

The Application Log will only send messages to SQL Server 

Agent when the Agent is running. The Application Log does 

not hold a queue of notifications to be made at a later 

time. 

For SQL Server Event Alerts, check that the error message is 

written to the Application Log and also make sure that the 

Application Log is configured with sufficient size to hold all 

event log details. 

Ensure that the alert is enabled. Alerts can be enabled or disabled and will not fire when 

disabled. 

Check that the alert was raised. If the alert does not appear to be raised, make sure that the 

setting for delay between responses is not set to too high a 

value.


(continued) 


If the alert was raised but no 

action was taken 

Check that the job that is configured to respond to the alert 

functions as expected. For operator notifications, check that 

Database Mail is working and that the SMTP Server 

configuration is correct. Test the Database Mail profile that 

is being used to send notifications by manually sending mail 

from the profile used by SQL Server Agent. 

Question: Why might an error message not be written to the application log?

Demonstration 3B: Configuring Alerts and Notifications 











• Open the script file 11 – Demonstration 1A.sql and follow the instructions in that file. 

• Open the script file 31 – Demonstration 3A.sql and follow the instructions in that file. 




Lab 15: Monitoring SQL Agent Jobs with Alerts and 

Notifications 

Lab Setup 













Lab Scenario 

You have configured automated management tasks using SQL Server Agent and have configured security 

for those tasks. You now need to configure alerts and notifications for your Proseware system. The IT 

Support team at AdventureWorks has a defined escalation policy for SQL Server systems. As Proseware is 

part of the group of companies owned by AdventureWorks, you need to implement the relevant parts of 

this policy.


The IT Support team has supplied you with details from the policy that they have determined are needed 

for your Proseware server. For some automated tasks, notifications need to be sent every time the tasks 

are completed, whether or not the tasks work as expected. For other tasks, notifications only need to be 

sent if the tasks fail for some reason. 

Notifications at AdventureWorks are pager-based. You need to configure Database Mail within SQL Server 

so that SQL Server Agent can send notification emails to the pager system. There are two on-call DBAs 

allocated to your system from the AdventureWorks IT Support team. You need to configure these staff 

members as operators based on their current on-call work schedules and also configure a fail-safe 

operator for any time period where no team member is working. 

If you have enough time, you should also configure SQL Server to alert you if severe errors occur on the 

server. 


Database Mail Configuration Parameters 

Profile Name: Proseware SQL Server Agent Profile 

SMTP Account Item Value 

Main Account Name Proseware Administrator 

E-mail Address prosewaresqladmin@adventureworks.com 

Display name Proseware SQL Server Administrator 

Reply e-mail prosewaresqladmin@adventureworks.com 

Server name mailserver.adventureworks.com 

Fail-safe Account Name AdventureWorks Administrator 

E-mail Address adventureworkssqladmin@adventureworks.com 

Display name AdventureWorks SQL Server Administrator 

Reply e-mail adventureworkssqladmin@adventureworks.com 

Server name mailserver.adventureworks.com 

Public Profiles: Configure Proseware SQL Agent Profile as public and as default 

Private Profiles: Configure SQL Server Agent Profile as the default profile for the SQL Server Agent 

service (AdventureWorks\PWService) 

Maximum E-mail File Size: 4MB


On-call DBA Operator Requirements 

• Senior DBA Jeff Hay is on-call via pager jeff.hay.pager@adventureworks.com for the entire 24 hours 

per day, seven days per week. 

• DBA Palle Petersen is on-call via pager palle.petersen.pager@adventureworks.com for the entire 24 

hours per day, seven days per week. 

• Although there should always be a DBA on call a fail-safe pager address 

itsupport.pager@adventureworks.com should be configured. The IT Support operator should also be 

available 24 hours per day, seven days per week. 

Job Notification Requirements 

• Backup-related jobs must send notifications on completion, not just on failure. Notifications for 

backup-related jobs should be sent to Jeff Hay. 

• System jobs do not need to send any notifications. System jobs are identified by the prefix sys. 

• All other jobs should notify on failure only. Notifications for other jobs should be sent to Palle 

Petersen. 

Severe Error Alerting Requirements 

• Any error of severity 17 or 18 should be notified to all operators via pager. 

• Error 9002 on any database should be notified to all operators via pager. 

Exercise 1: Configure Database Mail 

Scenario 

Notifications at AdventureWorks are pager-based. You need to configure Database Mail within SQL Server 

so that SQL Server Agent can send notification emails to the pager system. 


1. Configure database mail. 

2. Test that database mail operates. 

Task 1: Configure database mail 

• Review the database mail configuration parameters in the supporting documentation for the exercise. 

• Configure database mail as per supplied parameters. 

Task 2: Test that database mail operates 

• Send a test email using the right-click option on the database mail node in Object Explorer. 

• From Solution Explorer, open and execute the script file 51 – Lab Exercise 1.sql to view outgoing mail 

items. 

Results: After this exercise, you should have configured and tested database mail.

Exercise 2: Implement Notifications 

Scenario 


The IT Support team at AdventureWorks has a defined escalation policy for SQL Server systems. As 

Proseware is part of the group of companies owned by AdventureWorks, you need to implement the 

relevant parts of this policy. 

The IT Support team has supplied you with details from the policy that they have determined are needed 

for your Proseware server. For some automated tasks, notifications need to be sent every time the tasks 

are completed, whether or not the tasks work as expected. For other tasks, notifications only need to be 

sent if the tasks fail for some reason. 

Notifications at AdventureWorks are pager-based. There are two on-call DBAs allocated to your system 

from the AdventureWorks IT Support team. You need to configure these staff members as operators 

based on their current on-call work schedules and also configure a fail-safe operator for any time period 

where no team member is working. 



2. Configure the required operators. 

3. Configure SQL Server Agent Mail. 

4. Configure and Test Notifications in SQL Server Agent Jobs. 


• Review the supplied requirements in the supporting documentation for the exercise. In particular, 

note any required operators. 

Task 2: Configure the required operators 

• Configure the required operators that you determined were required in Task 1. The supporting 

documentation includes details of how the operators need to be configured. 

Task 3: Configure SQL Server Agent Mail 

• Configure SQL Server Agent to use the mail profile that you created in Exercise 1. 

• Configure SQL Server Agent to use the IT Support fail-safe operator that you configured in Task 2. 

Task 4: Configure and Test Notifications in SQL Server Agent Jobs 

• Configure notifications for jobs as per the requirements in the supporting documentation. 

• Test the notifications by executing all non-system jobs and reviewing the mail item sent. 

Results: After this exercise, you should have configured SQL Server Agent 

operators, and job notifications. 

Challenge Exercise 3: Implement Alerts (Only if time permits) 

Scenario 

If you have enough time, you should also configure SQL Server to alert you if severe errors occur on the 

server.



1. Configure and test alerts. 

Task 1: Configure and test alerts 

• Review the supporting documentation for the alerting requirements. 

• Configure the required alerts. 

• Execute the script 71 – Lab Exercise 3.sql to test the alerting functionality. 

Note The script will return error 9002. 

Results: After this exercise, you should have configured and tested SQL Server 

alerts.



1. What is an Operator in SQL Server Agent terminology? 

2. What is the lowest error severity that appears as an error message in SSMS? 


1. Use Database Mail and not SQL Mail. 

2. Configure different profiles for different usage scenarios. 

3. Provide limited access to the ability to send emails from the database engine. 

4. Implement a retention policy for database mail log and mail auditing. 

5. Create operators to send notifications about Jobs and Alerts. 

6. Define Alerts for severe error messages. 

Administering Microsoft SQL Server 2012 Databases 15-35

15-36 Monitoring SQL Server 2012 with Alerts and Notifications

Module 16 

Performing Ongoing Database Maintenance 

Contents: 

Lesson 1: Ensuring Database Integrity 16-3 

Lesson 2: Maintaining Indexes 16-12 

Lesson 3: Automating Routine Database Maintenance 16-26 

Lab 16: Performing Ongoing Database Maintenance 16-30 

16-1

16-2 Performing Ongoing Database Maintenance 


The Microsoft® SQL Server® database engine is very capable of running indefinitely without any ongoing 

maintenance. However obtaining the best outcomes from the database engine requires a schedule of 

routine maintenance operations. 

Database corruption is relatively rare but one of the most important tasks in the ongoing maintenance of 

a database is to check that no corruption has occurred in the database. Recovering from corruption 

depends upon detecting the corruption soon after it occurs. 

SQL Server indexes can also continue to work without any maintenance but they will perform better if any 

fragmentation that occurs within them is periodically removed. 

SQL Server includes a Maintenance Plan Wizard to assist in creating SQL Server Agent jobs that perform 

these and other ongoing maintenance tasks. 

Objectives 


• Ensure database integrity. 

• Maintain indexes. 

• Automate routine database maintenance.

Lesson 1 

Ensuring Database Integrity 


It is particularly rare for the database engine to cause corruption directly. However, the database engine 

depends upon the hardware platform that it runs upon and that platform can cause corruption. In 

particular, issues in the memory and I/O subsystems can lead to corruption within databases. 

If you do not detect corruption soon after it has occurred, further (and significantly more complex or 

troublesome) issues can arise. For example, there is little point attempting to recover a corrupt database 

from a set of backups where every backup contains a corrupted copy of the database. 

The DBCC CHECKDB command can be used to detect, and in some circumstances correct, database 

corruption. It is important that you are familiar with how DBCC CHECKDB is used. 

Objectives 


• Use DBCC CHECKDB. 

• Explain the most common DBCC CHECKDB options. 

• Explain how to use the DBCC CHECKDB repair options.


Discussion: Ensuring Database Integrity 

Discussion Topics 

Question: What is database integrity? 

Question: What techniques are you currently using to check and maintain database 

integrity?

Overview of DBCC CHECKDB 

Key Points 


DBCC is a utility that is supplied with SQL Server that provides a large number of management facilities. In 

earlier documentation, you may see it referred to as the Database Consistency Checker. While checking 

the consistency of databases by using the CHECKDB option is a primary use of DBCC, it has many other 

uses. In current versions of the product, it is referred to as the Database Console Commands utility, to 

more closely reflect the wider variety of tasks that it can be used for. 

DBCC CHECKDB 

The CHECKDB option in the DBCC utility makes a particularly thorough check of the structure of a 

database, to detect almost all forms of potential corruption. The series of functions that are contained 

within DBCC CHECKDB are also available as options that can be performed separately if required. 

The most important of these options is shown in the following table: 


DBCC CHECKALLOC Checks the consistency of disk space allocation structures for a 

specified database. 

DBCC CHECKTABLE Checks the pages associated with a specified table and the 

pointers between pages that are associated with the table. DBCC 

CHECKDB executes DBCC CHECKTABLE for every table in the 

database.


(continued) 


DBCC CHECKCATALOG Checks the database catalog by performing logical consistency 

checks on the metadata tables in the database. These metadata 

tables are used to hold information that describes both system and 

user tables and other database objects. DBCC CHECKCATALOG 

does not check user tables. 

DBCC CHECKDB also performs checks on other types of objects such as the links for FILESTREAM objects 

and consistency checks on the Service Broker objects. 

Note FILESTREAM and Service Broker are advanced topics that are out of scope for this 

course. 

Repair Options 

Even though DBCC CHECKDB has repair options, it is not always possible to repair a database without 

data loss. Usually, the best option for database recovery is to restore the database. This means that the 

execution of DBCC CHECKDB should be synchronized with your backup retention policy, to make sure 

that you can always restore a database from an uncorrupted database and that all required log backups 

since that time are available. 

Online Concurrent Operations 

DBCC CHECKDB can take a long time to execute and consumes considerable I/O and CPU resources. For 

this reason, DBAs often need to run it while the database is in use. 

In versions of SQL Server prior to SQL Server 2005, it was possible to receive indications of corruption 

where no corruption was present if DBCC CHECKDB was executed while the database was being used 

concurrently by other users. Since SQL Server 2005, DBCC CHECKDB operates using internal database 

snapshots to make sure that the utility works with a consistent view of the database. If DBCC CHECKDB 

reports corruption, it needs to be investigated. 

If the performance needs for the database activity that needs to run while DBCC CHECKDB is executing 

are too high, running DBCC CHECKDB against a restored backup of your database would be a better (but 

far from ideal) option than not running DBCC CHECKDB at all. 

Disk Space 

The use of an internal snapshot causes DBCC CHECKDB to need additional disk space. DBCC CHECKDB 

creates hidden files (using NTFS Alternate Streams) on the same volumes as the database files are located. 

Sufficient free space on the volumes must be available for DBCC CHECKDB to run successfully. The 

amount of disk space required on the volumes depends upon how much data is changed during the 

execution of DBCC CHECKDB. 

DBCC CHECKDB also uses space in tempdb while executing. To provide an estimate of the amount of 

space required in tempdb, DBCC CHECKDB offers an ESTIMATEONLY option.

Backups and DBCC CHECKDB 


It is considered a good practice to run DBCC CHECKDB on a database prior to performing a backup of the 

database. This check helps to ensure that the backup contains a consistent version of the database. 

Question: Why is it vital to run DBCC CHECKDB regularly?


DBCC CHECKDB Options 

Key Points 

DBCC CHECKDB provides a number of options that alter its behavior while it is executing. 

• The PHYSICAL_ONLY option is often used on production systems because it substantially reduces the 

time taken to run DBCC CHECKDB on large databases. If you regularly use the PHYSICAL_ONLY 

option, you still need to periodically run the full version of the utility. How often you perform the full 

version would depend upon specific business requirements. 

• The NOINDEX option specifies that intensive checks of nonclustered indexes for user tables should 

not be performed. This also decreases the overall execution time but does not affect system tables 

because integrity checks are always performed on system table indexes. The assumption that you are 

making when using the NOINDEX option is that you can rebuild the nonclustered indexes if they 

become corrupt. 

• The EXTENDED_LOGICAL_CHECKS can only be performed when the database is in database 

compatibility level 100 (SQL Server 2008) or above. It performs detailed checks of the internal 

structure of objects such as CLR user-defined data types and spatial data types. 

• The TABLOCK option is used to request that DBCC CHECKDB takes a table lock on each table while 

performing consistency checks rather than using the internal database snapshots. This reduces the 

disk space requirements at the cost of preventing other users from updating the tables. 

• The ALL_ERRORMSGS and NO_INFOMSGS options only affect the output from the command but not 

the operations performed by the command. 

• The ESTIMATEONLY option estimates the space requirements in tempdb as discussed in the previous 

topic. 

Question: Which DBCC CHECKDB option might be used on very large production systems?

DBCC CHECKDB Repair Options 

Key Points 


As well as providing details of errors that have been found, the output of DBCC CHECKDB shows the 

repair option that would be needed to correct the problem. In the example on the slide, four consistency 

errors were found and the REPAIR_ALLOW_DATA_LOSS option would be needed to repair the database. 

Repair Options 

DBCC CHECKDB offers two repair options. For both options, the database needs to be in single user 

mode. The options are: 

• REPAIR_REBUILD rebuilds indexes. Corrupt data pages are removed. This option only works with 

certain mild forms of corruption and does not involve data loss. 

• REPAIR_ALLOW_DATA_LOSS will almost always produce data loss. It deallocates the corrupt pages 

and changes other pages that reference the corrupt pages. After the operation is complete, the 

database will be consistent, but only from a physical database integrity point of view. Significant loss 

of data could have occurred. Repair operations also do not consider any of the constraints that may 

exist on or between tables. If the specified table is involved in one or more constraints, it is 

recommended that you execute DBCC CHECKCONSTRAINTS after the repair operation is complete. 

The use of DBCC CHECKDB is shown in Demonstration 1A. 

You should backup a database before performing any repair option. Repairing a database should be an 

option of last resort. When a database is corrupt, it is typically better to restore the database from a 

backup, after solving the cause of the corruption. Unless you find and resolve the reason for the 

corruption, it may well happen again soon after. Corruption in SQL Server databases is mostly caused by 

failures in I/O or memory subsystems.


Transaction Log Corruption 

If the transaction log becomes corrupt, a special option called an emergency mode repair can be 

attempted, but it is strongly recommended to restore the database in that situation. An emergency mode 

repair should only be used when no backup is available. 

Question: Why would it be preferable to restore a database rather than using 

REPAIR_ALLOW_DATA_LOSS?

Demonstration 1A: Using DBCC CHECKDB 













Lesson 2 

Maintaining Indexes 

Another important aspect of SQL Server that requires ongoing maintenance for optimal performance is 

the management of indexes. Indexes are used to speed up operations where SQL Server needs to access 

data in a table. Over time, indexes can become fragmented and the performance of database applications 

that use the indexes will be reduced. Defragmenting or rebuilding the indexes will restore the 

performance of the database. 

Index management options are often included in regular database maintenance plan schedules. Before 

learning how to set up the maintenance plans, it is important to understand more about how indexes 

work and how they are maintained. 

Objectives 


• Describe how indexes affect performance. 

• Describe the different types of SQL Server indexes. 

• Describe how indexes become fragmented. 

• Use FILLFACTOR and PAD_INDEX. 

• Explain the ongoing maintenance requirements for indexes. 

• Implement online index operations. 

• Describe how statistics are created and used by SQL Server.

How Indexes Affect Performance 

Key Points 


SQL Server can access data in a table by reading all the pages of the table (known as a table scan) 

or by using index pages to locate the required rows. 

Indexes 

Whenever SQL Server needs to access data in a table, it makes a decision about whether to read all the 

pages of the table or whether there are one or more indexes on the table that would reduce the amount 

of effort required in locating the required rows. 

Queries can always be resolved by reading the underlying table data. Indexes are not required but 

accessing data by reading large numbers of pages is usually considerably slower than methods that use 

appropriate indexes. 

Indexes can help to improve searching, sorting, and join performance but they can impact data 

modification performance, they require ongoing management, and they require additional disk space. 

On occasion, SQL Server will create its own temporary indexes to improve query performance. However, 

doing so is up to the optimizer and beyond the control of the database administrator or programmer, so 

these temporary indexes will not be discussed in this module. The temporary indexes are only used to 

improve a query plan, if no proper indexing already exists. 

In this module, you will consider standard indexes created on tables. SQL Server includes other types of 

index: 

• Integrated full-text search (iFTS) uses a special type of index that provides flexible searching of text. 

• Spatial indexes are used with the GEOMETRY and GEOGRAPHY data types. 

• Primary and secondary XML indexes assist when querying XML data.


• Columnstore indexes are used typically used in large data warehouses. The tables essentially become 

read-only while the columnstore indexes are in place. 

Note iFTS, Spatial, XML indexes, and Columnstore indexes are out of scope for this course 

but iFTS, Spatial, and XML indexes are described in course 10776A: Developing Microsoft 

SQL Server 2012 Databases, along with greater detail on standard clustered and 

nonclustered indexes. 

Question: When might a table scan be more efficient than using an index?

Types of SQL Server Indexes 

Key Points 


Rather than storing rows of a data as a heap, tables can be designed with an internal logical ordering. This 

is known as a clustered index. 

Clustered Index 

A table with a clustered index has a predefined order for rows within a page and for pages within the 

table. The order is based on a key made up of one or more columns. The key is commonly called a 

clustering key. 

Because the rows of a table can only be in a single order, there can be only a single clustered index on a 

table. An Index Allocation Map entry is used to point to a clustered index. Clustered indexes are always 

index id = 1. 

There is a common misconception that pages in a clustered index are "physically stored in order". While 

this is possible in rare situations, it is not commonly the case. If it was true, fragmentation of clustered 

indexes would not exist. SQL Server tries to align physical and logical order while creating an index but 

disorder can arise as data is modified. 

Index and data pages are linked within a logical hierarchy and also double-linked across all pages at the 

same level of the hierarchy to assist when scanning across an index. For example, imagine a table with ten 

extents and with allocated page numbers 201 to 279 all linked in order. (Each extent contains eight 

pages). If a page needed to be placed into the middle of the logical order, SQL Server finds an extent with 

a free page or allocates a new extent for the index. The page is logically linked into the correct position 

but it could be located anywhere within the database pages.


Nonclustered Index 

A nonclustered index is a type of index that does not affect the layout of the data in the table in the way 

that a clustered index does. 

If the underlying table is a heap (that is, it has no clustered index), the leaf level of a nonclustered index 

contains pointers to where the data rows are stored. The pointers include a file number, a page number, 

and a slot number on the page. 

If the underlying table has a clustered index (that is, the pages and the data are logically linked in the 

order of a clustering key), the leaf level of a nonclustered index contains the clustering key that is then 

used to seek through the pages of the clustered index to locate the desired rows.

Index Fragmentation 

Key Points 


Index fragmentation is the inefficient use of pages within an index. Fragmentation occurs over time as 

data is modified. 

Index Fragmentation 

For operations that read data, indexes perform best when each page of the index is as full as possible. 

While indexes may initially start full (or relatively full), modifications to the data in the indexes can cause 

the need to split index pages. Adding a new index entry to the end of an index is easy but the process is 

more complicated if the entry needs to be made in the middle of an existing full index page. 

Internal vs. External Fragmentation 

Internal fragmentation occurs when pages are not holding as much data as they are capable of holding. 

This often occurs when a page is split during an insert operation and can also occur when an update 

operation causes a row to be moved to another page. In either situation, empty space is left within pages. 

External fragmentation occurs when pages that are logically sequenced are not held in sequenced page 

numbers. If a new index page needs to be allocated, it would be logically inserted into the correct location 

in the list of pages but could well be placed at the end of the index. That means that a process that needs 

to read the index pages in order would need to follow pointers to locate the pages and the process would 

involve accessing pages that are not sequential within the database. 

Detecting Fragmentation 

SQL Server provides a useful measure in the avg_fragmentation_in_percent column of the 

sys.dm_db_index_physical_stats dynamic management view.


SQL Server Management Studio also provides details of index fragmentation in the properties page for 

each index as shown in the following screenshot from the AdventureWorks database: 

Question: Why does fragmentation affect performance?

FILLFACTOR and PAD_INDEX 

Key Points 


The FILLFACTOR and PAD_INDEX options are used to provide free space within index pages. This can 

improve INSERT and UPDATE performance in some situations but often to the detriment of SELECT 

operations. 

FILLFACTOR and PAD_INDEX 

The availability of free space in an index page can have a significant effect on the performance of index 

update operations. If an index record must be inserted and there is no free space, a new index page must 

be created and the contents of the old page split across the two pages. This can affect performance if it 

happens too frequently. 

The performance impacts of page splits can be alleviated by leaving empty space on each page when 

creating an index, including a clustered index. This is achieved by specifying a FILLFACTOR value. 

FILLFACTOR defaults to 0, which means "fill 100%". Any other value (including 100) is taken as the 

percentage of how full each page should be. For the example in the slide, this means 70% full and 30% 

free space on each page. 

Note The difference between the values 0 and 100 can seem confusing. While both values 

lead to the same outcome, 100 indicates that a specific FILLFACTOR value has been 

requested. The value 0 indicates that no FILLFACTOR has been specified.


FILLFACTOR only applies to leaf level pages in an index. PAD_INDEX is an option that, when enabled, 

causes the same free space to be allocated in the non-leaf levels of the index. 

Question: While you could avoid many page splits by setting a FILLFACTOR of 50, what 

would be the downside of doing this? 

Question: When would a FILLFACTOR of 100 be useful? 

Question: What is the significance of applying a FILLFACTOR on a clustered index versus a 

non-clustered index?

Ongoing Maintenance of Indexes 

Key Points 


As indexes are updated during data modifications, over time the indexes can become fragmented. SQL 

Server provides two options for removing fragmentation from clustered and nonclustered indexes: 

• Rebuild 

• Reorganize 

Rebuild 

Rebuilding an index drops and re-creates the index. This removes fragmentation, reclaims disk space by 

compacting the pages based on the specified or existing fill factor setting, and reorders the index rows in 

contiguous pages. When the option ALL is specified, all indexes on the table are dropped and rebuilt in a 

single operation. If any part of the operation fails, the entire operation is rolled back. 

Because rebuilds are performed as single operations and are logged, a single rebuild operation can use a 

large amount of space in the transaction log. It is possible to perform the rebuild operation as a 

minimally-logged operation when the database is in BULK_LOGGED or SIMPLE recovery model. A 

minimally-logged rebuild operation uses much less space in the transaction log and completes faster. 

Free space needs to be available when rebuilding indexes. 

Reorganize 

Reorganizing an index uses minimal system resources. It defragments the leaf level of clustered and 

nonclustered indexes on tables by physically reordering the leaf-level pages to match the logical, left to 

right order of the leaf nodes. Reorganizing an index also compacts the index pages. The compaction is 

based on the existing fill factor value. It is possible to interrupt a reorganize without losing the work 

performed so far. For example, this means that on a large index, partial reorganization could be 

performed each day.


For heavily fragmented indexes (> 30%) rebuilding is usually the most appropriate option to use. 

SQL Server maintenance plans include options to rebuild or reorganize indexes. If maintenance plans are 

not used, it is important to build a job that performs defragmentation of the indexes in your databases. 

Question: What is typically the best option to defragment big indexes and tables (clustered 

indexes)?

Online Index Operations 

Key Points 


For most organizations, the primary reason for purchasing the Enterprise edition of SQL Server is that 

those editions can perform index operations online, while users are accessing the database. This is very 

important because many organizations have no available maintenance time windows during which to 

perform database maintenance operations such as index rebuilds. 

When performing an online index rebuild operation, SQL Server creates a temporary mapping index that 

tracks data changes that occur while the index rebuild operation is occurring. For consistency, SQL Server 

takes a very brief shared lock on the object at the beginning of the operation and again at the end. 

During the online rebuild operation, schema locks are held to prevent metadata changes. This means that 

users cannot change the structure of the table using commands such as ALTER TABLE while the online 

index rebuild operation is occurring. 

Because of the extra work that needs to be performed, online index rebuild operations are typically slower 

than their offline counterparts. 

Note Some indexes cannot be rebuilt online, including clustered indexes with large object 

data or nonclustered indexes that include large object data. 

Question: When would online index operations be most important?


Updating Statistics 

Key Points 

One of the main tasks performed by SQL Server when it is optimizing queries that it needs to execute, is 

deciding which indexes to use. SQL Server makes decisions about which indexes to use based upon 

statistics that it keeps about the distribution of the data in the index. 

Statistics should mostly be updated automatically by SQL Server and AUTO_UPDATE_STATISTICS is 

enabled in all databases by default. It is recommended that you do not disable this option. 

Alternatives to Auto-updating Statistics 

For large tables, the AUTO_UPDATE_STATISTICS_ASYNC option instructs SQL Server to update statistics 

asynchronously instead of delaying query execution, where it would have otherwise updated an outdated 

statistic that it required for query compilation. 

Statistics can also be updated on demand. Executing the command UPDATE STATISTICS against a table 

causes all statistics on the table to be updated. 

The system stored procedure sp_updatestats can be used to update all statistics in a database. 

Question: Why might you decide to update statistics out of hours instead of automatically?

Demonstration 2A: Maintaining Indexes 















Lesson 3 

Automating Routine Database Maintenance 

You have now seen how to manually perform some of the common database maintenance tasks that 

need to be executed on a regular basis. SQL Server provides a Database Maintenance Plan Wizard that 

can be used to create SQL Server Agent jobs that perform the most common database maintenance tasks. 

While the Database Maintenance Plan Wizard makes this process easy to set up, it is important to realize 

that you could use the output of the wizard as a starting point for creating your own maintenance plans, 

or you could create plans from scratch. 

Objectives 


• Configure SQL Server database maintenance plans. 

• Monitor database maintenance plans.

Overview of SQL Server Database Maintenance Plans 

Key Points 


The SQL Server Maintenance Plan Wizard creates SQL Server Agent jobs that perform routine database 

maintenance tasks and schedules those jobs to ensure that your database is regularly backed up, performs 

well, and is checked for inconsistencies. The wizard creates SQL Server Integration Services packages that 

are executed by SQL Server Agent tasks. 

You can schedule many maintenance tasks to run automatically, including: 

• Backing up the database and transaction log files. Database and log backups can be retained for a 

specified period and then automatically deleted. 

• Running SQL Server Agent jobs that perform a variety of actions. 

• Compacting data files by removing empty database pages. 

• Performing internal consistency checks of the data and data pages within the database to make sure 

that a system or software problem has not damaged data. 

• Reorganizing the information on the data pages and index pages by rebuilding indexes. 

• Updating index statistics to make sure the query optimizer has up-to-date information about the 

distribution of data values in the tables. 

Note Maintenance plans can be created using one schedule for all tasks or with individual 

schedules for every selected task. 

Question: What types of maintenance tasks should be automated?


Monitoring Database Maintenance Plans 

Key Points 

SQL Server database maintenance plans are implemented using SQL Server Agent jobs that run SQL 

Server Integration Services (SSIS) packages. Because they use SQL Server Agent jobs, the maintenance 

plans can be monitored using the standard Job Activity Monitor in SSMS. As with other SQL Server Agent 

jobs, job history is written but maintenance plans record additional information. 

Results from Maintenance Plans 

The results generated by the maintenance tasks are written to the maintenance plan tables 

dbo.sysmaintplan_log and dbo.sysmaintplan_log_detail in the msdb database. The entries in these tables 

can be viewed by querying those tables directly using T-SQL or by using the Log File Viewer. 

In addition, text reports can be written to the file system and can also be sent automatically to operators 

that have been defined in SQL Server Agent. 

Note that the cleanup tasks that are part of the maintenance plans are used to implement a retention 

policy for backup files, job history, maintenance plan report files, and msdb database table entries. 

Question: Are maintenance plan history records cleaned up automatically?


Demonstration 3A: Configuring a Database Maintenance Plan 














Lab 16: Performing Ongoing Database Maintenance 

Lab Setup 













Lab Scenario 

There has been a disk failure in the I/O subsystem. The disk has been replaced but you want to check the 

consistency of your existing databases. You will execute DBCC CHECKDB to verify the logical and physical 

integrity of all databases on the Proseware instance. 

You have identified fragmentation in a number of tables in the MarketDev database and you are sure that 

performance is decreasing as the amount of fragmentation increases. You will rebuild the indexes for any 

of the main database tables that are heavily fragmented.


You have also identified a degradation of performance in the application when proper index maintenance 

has not been performed. You want to ensure that there is an early detection of any consistency issues in 

the MarketDev database and that the index maintenance is automatically executed on a scheduled basis. 

To make sure this regular maintenance occurs, you will create a Database Maintenance plan to schedule 

these operations on a weekly basis. 

While DBCC CHECKDB runs quite quickly, you are interested in the performance difference that might be 

achieved by using table locks instead of database snapshots during DBCC CHECKDB operations. If you 

have time, you will investigate the performance differences. 


Database Maintenance Plan Requirements 

Item Configuration 

Plan Name Proseware Weekly Maintenance 

Schedule Once per week for all tasks at 6PM Sunday night 

Tasks required Check Database Integrity for all databases on the Proseware 

server instance 

Rebuild indexes in the MarketDev database 

Notes The database integrity checks should include indexes 

When indexes in the MarketDev database are rebuilt, pages in 

the indexes should be 90% full 

As Proseware uses an Enterprise Edition license, online index 

rebuilds are supported and should be used 

Reports should be written to the folder L:\MKTG 

Exercise 1: Check Database Integrity Using DBCC CHECKDB 

Scenario 

There has been a disk failure in the I/O subsystem. The disk has been replaced but you want to check the 

consistency of your existing databases. You will execute DBCC CHECKDB to verify the logical and physical 

integrity of all databases on the Proseware instance. 


1. Check the consistency of the databases on the Proseware instance. 

2. Correct any issues found.


Task 1: Check the consistency of the databases on the Proseware instance 

• Execute DBCC CHECKDB against all databases on the Proseware server instance. Note any databases 

that have errors. 

Task 2: Correct any issues found 

• For any databases with errors, using the DBCC option to repair while allowing data loss. (Note that 

this is an extreme action that should only be undertaken in emergency situations where no backups 

are available to be restored). 

Results: After this exercise, you should have used the DBCC CHECKDB command to check 

consistency on all databases on the Proseware instance and corrected any issues that were 

found. 

Exercise 2: Correct Index Fragmentation 

Scenario 

You have identified fragmentation in a number of tables in the MarketDev database and you are sure that 

performance is decreasing as the amount of fragmentation increases. You will rebuild the indexes for any 

of the main database tables that are heavily fragmented. 


1. Review the fragmentation of indexes in the MarketDev database to determine which indexes should 

be defragmented and which indexes should be rebuilt. 

2. Defragment indexes as determined. 

3. Rebuild indexes as determined. 

Task 1: Review the fragmentation of indexes in the MarketDev database to determine 

which indexes should be defragmented and which indexes should be rebuilt 

• Write a query using sys.dm_db_index_physical_stats function to locate indexes that have more than 

30% fragmentation. 

Task 2: Defragment indexes as determined 

• Write a query to defragment the indexes that you determined had fragmentation levels above 30% 

but below 70%. 

Task 3: Rebuild indexes as determined 

• Write a query to rebuild the indexes that you determined had fragmentation levels above 70% 

Results: After this exercise, you should have rebuilt or defragmented any indexes 

with substantial fragmentation.

Exercise 3: Create a Database Maintenance Plan 

Scenario 


You have also identified a degradation of performance in the application when proper index maintenance 

has not been performed. You want to ensure that there is an early detection of any consistency issues in 

the MarketDev database and that the index maintenance is automatically executed on a schedule basis. 

To make sure this regular maintenance occurs, you will create a Database Maintenance plan to schedule 

these operations on a weekly basis. 


1. Create the required database maintenance plan. 

Task 1: Create the required database maintenance plan 

• Review the requirements for the exercise in the supporting documentation. 

• Create a database maintenance plan that meets the requirements. 

Results: After this exercise, you should have created the required database 

maintenance plan. 

Challenge Exercise 4: Investigate Table Lock Performance (Only if time 

permits) 

Scenario 

While DBCC CHECKDB runs quite quickly, you are interested in the performance difference that might be 

achieved by using table locks instead of database snapshots during DBCC CHECKDB operations. If you 

have time, you will investigate the performance differences. 


1. Execute DBCC CHECKDB using database snapshots. 

2. Execute DBCC CHECKDB using table locks. 

Task 1: Execute DBCC CHECKDB using database snapshots 

• Execute DBCC CHECKDB against all databases in the Proseware server instance using database 

snapshots (the default option). 

• Record the total execution time. 

Task 2: Execute DBCC CHECKDB using table locks 

• Execute DBCC CHECKDB against all databases in the Proseware server instance using table locks 

(TABLOCK option). 

• Record the total execution time. 

• Compare the execution time to the time recorded in Task 1. 

Results: After this exercise, you should have compared the performance of DBCC 

CHECKDB when using database snapshots and table locks.




1. What regular tasks should be implemented for read only databases? 

2. What option should you consider using when running DBCC CHECKDB against large production 

databases? 


1. Run DBCC CHECKDB regularly. 

2. Synchronize DBCC CHECKDB with your backup strategy. 

3. Consider RESTORE before repairing if corruption occurs. 

4. Defragment your indexes when necessary. 

5. Update statistics on schedule, if you don’t want it to occur during normal operations. 

6. Use Maintenance Plans to implement regular tasks.

Module 17 

Tracing Access to SQL Server 2012 

Contents: 

Lesson 1: Capturing Activity Using SQL Server Profiler and Extended 

Events Profiler 17-3 

Lesson 2: Improving Performance with the Database Engine Tuning 

Advisor 17-17 

Lesson 3: Working with Tracing Options 17-25 

Lab 17: Tracing Access to SQL Server 2012 17-36 

17-1

17-2 Tracing Access to SQL Server 2012 


Microsoft® SQL Server® performs well with many types of SQL workloads but the performance of most 

SQL Server systems can be improved by a process of tuning queries and database structures. For most 

large organizations, performance tuning is not a task that is performed once and completed. Performance 

tuning typically involves a process of continuous incremental improvements. 

It is important to spend most of your performance tuning efforts where the effort will provide the greatest 

benefit. Developers will often guess how their applications will be used and try to optimize the 

applications based on those guesses. The ability to trace activity against a SQL Server removes the 

guesswork from this process and allows you to focus your efforts on the areas of the applications that 

users are actually using. 

SQL Server Profiler and Extended Events Profiler are used to capture traces of activity against SQL Server. 

The Database Engine Tuning Advisor can be used to analyze the traces captured by SQL Server Profiler 

and to suggest improvements that can be made, particularly in relation to indexes and statistics. 

Objectives 


• Capture activity using SQL Server Profiler and Extended Events Profiler. 

• Improve performance with the Database Engine Tuning Advisor. 

• Work with tracing options.


Lesson 1 

Capturing Activity Using SQL Server Profiler and Extended 

Events Profiler 

SQL Server Profiler and Extended Events Profiler provide you with the ability to trace the activity that is 

occurring in the database engine within SQL Server. SQL Server Profiler can also trace activity against 

Analysis Services. (The tracing of Analysis Services activity is out of scope for this training). 

Traces can be used for performance tuning, for troubleshooting and diagnostic purposes, and for 

replaying workloads. The ability to replay a workload allows you to test the impact of performance 

changes against test systems or to test application workloads against newer versions of SQL Server. 

It is important to learn to configure these tools, to avoid creating excessive impacts from the tracing 

process itself. 

Objectives 


• Use SQL Server Profiler. 

• Describe available tracing output options. 

• Detail commonly used trace events. 

• Detail commonly used trace columns. 

• Filter traces. 

• Work with trace templates. 

• Use Extended Events Profiler.


Overview of SQL Server Profiler 

Key Points 

SQL Server Profiler is an important tool when tuning the performance of SQL Server queries. It captures 

the activity from client applications to SQL Server and stores it in a trace. These traces can then be 

analyzed. 

SQL Server Profiler 

SQL Server profiler captures data when events occur. Only events that have been selected are captured. A 

variety of information (shown as a set of columns) is available when each event occurs. The trace created 

contains only the selected columns for the selected events. 

Rather than needing to select events and columns each time you run SQL Server Profiler, a set of existing 

templates are available. You can also save your own selections as a new template. 

The captured traces are useful when tuning the performance of an application and when diagnosing 

specific problems that are occurring. When using traces for diagnosing problems, log data from the 

Windows Performance Monitor tool can be loaded. This allows relationships between system resource 

impacts and the execution of queries in SQL Server to be made. 

The traces can also be replayed. The ability to replay traces is useful for load testing systems or for 

ensuring that upgraded versions of SQL Server can be used with existing applications. SQL Server Profiler 

also allows you to step through queries when diagnosing problems.

SQL Trace 


SQL Server Profiler is a graphical tool and it is important to realize that it can have significant performance 

impacts on the server being traced, depending upon the options chosen. SQL Trace is a library of system 

stored procedures that can be used for tracing when minimizing the performance impacts of the tracing is 

necessary. Internally, SQL Server Profiler uses the programming interface that has been provided by SQL 

Trace. 

Note The Extended Events system that was introduced in SQL Server 2008 also provides 

capabilities for tracing SQL Server activity and resources. The use of Extended Events for 

tracing activity is discussed later in this lesson. The use of Extended Events for other 

monitoring purposes is outside the scope of this course. 

Question: Where would the ability to replay a trace be useful?


Available Tracing Output Options 

Key Points 

When a SQL Server Profiler trace is active, the captured events are loaded into a graphical grid within the 

SQL Server Profiler user interface. 

In addition, SQL Server Profiler can send the captured event details to either operating system files or to 

database tables. 

Capture to Files 

Capturing to an operating system file is the most efficient option for SQL Server Profiler traces. When 

configuring file output, you need to supply a filename for the trace. The default file type for a trace file is 

".trc". SQL Server Profiler defaults to a file size of 5MB which is far too small for most traces. A more 

realistic value on most large systems would be either 500MB or 5000MB, depending upon the volume of 

activity that needs to be recorded. 

When the allocated file size is exhausted, SQL Server Profiler will open a new file based on a variation of 

the current file name and start writing to it, if the "Enable file rollover" option has been checked. It is 

considered good practice to work with a large maximum file size and to avoid the need for rollover files, 

unless there is a need to move the captured traces onto media such as DVDs or onto download sites that 

cannot work with larger files. 

Selecting the "Server processes trace data" option causes the SQL Server service to write the output file 

instead of the client system that is running SQL Server Profiler. Using this option can enhance 

performance but requires access to the server's filesystem.

Capturing to Tables 


SQL Server Profiler can also capture trace data to database tables. The underlying SQL Trace 

programming interface does not directly support output to tables. This means that the SQL Server Profiler 

program needs to retrieve the event data into its graphical grid and as batches of rows are received, SQL 

Server Profiler then writes those rows to the selected database table. 

Note It is very important to avoid writing trace data directly back to the SQL Server 

system that is being monitored, unless a very low level of activity is expected. 

SQL Server Profiler also provides an option for saving existing captured event data that is being displayed 

in the graphical grid into a database table. 

Question: What might be an advantage of saving events in a SQL Server table?


Commonly Used Trace Events 

Key Points 

The information recorded in a trace is divided into categories. Categories contain events, each of which 

has attributes further defined by columns. 

Trace Categories 

In SQL Server Profiler, a category is a group of related event classes. Event classes consist of types of 

events that can be traced. The event class contains all the data columns that can be reported by an event. 

Events 

An event is defined as the occurrence of an action within an instance of the SQL Server Database Engine. 

Events are further defined by their attributes, which are listed in data columns. 

The most commonly traced events are as follows: 

Event Description 

SQL:BatchCompleted When a batch of T-SQL statements is completed, the 

SQL:BatchCompleted event is fired. Note that there is also an event 

raised when the batch is first started but the completed event 

contains more useful information such as details of the resources 

used during the execution of the batch. 

SQL:StmtCompleted If tracing at the SQL batch level is too coarse, it is possible to 

retrieve details of each individual statement that is contained 

within the batch.

(continued) 

Event Description 


RPC: Completed The RPC:Completed event is fired when a stored procedure finishes 

execution. There is a traceable event when the stored procedure 

starts but similar to the SQL:BatchCompleted event, the 

RPC:Completed event is useful as it contains details of the resources 

used during the execution of the stored procedure. You can see a 

statement by statement breakdown of resources used within the 

stored procedure via the SP:StmtCompleted event. 

Audit Login / Audit 

Logout 

You can include in your traces details of each login and logout 

event that occurs during the tracing activity. 

Deadlock Graph Unhandled deadlocks often lead to errors being passed to end users 

from applications. If your system is suffering from deadlocks, the 

Deadlock Graph event fires when deadlocks occur and captures 

details of what caused the deadlock. The details are captured into 

an XML document that can be viewed graphically within SQL Server 

Profiler. 

Question: Why would events that are raised on completion of batches or statements often 

be more interesting than events that are raised when batches or statements start?


Commonly Used Trace Columns 

Key Points 

Data columns contain the attributes of events. SQL Server Profiler uses data columns in the trace output 

to describe events that are captured when the trace runs. 

SQL Server Profiler has a large set of potential columns but not every event writes values to all the 

possible columns. For example, in the SQL:BatchStarting event, the columns Reads, Writes, Duration, and 

CPU are not available because the values are not available at the time of the event. Those columns are 

available in the SQL:BatchCompleted event. 

Note The output in the SQL Server Profiler graphical grid can be grouped based on based 

on column values. 

You should minimize the number of columns that you capture when events occur, to help to minimize the 

overall size of the trace that is captured. 

You can also organize columns into related groups by using the Organize Columns function.

Useful Columns Often Omitted 


One of the more interesting columns is the TextData column. Many events do not include it by default yet 

the values contained in it are very useful. For example, in the RPC:Completed event, the TextData column 

contains the T-SQL statement that was used to execute the stored procedure. 

Two other useful columns are the database ID and the database name. You will often need to create a 

filter based on the database that you want to trace activity against. Tracing by database ID is more 

efficient than tracing by database name. However, trace templates that filter by database ID are less 

portable than those that filter by database name because a database that is restored on another server 

will typically have a different database ID. You can also use wildcard values within the LIKE clause of a 

database name filter. 

Question: What information would the TextData column return?


Filtering Traces 

Key Points 

Filters can be set for each of the columns that are captured in a trace. It is important to ensure that you 

are only capturing events of interest by limiting the events via filters. Effective use of filters helps to 

minimize the overall size of the captured trace, helps to avoid overwhelming the server with tracing 

activity, and minimizes the number of events that are contained in the trace, which reduces complexity 

during analysis. Smaller traces are also typically faster to analyze. 

Filters are only applied if an event writes a particular column. For example if you set a filter for 

DatabaseName = AdventureWorks and define the event Deadlock Graph to be captured, all deadlock 

events will be shown as the DatabaseName column is not exposed by the Deadlock Graph event. 

Question: What filter would you use to locate long running batches or statements?

Working with Trace Templates 

Key Points 


You can use SQL Server Profiler to create templates that define the event classes and data columns to 

include in traces. After you define and save the template, you can run a trace that records the data for 

each event class you selected. 

Templates can be generated within SQL Server Profiler by creating a trace using the graphical interface, 

starting and stopping the trace at least once and then using File > Save as > Trace Template. 

SQL Server Profiler offers predefined trace templates that allow you to easily configure the event classes 

that you need for specific types of traces. The Standard template, for example, helps you to create a 

generic trace for recording logins, logouts, batches completed, and connection information. You can use 

this template to run traces without modification or as a starting point for additional templates with 

different event configurations. 

Question: How do SQL Server Profiler templates help you trace activity?


Demonstration 1A: Capturing Activity Using SQL Server Profiler 











Question: Why is there only one Batch Starting event and one Batch Completed event for 

the workload we ran?

Working with Extended Events Profiler 

Key Points 


SQL Server 2012 introduces a new tool for managing sessions that capture events as they occur, based 

upon the Extended Events infrastructure that was introduced in SQL Server 2008. It is the same 

technology that underpins SQL Server Audit. 

Extended Events Profiler is integrated directly into SQL Server Management Studio and can be used to 

capture activity in the SQL Server database engine in much the same way that you can use SQL Server 

Profiler. 

Over time, Extended Events Profiler will replace SQL Server Profiler as the tool of choice for tracing activity 

in SQL Server. In this version, the two tools have intersecting feature sets and both will likely continue to 

be used.


Demonstration 1B: Capturing Activity Using Extended Events Profiler 













Lesson 2 

Improving Performance with the Database Engine Tuning 

Advisor 

Tuning the performance of a SQL Server system is one of the most important tasks undertaken by 

database administrators. As mentioned earlier in this module, performance tuning tends to be an ongoing 

process, not a one-time task. 

It is important to follow a standard methodology for performance tuning. SQL Server includes many tools 

that can help with performance tuning, including the Database Engine Tuning Advisor (DETA). It is 

important to know how to configure and use DETA. 

Objectives 


• Explain performance tuning. 

• Describe the available options for performance tuning. 

• Use Database Engine Tuning Advisor. 

• Describe the available DETA tuning options.


Overview of Performance Tuning 

Key Points 

Performance tuning is an iterative process of incremental improvement made on an ongoing basis. 

First of all, it is important to define an initial goal based on any problems that might be apparent. "It 

needs to be faster" is not usually a well enough defined goal. Based on the chosen goal, you then need to 

select the appropriate tools to monitor the system and provide the metrics that will help you reach the 

goal. SQL Server provides a number of tools to help with this phase. (An overview of the available tools 

will be provided in the next topic). 

In the chosen tools, you need to identify the metrics that you will use, from the list of available metrics. A 

baseline needs to be created via monitoring and a decision made about the changes to implement. 

Based on the results, a strategy is then developed to overcome the issues that have been detected. The 

strategy is then implemented, the results are monitored and the process begins again. 

Work On Causes Rather Than Symptoms 

A key concept when performance tuning is that you need to try to find the underlying causes of 

problems, rather than constantly battling against the symptoms. For example, a client might ask you to 

help resolve a blocking issue. It is often the case that excessive blocking occurs because of long running 

queries. By fixing the queries and indexing so that the queries run quickly, the blocking issues often 

disappear. 

As another common example, systems often appear to have I/O performance problems yet in many cases, 

this could be caused by the lack of available memory in the system. 

Question: When would you know that performance tuning is complete?

Available Options for Performance Tuning 

Key Points 


SQL Server provides a number of tools that can be used to perform performance monitoring and tuning. 

Each of them is useful in certain scenarios and you will often need to combine several tools to achieve the 

desired outcome. 

Tool Description & Location 

Database Engine Tuning Advisor Tool provided with SQL Server for tuning indexes and 

statistics. DETA is discussed in this lesson. 

SSMS Core management tool provided with SQL Server. 

Aspects that are useful in performance tuning (activity 

monitor, standard and custom reports) are discussed in 

Module 18. 

Dynamic Management Objects Database objects that provide insight into internal SQL 

Server operations. Many useful DMOs are discussed in 

Module 18.


(continued) 

Tool Description & Location 

SQL Server Data Collection Automated system for collecting and storing 

performance data along with a set of standard reports. 

Data collection is discussed in Module 18. 

SQL Server Profiler Tracing and profiling tool that was discussed in the first 

lesson in this module. 

SQL Trace Programming interface for tracing SQL Server access 

that is discussed in the last lesson in this module. 

SQL Server Extended Events Light-weight eventing architecture. You have seen how 

to use Extended Events Profiler to capture server activity. 

Working directly with Extended Events (not via a GUI 

interface) is out of scope for this training. 

Distributed Relay Advanced tool for replaying workloads across a 

potentially distributed set of servers. Distributed Relay is 

out of scope for this training. 

Reliability and Performance 

Monitor 

Standard Windows performance tool that is discussed in 

Module 18. 

Question: Which tools might be useful for real time monitoring?

Introduction to the Database Engine Tuning Advisor 

Key Points 


The Database Engine Tuning Advisor utility analyzes the performance effects of workloads run against one 

or more databases. Typically these workloads are obtained from traces captured by SQL Server Profiler or 

the SQL Trace facility. (SQL Trace is discussed later in the next lesson). After analyzing the effects of a 

workload on your databases, Database Engine Tuning Advisor provides recommendations for improving 

the performance of your system. 

Database Engine Tuning Advisor 

In SQL Server 2000 and earlier, a previous version of this tool was supplied. It was called the "Index Tuning 

Wizard". In SQL Server 2005, the name was changed as the tool evolved to be able to provider a broader 

range of recommendations. 

Database Engine Tuning Advisor was further enhanced in SQL Server 2008 with improved workload 

parsing, integrated tuning, and the ability to tune multiple databases concurrently. 

Workloads 

A workload is a set of Transact-SQL statements that executes against databases that you want to tune. The 

workload source can be a file containing Transact-SQL statements, a trace file generated by SQL Profiler, 

or a table of trace information, again generated by SQL Profiler. SQL Server Management Studio also has 

the ability to launch Database Engine Tuning Advisor to analyze an individual statement.


Recommendations 

The recommendations that can be produced include suggested changes to the database such as new 

indexes, indexes that should be dropped, and depending on the tuning options you set, partitioning 

recommendations. The recommendations that are produced are provided as a set of Transact-SQL 

statements that would implement the suggested changes. You can view the Transact-SQL and save it for 

later review and application, or you can choose to implement the recommended changes immediately. 

Be careful of applying changes to a database without detailed consideration, especially in production 

environments. Also, ensure that any analysis that you perform is based on appropriately sized workloads 

so that recommendations are not made based on partial information. 

Question: Why is it important to tune an entire workload rather than individual queries?

Database Engine Tuning Advisor Options 

Key Points 


DETA provides a rich set of configuration options that allow you to configure what analysis should be 

performed and how optimization recommendations should be made. 

Executing DETA on large workloads can take a long time, particularly on systems that also have large 

numbers of database objects. You can configure DETA to limit the time it will spend on analysis and to 

return the results that it has obtained up to the time limit. 

You can also configure which types of recommendations should be made, along with whether or not you 

wish to see recommendations that involve dropping existing objects. 

Exploratory Analysis 

Database administrators can use Database Engine Tuning Advisor also to perform exploratory analysis. 

Exploratory analysis involves a combination of manual tuning and tool-assisted tuning. To perform 

exploratory analysis with Database Engine Tuning Advisor, use the user-specified configuration feature. 

The user-specified configuration feature allows you to specify the tuning configurations for existing and 

hypothetical physical design structures, such as indexes, indexed views, and partitioning. The benefit of 

specifying hypothetical structures is that you can evaluate their effects on your databases without 

incurring the overhead of implementing them first. 

You can create an XML configuration file to specify a hypothetical configuration. The configuration can 

then be used for analysis. The analysis can be performed either in isolation or relative to the current 

configuration. This type of analysis can also be performed using a command line interface. 

Question: What is the disadvantage of limiting the analysis time?


Demonstration 2A: Using the Database Engine Tuning Advisor 

Demonstration Setup 











Question: Should you immediately apply the recommendations made by DETA to your 

server?

Lesson 3 

Working with Tracing Options 


In many larger organizations, you will not be able to use the graphical SQL Server Profiler tool in 

production environments as it places too high a load on the systems being profiled. 

It is still possible, however, to use the SQL Trace programming interface that is based on system stored 

procedures, to create lightweight traces. It is important to know how to use these traces in place of SQL 

Server Profiler and how to use SQL Server Profiler to help you to configure SQL Trace configurations. 

Objectives 


• Describe SQL Trace. 

• Describe the differences between SQL Trace and SQL Server Profiler. 

• Retrieve trace output. 

• Replay traces. 

• Use the default trace. 

• Combine traces with Reliability and Performance Monitor logs.


Overview of SQL Trace 

Key Points 

SQL Trace is a feature running within the database engine to create and run traces. Traces are managed 

using system stored procedures. Internally, SQL Server Profiler makes calls to the SQL Trace facility in SQL 

Server when SQL Server Profiler needs to create or manage traces. 

Traces run in the process of SQL Server database engine and can write events to a file or to an application 

using SQL Server Management Objects (SMO) objects. The information you learned about how events, 

columns, and filtering work in SQL Server Profiler is directly applicable to how the same objects work 

within SQL Trace. 

Implementing traces can at first appear difficult as you need to make many stored procedure calls to 

define and run a trace. However, the graphical interface in SQL Server Profiler can be used to create a 

trace and to then script the trace for use with SQL Trace. Very few changes typically need to be made to 

the SQL Trace script files that are created by SQL Server Profiler, such as the path to output files.

SQL Trace vs. SQL Server Profiler 

Key Points 


It is important to understand the differences between SQL Trace and SQL Server Profiler and to 

understand where each tool should be used. 

• SQL Trace needs to be defined using a series of system stored procedure calls whereas SQL Server 

Profiler provides a graphical interface for configuration and for controlling the tracing activity. 

• SQL Trace runs directly inside the database engine whereas SQL Server Profiler runs on a client system 

(or on the server) and communicates to the database engine by the use of the SQL Trace procedures. 

• SQL Trace can write events to files or to applications based on SMO whereas SQL Server Profiler can 

write events to files or to database tables. 

• SQL Trace is useful for long running, performance-critical traces, or for very large traces that would 

significantly impact the performance of the target system whereas SQL Server Profiler is more 

commonly used for debugging on test systems, for performing short term analysis, or for capturing 

small traces. 

Note The option “Server processes trace data” in SQL Server Profiler is not the same 

option as scripting a trace and starting it directly through stored procedures. The option 

creates two traces: one trace that directly writes to a file and a second trace to send the 

events through SMO to SQL Server Profiler.


Traces do not automatically restart after the server instance restarts. If a trace needs to be run constantly, 

the trace needs to be scripted, launched from within a stored procedure, and the stored procedure 

marked as a startup procedure. 

Question: Which option would have less impact on a traced system? 

a) SQL Trace with output to a file 

b) SQL Profiler with output to a table

Demonstration 3A: Configuring SQL Trace 














Retrieving Trace Output 

Key Points 

Traces that are written to trace files are not easy to read directly and are somewhat difficult to parse from 

within an application. 

Two options are provided by SQL Server to make it easy to work with the contents of trace files: 

• SQL Server Profiler can be used to open trace files. Within SQL Server Profiler the trace output can be 

filtered and grouped for analysis. SQL Server Profiler is especially useful for working with small trace 

files. 

• Trace files can be imported into SQL Server using the fn_trace_gettable system function. Reading the 

files into a table is particularly useful when you need to analyze large volumes of trace data as the 

table can be indexed to improve the speed of common queries against the captured data. T-SQL 

queries can then be used to analyze and filter the data.

Replaying Traces 

Key Points 


SQL Server Profiler provides the ability to replay trace files. The ability to replay trace files is useful for 

validating changes that you are considering making to a system or for testing a workload against new 

hardware, indexes, or physical layout changes. 

The replay does not need to be performed against the same system that the trace events were captured 

on but the system must be configured in a very similar way. This particularly applies to objects such as 

databases and logins. 

Distributed Replay 

SQL Server 2012 introduced a Distributed Replay feature for traces captured by either SQL Server Profiler 

or SQL Trace. Distributed Replay is not limited to replaying the workload from a single computer and 

provides a more scalable solution than the replay option provided by SQL Server Profiler. This capability 

can allow improved simulation of mission-critical workloads. 

Note In addition to the replay capabilities of SQL Server Profiler and the Distributed 

Replay Utility, a set of unsupported utilities from the SQL Server Product Support Group are 

available. These unsupported utilities are called the RML Utilities and are capable of 

replaying SQL Server workloads with advanced features such as synchronized replay 

through several clients. The RML utilities can also be used for analyzing trace files and are 

available for download from support.microsoft.com. 

Before you can replay captured traces, you need to ensure that all columns that are required for replay 

have in fact been captured. To make this easier, SQL Server Profiler provides a template called TSQL 

Replay. You can use that template as a starting point but make sure you do not remove any columns that 

are included in the template. 

Question: When might it be a good idea to test systems using the replay functionality?


Default Trace 

Key Points 

Beginning with SQL Server 2005, a default server side trace is started automatically whenever SQL Server 

starts. This trace is called the default trace and has the trace id of 1. The default trace is a lightweight trace 

that only keeps up to 5MB of data at any point in time. It captures the following events: 

Object Events 

Database Data file auto grow, Data file auto shrink, Database 

mirroring status change, Log file auto grow, Log file 

auto shrink 

Errors and Warnings Errorlog, Hash warning, Missing Column Statistics, 

Missing Join Predicate, Sort Warning 

Full-Text FT Crawl Aborted, FT Crawl Started, FT Crawl Stopped 

Objects Object Altered, Object Created, Object Deleted

(continued) 

Object Events 

Security Audit Audit Add DB user event 

Audit Add login to server role event 

Audit Add Member to DB role event 

Audit Add Role event 

Audit Add login event 

Audit Backup/Restore event 

Audit Change Database owner 

Audit DBCC event 

Audit Database Scope GDR event 

Audit Login Change Property event 

Audit Login Failed 

Audit Login GDR event 

Audit Schema Object GDR event 

Audit Schema Object Take Ownership 

Audit Server Starts and Stops 

Server Server Memory Change 


The default trace can be enabled or disabled using sp_configure. In the example shown in the slide, you 

can see how to re-enable the default trace if necessary. 

The default trace cannot be modified and also the file location cannot be changed. 

Question: Should the default trace be kept enabled?


Combining Traces with Performance Monitor Logs 

Key Points 

Using SQL Server Profiler, you can open a Microsoft Windows® performance log, choose the counters 

you want to correlate with a trace, and display the selected performance counters alongside the trace in 

the SQL Server Profiler graphical user interface. When you select an event in the trace window, a vertical 

red bar in the System Monitor data window pane of SQL Server Profiler indicates the performance log 

data that correlates with the selected trace event. 

To correlate a trace with performance counters, open a trace file or table that contains the StartTime and 

EndTime data columns, and then click Import Performance Data on the SQL Server Profiler File menu. You 

can then open a performance log, and select the System Monitor objects and counters that you want to 

correlate with the trace 

Question: What is the main advantage of using this feature?


Demonstration 3B: Combining Traces with Performance Monitor Logs 













Lab 17: Tracing Access to SQL Server 

Lab Setup 













Lab Scenario 

The developers for the new marketing application are concerned about the performance of their queries. 

When the developers were testing the application they were working with small amounts of data and 

performance was acceptable. The developers are unsure that they have created appropriate indexes to 

support the application. 

You will use SQL Server Profiler to capture traces of application execution. You will then analyze the traces 

using the Database Engine Tuning Advisor. 

If you have time, you will configure traces using the SQL Trace system stored procedures.

Exercise 1: Capture a Trace Using SQL Server Profiler 

Scenario 


You have isolated the workload that causes the poor performance and you want to test the queries in a 

development environment. In this exercise, you will generate sample workload and you will capture 

database activity using SQL Server Profiler. 


1. Create and start a suitable SQL Server Profiler trace. 

2. Execute the workload. 

3. Stop the trace. 

Task 1: Create and start a suitable SQL Server Profiler trace 

• Create a SQL Server Profiler trace based upon the following settings: 

• Tuning template 

• Filtered to the MarketDev database only 

• Rollover files disabled 

• Maximum trace file size is 500 MB 

• Start the trace. 

Task 2: Execute the workload 

• Open and execute the file 51 – Lab Exercise 1.sql which is a workload file to be analyzed. 

Note Ensure that you configure the workload window as per the instructions at the top of 

the script. 

Task 3: Stop the trace 

• When the query completes, stop the trace. 

• Close SQL Server Profiler. 

Results: After this exercise, you should have captured a workload using SQL Server Profiler. 

Exercise 2: Analyze a Trace Using Database Engine Tuning Advisor 

Scenario 

You want to take the results captured from the SQL Trace and identify any changes that could be made to 

improve performance. In this exercise you will analyze captured activity using the Database Engine Tuning 

Advisor. 


1. Analyze the captured trace in Database Engine Tuning Advisor. 

2. Review the suggested modifications.


Task 1: Analyze the captured trace in Database Engine Tuning Advisor 

• Analyze the captured trace file using Database Engine Tuning Advisor. 

Task 2: Review the suggested modifications 

• Review the suggested modifications. 

• Close Database Engine Tuning Advisor. 

Results: After this exercise, you should have analyzed the trace using Database 

Engine Tuning Advisor and reviewed the suggested modifications. 

Challenge Exercise 3: Configure SQL Trace (Only if time permits) 

Scenario 

You have noticed that when SQL Profiler is running on the production server that performance is reduced. 

You want to capture the performance metrics and reduce the impact on the server. In this exercise, you 

will capture activity using the SQL Trace stored procedures to show how this can be used instead of SQL 

Profiler, to lessen the impact on the server. 


1. Create a script that uses SQL Trace procedures to implement the same type of capture as you 

performed in Exercise 1 but with a different trace name. 

2. Test that the script works as expected by using the same workload. 

3. Analyze the new captured output and note if the suggested changes are identical to those suggested 

in Exercise 2. 

Task 1: Create a script that uses SQL Trace procedures to implement the same type of 

capture as you performed in Exercise 1 but with a different trace name 

• Create, start, and stop the same trace that you used in Exercise 1 but call the trace ProsewareTrace2. 

• Export the trace definition to a file. 

Task 2: Test that the script works as expected by using the same workload 

• Configure and start the saved trace definition file. Make sure that you note the trace ID. 

• Re-execute the 51 – Lab Exercise 1.sql workload file. 

Task 3: Analyze the new captured output and note if the suggested changes are 

identical to those suggested in Exercise 2 

• Stop the trace. 

• Open and review the captured trace file. 

Results: After this exercise, you should have captured a trace using SQL Trace.



1. What is the main purpose of Database Engine Tuning Advisor? 

2. What can be used to test a workload after configuration changes? 



1. Use SQL Server Profiler to perform short traces for debugging and other purposes. 

2. Use SQL Trace for large and long running traces. 

3. Use SQL Server Profiler to define traces and script them for SQL Trace. 

4. Import trace data into a database table for advanced analysis. 

5. Use Database Engine Tuning Advisor to analyze the database based on a workload rather than 

focusing on individual queries.

17-40 Tracing Access to SQL Server 2012

Module 18 

Monitoring SQL Server 2012 

Contents: 

Lesson 1: Monitoring Activity 18-3 

Lesson 2: Capturing and Managing Performance Data 18-15 

Lesson 3: Analyzing Collected Performance Data 18-23 

Lab 18: Monitoring SQL Server 2012 18-32 

18-1

18-2 Monitoring SQL Server 2012 


The Microsoft® SQL Server® database engine is capable of running for very long periods without the 

need for administration. However, a process of ongoing monitoring of the activity that is occurring on the 

database server allows you to be proactive in dealing with potential issues before they arise. 

SQL Server provides a number of tools that can be used for monitoring current activity and for recording 

details of previous activity. You need to become familiar with what each of the tools does and with how to 

use the tools. 

When you record activity using monitoring tools, it is easy to become overwhelmed by the volume of 

output that a monitoring tool can provide. You also need to learn techniques for analyzing the output 

that is provided by the monitoring tools. 

Objectives 


• Monitor current activity. 

• Capture and manage performance data. 

• Analyze collected performance data.

Lesson 1 

Monitoring Activity 


Dynamic management views (DMVs) and dynamic management functions (DMFs) provide insights directly 

into the inner operations of the SQL Server database engine and are useful for monitoring. It is important 

for SQL Server database administrators to become familiar with some of the more useful DMVs and DMFs 

as part of a process of ongoing server monitoring. 

SQL Server Management Studio (SSMS) provides the Activity Monitor which can be used to investigate 

both current issues such as "Is one process being blocked by another process?" and recent historical issues 

such as "Which query has taken the most resources since the server was last restarted?" You should 

become familiar with the capabilities of Activity Monitor. 

The SQL Server processes also expose a set of performance-related objects and counters to the Windows 

Performance Monitor. These objects and counters allow you to monitor SQL Server as part of monitoring 

the entire server. 

Objectives 


• Explain Dynamic Management Views and Functions. 

• View activity using Dynamic Management Views. 

• Work with Activity Monitor in SSMS. 

• Work with Performance Monitor. 

• Work with SQL Server counters.


Overview of Dynamic Management Views and Functions 

Key Points 

In earlier versions of SQL Server, database administrators often used third party tools to monitor the 

internal state of SQL Server. Most third party tools performed this monitoring by the use of extended 

stored procedures. Using extended stored procedures is not desirable as they operate within the memory 

space of the SQL Server process. Poorly-written programs that operate in these memory regions can cause 

instability or crashes of SQL Server. 

SQL Server 2005 and later offer dynamic management objects to provide insight into the inner operation 

of the database engine without the need to use extended stored procedures. Some of the objects have 

been created as views and are called dynamic management views (DMVs). Other objects have been 

created as functions and are called dynamic management functions (DMFs). 

Note The information exposed by DMVs and DMFs is generally not persisted in the 

database as is the case with catalog views. The views and functions are virtual objects that 

return state information. The state is cleared when the server instance is restarted. 

DMVs and DMFs 

DMVs and DMFs return server state information that can be used to monitor the health of a server 

instance, diagnose problems, and tune performance. There are two types of dynamic management views 

and functions: 

• Server-scoped dynamic management views and functions. 

• Database-scoped dynamic management views and functions.


All dynamic management views and functions exist in the sys schema and follow the naming convention 

dm_%. They are defined in the hidden resource database and are mapped to the other databases. The 

DMVs and DMFs are organized into a set of categories: 

Category Description 

sys.dm_exec_% These objects provide information about connections, 

sessions, requests, and query execution. For example, 

sys.dm_exec_sessions provides one row for every session that 

is currently connected to the server. 

sys.dm_os_% These objects provide access to SQL OS related information. 

For example, sys.dm_os_performance_counters provides 

access to SQL Server performance counters without the need 

to access them using operating system tools. 

sys.dm_tran_% These objects provide access to transaction management. For 

example, sys.dm_os_tran_active_transactions provides details 

of currently active transactions. 

sys.dm_io_% These objects provide information on I/O processes. For 

example, sys.dm_io_virtual_file_stats provides details of I/O 

performance and statistics for each database file. 

sys.dm_db_% These objects provide database-scoped information. For 

example, sys.dm_db_index_usage_stats provides information 

about how each index in the database has been used. 

Required Permissions 

To query a DMV or DMF requires SELECT permission on the object and VIEW SERVER STATE or VIEW 

DATABASE STATE permission, depending upon whether the object is server-scoped or database-scoped. 

This lets you selectively restrict access of a user or login to dynamic management views and functions. To 

control access for a user, first create the user in master (with any user name) and then deny the user 

SELECT permission on the DMVs or DMFs that you do not want them to access. After this, the user cannot 

select from these DMVs and DMFs, regardless of database context of the user because the DENY within 

that database context is processed first. 

Question: Why would you want to use dynamic management views to view current activity?


Viewing Activity Using Dynamic Management Views 

Key Points 

You can see the list of available DMVs in Object Explorer in the System Views node for any database. The 

DMFs are shown in the Table Valued Functions node under the System Functions node that is under the 

master database. 

Note Dynamic management views and functions need to be referenced in T-SQL 

statements by using the sys schema as a prefix. They cannot be referenced by one-part 

names. 

There are two basic types of dynamic management objects: 

• Objects that return real-time state information from the system 

• Objects that return recent historical information 

Objects That Return Real-Time State Information from the System 

Most DMVs and DMFs are designed to provide information about the current state of the system. In the 

example on the slide, two DMVs are being joined. The sys.dm_exec_sessions view returns one row for each 

current user session. The sys.dm_os_waiting_tasks view returns a row for each task that is currently waiting 

on a resource. By joining the two views and adding a filter, you can locate a list of user tasks that have 

been waiting for longer than 3000 milliseconds (3 seconds). 

Note Whenever a task has to wait for any resource, the task is sent to a waiting list. The 

task remains on that list until it receives a signal telling it that the requested resource is now 

available. The task is then returned to the running list, where it waits to be scheduled for 

execution again. This type of wait analysis is very useful when tuning system performance as 

it allows you to identify bottlenecks within the system.


In many cases, when a task is waiting, the cause of the wait will be some form of lock. Locks are discussed 

further in Module 20. 

Objects That Return Historical Information 

The second type of dynamic management object returns historical information. For example, you saw that 

the sys.dm_os_waiting_tasks view returned details of tasks that are currently waiting on resources. By 

comparison, the sys.dm_os_wait_stats view returns information about how often and how long any task 

had to wait for a specific wait_type since the SQL Server instance started. 

Another useful example of a historical function is the sys.dm_io_virtual_file_stats() function that returns 

information about the performance of database files. 

Question: What types of resources might SQL Server need to wait for?


Demonstration 1A: Viewing Activity Using Dynamic Management Views 












Working with Activity Monitor in SQL Server® Management Studio 

Key Points 

Activity Monitor is a tool in SQL Server Management Studio that shows information about processes, 

waits, I/O resource performance, and recent expensive queries. To start Activity Monitor, in SQL Server 

Management Studio, right-click the server name, and then click Activity Monitor. 

Activity Monitor has five sections: 

• The Overview section contains graphical information about processor usage, waiting tasks, database 

I/O, and batch requests per second. 

• The Processes section includes detailed information on processes, their ID's, logins, databases, and 

commands. This section will also show details of processes that are blocking other processes. 

• The Resource Waits section shows categories of processes that are waiting for resources, and 

information about the wait times. 

• The Data File I/O section shows information about the physical database files in use, and their recent 

performance. 

• The Recent Expensive Queries section shows detailed information about the most expensive recent 

queries, and resources consumed by those queries. You can right-click the queries in this section to 

view either the query or an execution plan for the query. 

You can filter data by clicking column headings and choosing the parameter you want to view 

information for. 

Question: Why is it important to monitor waits?


Demonstration 1B: Working with Activity Monitor in SQL Server 

Management Studio 












Working with Performance Monitor 

Key Points 


Windows Performance Monitor is a Microsoft Windows Server 2008 (and later) tool that brings together 

several previously disparate Microsoft Windows Server 2003 performance and monitoring tools. By 

consolidating several sources of information in one place, Windows Performance Monitor helps 

administrators obtain information needed to diagnose server performance and instability issues. 

An important new feature in Windows Performance Monitor is the Data Collector Set, which groups data 

collectors into reusable elements for use with different performance monitoring scenarios. Once a group 

of data collectors are stored as a Data Collector Set, operations such as scheduling can be applied to the 

entire set through a single property change. 

Windows Performance Monitor also includes a default Data Collector Set templates to help system 

administrators begin collecting performance data specific to a Server Role or monitoring scenario 

immediately. 

Windows Performance Monitor is the key tool for monitoring Microsoft Windows® systems. Since SQL 

Server runs on the Windows operating system, it is important to monitor at the server level as well as at 

the database engine level as problems within the database engine might be caused by problems outside 

the database engine. 

The main focus of the Windows Performance Monitor is on monitoring CPU, Memory, Disk System, and 

Network. After you install SQL Server, a number of SQL Server objects and counters are available within 

Windows Performance Monitor. 

Question: Why is Performance Monitor useful when determining performance issues?


Working with SQL Server Counters 

Key Points 

It is important to understand some of the basic terminology used within Windows Performance Monitor: 

• The term object is used to represent a resource that can be monitored. 

• Every object exposes one or more counters. 

• A counter might have several instances if more than one resource of that type exists. 

As an example, there is an object called Processor that consists of several counters. The Processor object 

provides metrics related to the processors that are available on the server. One of the commonly used 

counters for the Processor object is the “% Processor Time” counter. That counter then offers a set of 

instances that represent the individual processor cores that exist on the system. In addition, a value called 

_Total represents all the instances combined. 

Application Objects and Counters 

Many applications expose application-related statistical data to Performance Monitor. SQL Server exposes 

a large number of objects and counters. 

The SQL Server objects have the following naming convention: 

Object Name Format Usage 

SQLServer: Used for default instances 

MSSQL$: Used for named instances 

SQLAgent$: Used for SQL Server Agent


SQL Server also provides the same counter values through the sys.dm_os_performance_counters dynamic 

management view. 

Question: Why might it be useful to query sys.dm_os_performance_counters to access SQL 

Server counters rather than using Performance Monitor?


Demonstration 1C: Working with Performance Monitor 












Lesson 2 

Capturing and Managing Performance Data 


You have seen that DMVs and DMFs provide useful information about the state of the system. The values 

that the DMVs and DMFs provide are not generally persisted in any way and only reside in memory while 

the server is running. When the server instance is restarted, these values are reset. 

When DMVs and DMFs were introduced in SQL Server 2005, it was common for users to want to persist 

the values that the DMVs and DMFs provided. To this end, many users would create a database to hold 

the values, then create a job that would periodically collect and save the values. 

The Data Collector system that was introduced with SQL Server 2008 formalizes this concept by creating a 

central warehouse for holding performance data, jobs for collecting and uploading the data to the 

warehouse, and a set of high quality reports that can be used to analyze the data. This lesson describes 

how to set up and configure the Data Collector. Lesson 3 describes the reports that are available from the 

data that has been collected by the Data Collector. 

Objectives 


• Explain the role of the Data Collector. 

• Design a topology for use with the Data Collector. 

• Configure the Data Collector. 

• Configure security for the Data Collector. 

• Monitor the Data Collector.


Overview of Data Collector 

Key Points 

Earlier in this module, you have seen how useful data can be obtained from the use of DMVs and DMFs. 

One disadvantage of using dynamic management objects is that most views and function only return real 

time data and the views and functions that return historic data are aggregations of the occurrences over 

time. However, to perform effective performance tuning and monitoring, an overview over time is 

needed, along with the ability to drill down to more detailed levels when investigating issues. The SQL 

Server Data Collector helps you to achieve this. 

Data Collection Sets 

When you configure the SQL Server Data Collector, a number of System Data Collection Sets are created. 

These sets define the data that needs to be collected, how often the data is uploaded to a central 

repository, and how long the data is retained in that repository. 

The Data Collector can collect information from several locations: 

• The Data Collector can query DMVs and DMFs to retrieve detailed information about the operation of 

the system. 

• The Data Collector can retrieve performance counters that provide metrics about the performance of 

both SQL Server and the entire server. 

• The Data Collector can also capture SQL Trace events that have occurred. 

In addition to the System Data Collection Sets, the SQL Server Data Collector can be extended by the 

creation of user-defined Data Collection Sets. The ability to add user-defined Data Collection Sets allows 

users to specify the data that they wish to collect and to use the infrastructure that is provided by the SQL 

Server Data Collector to collect and centralize the data.

Management Data Warehouse and Reports 


The data that is collected by the SQL Server Data Collector is stored in a central repository called a 

management data warehouse. The management data warehouse is a SQL Server database that is created 

by a wizard that is also used to configure data collection. 

Three standard reports and a rich set of sub-reports has been provided with the Data Collector but it is 

possible to write your own reports that are based on either the data that is collected by the System Data 

Collection Sets or data that is collected by user-defined Data Collection Sets. 

Question: Can Data Collector be used for real time monitoring?


Designing a Data Collector Topology 

Key Points 

There are three components that make up the data collection system in SQL Server: 

• The Data Collector is made up of a set of jobs that run on the local server that collect data from 

dynamic management objects, performance counters, and SQL Trace events and upload that data to 

a central repository. 

• The central repository that can consolidate data from multiple server instances. 

• The rich reports which are available to analyze the data in the management data warehouse. The 

reports are accessed using SSMS. 

A large enterprise should consider the use of a standalone system for the management data warehouse. 

There are two goals for creating a centralized management data warehouse: 

• You can access reports that combine information for all server instances in your enterprise. 

• You can offload the need to hold collected data and to report on it from the production servers. 

The data collector has two methods for uploading captured performance data into the central warehouse. 

Low volume information is sent immediately to the warehouse. Higher volume information is cached 

locally first and then uploaded to the warehouse using SSIS. 

Question: Is it possible to configure all of the data collector features on a single instance?

Configuring Data Collector 

Key Points 

Installing the data collection system in SQL Server involves two steps: 


• Configuring a central management data warehouse to hold the collected data. 

• Configuring each server instance to collect and upload the required data. 

SQL Server provides a wizard that is used for both these tasks. The first step when running the wizard is to 

create a management data warehouse. The management data warehouse can store collection data from 

many SQL Server instances. 

Planning Space Requirements 

Sufficient disk space needs to available to support the needs of the management data warehouse. In a 

typical configuration, you should allow at least 300MB per day for each instance that is managed. 

Impact on Local Systems 

The only processes that are run on the local instances are the jobs that are used to collect and upload the 

data to the management data warehouse. Some data is collected very regularly and is cached locally and 

later uploaded using SSIS. Other data is captured infrequently and uploaded immediately. 

System Data Collection Sets are created automatically during setup. They can be enabled and disabled as 

needed and both the frequency of collection and the retention periods for collected data can be 

customized for System Data Collection Sets as well as for user-defined Data Collection Sets. 

It is also important to consider the security requirements for the Data Collector. The security requirements 

are discussed in the next topic. 

Question: What might be interesting to include as a custom collection set?


Data Collector Security 

Key Points 

The SQL Server Data Collector system has two security aspects that need to be considered: 

• Who can access the Management Data Warehouse? 

• Who can configure the Data collection? 

Database roles exist for both these purposes as shown in the tables on the slide. 

Note A user needs to be member of the mdw_reader role to be able to access the reports 

and the collected data. 

As well as needing to be a member of the mdw_writer role to upload data, the jobs that collect the data 

need whatever permissions are required to access the data that they are collecting. 

Question: If the SQL Server Agent service account does not have sufficient privileges to 

access the management data warehouse to upload the data, what configuration changes 

could you make to allow this?

Monitoring Data Collector 

Key Points 


As with other SQL Server Agent jobs, the history of the jobs that are used by SQL Server Data Collector to 

capture and upload performance data are held in the SQL Server Agent job history tables and can be 

viewed using the standard SQL Server Agent job history viewer. 

In addition to the standard job history, the Data Collector also logs configuration and other log 

information to tables in the msdb database. The Data Collector calls stored procedures to add the log 

information and also uses the SSIS logging features for the SSIS packages that it executes. 

The data that is logged into the msdb database is kept with the same retention period settings as the 

Data Collection Sets that it relates to. The information that is retained can be viewed through the log file 

viewer or by querying the following views: 

• fn_syscollector_get_execution_details() 

• fn_syscollector_get_execution_stats() 

• syscollector_execution_log 

• syscollector_execution_log_full 

• syscollector_execution_stats 

Three levels of logging are available and can be set by calling the sp_syscollector_update_collection_set 

system stored procedure. The lowest level of logging records starts and stops of collector activity. The 

next level of logging adds execution statistics and progress reports. The highest level of logging adds 

detailed SSIS package logging. 

Question: Why is it better to use the Data Collector logs than the data collector job history 

for troubleshooting Data Collector?


Demonstration 2A: Configuring Data Collector 












Lesson 3 

Analyzing Collected Performance Data 


Once performance data has been collected from a number of server instances and consolidated into a 

management data warehouse, the data can then be analyzed. You can write your own custom reports 

using SQL Server Reporting Services, via custom reports in SSMS, or via T-SQL queries. Most users will find 

the standard reports that are supplied with SQL Server to be sufficient, without the need to write 

additional reports. It is important to be familiar with the information that is contained in the standard 

reports and with how to navigate within the reports. 

Objectives 


• Explain the available Data Collector reports. 

• Use the Disk Usage report. 

• Use the Server Activity report. 

• Use the Query Statistics report.


Overview of Data Collector Reports 

Key Points 

The SQL Server Data Collector provides a series of standard reports that are based on the data that is 

collected from the System Data Collection Sets and that has been consolidated into a centralized 

management data warehouse. The reports are accessed from within SQL Server Management Studio as a 

right-click option from the management data warehouse database as shown in the screen shot below:


The overview page for the Management Data Warehouse reports provides links to the main report areas 

as shown in the following screenshot: 

From this overview page, there are three main report areas that are linked: 

• Disk Usage Summary 

• Query Statistics History 

• Server Activity History 

Note Each report can be printed and exported to PDF or Microsoft Excel® files for further 

analysis. 

Question: What period would the Data Collector reports cover?


Disk Usage Report 

Key Points 

The disk usage reports are based on the Disk Usage System Data Collection Set. By default, the collection 

set gathers disk usage data every six hours and keeps the data for two years. 

Note that by default, the Disk Usage System Collection Set retains data for much longer than other 

System Data Collection Sets. However, as the amount of data collected by this collection set is quite small, 

this should not be a concern and the value of being able to track individual file space usage over time 

warrants the use of this longer retention period. 

This report also includes a number of hyperlinks that lead to a set of linked sub-reports for drilling into 

the usage data. 

Question: What might be a good custom report that could be created based on disk usage 

data?

Demonstration 3A: Viewing the Disk Usage Report 











• Open and follow the instructions in the 21 – Demonstration 2A.sql script file. 




Server Activity Report 

Key Points 

The Server Activity Report is based on the Server Activity System Data Collection Set. The collection set 

gathers a lot of SQL Server related statistics such as waits, locks, latches, and memory statistics that are 

accessed using DMVs. In addition, the collection set gathers Windows and SQL Server Performance 

counters to retrieve information such as CPU and memory usage from the system and from the processes 

that are running on the system. The collection runs every sixty seconds and is uploaded every fifteen 

minutes by default. The history is retained for fourteen days by default. 

This report has a large number of linked sub-reports that provide much deeper information than is 

provided on the initial summary. The initial report is a dashboard that provides an overview. If you 

investigate this report, you will find that almost every item displayed is a possible drill-through point. For 

example, you can click on a trend line in a graph to find out the values that make up the trend. 

Question: Why is it important that data collection also tracks the memory usage of other 

processes running on the system?

Demonstration 3B: Viewing the Server Activity Report 















Query Statistics Report 

Key Points 

The Query Statistics Report is based on the Query Statistics System Data Collection Set that retrieves 

details of expensive queries. The collection set is the most intensive default collection system and, by 

default, runs every ten seconds. To avoid the overhead of constant uploading, the data that is collected by 

this collection set is cached in the local file system and uploaded using SSIS every fifteen minutes. The 

data that is collected is retained for fourteen days by default but this value can be extended. 

SQL Server determines expensive queries based upon: 

• Elapsed time 

• Worker time 

• Logical reads 

• Logical writes 

• Physical reads 

• Execution count 

This report also includes a large number of linked sub-reports that can be used to drill-through to higher 

levels of detail. As an example, it is possible to retrieve query plans from the expensive queries that were 

in memory at the time the capture was performed. 

Question: What is meant by the term "expensive queries"?

Demonstration 3C: Viewing the Query Statistics Report 















Lab 18: Monitoring SQL Server 2012 

Lab Setup 













Lab Scenario 

The earlier versions of SQL Server that you have worked with did not include dynamic management 

functions and views. You have recently read about these and are interested to see how they might be 

used for collecting performance information. 

Rather than collecting information separately for each SQL Server instance, you have decided to collect all 

the performance information to a central server. This will help when dealing with issues that were not 

reported to the helpdesk at the time they occurred.

Exercise 1: Investigating DMVs 

Scenario 


You have been provided with a series of sample queries that can be used to provide information from 

Dynamic Management Views and to provide an insight into SQL Server activity. In this exercise, you will 

execute these queries to gain an understanding of the potential uses for DMVs. 


1. Investigate the use of Dynamic Management Views and Functions. 

Task 1: Investigate the use of Dynamic Management Views and Functions 

• Open the script file 51 - Lab Exercise 1.sql and follow the instructions contained in the script file. 

Results: After this exercise, you should have investigated the use of Dynamic Management Views 

and Functions. 

Exercise 2: Configure Management Data Warehouse 

Scenario 

You want to be able to centrally collect performance information so that you can analyze the all the 

Adventure Works performance data a later stage. In this exercise, you will configure a server to hold the 

management data warehouse to collect the performance data. 


1. Create a management data warehouse for central collection of performance data. 

Task 1: Create a management data warehouse for central collection of performance data 

• Create a management data warehouse for central collection of performance data. Create the 

management data warehouse with a database name of MDW and on the Proseware instance. 

Results: After this exercise, you should have created a management data warehouse. 

Exercise 3: Configure Instances for Data Collection 

Scenario 

You want to configure each Adventure Works SQL Server instance so that it sends performance 

information to a central server. In this exercise, you will configure each of the SQL Server instances to send 

performance data to the newly configured data warehouse. 


1. Configure data collection on each instance. 

2. Configure data collection security for the AdventureWorks instance.


Task 1: Configure data collection on each instance 

• Configure data collection on the Proseware instance. 

• Set the target for the performance data to the management data warehouse created in Exercise 2. 

• Configure data collection on the AdventureWorks instance. 

Results: After this exercise, you should have configured both instances for data collection. 

Challenge Exercise 4: Work with Data Collector Reports (Only if time 

permits) 

Scenario 

You want to create a performance report that summarizes the performance information for all of the 

Adventure Works SQL Server instances. In this exercise, you will review the reports provided by the data 

collection system. 

Note Performance data takes some time to begin to be collected. To assist with this 

exercise, you have been provided with a backup of another management data warehouse 

to use for testing reports. 


1. Disable data collectors on both instances. 

2. Restore a backup of the MDW database. 

3. Review the available reports. 

Task 1: Disable data collectors on both instances 

• Disable data collection on the Proseware instance. 

• Disable data collection on the AdventureWorks instance. 

Task 2: Restore a backup of the MDW database 

• Restore the MDW database from the backup file 

D:\10775A_Labs\10775A_18_PRJ\10775A_18_PRJ\MDW.bak. 

Task 3: Review the available reports 

• Create a server activity report. 

• Create a disk space usage report. 

• Create a query statistics report. 

Results: After this exercise, you should have worked with Management Data Warehouse Reports.




1. Why is it better to have a central management data warehouse for data collection, than local 

installations? 

2. What are Dynamic Management Objects? 


1. Use Dynamic Management Objects to perform real-time monitoring and troubleshooting. 

2. Use Activity Monitor for easy access to the most relevant information. 

3. Use Performance Monitor to gather metrics for Windows and SQL Server. 

4. Create a central Management Data Warehouse to hold historical performance information. 

5. Set up data collection to gather performance data of your SQL Server Instances.

18-36 Monitoring SQL Server 2012

Module 19 

Managing Multiple Servers 

Contents: 

Lesson 1: Working with Multiple Servers 19-3 

Lesson 2: Virtualizing SQL Server 19-9 

Lesson 3: Deploying and Upgrading Data-tier Applications 19-15 

Lab 19: Managing Multiple Servers 19-22 

19-1

19-2 Managing Multiple Servers 


Database administrators that work with Microsoft® SQL Server® are increasingly being required to 

manage larger numbers of servers. The need to manage multiple servers provides additional challenges. 

Microsoft has been making substantial investments in SQL Server tooling to assist in the management of 

multiple servers. 

While the virtualization of operating systems and applications is not new, virtualized SQL Server systems 

have been less common than other types of systems. However, virtualized SQL Server systems are now 

rapidly being deployed. It is important that you understand the core concepts involved with the 

virtualization of SQL Server systems, the tools that are commonly used to implement the virtualization, 

and with how such systems are managed. 

In SQL Server 2012, Microsoft introduced a new form of database development project known as data-tier 

applications. While database administrators do not necessarily need to understand how to create data-tier 

applications, database administrators need to know how to deploy and upgrade data-tier applications. 

Objectives 


• Work with multiple servers. 

• Describe options for virtualizing SQL Server. 

• Deploy and upgrade Data-Tier Applications.

Lesson 1 

Working with Multiple Servers 


One of the first tools that you need to become familiar with when you need to manage multiple SQL 

Server systems is the central management server (CMS). The CMS was first introduced in SQL Server 2008 

and allows you to define groups of servers and to execute queries and apply policies against the defined 

groups of servers. 

It is important that you are aware of how to configure a CMS, to define server groups, and to execute 

queries against the groups of servers. It is also important that you are aware of the limitations related to 

multi-server queries. 

Objectives 


• Configure central management servers. 

• Execute multi-server queries.


Overview of Central Management Servers 

Key Points 

For many product versions, SQL Server Management Studio has provided the ability for users to define 

groups of servers in the Registered Servers tool window. The typical use for this capability was to group 

together servers in different environments. For example, you could create a group of development 

servers, a group of test servers, a group of staging servers, and a group of production servers. 

No actions were permitted against entire groups of servers and a key challenge with this capability was 

that the definition of the server groups was stored in an XML file on the local client computer that was 

executing SSMS. 

If a user moved to a different computer, the groups of servers would no longer exist and would need to 

be recreated. If the list of servers in a group changed, the groups would need to be modified on every 

computer that was executing SSMS, if access to the groups was needed. 

Central Management Server 

A central management server is a server that is configured to maintain a centralized list of groups of 

servers that needs to be defined only once and that can be accessed by all authorized users. The 

centralized list is stored in tables within the msdb database of the CMS. 

Users that need to access the list of servers must be members of the ServerGroupReaderRole in the msdb 

database. All SQL Server editions and versions can be registered through the CMS but all registrations 

require the use of Windows Authentication. The server that provides the CMS needs to be SQL Server 

2008 or later.


While the ability to maintain central lists is useful, SQL Server 2008 and later versions provide the ability to 

perform actions against entire groups of computers. By right-clicking a group in the Registered Servers 

tool window, users can execute T-SQL statements against all servers within the group at the same time. 

Users can also use Object Browser to browse multiple servers concurrently. 

Note Users can also import and evaluate policies that are part of SQL Server Policy-Based 

Management (PBM) but PBM is an advanced topic that is out of scope for this course. 

Question: What is the main advantage of using a central management server instead of 

standard registered servers in SSMS?


Executing Multi-server Queries 

Key Points 

When you open a multi-server query window, SSMS changes the color of the status bar to indicate to you 

that the query is not a standard query. In addition, instead of showing a server name at the bottom of the 

window, SSMS shows the name of the server group. The following screenshot shows the result of 

executing the following command against a group containing both the AdventureWorks and Proseware 

servers: 

SELECT SERVERPROPERTY('IsFullTextInstalled') AS IsFullTextInstalled;


Note the additional column called Server Name that is included in the results but was not included in the 

SELECT statement. For the execution of multi-server queries, SSMS provides options that determine how 

the results of the queries should be presented. From the Tools menu, click Options, click Query Results, 

click SQL Server, and then click Multi-server Results as shown in the following screenshot: 

By default, SSMS will merge the results from each server into a single result set and insert a first column 

that contains the name of the server. Optionally, you can remove this server name, add the login name, or 

request that the results are not merged. 

Question: What happens if the user has no permissions to execute a statement on one of 

the servers of a multi-server query?


Demonstration 1A: Executing Multi-server Queries 











Lesson 2 

Virtualizing SQL Server 


Virtualization of servers has been common for many years, particularly in relation to server consolidation 

efforts. SQL Server virtualization has been the exception. It has been much less common to see SQL Server 

systems virtualized. Mostly, this has been because of concerns about the intense I/O requirements that are 

common with SQL Server systems. This situation is now rapidly changing and it is very important that 

database administrators who work with SQL Server are aware of the techniques for virtualizing SQL Server 

and of the advantages and disadvantages associated with SQL Server virtualization. 

Objectives 


• Discuss the advantages and disadvantages of virtualizing SQL Server. 

• Describe virtualization. 

• Describe available virtualization options. 

• Explain considerations for virtualizing SQL Server. 

• Describe System Center Virtual Machine Manager.


Discussion: Advantages and Disadvantages of Virtualizing SQL Server 

Discussion Points 

Question: Do you use virtualization of SQL Server in your environment? 

Question: If you are using virtualization, why are you using it? 

Question: What are the main advantages provided by virtualization? 

Question: What are the main concerns with virtualizing SQL Server?

Overview of SQL Server Virtualization 

Key Points 


Virtualization is a technology that allows you to create and manage workloads running in separate virtual 

machines rather than separate physical computers. Microsoft Hyper-V® is a feature of Windows Server® 

2008 (R2) x64 and is installed as an operating system role. 

Hyper-V supports isolation through a concept of partitions. A Hyper-V partition is a logical unit that 

executes an operating system. Hardware access is performed through the root partition that is initially 

created as part of the operating system. None of the child partitions has direct access to the hardware. 

Child partitions access resources through the hypervisor that controls the whole system. 

Every machine must have a root partition with Windows Server running. The root partition is used to 

manage the system, along with any child partitions. 

The virtualization that is provided by using Hyper-V technology not only provides better use of hardware 

resources, but also enables easier management and high availability through the ability of Live Migration, 

Snapshots, and many other features. 

Live Migration allows the movement of a child partition from one computer to the child partition of 

another computer, while maintaining user connections throughout the process. 

Snapshots allow the creation of named points in time that entire virtual machines can be reverted to on 

demand. 

Question: What advantage would Live Migration provide over other options such as SQL 

Server Failover Clustering?


Common Virtualization Scenarios 

Key Points 

There are many reasons for virtualizing a SQL Server installation: 

• One of the primary reasons for virtualizing SQL Server is to consolidate a number of standalone 

servers onto a single more powerful physical server. Consolidation can bring a number of benefits, 

particularly in terms of physical space and power consumption. 

• Another core reason for virtualizing SQL Server is to move older versions of SQL Server and older 

server operating systems that need to be retained for application compatibility reasons, onto newer 

hardware platforms that are more supportable. Many older servers cannot be repaired when they fail. 

Virtualizing the servers alleviates much of this issue. PTV tools (physical to virtual tools) are available 

to help with this migration. 

• Virtual servers are independent of the underlying hardware and are much easier to move to alternate 

hardware. 

• Hyper-V based virtualization supports the creation of Hyper-V clusters across multiple physical 

servers. SQL Server failover clusters can be constructed above the Hyper-V clusters to provide high 

availability options. Live Migration can be used for manual failover of virtual machines. 

• It is often difficult to balance the resource requirements of different applications. By separating the 

applications into separate virtual servers, dynamic balancing of resources between the virtual 

machines is possible. 

• Test environments are easy to create and tear down when they are based on virtualization 

technology. Snapshots provide the ability to roll back the effect of application installations or test 

executions. 

Question: Why would virtualization be very useful when testing applications?

Considerations for Virtualizing SQL Server 

Key Points 


Before virtualizing a SQL Server (or any) workload, you should carry out an appropriate proof of concept 

(POC), making sure to use typical database sizes and typical workloads. 

A very common mistake that is often made when virtualizing SQL Server systems is to neglect to provide 

sufficient I/O resources for the virtual servers. There is a common misconception that a set of virtualized 

servers requires fewer resources than the individual servers. Pass-through disks route I/O calls to the host 

system for execution and add minimal overhead to the calls. Pass-through disks need to be used in all 

cases. Emulated disks introduce substantial overhead and should always be avoided. 

The SQLIO utility should be used to stress test the I/O subsystem before deploying SQL Server, as should 

be done with a non-virtualized SQL Server system. The testing should be performed from within the 

virtual system that will be used to run SQL Server so that all software layers are tested. The same 

suggestions regarding the separation of data and log drives onto separate physical drives that applies to 

non-virtualized servers also apply to virtualized servers. 

Virtualized servers tend to make more use of CPU resources than non-virtualized servers. Network 

intensive systems require even greater CPU resources. 

Hyper-V provides a set of integration components that increase the performance of the virtual system by 

replacing devices that are emulated in software with synthetic versions of the devices. 

Question: What differences would exist between the needs of a virtualized SQL Server and a 

non-virtualized SQL Server in terms of I/O requirements?


Overview of System Center Virtual Machine Manager 

Key Points 

SQL Server 2008 introduced the SQL Server Resource Governor to help with balancing resource 

requirements for multiple applications on a single server. While the use of Resource Governor can assist 

somewhat with CPU and memory requirements that relate to the database engine and certain types of 

queries, users often want to balance resources at a higher level of granularity and across other SQL Server 

components. 

One common option is to install multiple virtual machines that are each running SQL Server and to 

separate the applications onto the separate virtual machines. The role of System Center Virtual Machine 

Manager (SCVMM) is to then balance the resources that are allocated to each of the virtual machines. 

SCVMM is a component of the System Center suite, along with other components such as System Center 

Operations Manager (SCOM) which provides an overall management framework for an organization. 

SCVMM is often used in conjunction with SCOM.


Lesson 3 

Deploying and Upgrading Data-tier Applications 

Creating .NET based applications in Microsoft Visual Studio® is a well-refined process. The creation of 

projects to support the database-related aspects of the projects has been less well defined. Since Visual 

Studio 2005, it has been possible to create database projects in Visual Studio. Database projects could 

form part of solutions that include other types of Visual Studio projects. Database projects continue to be 

used for line of business or large mission-critical applications. 

Data-tier applications are another form of database project that offer many of the advantages of database 

projects but are much easier to create, deploy, and upgrade. While database administrators do not 

necessarily need to know how to create data-tier applications, it is important that database administrators 

know how to deploy and upgrade data-tier applications that have been provided to them by developers. 

Objectives 


• Describe data-tier application. 

• Deploy data-tier applications. 

• Upgrade data-tier applications. 

• Extract data-tier applications.


Data-tier Application Overview 

Key Points 

Data-tier applications provide a mechanism for deploying and upgrading simple departmental 

applications. 

Problems with Previous Approaches 

Consider how most database applications are installed. The application itself is normally installed using a 

Windows setup program. The setup program asks for configuration information and then installs all 

necessary files, registers components, adds necessary registry entries, and so on. Upgrades also usually 

work in a very similar way. 

Now consider how the databases that are required by the applications are installed and upgraded. The 

majority of database projects today are installed via T-SQL scripts. Some applications provide installers 

that execute the T-SQL commands automatically. Script-based installation has many disadvantages. 

Developers have had very little support in their development environments to assist in creating the 

required setup scripts. The scripts often need to be edited manually. These manual processes invariably 

lead to errors. In addition, it is difficult for a developer to view the overall schema of the database they are 

working against, without building a database based on the schema. In many cases, this will mean 

retrieving and executing a "seed" script that creates a new database and then applying a large number of 

upgrade scripts to bring the database to the required level. 

The database administrator often needs to run installation scripts manually and often has to perform 

other tasks such as creating logins and other objects. If these tasks are not performed perfectly, the 

installation and upgrade scripts will often fail and might leave the database in an inconsistent (or even 

unknown) state.

Data-tier Applications 


Data-tier applications are designed to provide a similar experience for installing and upgrading database 

applications as occurs with Windows applications. The developer creates a data-tier application using 

Visual Studio, with all required objects, and defines policies that limit how the application can be installed. 

For example, a deployment policy could indicate that an application can only be installed on SQL Server 

versions 10.5 and above. 

When the data-tier application project is built, the output is a .dacpac file that can be delivered to the 

database administrator. A single .dacpac file can be used for both installing and upgrading an application 

and is portable across different environments such as development, test, staging, and production. 

Installation and upgrade of data-tier applications is automated. Data-tier applications are not designed 

for large line of business applications. The intention is to make it easy to install and upgrade large 

numbers of simpler applications. 

Question: What is a disadvantage of deploying upgrades via T-SQL scripts?


Deploying Data-tier Applications 

Key Points 

Deploying a data-tier application has been designed to be very straightforward and automated. SSMS 

includes a data-tier application installation wizard. The wizard begins by asking for a database name and 

the location (file paths) for the database files. 

Before making any changes, the wizard checks any policies that are included. In SQL Server 2012, the only 

policy that is available is a server selection policy that determines which versions of SQL Server that the 

application can be installed on. Later versions of data-tier applications might include other types of policy 

such as a policy that details failover or high availability requirements. 

Before you deploy a .dacpac file as a data-tier application, make sure you trust the source of the .dacpac 

file. Otherwise, you should inspect the .dacpac files before deploying them. It is recommended, as with 

any type of application, that you install the data-tier applications on a test environment before installing 

them in a production environment. 

You can view the contents of a .dacpac file by importing the file into a data-tier application project in 

Visual Studio. If Visual Studio is not available, a right-click "Unpack" option is available for .dacpac files on 

systems where SQL Server 2012 and later has been installed. 

Question: Why is it important to review a dacpac file before deployment?

Upgrading Data-tier Applications 

Key Points 


Upgrades to data-tier applications are also automated. A right-click option on an existing deployed datatier 

application in SSMS provides an option to upgrade the application. Upgrades are also wizard based 

and designed to be easy to apply. 

In earlier versions of SQL Server, when you upgraded a data-tier application, a new database was created 

and all data in the database that you were upgrading was migrated across to the new database. In SQL 

Server 2012, databases are upgraded in place instead of being migrated. 

The disk space requirements for the upgraded database must also be considered. 

All aspects of data-tier applications that can be managed from within SSMS can also be managed by the 

use of Windows PowerShell® scripting. 

One key advantage of data-tier application upgrades is that when errors occur, the upgrade is rolled back. 

Unlike script based upgrades where errors often lead to databases in inconsistent or unknown states, 

upgrades to data-tier applications either work or they do not work. 

Question: What is the main advantage over .dacpac based upgrades compared to scriptbased 

upgrade?


Extracting Data-tier Applications 

Key Points 

Not all applications are started from scratch. There is a common need to work to further develop existing 

applications. 

SSMS provides two options for working with existing applications: 

• You can register an existing database as a data-tier application. 

• You can extract a data-tier application (via a .dacpac file) from an existing database. 

Note that data-tier applications do not support all SQL Server objects at this time. For example, XML 

schema collections and SQL CLR based objects are not supported. For this reason, not all databases can be 

either registered as data-tier applications or extracted to .dacpac files. When SQL Server is unable to 

perform a registration or extraction, the objects that are not supported are displayed within the wizard. 

Question: What is the main purpose of extracting data-tier applications?

Demonstration 3A: Working with Data-tier Applications 














Lab 19: Managing Multiple Servers 

Lab Setup 













Lab Scenario 

You need to configure a solution that allows you to easily manage multiple SQL Server instances. You 

have noticed that on each computer that you connect to your SQL Server network, a different set of 

servers has been configured. You decide to configure a central management server to provide a 

consistent list of server groups. Your developers have begun using Data-Tier applications for some of their 

development. You need to deploy one of these applications to the new server, register an existing 

database as a Data-Tier application and, if time permits, upgrade a Data-Tier application.


Exercise 1: Configure CMS and Execute Multi-server Queries 

Scenario 

You want to create a list of SQL Server instances so that each database administrator has a consistent list 

of SQL Server instances in SQL Server Management studio. You want to manage this list of servers 

centrally. In this exercise, you will configure a central management server and execute multi-server 

queries. 


1. Create a central management server. 

2. Create a server group within the CMS. 

3. Execute a command to find all databases on any core server in full recovery model. 

Task 1: Create a central management server 

• Create a central management server on the Proseware instance. 

Task 2: Create a server group within the CMS 

• Create a server group called Core Servers. 

• Register the Proseware instance in the CoreServers group. 

• Register the AdventureWorks instance in the CoreServers group. 

Task 3: Execute a command to find all databases on any core server in full recovery 

model 

• Open a multi-server query window. 

• Execute a multi-server query to find all databases in full recovery model. 

• Hint: Look for the value FULL in the recovery_model_desc column in the sys.databases view. 

Results: After this exercise, you should have created a centrally managed server group and 

executed a multi-server query.


Exercise 2: Deploy a Data-tier Application 

Scenario 

You want to deploy a data-tier application that has been supplied by your application development 

group. This data-tier application contains all of the database and instance objects used by an application. 

In this exercise, you will use SQL Server Management Studio to deploy a data-tier application. 


1. Deploy the data-tier application using SSMS. 

Task 1: Deploy the data-tier application using SSMS 

• Deploy the data-tier application D:\10775A_Labs\10775A_19_PRJ\10775A_19_PRJ\CityCode.dacpac as 

database name CityCode on the Proseware instance. 

• Test the data-tier application by executing the script file 61 – Lab Exercise 2.sql. 

Results: After this exercise, you should have deployed a data-tier application. 

Exercise 3: Register and Extract a Data-tier Application 

Scenario 

You want to encapsulate all of the database and instance objects used by an existing application into a 

single package that you can email. In this exercise, you will register an existing database as a data-tier 

application. You will also extract a data-tier application to send to the development team. 


1. Register the existing database as a data-tier application. 

2. Extract a dacpac from the database to send to the development team. 

Task 1: Register the existing database as a data-tier application 

• Register the Research database as a data-tier application. 

Task 2: Extract a dacpac from the database to send to the development team 

• Extract a dacpac from the Research database, to the file D:\MKTG\Research.dacpac. 

Results: After this exercise, you should have registered the Research database as a 

data-tier application and extracted a DAC package file.


Challenge Exercise 4: Upgrade a Data-tier Application (Only if time 

permits) 

Scenario 

The application development group has provided you with a new version of the database schema as a 

data-tier application. You want to deploy this new version of the schema. In this exercise, you will upgrade 

the existing data-tier application. 

Note: Two versions of the updated data-tier application have been supplied. The first (CityCode_v2) will 

cause an error when you attempt to deploy it. The intention is to allow you to see that the system is not 

left in an unknown state. The second version (CityCode_v3) should deploy successfully. 


1. Attempt to deploy the v2 upgrade. 

2. Deploy the v3 upgrade. 

Task 1: Attempt to deploy the v2 upgrade 

• Attempt to deploy the v2 upgrade from the file 

D:\10775A_Labs\10775A_19_PRJ\10775A_19_PRJ\CityCode_v2.dacpac. 

Task 2: Deploy the v3 upgrade 

• Deploy the v3 upgrade from the file 

D:\10775A_Labs\10775A_19_PRJ\10775A_19_PRJ\CityCode_v3.dacpac. 

Results: After this exercise, you should have upgraded the data-tier application.




1. What must be considered, when executing multi-server queries? 

2. What is the purpose of Live Migration as part of Hyper-V? 


1. Use Central Management Server to maintain a central configuration of registered servers and groups. 

2. Use multi-server queries to run batches against several servers concurrently. 

3. Consider virtualization for high availability, consolidation, better hardware utilization, and test 

environments. 

4. Consider the use of data-tier application for departmental database applications.

Module 20 

Troubleshooting Common SQL Server 2012 Administrative 

Issues 

Contents: 

Lesson 1: SQL Server Troubleshooting Methodology 20-3 

Lesson 2: Resolving Service-related Issues 20-7 

Lesson 3: Resolving Login and Connectivity Issues 20-13 

Lesson 4: Resolving Concurrency Issues 20-17 

Lab 20: Troubleshooting Common Issues 20-25 

20-1

20-2 Troubleshooting Common SQL Server 2012 Administrative Issues 


An important role that database administrators that work with Microsoft® SQL Server® need to fulfill is 

that of a troubleshooter when issues arise, particularly those issues that are preventing users from 

working. 

It is important to have a solid methodology for resolving issues in general, and to be familiar with the 

most common issues that can arise when working with SQL Server systems. 

Objectives 


• Explain SQL Server troubleshooting methodology. 

• Resolve service-related issues. 

• Resolve login and connectivity issues. 

• Resolve concurrency issues.

Lesson 1 

SQL Server Troubleshooting Methodology 


Before starting to try to resolve any issue, it is important to apply a logical troubleshooting methodology 

and to apply it in a consistent manner. Troubleshooting is often regarded as somewhat of an art as much 

as it regarded as a science. There are a number of characteristics that are common to all good 

troubleshooters. You should aim to develop or emulate those characteristics to ensure that you are 

successful when troubleshooting issues. 

Objectives 


• Discuss characteristics of good troubleshooters. 

• Apply a troubleshooting methodology.


Discussion: Characteristics of Good Troubleshooters 

Discussion Points 

Question: What characteristics have you observed in people that you consider to be good 

troubleshooters? 

Question: What characteristics do you notice in people that are poor troubleshooters?

Applying a Troubleshooting Methodology 

Key Points 


You have seen in the discussion in the last topic that a key characteristic of good troubleshooters is that 

they follow a clear methodology in a logical manner. There are many different methodologies that are 

often applied to troubleshooting but the following list describes four phases that are common to most 

methodologies: 

Investigation Phase 

This is a critical phase. Too many people shortcut this step and start to jump directly into finding solutions. 

Before you can solve any problem, you need to be very clear in your understanding of the problem that 

you are solving. 

One very important concept in this phase is that the issue needs to be defined from the point of view of 

the user that is affected, not from an assumed perspective of an IT person. For example, there is no point 

telling a user that a system is working if the user cannot use it for any reason, regardless of how your ITbased 

perspective might tell you that the system is working. 

You need to understand what works and what doesn't work. A common mistake in this phase is to assume 

that when a user complains that something doesn't work, that it did ever work. Make sure that there was a 

time when the issue didn't exist and find out when that was. Also find out about anything, no matter how 

unrelated it might seem at this point, that has changed since that time. 

Finally, you need to know how the user would decide that the issue is resolved. A common 

troubleshooting error is to find a problem, to assume that it is the cause of the issue, to resolve that 

problem, and to assume that the original issue is now resolved.


Analysis Phase 

In the analysis phase, you need to determine all possible causes of the issue that you are trying to resolve. 

At this point, it is important to avoid excluding any potential causes, no matter how unlikely you consider 

them to be. 

A brainstorming session with another person is often useful in this phase, particularly if that person is 

capable of constantly providing alternative viewpoints during discussions. (In many countries, this person 

would be described as being good at playing the Devil's advocate). The analysis phase often benefits from 

two types of people, one of whom has excellent technical knowledge of the product, and another that 

constantly requires the first person to justify their thoughts and to think both logically and laterally. 

Implementation Phase 

In the implementation phase, you need to eliminate each potential cause. This process of elimination 

usually returns the best results when the potential causes are eliminated in order from the most likely 

cause to the least likely cause. 

The critical aspect of the implementation phase is to make sure that your reasons for eliminating potential 

causes are logically valid. 

If you reach the end of your list of potential causes and have not yet found a solution to the issue, you 

need to return to the analysis phase and recheck your thinking. If you cannot find a problem in your 

analysis, you might even need to go back to recheck your initial assumptions in the investigation phase. 

Validation Phase 

Too many people, particularly those that are new to troubleshooting, assume that problems are resolved 

when they are not. Do not assume that because you have found and resolved a problem that it was the 

original problem that you have solved. 

In the investigation phase, you should have determined how the user would decide if the issue is resolved. 

In the validation phase, you need to apply that test to see if the issue really is resolved. 

Documentation 

After the problem is resolved, it is really important to make sure that all in the organization learn from 

what happened. 

Question: How do you know that a problem is resolved?

Lesson 2 

Resolving Service-related Issues 


In the remainder of this module, you will see how to approach common types of issues that can arise 

when working with SQL Server systems. This lesson covers the first of these types of issue that involves 

problems with SQL Server services. 

SQL Server comprises a series of Windows services. The troubleshooting of issues with these services 

shares much in common with the troubleshooting of issues with other Windows services but there are 

some SQL Server specific considerations. 

Objectives 


• Troubleshoot service-related issues. 

• Use SQL Server error log. 

• Use Windows event logs.


Troubleshooting Service-related Issues 

Key Points 

The most common service-related problem is that one of the SQL Server services will not start or cannot 

be accessed. As with all Windows services, the SQL Server services are not permitted to interact directly 

with the system console, so this limits the options that are available to the service to advise you of 

problems. Also, no user may be logged on at the console to receive notifications even if they were 

permitted, as services run in the background and are mostly started automatically, even before any user 

logs in. 

Windows and SQL Server Logs 

The most common cause of a service not being able to start is that the service account logon is failing for 

some reason. This could be caused by an incorrect or expired password, or the account could be locked 

out. Logon failures for services typically appear in the Windows system event log. More complex issues 

such as missing files cause entries to be written to the SQL Server logs. 

Check both the Windows and SQL Server logs as the first step in resolving service startup issues. 

Other Service-related Issues 

If SQL Server does start but cannot be accessed, the problem often relates to network issues that are 

discussed later in this module. In rare cases, the SQL Server scheduler might hang and stop accepting new 

connections. In this situation, and in similar situations, you should also try to connect to SQL Server using 

the Dedicated Administration Connection (DAC). You might need to use the DAC to access the instance 

and analyze the problem. On occasions, you might need to kill individual sessions that are causing the 

problem.

If SQL Server will not start but the issue isn't a logon issue, check the following: 


• Check whether the SQL Server log files indicate that the master or model database is corrupt. If either 

of these databases is corrupt, follow the procedures to recover the databases that were described in 

Module 7. 

• Check whether or not the file paths to the tempdb database files are accessible. The tempdb database 

is recreated each time the server instance starts but the path to the database files (as configured in 

the master database) must exist and be accessible. 

• Try to start the instance using the command prompt. If starting SQL Server from a command prompt 

does work, check the configuration of the service and make sure that the permission requirements 

are met. 

Question: What should be reviewed first when a service-related issue happens with SQL 

Server?


SQL Server Error Log 

Key Points 

The SQL Server log will often provide detailed information about startup issues. The log can be viewed 

using the log viewer as part of SSMS. 

However, if SQL Server cannot start, you cannot use the log viewer in SSMS to see the contents of the SQL 

Server logs. You can, however, open these logs in an editor such as NotePad, as shown in the example on 

the slide. 

The SQL Server Error log was discussed in more detail in Module 15. While the latest error log usually 

provides the most useful information, SQL Server keeps a set of archive log files and you should review 

those files as well, as problems may have been occurring for some time. 

Question: What is the problem with the instance startup in the example shown in the slide?

Windows Event Logs 

Key Points 


Windows services are not permitted to interact directly with the console. The main place they can use to 

tell you about issues is the Windows system event log. 

In addition, as with other applications, SQL Server writes quite an amount of information to the Windows 

application log over time. 

Both these logs should be checked periodically as not all errors that are logged in them produce 

symptoms that are apparent to users. 

Question: Which Windows log would logon failures for the SQL Server service appear in?


Demonstration 2A: Troubleshooting Service-related Issues 











Lesson 3 

Resolving Login and Connectivity Issues 


The final type of issues that database administrators who work with SQL Server are commonly called upon 

to resolve are connectivity and login issues. Users may have issues making connections to SQL Server, in 

relation to network names, protocols, and ports and the users may have issues with passwords that need 

to be resolved. In general, you should try to create logins that are based on Windows group membership. 

This removes the need for you as a database administrator to deal with most password and Windows 

account related issues. 

Objectives 


• Troubleshoot connectivity issues. 

• Troubleshoot login failures.


Troubleshooting Connectivity Issues 

Key Points 

The most common issue of this type that you might need to resolve is that users cannot connect to SQL 

Server at all. 

Eliminate the Network 

The first step in trying to resolve these issues is to determine whether or not the issue is related to 

network connectivity. You can often eliminate the network from consideration by attempting to connect 

via a shared memory connection while local to the server. If you cannot access SQL Server via a shared 

memory connection, you will need to troubleshoot the login or the service. Login troubleshooting is 

discussed in the next topic. Service troubleshooting was discussed in Lesson 2. 

Network Related Issues 

If the login using shared memory succeeds, the problem is almost always network related. In rare cases, 

you could see a problem with incompatible network libraries on the client and the server but most 

problems are much less subtle. 

Issue Actions 

Can the server name be resolved? The client system needs to be able to find the network 

address of the server. In TCP/IP networks, this will usually 

involve a DNS lookup. Make sure you can ping the server 

that SQL Server is installed on by name and that you see an 

IP address returned by the ping command.

(continued) 

Issue Actions 

Can the network and the server be 

reached? 

Is the Browser Service Running for 

Named Instances that are not using 

fixed ports? 

Is the client configured to use the 

right protocol and settings? 


While a server name might be successfully resolved to a 

network address, no connectivity may be possible between 

the client and server systems. On TCP/IP networks, make 

sure that you can successfully ping the server that SQL 

Server is installed on, assuming that it does not have the 

ability to echo ping commands disabled. In many cases, 

problems in this area will relate to incorrect subnet or 

default gateway/router addresses. 

If you are using named instances of SQL Server, the client 

systems need to be able to resolve the names of the 

instances to a port number. By default, this is achieved by 

connecting to the SQL Browser service on UDP port 1434. If 

the SQL Browser service is disabled, the named instances 

need to be configured to use fixed ports and the client 

systems need to be configured to access those ports, 

potentially by the creation of aliases. Make sure that the 

aliases are created for the correct network library such as 32 

bit vs. 64 bit. 

Is the protocol that the client is attempting to use to 

connect to the server, actually enabled on the server? Are 

the protocol settings appropriate? 

Is a firewall blocking connectivity? Check to make sure that there is no firewall that is blocking 

the ports that you are trying to connect over. If a firewall is 

blocking your access, an exception or rule will likely need to 

be configured in the firewall. 

Question: Why should a local connection be tested first?


Troubleshooting Login Failures 

Key Points 

The typical issue with this type of problem is that a user can establish a network connection to SQL Server 

but cannot log in. The troubleshooting actions that you need to perform depend upon the type of login 

that is being used: 

• For Windows Logins, make sure that SQL Server can connect to a Domain Controller to process the 

logins. To review potential issues, inspect the Windows Logs. 

• For SQL Server Logins, make sure that SQL Server is configured for SQL Server Authentication. SQL 

Server Logins can be created and can also be enabled, even when SQL Server is configured for 

Windows Authentication only. The most common error that is returned in this situation says that a 

trusted connection is not available. 

Also when working with SQL Server logins, make sure that the supplied password is correct and that the 

login has not been locked out by account policy. Another common problem for SQL Server logins is that 

the login might expire but the application that is trying to connect to SQL Server does not understand 

password expiry. This situation is common with applications that were designed for previous versions of 

SQL Server that did not implement account policy for SQL Server logins. 

For both login types, make sure that the login has permission to connect to SQL Server and that 

permission has been granted to the login to access the database that the login is attempting to connect 

to. This check should include the default database for the login. 

If a login problem is happening with a large number of different users, check to make sure that there isn't 

a logon trigger that is failing. When a logon trigger prevents users from connecting, the error message 

that is returned to interactive users indicates that a logon trigger prevented the connection. 

Question: Can a SQL Server Login be created and enabled when SQL Server is configured for 

Windows Authentication only?

Lesson 4 

Resolving Concurrency Issues 


SQL Server attempts to provide each user with the illusion that they are the only user on the system. It is 

not possible for SQL Server to provide this illusion in all circumstances and the actions of one user will 

impact on the actions of other users. 

It is important to understand the core concepts surrounding concurrency and to then see how to 

troubleshoot the more common blocking and deadlock issues. 

Objectives 


• Describe core concurrency concepts. 

• Troubleshoot blocking issues. 

• Troubleshoot deadlock issues.


Core Concurrency Concepts 

Key Points 

Consider your expectations when you transfer money from one bank account to another bank account. 

You would expect the same amount of money to come out of one account as is added to the other 

account. You would also expect that the entire operation either occurs or does not occur, even if some 

form of failure happens during your transfer. You would not expect the funds to be removed from one 

account and not to be added to the other account. 

Further consider what you would expect to see if you viewed the state of the two accounts while the 

transfer was occurring. You would expect to always see the accounts in a consistent state, based on either 

the balances of the accounts prior to the transfer or based on the balances of the accounts after the 

transfer was complete. You would not expect to ever be able to see the accounts in an intermediate state. 

One final issue to consider is what you expect to see when you viewed the state of the accounts on the 

day following the successful transaction. You would expect to see that the transaction was still shown as 

completed. 

ACID Properties 

The expectations that you have closely relate to a set of properties that the IT industry refers to as ACID 

properties that are expected of transactions: 

• Atomicity - A transaction has a defined start and end. It runs completely or is rolled back completely. 

• Consistency - The database is not left in an intermediate state after the transaction. All logical 

constraints are enforced. 

• Isolation - Transactions are prevented from interfering with each other. 

• Durability - After a transaction is committed, the details of the transaction are persisted in the system 

and will survive restarts.


To achieve the isolation requirements, SQL Server uses a locking scheme. Locking is a mechanism used by 

the database engine to synchronize access by multiple users to the same piece of data at the same time. 

The aim is to maximize concurrency while maintaining the ACID properties. 

Note Concurrency is discussed in detail in course 10776A: Developing Microsoft SQL 

Server 2012 Databases. 

Locking Behavior 

Before a transaction acquires a dependency on the current state of a data element, such as by reading or 

modifying the data, it must protect itself from the effects of another transaction that attempts to modify 

the same data. The transaction does this by requesting a lock on the data element. Locks have different 

modes, such as shared or exclusive. The locking mode defines the level of dependency the transaction has 

on the data. 

No transaction can be granted a lock that would conflict with the mode of a lock that has already been 

granted to another transaction on that same data. If a transaction requests a lock mode that conflicts with 

a lock that has already been granted on the same data, the database engine will block the requesting 

transaction until the first lock is released. 

For UPDATE operations, SQL Server always holds locks to the end of the transaction. For SELECT 

operations, it holds the lock protecting the row for a period that depends upon the transaction isolation 

level setting. All locks that are still held when a transaction completes are released, whether the 

transaction commits or rolls back. 

Locking is crucial for transaction processing and is normal behavior for the system. Problems only occur 

when locks are held for too long and other transactions are blocked for too long because of the locks that 

are being held. 

Question: Why would SELECT statements acquire locks in most cases?


Troubleshooting Blocking 

Key Points 

The most common issue that occurs with blocking is that applications appear to be hung. The symptoms 

of this are that the application is not busy and has work that needs to be done, yet no work is occurring. 

This situation generally indicates that the application is blocked while waiting for a resource of some type. 

You saw in the last topic that locking is the action of taking and holding locks that is used to implement 

concurrency control and that blocking is what happens to one process while it needs to wait for a 

resource that another process has locked. Blocking is a normal occurrence for systems and is not an issue. 

Excessive blocking can be an issue. 

Blocking can be monitored in real-time using SQL Server Activity Monitor and through Dynamic 

Management Views. You will see how to perform this monitoring in Demonstration 3A. 

The SQL Server data collector that was discussed in Module 18 can be used to collect data about blocking 

scenarios including information about all the processes that are involved with the blocking. The reports 

that are provided with the data collector via the management data warehouse can be useful when 

investigating blocking issues that have happened earlier. 

Question: What do you suspect that "excessive" blocking might refer to?

Demonstration 4A: Troubleshooting Blocking 











4. Open the 41 – Demonstration 4A.sql script file from within Solution Explorer. 



Troubleshooting Deadlocks 

Key Points 

Deadlock errors are a special type of blocking error where SQL Server needs to intervene as there would 

otherwise never be any locks released. The most common form of deadlock occurs when two transactions 

have locks on separate objects and each transaction requests a lock on the other transaction’s object. For 

example: 

• Task 1 holds a shared lock on row 1. 

• Task 2 holds a shared lock on row 2. 

• Task 1 requests an exclusive lock on row 2, but it cannot be granted until Task 2 releases the shared 

lock. 

• Task 2 requests an exclusive lock on row 1, but it cannot be granted until Task 1 releases the shared 

lock. 

• Each task must wait for the other to release the lock, which will never happen. 

A deadlock can occur when several long-running transactions execute concurrently in the same database. 

A deadlock also can occur as a result of the order in which the optimizer processes a complex query, such 

as a join.

How SQL Server Ends a Deadlock 


SQL Server ends a deadlock by automatically terminating one of the transactions. SQL Server does the 

following: 

• Chooses a deadlock victim. SQL Server gives priority to the process that has the highest deadlock 

priority. If both processes have the same deadlock priority, SQL Server rolls back the transaction that 

is the least costly to rollback. 

• Rolls back the transaction of the deadlock victim. 

• Notifies the deadlock victim’s application (with message number 1205). 

• Allows the other transaction to continue. 

Important In a multi-user environment, each client should check for message number 

1205, which indicates that the transaction was rolled back. If message 1205 is found, the 

application should reconnect and try the transaction again. 

Working with Deadlocks 

Deadlocks are normally not logged. The only indication that a deadlock has occurred is that an error 

message is returned to the client that has been selected as the victim. 

To monitor deadlocks use SQL Server Profiler and/or SQL Trace. There are several deadlock events 

available. The event with most information and that is easiest to read is the Deadlock Graph event. You 

will see an example of a deadlock graph in Demonstration 3B. 

Note that there are other tools that can help with deadlocks that are out of scope for this course: 

• Trace flags can be set to write deadlock information to the SQL Server Error Log. 

• Event Notifications can be generated. 

• Extended events can be tracked. 

Question: Have you experienced deadlocking problems in your current environment? If so, 

how did you determine that deadlocks were a problem, and how was it resolved?


Demonstration 4B: Troubleshooting Deadlocks 












Lab 20: Troubleshooting Common Issues 

Lab Setup 














Lab Scenario 

You need to be able to resolve common issues with SQL Server processes and services at the time they are 

occurring. There are five exercises that create issues. You should attempt to troubleshoot and resolve as 

many of these issues as possible.



Exercise 1 

Users of the Promote application are complaining that the application can no longer connect to the 

server. The application connects using the SQL Login PromoteApp. 

Exercise 2 

A junior DBA created a backup of the production AdminDB database to send to the development team 

for testing. Now users of that database are complaining they can no longer connect to it. 

Exercise 3 

Users are complaining that the job Get File List in SQL Server Agent is failing to execute. 

Exercise 4 

The performance of the AdminDB database has been steadily reducing since the database was deployed. 

Queries that once took seconds are now taking minutes. 

Exercise 5 

A strange situation is occurring with the CityDetails database. Most databases work slower as more users 

are added. However, the CityDetails database performs the worst when only a single user connects to it. 

The connection time for just this database can be very long and sometimes times out. Other databases 

are OK. 

Exercises 1 - 5: Troubleshoot and Resolve SQL Server Administrative Issues 

Scenario 

A number of issues have been reported by the users of the Proseware server. You need to troubleshoot 

and resolve the issues. 

The main tasks for each exercise are as follows: 

1. Read the supporting documentation for the exercise. 

2. Troubleshoot and resolve the issue. 

Task 1: Read the supporting documentation for the exercise 

• Read the supporting documentation for the exercise. 

Task 2: Troubleshoot and resolve the issue 

• Troubleshoot the issue. 

• Resolve the issue. 

• If you have difficulty, check the solution in the LAK. 

Results: After these exercise, you should have investigated and resolved a number of issues.



1. What can be used to monitor blocking issues? 

2. What happens when a deadlock occurs? 



1. Monitor your system and store historical data using Data Collector for example for easier 


2. Clearly identify underlying problems rather than fighting symptoms. 

3. Apply deadlock monitoring using SQL Trace.


Course Review and Evaluation 

Your evaluation of this course will help Microsoft understand the quality of your learning experience. 

Please work with your training provider to access the course evaluation form. 

Microsoft will keep your answers to this survey private and confidential and will use your responses to 

improve your future learning experience. Your open and honest feedback is valuable and appreciated.

Appendix A 

Core Concepts in SQL Server High Availability and 

Replication 

Contents: 

Lesson 1: Core Concepts in High Availability A-3 

Lesson 2: Core Concepts in Replication A-11 

A-1

A-2 Core Concepts in SQL Server High Availability and Replication 

Appendix Overview 

As you become a more experienced database professional, you are likely to need to implement more 

advanced technologies that are available within the Microsoft SQL Server platform. Two core areas are 

high availability and replication. 

In this appendix, you will be introduced to the core concepts surrounding each of these technologies. In 

particular, you will learn when to use each of these technologies. 

Objectives 

After reading this lesson, you will be able to: 

• Explain the different high availability options available for Microsoft SQL Server and know when to 

use each. 

• Explain the different replication options available for Microsoft SQL Server and know when to use 

each.

Lesson 1 

Core Concepts in High Availability 

Administering Microsoft SQL Server 2012 Databases A-3 

SQL Server provides a wide variety of options for ensuring the highest availability of servers and 

databases. It is important that you understand the core concepts involved and know how to choose 

between the available options. 

Objectives 


• Describe database mirroring. 

• Describe failover clustering. 

• Explain the role of AlwaysOn technologies. 

• Describe log shipping. 

• Choose appropriate use cases for each high availability option.


Discussion: Previous Experience with High Availability 

Key Points 

In this discussion, members of your class will share their experiences with high availability strategies. In 

particular, consider (but do not limit yourself to) the following questions: 

• What do you understand by the term "High Availability"? 

• What techniques have you used to try to achieve high availability? 

• How successful have these attempts been? 

High Availability is more than technology. It also involves defined processes, documentation, knowledge 

of the people and much more. If the staff involved do not know what to do when issues occur, the best 

technology will not help. A good backup strategy is also part of a high availability solution.

Database Mirroring 

Key Points 


Database mirroring is a software based solution for achieving high availability of databases that was 

introduced in Microsoft SQL Server 2005. The transaction log from a database on one server is 

continuously applied to a copy of the database residing on another server. Databases to be mirrored must 

be in full recovery model. 

Because an entirely separate server is used for the mirror partner, the chance of having a single point of 

failure is greatly reduced. While not generally desirable, the servers used in database mirroring could also 

be implemented using quite different hardware architectures. Database mirroring is, however, easier to 

maintain when the servers involved are similar, and when the disk layout of each server is identical. 

Two modes of operation are available. In high safety mode, the principal server sends update information 

to both its own transaction log and to the transaction log of the mirror partner, and then waits for the 

writes to occur on the partner's transaction log, as well as waiting for its own writes to occur. In high 

performance mode, the principal server sends the update information to both logs but only waits for its 

own log to be written. High performance mode sacrifices data consistency for performance. 

When a failure occurs, the mirror partner can take over the role of the principal. This can occur in two 

ways. The database administrator can initiate a manual failover or an automated failover can occur. 

Automated failovers require the following: 

• High safety mode. 

• The mirror partner must have been synchronized with the primary at the time of the failover. (This 

might not be the case if the mirror partner was catching up after a failure or network issue.) 

• A witness server has been configured.


A witness server can be any edition of SQL Server including the Express edition, and should reside on 

another physical server, separate to both the principal server and the mirror partner. The witness server is 

used to provide a quorum with the mirror partner server, where they can agree that the principal server 

has failed and that a failover should occur. During a failure, if an automated failover cannot occur, it is 

possible to "force service" by switching the mirror partner into the principal role, even though a loss of 

data could occur. 

Note that system databases such as master, msdb, tempdb, and the model database cannot be mirrored. 

SQL Server 2008 improved the performance of database mirroring through the introduction of log stream 

compression. While only a single mirror could be provided for each database, many more databases could 

be concurrently mirrored. 

Mirroring can improve the availability of databases, including times when routine maintenance such as 

applying service packs is needed. The data held on the mirror partner is not accessible unless a database 

snapshot is created on the mirror to provide read-only access to the data. 

The biggest limitation of database mirroring is that databases often have external dependencies such as 

logins in the master database. Mechanisms or processes need to be put in place to ensure that these 

dependent objects are present on both the servers.

Failover Clustering 

Key Points 


SQL Server failover clustering is built on Windows Server failover clustering. It requires each server to be a 

Windows Failover cluster node. Failover clustering is designed to protect against the failure of a server. 

Clients connect to a virtual SQL Server rather than to either physical server. 

Unlike database mirroring, when a failover occurs the entire instance fails over. This removes the 

complexity of maintaining external database dependencies because the system databases (such as the 

master database) are also failed over. Databases do not need to be in full recovery model. 

Servers involved in failover clustering should use identical hardware. A Cluster Validation Tool (CVT) is 

provided to check the configuration of a failover cluster before the cluster is created. Passing the tests 

provided by the CVT is a prerequisite for obtaining Microsoft support on the cluster configuration. 

Failover clustering uses a shared disk subsystem. It is important to note that only a single copy of the data 

is being held. This means that the disk subsystem needs to incorporate its own redundancy mechanisms. 

A SQL Server cluster exposes a virtual server to client systems. Regardless of which server is currently 

operating, the clients continue to connect to the same virtual server name or address. Each server 

monitors the other servers in the cluster, so that failover action can be initiated when necessary. This 

communication is normally carried out across a private network connection (often called a heartbeat 

network). The private network is kept separate to the public network connections from each server. 

At any point in time, each SQL Server instance is only running on a single server. When a server failover 

occurs, the SQL Server service for each instance on the secondary server must be restarted and databases 

recovered. This process can take some time, depending upon how long recovery takes for each database.


AlwaysOn Availability Groups 

Key Points 

SQL Server 2012 introduced the AlwaysOn technologies. One of these technologies, AlwaysOn Availablity 

Groups, provides an enterprise-level alternative to database mirroring. AlwaysOn Availability Groups must 

be installed on a Windows cluster node and improves on database mirroring in the following ways: 

Aspect Database Mirroring AlwaysOn Availability Groups 

Applies to Database Group of databases 

Replicas One Four 

Replica Usage Possible to make it available 

read-only via database snapshots 

but in practice not very useful 

Each replica can be made readonly 

and can be used for backups 

Replica Operation Mode Synchronous or Asynchronous Replicas can be synchronous or 

asynchronous. Up to two 

synchronous replicas are 

supported. Combinations of 

synchronous and asynchronous 

replicas are supported. 

Client Connection Options for automated 

redirection available 

Easier options for automated 

redirection available

Log Shipping 

Key Points 


Log shipping is a mature and reliable technology that was introduced in SQL Server 2000. Many third 

party organizations and users have also implemented their own variations on log shipping. In essence, log 

shipping is a simple repetitive process involving: 

• Backup the transaction log on the primary server. 

• Copy the transaction log to the secondary server. 

• Restore the transaction log on the secondary server. 

Each time the restore is carried out on the secondary server, the database restores are performed without 

the recovery option, so that additional transaction logs can be restored later. 

When a failure occurs, placing the secondary server into production is a manual task. No automation is 

provided for doing this within the product. 

Log shipping allows for multiple secondary servers.


Choosing Between High Availability Options 

Key Points 

The table above provides a comparison of a number of the aspects of each high availability option, as 

discussed in the previous four topics. Note that a high availability solution might comprise a combination 

of these technologies. 

With Failover Clustering, even though a single copy of data is held, the shared drive subsystem should 

always be configured with redundancy options. 

With Log Shipping, read-only access to the replica data is only available when Standby Mode has been 

chosen.

Lesson 2 

Core Concepts in Replication 


SQL Server provides a wide variety of options for replicating data between servers. It is important that you 

understand the core concepts involved and know how to choose between the available options. 

Objectives 


• Explain the publisher/subscriber metaphor that replication is based upon. 

• Describe snapshot replication. 

• Describe transactional replication. 

• Describe peer-to-peer transactional replication. 

• Describe merge replication. 

• Choose between the available replication options.


SQL Server Replication Architecture 

Key Points 

While SQL Server replication can play a role in high availability (particularly in relation to peer-to-peer 

transactional replication), the major role that it plays is related to the distribution of data. 

It is important to understand the terminology used by replication. 

• A Publisher is an instance that is publishing data for subscribers to consume. A database needs to be 

configured to allow publication of data contained within it. (In the metaphor, this is the publishing 

house). 

• An Article is the object being published. An article can comprise a table or a view. Either the entire 

table or view can be published, or an article can be based on vertical filtering (columns), horizontal 

filtering (rows) or both. (In the metaphor, this directly relates to the concept of an article within a 

magazine). 

• A Publication is a group of articles that are being published. It is the unit of subscription. (In the 

metaphor, this is the magazine). 

• A Distributor is used to move publications from publishers to subscribers. A distribution database is 

used to hold publications that need to be supplied to a subscriber. A distributor that is on the same 

local network as the publisher is called a Local Distributor. Other distributors (perhaps even in a 

different continent) are considered to be Remote Distributors. 

• A Subscriber is an instance that receives the publications. 

• An Agent is a service that performs operations needed by any of the replication roles.


A remote distributor might be used to minimize the network traffic between the distributor and a number 

of subscribers by placing the distributor close to the subscribers. In a push subscription, the distributor 

sends the data to the subscriber. In a pull subscription, the subscriber retrieves the data from the 

distributor.


Snapshot Replication 

Key Points 

Snapshot is the simplest form of replication. Periodically, the snapshot agent creates a copy of the 

published data. The entire copy of the data is then used to replace the data at the subscriber. 

Snapshot replication is useful in several situations: 

• If permitting out-of-date data at the subscriber is acceptable. Not all systems would allow this. 

• If the data does not change often, then having out-of-date data at the subscriber is more likely to be 

acceptable. 

• If the volume of data is very small, copying all the data is easier than trying to work out which data to 

copy. 

• If the number of changes that occurs to the data is very large, it might be less costly to recopy the 

entire data rather than to copy the changes as the size of the changes might be larger than the size 

of the source data. 

• The publisher is not a SQL Server database. (Publishing from an Oracle database is supported.)

Transactional Replication 

Key Points 


Transactional replication is used to send changes to subscribers shortly after the changes have occurred 

on the publishers. Transactional replication is initiated by first creating a snapshot of the data and 

applying the snapshot to the subscriber. There are several options available for creating this copy of the 

data, including taking a database backup and restoring it. Changes are applied in the same order and 

within the same transactional boundaries as they occurred at the publisher. 

Transactional replication should typically be regarded as one-way replication. In general, changes made at 

the subscriber are not sent back to the publisher; however there are configuration options to allow for 

updates at the subscriber. 

Transactional replication is useful in the following situations: 

• Incremental changes to data need to be applied to the subscriber shortly after they occur. 

• The application requires the delay between a change occurring and it being applied to be short. Note 

that this delay is configurable and might range from almost instantaneous to several hours. 

• The subscriber needs to see each change to the data that occurs. (This allows the subscriber to take 

actions on each change such as firing triggers). 

• A high volume of data modification activity occurs at the publisher. 

• The publisher is not a SQL Server database. (Publishing from an Oracle database is supported.)


Peer-To-Peer Transactional Replication 

Key Points 

"Allow peer-to-peer subscribers" is an option that can be configured on transactional replication 

publications. This can help to scale out a replication topology to allow read operations to occur on any 

node. 

Reads and writes can occur on all nodes but to prevent conflicts, an appropriate data partitioning scheme 

needs to be used. Write operations on any individual rows are still single node. While conflicts can be 

detected, they cause the replication to fail or the changes to be held. For this reason, the most important 

aspect of peer-to-peer transactional replication is designing the partitioning of the data held by each 

server to avoid any chance of conflicts from occurring. 

As a typical example, a company might have servers in London, Singapore, and Mumbai. Each row in a 

table would indicate which location the data has originated at. All rows are replicated to each server but a 

single row is never modified at more than one location. 

Peer-to-peer transactional replication is useful in the following scenarios: 

• Where a natural partitioning of the data exists. 

• Where the partitioning of the data matches the topology of the servers. 

• Where conflicts would rarely occur such as situations where each data row within a table is owned by 

a single server.

Merge Replication 

Key Points 


Merge replication is commonly used in simple client-server applications. Merge replication works by 

applying a set of triggers to the source tables and using the triggers to insert data into change tracking 

tables whenever data modifications occur. The merge agent is used to copy those changes across to 

subscribers whenever synchronization occurs. 

Merge replication is not transactionally consistent but does support non-SQL-Server nodes as part of the 

replication topology. The performance of merge replication usually suffers as the volume of data or the 

number of subscribers increases. 

Merge replication is useful in the following situations: 

• Multiple subscribers might update the data at the same time. Merge replication provides conflict 

detection and conflict correction. 

• Subscribers need to make changes to data while disconnected. 

• Conflicts occur during data changes on multiple subscribers. 

• Applications do not depend upon tables being transactionally consistent.


Choosing Between Replication Options 

Key Points 

The table above provides a comparison of a number of the aspects of each replication option, as 

discussed in the previous four topics.


Lab 1: Introduction to SQL Server and Its 

Toolset 

Lab Setup 


complete the following step: 


Exercise 1: Verify SQL Server Component Installation 

Task 1: Check that Database Engine and Reporting Services have been installed for the 

MKTG instance 

1. Click Start, click All Programs, click Microsoft SQL Server 2012, click Configuration Tools, and 

then click SQL Server Configuration Manager. 

2. In the left-hand pane of the SQL Server Configuration Manager window, click SQL Server Services. 

3. In the right-hand pane, ensure that the following services are listed for the MKTG instance: 

• SQL Server (MKTG) 

• SQL Full-text Filter Daemon Launcher (MKTG) 

• SQL Server Reporting Services (MKTG) 

• SQL Server Agent (MKTG) 

Task 2: Note the services that are installed for the default instance 


2. In the right-hand pane, ensure that the following services are listed for the default instance: 

• SQL Server (MSSQLSERVER) 

• SQL Full-text Filter Daemon Launcher (MSSQLSERVER) 

• SQL Server Analysis Services (MSSQLSERVER) 

• SQL Server Agent (MSSQLSERVER) 

Task 3: Ensure that all required services including SQL Server Agent are started and set 

to autostart for both instances 

1. Check that all the services for the MKTG instance have a Start Mode of Automatic. Ignore the SQL 

Full-text Filter Daemon Launcher service at this time. 

2. Check that all the services for the default instance have a Start Mode of Automatic. Ignore the SQL 

Full-text Filter Daemon Launcher service at this time. 

L1-1

L1-2 Module 1: Introduction to SQL Server 2012 and Its Toolset 

Exercise 2: Alter Service Accounts for New Instance 

Task 1: Change the service account for the MKTG database engine 


2. In the right-hand pane, right-click SQL Server (MTKG), and select Properties. 

3. In the Account Name text box, type AdventureWorks\PWService. 

4. In the Password text box, type Pa$$w0rd. 

5. In the Confirm Password text box, type Pa$$w0rd and click OK. 

6. In the Confirm Account Change window, click Yes. 

Task 2: Change the service account for the MKTG SQL Server Agent 


2. In the right-hand pane, right-click SQL Server Agent (MTKG), and select Properties. 

3. In the Account Name text box, type: 

• AdventureWorks\PWService. 

4. In the Password text box, type Pa$$w0rd. 

5. In the Confirm Password text box, type Pa$$w0rd and click OK. 

6. Right-click SQL Server Agent (MTKG) and select Start to restart the service. 

Exercise 3: Enable Named Pipes Protocol for Both Instances 

Task 1: Enable the named pipes protocol for the default instance 

1. In the left-hand pane of the SQL Server Configuration Manager window, expand SQL Server 

Network Configuration and then click Protocols for MSSQLSERVER. 

2. In the right-hand pane, if the Named Pipes protocol is not enabled, right-click Named Pipes and 

select Enable. In the Warning window, click OK. 

Task 2: Enable the named pipes protocol for the MKTG instance 

1. In the left-hand pane of the SQL Server Configuration Manager window, click Protocols for MKTG. 

2. In the right-hand pane, if the Named Pipes protocol is not enabled, right-click Named Pipes and 

select Enable. In the Warning window, click OK. 

Task 3: Restart both database engine services 


2. Right-click SQL Server (MSSQLSERVER) and select Restart. 

3. Right-click SQL Server (MKTG) and select Restart. 


5. In the toolbar, click the Refresh icon.

Exercise 4: Create an Alias for AdvDev 


Lab 1: Introduction to SQL Server and Its Toolset L1-3 

1. In the left-hand pane of the SQL Server Configuration Manager window, expand SQL Native Client 

11.0 Configuration (32bit) and click Client Protocols. 

2. Confirm that the Named Pipes protocol is Enabled. 

3. In the left-hand pane, click Aliases. 

4. In the left-hand pane, right-click Aliases and select New Alias. 

5. In the Alias – New window, in the Alias Name text box, type AdvDev. 

6. In the Protocol drop-down list box, select Named Pipes. 

7. In the Server text box, type .\MKTG and click OK. 



11.0 Configuration and click Client Protocols. 


3. In the left-hand pane, click Aliases. 


5. In the Alias – New window, in the Alias Name text box, type AdvDev. 


7. In the Server text box, type .\MKTG and click OK. 

Task 3: Use SQL Server Management Studio to connect to the alias to ensure it works as 

expected 

1. Click Start, click All Programs, click Microsoft SQL Server 2012, and then click SQL Server 


2. In the Connect to Server window, ensure that Server Type is set to Database Engine. 

3. In the Server name text box, type AdvDev. 


5. In Object Explorer, under AdvDev expand Databases. 

Note: The databases that are present include at least the following: System Databases, 

Database Snapshots, ReportServer$MKTG, and ReportServer$MKTGTempDB. 


7. Close SQL Server Configuration Manager.

L1-4 Module 1: Introduction to SQL Server 2012 and Its Toolset 

Challenge Exercise 5: Ensure SQL Browser is Disabled and Configure a 

Fixed TCP/IP Port (Only if time permits) 

Task 1: Configure the TCP port for the MKTG database engine instance to 51550 

1. In the Virtual Machine window, from the Start menu, click All Programs, click Microsoft SQL Server 

2012, click Configuration Tools, and then click SQL Server Configuration Manager. 


Network Configuration and then click Protocols for MKTG. 

3. Right-click the TCP/IP protocol and select Properties. 

4. In the TCP/IP Properties window, click IP Addresses tab. 

5. Scroll to the bottom of the screen, under the IP All section, clear the value for TCP Dynamic Ports. 

6. For TCP Port, type 51550, and click OK. 

7. In the Warning window, click OK. 

8. In the left-hand pane, click SQL Server Services. 

9. Right-click SQL Server (MKTG) and select Restart. 


11. In the toolbar, click the Refresh icon and make sure the service starts. 

Task 2: Disable the SQLBrowser service 


2. In the right-hand pane, if the state for the SQL Server Browser is Running, right-click SQL Server 

Browser and click Stop. 

3. Right-click the SQL Server Browser and click Properties. 

4. In the SQL Server Browser Properties window, in the Service tab, set the Start Mode to Disabled and 

click OK. 



Lab 2: Preparing Systems for SQL Server 

Lab Setup 











7. In Solution Explorer, double-click the query 00-Setup.sql. When the query window opens, click 

Execute on the toolbar. 

Exercise 1: Adjust Memory Configuration 

Task 1: Check total server memory 

1. Click Start, right-click Computer, and click Properties. 

2. Write down the value for Installed memory (RAM). 

3. Close the System window. 

Task 2: Check the memory allocated to the default instance 

1. Click Start, click All Programs, click Microsoft SQL Server 2012, and click SQL Server 


2. In the Connect to Server window, type AdventureWorks for the Server name and click Connect. 

3. In Object Explorer, right-click the AdventureWorks server instance, and click Properties. 

4. In the Select a page pane click Memory. 

5. Write down the values for Minimum server memory (in MB) and Maximum server memory (in 

MB), and click Cancel. 

6. In SQL Server Management Studio, from the File menu, click Exit. 

L2-5

L2-6 Module 2: Preparing Systems for SQL Server 2012 

Task 3: Check the memory allocated to the MKTG instance 



2. In the Connect to Server window, type Proseware for the Server name and click Connect. 

3. In Object Explorer, right-click the Proseware server instance, and click Properties. 


5. Write down the values for Minimum server memory (in MB) and Maximum server memory (in 

MB), and click Cancel. 

6. In SQL Server Management Studio, from the File menu, click Exit. 

Task 4: Decide if the memory allocation is appropriate. If not, make the required 

changes to the memory configuration 

1. Review the Required Memory Configuration from the Supporting Documentation in the Student 

Manual. 

2. Calculate the Maximum memory for the AdventureWorks server instance as follows: 

• Example calculation (actual values depend upon VM configuration) 

• Max Memory = (Server Memory – 1.5GB) * 0.6 

• Max Memory = (3.0 – 1.5) * 0.6 

• Max Memory = 0.9 (approximate) 

3. Calculate the Maximum memory for the Proseware server instance as follows: 



• Max Memory = (3.0 – 1.5) * 0.4 







8. Set the Maximum server memory (in MB) to the value 900, and click OK. 

Note: A more accurate value for 0.9GB would have been 921MB, but the value 900 has 

been used for simplicity.

9. In Object Explorer click Connect, and click Database Engine. 

Lab 2: Preparing Systems for SQL Server L2-7 





Note: A more accurate value for 0.6GB would have been 614MB, but the value 600 has been 

used for simplicity. 

Exercise 2: Pre-installation Stress Testing 

Task 1: Configure SQLIOSIM 

1. In the folder D:\10775A_Labs\10775A_02_PRJ, right-click sqliosimx64.exe and click Run as 

administrator. 

2. In the Microsoft SQL Server IO Simulator window, note the agreement and click Yes. 

3. In the WinZip Self-Extractor - SQLIOS~1.EXE window click Unzip. 

4. In the WinZip Self-Extractor window click OK. 

5. In the WinZip Self-Extractor - SQLIOS~1.EXE window click Close. 

6. Open Windows Explorer and navigate to the C:\SQLIOSimX64 folder. Note that two versions of 

SQLIOSim are supplied: a command line version and a GUI version. Right-click SQLIOSim.exe, and 

click Run as administrator. 

7. In the Files and Configuration window click on the line containing C:\sqliosim.mdx, then click 

Remove. 

8. In the Files and Configuration window click on the line containing C:\sqliosim.ldx, then click 

Remove. 

9. In the Files and Configuration window click on the line containing D:\sqliosim.ldx, then click 

Remove. 

10. In the Files and Configuration window click on the line containing L:\sqliosim.mdx, then click 

Remove. 

11. In the Files and Configuration window click on the line containing D:\sqliosim.mdx, then in the 

Size (MB) change the value from 4096 to 100, also change the Max Size value from 8192 to 200, 

and the Increment to 20, then click Apply. 

12. On the line containing L:\sqliosim.ldx, set the Size (MB) to 50, the Max Size to 100, the 

Increment to 10, and click Apply. 

13. Change the Cycle Duration (sec) value from 300 to 60. 

14. Ensure that the Delete Files at Shutdown checkbox is checked, and click OK to complete the 

configuration.

L2-8 Module 2: Preparing Systems for SQL Server 2012 

Task 2: Execute SQLIOSIM 

1. In the SQLIOSIM window from the Simulator menu, click Start. 

2. Wait for the test to complete in about 1 minute. While the test is running, note the information that 

is displayed. 

3. In the SQLIOSim window click OK. 

Task 3: Review the results from executing SQLIOSIM 

1. If any errors are returned in red, review the errors. 

2. Locate the final summary for file D:\sqliosim.mdx and note the Running Average IO 

Duration (ms). 

3. Locate the final summary for file L:\sqliosim.ldx and note the Running Average IO 

Duration (ms). 

Note: The value returned for each drive depends upon the speed of the hardware. A typical 

value for either drive would be 15. 

4. In the SQLIOSim window from the File menu click Exit. 

Challenge Exercise 3: Check Specific I/O Operations (Only if time permits) 

Task 1: Install the SQLIO Utility 

1. In the folder D:\10775A_Labs\10775A_02_PRJ, right-click SQLIO.msi and click Install. 

2. In the Welcome to the SQLIO Setup Wizard window click Next. 

3. In the License Agreement window, note the agreement click the I Agree radio button, and click 

Next. 

4. In the Select Installation Folder window click the Everyone radio button, and click Next. 

5. In the Confirm Installation window click Next. 

6. In the Installation Complete window click Close. 

Task 2: Configure and Execute the SQLIO Utility 

1. Review the Supporting Documentation in the Student Manual for details of the SQLIO tests to be 

performed. 

2. In Windows Explorer, navigate to the C:\Program Files (x86)\SQLIO folder. 

3. Double-click the file param.txt. Place a # at the beginning of the line c:\testfile.dat. Remove the # 

from the line beginning d:\testfile.dat. 

4. From the File menu click Exit. 

5. In the Notepad window click Save. 

6. In Windows Explorer, double-click the file C:\Program Files (x86)\SQLIO\Using SQLIO.rtf. Note 

the examples and descriptions of the available parameters for SQLIO.

7. Close the using SQLIO.rtf - WordPad window. 

Lab 2: Preparing Systems for SQL Server L2-9 

8. From the Start menu, click All Programs, click Accessories, right-click Command Prompt and 

click Run as administrator. 

9. Type CD \Program Files (x86)\SQLIO and press Enter. 

10. Type the following command and press Enter: 

sqlio.exe -kR -s60 -fsequential -o8 –b64 -LS -Fparam.txt timeout /T 60 

11. Look through the output of the command, note the values returned for IOs/sec and MBs/sec. These 

values are commonly referred to as IOPS and throughput. Note the minimum, maximum and 

average latency. 

12. Type the following command and press Enter: 

sqlio.exe -kW -s60 -frandom -o8 –b8 -LS -Fparam.txt timeout /T 60 

13. Look through the output of the command, note the values returned for IOs/sec and MBs/sec. These 

values are commonly referred to as IOPS and throughput. Note the minimum, maximum and 

average latency. 

14. Type Exit and press Enter.


Lab 3: Installing and Configuring SQL 

Server 

Lab Setup 













8. On the host system, in the Virtual Machines list in Hyper-V Manager, right-click the 

10775A-MIA-SQL1 virtual machine and click Settings. 



10. In the DVD Drive properties pane, click Image file, and click browse. 

11. Navigate to the file C:\Program Files\Microsoft Learning\10775\Drives\10775A-MIA-SQL1 



Exercise 1: Review installation requirements 

Task 1: Review the supporting documentation prior to installation 

• Read the supporting documentation in the student manual. 

Task 2: Create the folders that are required for the data and log files 

• Using Windows Explorer, create the following folders: 

• D:\MKTGDEV 

• L:\MKTGDEV 

L3-11

L3-12 Module 3: Installing and Configuring SQL Server 2012 

Exercise 2: Install the SQL Server Instance 

Task 1: Based on the requirements reviewed in exercise 1, install another instance of 

SQL Server 

1. In the Virtual Machine window, in the AutoPlay window (which should now have popped up) click 

Run SETUP.EXE and wait for SQL Server Setup to start. (If the AutoPlay window has not launched, 

or you have inadvertently closed it, double-click SETUP.EXE in the root of the new drive that has 

been mounted when you connected the ISO file to your virtual machine). 

2. In the SQL Server Installation Center window, click on the Installation tab. 

3. Click New SQL Server stand-alone installation or add features to an existing installation from 

the list of available options and wait for SQL Server setup to start. 

4. In the Setup Support Rules window, click Show details and note that the list of rules that has been 

checked. 

5. In the Setup Support Rules window, click OK. 

6. Make sure that Send feature usage data to Microsoft is not selected and click Next. 

Note In general, you are encouraged to choose this feature as it helps Microsoft 

produce a better product. In this case, we are deselecting it because we are in an isolated 

environment without network access within the virtual machine. 

7. In the Product Updates window, uncheck Include SQL Server product updates and click Next. 

(Note the next screen might take some time to display.) 

8. In the Setup Support Rules page, click Show details (if visible) and read the installation checklist 

and check to make sure the Status for items have Passed. Note any warnings that are listed and 

click Next. 

9. In the Installation Type page, ensure the option button Perform a new installation of SQL 

Server 2012 is selected and then click Next. 

10. In the Product Key window, click Next. 

11. In the License Terms page, note the Microsoft Software License Terms and check I accept the 

license terms. 

12. In the Setup Role page, ensure that SQL Server Feature Installation is selected and click Next. 

13. In the Feature Selection page, under the Instance Features check Database Engine Services and 

click Next. 

14. In the Installation Rules page, click Show details, note the list of rules and the status of each rule 

and click Next. 

15. In the Instance Configuration page, ensure that Named instance is checked and type MKTGDEV 

in the Named instance field and click Next. 

16. In the Disk Space Requirements page, read the Disk Usage Summary and then click Next.

Lab 3: Installing and Configuring SQL Server L3-13 

17. In the Server Configuration page, click the Account Name field for the SQL Server Database 

Engine row and select from the drop-down list. 

18. In the Select User, Computer, Service Account, or Group window, in the Enter the object name to 

select (Examples): dialog box type AdventureWorks\PWService, click Check Names and click 

OK. 

19. In the Password column for the SQL Server Database Engine row, type Pa$$w0rd. 

20. In the Server Configuration page, click the Account Name field for the SQL Server Agent row 

and click from the drop-down list. 

21. In the Select User, Computer, Service Account, or Group window, in the Enter the object name to 

select (Examples): dialog box type AdventureWorks\PWService, click Check Names and click 

OK. 

22. In the Password column for the SQL Server Agent row, type Pa$$w0rd. 

23. In the Server Configuration page, in the Service Accounts tab, and in the Startup Type dropdown 

list for the SQL Server Agent select Automatic. 

24. Click the Collation tab, ensure that SQL_Latin1_General_CP1_CI_AS is selected and click Next. 

25. In the Database Engine Configuration page, on the Server Configuration tab, in the 

Authentication Mode section, ensure that Mixed Mode (SQL Server authentication and 

Windows authentication) is selected. 

26. In the Enter password textbox, type Pa$$w0rd. 

27. In the Confirm password textbox, type Pa$$w0rd. 

28. Click Add Current User, this will add the user ADVENTUREWORKS\administrator 

(Administrator) to the list of Administrators. 

29. Click the Data Directories tab, change the User database directory to D:\MKTGDEV. 

30. Change the User database log directory to L:\MKTGDEV. 

31. Change the Temp DB directory to D:\MKTGDEV. 

32. Change the Temp DB log directory to L:\MKTGDEV. 

33. Click the FILESTREAM tab, and ensure that Enable FILESTREAM for Transact-SQL access is not 

selected and click Next. 

34. In the Error Reporting page, make sure that Send Windows and SQL Server Error Reports to 

Microsoft or your corporate report server is not checked, then click Next. 

35. In the Installation Configuration Rules page, Show details, review the list of rules, and click 

Next. 

36. In the Ready to Install page, review the summary and click Install. 

37. In the Complete page, click Close. 

38. Close the SQL Server Installation Center window.


Exercise 3: Perform Post-installation Setup and Checks 

Task 1: Check that the services for the new SQL Server instance are running 




3. In the right-hand pane, ensure that the following services are listed as running for the MKTGDEV 

instance: 

• SQL Server (MKTGDEV) 

• SQL Server Agent (MKTGDEV) 

Task 2: Configure both 32 bit and 64 bit aliases for the new instance 


Network Configuration and then click Protocols for MKTGDEV. 

2. In the right-hand pane, right-click Named Pipes and select Enable. 

3. In the Warning window, click OK. 


5. Right-click SQL Server (MKTGDEV) and select Restart. 


7. In the toolbar, click the Refresh icon. 


11.0 Configuration (32bit) and click Client Protocols. 



11. In the Alias – New window, in the Alias Name text box, type PWDev. 


13. In the Server text box, type .\MKTGDEV and click OK. 


11.0 Configuration and click Client Protocols. 



17. In the Alias – New window, in the Alias Name text box, type PWDev. 


19. In the Server text box, type .\MKTGDEV and click OK. 


Task 3: Connect to the new instance using SSMS 

Lab 3: Installing and Configuring SQL Server L3-15 

1. Click Start, click All Programs, click Microsoft SQL Server 2012, and then click SQL Server 


2. In the Connect to Server window, ensure that Server Type is set to Database Engine. 

3. In the Server name text box, type PWDev. 


5. In Object Explorer, under PWDev expand Databases. 


Challenge Exercise 4: Configure Server Memory (Only if time permits) 

Task 1: Review the current memory available on the server 

1. Click Start, right-click Computer, and click Properties. 

2. Write down the value for Installed memory (RAM). 

Task 2: Determine an appropriate memory allocation for each instance 

1. Review the Required Memory Configuration from the Supporting Documentation in the Student 

Manual. 

2. Calculate the Maximum memory for the AdventureWorks server instance as follows: 



• Max Memory = (3.0 – 1.0) * 0.4 


3. Calculate the Maximum memory for the Proseware server instance as follows: 



• Max Memory = (3.0 – 1.0) * 0.3 


4. Calculate the Maximum memory for the PWDev server instance as follows: 



• Max Memory = (3.0 – 1.0) * 0.3 

• Max Memory = 0.6 (approximate)


Task 3: Configure each instance appropriately 







Note A more precise value could have been used but the value 800 has been used for 

simplicity. 






Note A more precise value for 1.0GB could have been used but the value 600 has been 

used for simplicity. 


12. In the Connect to Server window, type PWDev for the Server name and click Connect. 

13. In Object Explorer, right-click the PWDev server instance, and click Properties. 



Note A more accurate value for 1.0GB could have been used but the value 600 has 

been used for simplicity. 

16. Close SQL Server Management Studio.


Lab 4: Working with Databases 

Lab Setup 













Exercise 1: Adjust tempdb Configuration 

Task 1: Adjust the size of tempdb 

1. Review the requirement for tempdb size in the Supporting Documentation. 

2. In Object Explorer expand the Proseware server, expand Databases, and expand System 

Databases. Right-click the master database and click New Query. 

3. Enter the following statements and click Execute: 

USE master; 

GO 

ALTER DATABASE tempdb 

MODIFY FILE ( NAME = tempdev, SIZE = 30MB ); 

GO 


MODIFY FILE ( NAME = templog, SIZE = 10MB ); 

GO 

Task 2: Check that the tempdb size is still correct after a restart 




3. In the right-hand pane, right-click the service SQL Server (MKTG) and click restart. 

4. In Object Explorer, right-click the tempdb database and click Properties. 

5. In the Database Properties – tempdb window, click Files in the Select a page pane. 

6. In the Database files list, check that the initial size of the data file is 30 and the initial size of the 

log file is 10. 

L4-17

L4-18 Module 4: Working with Databases 

Exercise 2: Create the RateTracking Database 

Task 1: Create the database 

1. Review the supplied requirements in the supporting documentation for the exercise. 




USE master; 

GO 

CREATE DATABASE RateTracking 

ON 

( NAME = RateTracking_dat, 

FILENAME = 'D:\MKTG\RateTracking.mdf', 

SIZE = 10MB, MAXSIZE = 100MB, 

FILEGROWTH = 10MB 

) 

LOG ON 

( NAME = RateTracking_log, 

FILENAME = 'L:\MKTG\RateTracking.ldf', 

SIZE = 20MB, 

MAXSIZE = UNLIMITED, 


); 

GO 

Task 2: Create the required filegroups and files 

1. Review the supplied requirements in the supporting documentation for the required files and 

filegroups. 




USE master; 

GO 

ALTER DATABASE RateTracking 

ADD FILEGROUP USERDATA; 

GO 


ADD FILE 

( NAME = RateTracking_dat_1, 

FILENAME = 'D:\MKTG\RateTracking_1.ndf', 

SIZE = 20MB, 

MAXSIZE = 100MB, 


) TO FILEGROUP USERDATA; 

GO 

(code continued on next page)


ADD FILE 



SIZE = 20MB, 



) TO FILEGROUP USERDATA; 

GO 


ADD FILEGROUP ARCHIVE; 

GO 


ADD FILE 



SIZE = 200MB, 



) TO FILEGROUP ARCHIVE; 

GO 


ADD FILE 



SIZE = 200MB, 



) TO FILEGROUP ARCHIVE; 

GO 

Task 3: Change the default filegroup for the database 

Lab 4: Working with Databases L4-19 

1. Review the supplied requirements in the supporting documentation for the default filegroup. 




USE master; 

GO 

ALTER DATABASE RateTracking MODIFY FILEGROUP USERDATA DEFAULT; 

GO

L4-20 Module 4: Working with Databases 

Exercise 3: Attach the OldProspects Database 

Task 1: Copy the database files 

• In Windows Explorer, copy the files as specified below: 

Filename Source Folder Destination Folder 

OldProspects.mdf D:\10775A_Labs\10775A_04_PRJ D:\MKTG 

OldProspects.ldf D:\10775A_Labs\10775A_04_PRJ L:\MKTG 

Task 2: Attach the database to the MKTG instance 

1. In Object Explorer, expand the Proseware server and expand Databases. 

2. Right-click Databases and click Attach. 

3. Click Add and navigate to the file D:\MKTG\OldProspects.mdf and click OK. 

4. Click the ellipsis beside the Current File Path for the log entry and navigate to the file 

L:\MKTG\OldProspects.ldf and click OK. 

5. Click OK to attach the database and note that OldProspects now appears in the list of databases in 

Object Explorer. 

Challenge Exercise 4: Add Multiple Files to tempdb (Only if time permits) 

Task 1: Review the tempdb file requirements 

• In the Supporting Documentation review the tempdb Requirements From The Consultant section. 

Task 2: Move existing files 




USE master; 

GO 


MODIFY FILE (NAME = tempdev, FILENAME = 'D:\MKTG\tempdb.mdf'); 


MODIFY FILE (NAME = templog, FILENAME = 'L:\MKTG\templog.ldf'); 

GO

Task 3: Add new files 

Lab 4: Working with Databases L4-21 




USE master; 

GO 


ADD FILE ( NAME = N'tempdev2', 

FILENAME = N'D:\MKTG\tempdb_file2.ndf' , 

SIZE = 20MB, 

FILEGROWTH = 10MB, 

MAXSIZE = UNLIMITED ); 




SIZE = 20MB, 






SIZE = 20MB, 



GO 

Task 4: Restart the server and check file locations 




3. In the right-hand pane, right-click the service SQL Server (MKTG) and click restart. 

4. In Object Explorer, right-click the tempdb database and click Properties. 

5. In the Database Properties – tempdb window, click Files in the Select a page pane. 

6. Make sure that the files listed match the requirements.

Module 5: Understanding SQL Server 2012 Recovery 

Models 

Lab 5: Understanding SQL Server Recovery 

Models 

Lab Setup 









6. In the Open Project window, open the project D:\10775A_Labs\10775A_05_PRJ 

\10775A_05_PRJ.ssmssln. 



Exercise 1: Plan a Backup Strategy 

Task 1: Review the business requirements 

• Review the supplied business requirements in the supporting documentation for the exercise. 

Task 2: Determine an appropriate backup strategy for each database 

• There is no one correct answer. The options provided below are an example strategy that would 

meet the requirements. 

For the MarketDev database: Full Recovery Model 

Type of Backup Scheduled 

Full 7:00pm Daily 

Log Every 20 minutes, starting at 8:20am 

and continuing till 6:00pm 

Notes: 

• Full database backup should complete in approximately 3.4 hours (20GB/100MB per minute). 

This means that you cannot employ only a full database backup strategy as it would not meet 

the RPO. The full database backup should complete by 10:24pm which is within the available 

time window for backups. 

L5-23

L5-24 Module 5: Understanding SQL Server 2012 Recovery Models 

• Each log backup should complete in approximately 3.4 minutes (1GB per hour / 3 log backups 

per hour /100 MB per minute). This fits within the 20 minute interval and meets the RPO. 

• Full database restore should complete in approximately 4.3 hours (20GB/80MB per minute). 

Log file restore should complete in approximately 2.1 hours (10 hours * 1GB per hour /80MB 

per minute) and meets the RTO. 

For the Research database: Simple Recovery Model 

Type of Backup Scheduled 

Full 6:30pm Daily 

Notes: 

• Recovery to last full daily database backup complies with the RPO. 

• Daily backup should complete in approximately 2 minutes (200MB/100MB per minute). 

• Full restore should complete in approximately 2.5 minutes and complies with RTO 

(200MB/80MB per minute). 

Exercise 2: Configure Recovery Models 

Task 1: Review and adjust the current database recovery models 

1. The recovery model for the MarketDev database is Simple and should be Full. Adjust the model by 

the following steps: 

1. In SSMS, in Object Explorer expand the Proseware server, right-click Databases and click 

Refresh. 

2. Expand Databases, right-click MarketDev and click Properties. 

3. In the Select a page pane, click Options. 

4. In the right hand pane, choose Full from the Recovery model drop down list and click OK. 

2. The recovery model for the Research database is correct and doesn’t need to be modified. 

Challenge Exercise 3: Review Recovery Models and Strategy (Only if time 

permits) 

Task 1: Review the RPO and RTO requirements for the databases 

• The supporting documentation includes details of the business continuity requirements for the 

databases. You need to review this documentation. 

Task 2: Review the existing recovery models and backup strategies 

• The supporting documentation also includes details of the backup strategy for the databases. You 

need to review this documentation.

Task 3: Indicate whether or not the strategy would be successful 

Lab 5: Understanding SQL Server Recovery Models L5-25 

1. For the CreditControl database, a Full backup would take approximately 3.4 hours (20GB/100MB 

per minute). This would not satisfy the requirements for the time window as the Wednesday 6am 

Full backup would not complete before office hours start. 

2. For the PotentialIssue database, the 15 minute log backups would meet the RPO. A Full restore 

should take approximately 24 minutes ((200MB + (7 days * 24 hours) * 10MB per hour) / 80MB per 

minute) which meets the RTO. The Full database backup would complete in approximately 2 

minutes (200MB/100MB per minute) which means that the Full database would complete in the 

available time window. The backup strategy for the PotentialIssue database meets the business 

requirements.

Module 6: Backup of SQL Server Databases 

Lab 6: Backup of SQL Server Databases 

Lab Setup 









6. In the Open Project window, open the project D:\10775A_Labs\10775A_06_PRJ 

\10775A_06_PRJ.ssmssln. 



Exercise 1: Investigate Backup Compression 

Task 1: Create a database backup without compression 

1. Using Windows Explorer create a new folder L:\SQLBackups. 

2. In Object Explorer, in SQL Server Management Studio, expand the Proseware server, expand 

Databases, right-click the MarketDev database, click Tasks, and click Back Up. 

3. In the Back Up Database – MarketDev window click Remove. 

4. In the Back Up Database – MarketDev window click Add. 

5. In the File name textbox type L:\SQLBackups\MarketDev_Full_Uncompressed.BAK and click 

OK. 


7. In the Set backup compression drop-down list, click Do not compress backup, and click OK. 

8. In the Microsoft SQL Server Management Studio window click OK. 

Task 2: Create a database backup with compression 

1. In Object Explorer, right-click the MarketDev database, click Tasks, and click Back Up. 



4. In the File name textbox type L:\SQLBackups\MarketDev_Full_Compressed.BAK and click OK. 

L6-27

L6-28 Module 6: Backup of SQL Server Databases 


6. In the Set backup compression drop-down list, click Compress backup, and click OK. 


Task 3: Compare the file sizes created 

1. In Windows Explorer, navigate to the folder L:\SQLBackups and note the size of the compress and 

uncompressed backup files. 

2. Calculate the space savings provided by compression as: 

SpaceSavings=(Uncompressed size–Compressed size)*100/Uncompressed size 

Note A typical value would be (233-66)*100/233 = 72% saving. 

Exercise 2: Transaction Log Backup 


1. In Solution Explorer, double-click the file 61 – Workload File.sql to open it. 

2. On the Toolbar click Execute. 

Task 2: Backup the transaction log on the MarketDev database 




4. In the File name textbox type L:\SQLBackups\MarketDev_Log_Compressed.BAK and click OK. 

5. From the Backup type drop-down list box, select Transaction Log. 




Exercise 3: Differential Backup 




Task 2: Create a differential backup of the MarketDev database 



3. In the Back Up Database – MarketDev window click Add.

Lab 6: Backup of SQL Server Databases L6-29 

4. In the File name textbox type L:\SQLBackups\MarketDev_Differential_Compressed.BAK and 

click OK. 

5. From the Backup type drop-down list box, select Differential. 




9. Using Windows Explorer, note the size of the differential backup L:\SQLBackups 

\MarketDev_Differential_Compressed.BAK compared to the full backup 

L:\SQLBackups\MarketDev_Full_Compressed.BAK. 

Note A typical value for the Differential backup size would be 240KB. A typical value for 

the Full backup size would be 66 MB. 




Task 4: Append a differential backup to the previous differential backup file 


2. Ensure that the Destination shows L:\SQLBackups\MarketDev_Differential_Compressed.BAK. 

3. From the Backup type drop-down list box, select Differential. 


5. In the Overwrite media option ensure that Append to the existing backup set is selected. 



8. Using Windows Explorer, note that the size of the Differential backup has increased. The file now 

contains two backups. 

Note A typical value for the backup file size would be 54 MB. 

Exercise 4: Copy-only Backup 

Task 1: Create a copy-only backup of the MarketDev database, ensuring to choose to 

verify the backup 




4. In the File name textbox type L:\SQLBackups\MarketDev_Copy_Compressed.BAK and click OK.

L6-30 Module 6: Backup of SQL Server Databases 

5. From the Backup type drop-down list box, select Full. 

6. Ensure that Copy-only Backup is checked. 


8. In the Overwrite media options, select Back up to a new media set, and erase all existing 

backup sets. 

9. In the New media set name text box, type MarketDev Copy Backup. 

10. In the New media set description text box, type MarketDev Copy Backup for Integration 

Team. 

11. In the Reliability options, ensure that Verify backup when finished is checked. 



14. Using Windows Explorer, note the size of the Copy backup compared to the Full backup. 

Challenge Exercise 5: Partial Backup (Only if time permits) 

Task 1: Perform a backup of the read-write filegroups on the RateTracking database 

1. In Solution Explorer, double-click the file 91 – Lab Exercise 5.sql to open it. 

2. Review the script. 

3. On the Toolbar click Execute.


Lab 7: Restoring SQL Server 2012 

Databases 

Lab Setup 













Note The setup script for this module is intended to throw an error regarding missing 

files this is normal. 

Exercise 1: Determine a Restore Strategy 

Task 1: Review the backups contained within the backup file 

1. In Solution Explorer, double-click the file 51 – Lab Exercise 1 Task 1.sql to open it. 

2. Review the script. 


4. The BackUpTypeDescription contained in the file are (in order): 

a. Database 

b. Database 

c. Database Differential 

d. Transaction Log 

e. Database Differential 

f. Transaction Log 

g. Transaction Log 

L7-31

L7-32 Module 7: Restoring SQL Server 2012 Databases 

Task 2: Determine how the restore should be performed 

1. Restoring a database requires: 

• Latest full database backup (File 2) 

• Most recent differential backup (File 5) 

• All log file backups since the latest differential backup (Files 6,7) 

2. With NORECOVERY should be specified on all restores. 

Exercise 2: Restore the Database 

Task 1: Restore the database 

1. In Object Explorer, expand the Proseware server, right-click Databases, and click Restore 

Database. 

2. In the Source options, click Device then click on the ellipsis button to the right hand side of the 

Device textbox. 

3. In the Select backup devices window, click Add. 

4. Navigate to the file D:\MSSQLServer\MarketYields.bak and click OK. 

5. In the Select backup devices window, click OK. 

6. In the Restore Database - MarketYields window, in the Select a page pane, click Files. 

7. In the Restore database files as options, check Relocate all files to folder. 


9. From the Recovery state dropdown, select RESTORE WITH STANDBY. 

10. In the Standby file textbox, type L:\MKTG\Log_Standby.bak and click OK. 

Note If the OK button is not visible you will need to scroll to the bottom of the window, 

or increase the resolution of your screen. 

11. In the Microsoft SQL Server Management Studio window, click OK. 

12. In Object Explorer expand the Proseware server, expand Databases, right-click Databases and 

click Refresh. 

13. The MarketYields database should show as Standby / Read-Only.

Lab 7: Restoring SQL Server 2012 Databases L7-33 

Challenge Exercise 3: Using STANDBY Mode (Only if time permits) 

Task 1: Execute queries against the STANDBY database to ensure it is accessible 

1. In Object Explorer, right-click Proseware server, and click New Query. 

2. Type the following query as shown in the snippet below: 

SELECT * FROM MarketYields.dbo.LogData; 


Note 25000 rows should be returned. 

4. Close the query window. (If prompted to Save changes click No). 

Task 2: Restore another log file, leaving the database in STANDBY mode 

1. In Object Explorer, expand the Proseware server, expand Databases, right-click the MarketYields 

database and click Tasks, click Restore, click Transaction Log. 

2. In the Restore source options, click From file or tape, click the ellipsis button at the right hand 

side of the From file or tape textbox. 


4. Navigate to the file D:\MSSQLSERVER\MarketYields_log.bak and click OK. 



7. In the Recovery state options select Leave the database in read-only mode. 

8. In the Standby file textbox, type L:\MKTG\Log_Standby.bak and click OK. 

9. In the Microsoft SQL Server Management Studio window, click Yes. 


11. In Object Explorer expand the Proseware server, expand Databases, right-click Databases and 

click Refresh. 

12. The MarketYields database should show as Standby / Read-Only.


Lab 8: Importing and Exporting Data 

Lab Setup 













Exercise 1: Import the Excel Spreadsheet 

Task 1: Import the data using the Import Wizard 

1. In SQL Server Management Studio, in Object Explorer, expand the Proseware server, expand 

Databases, right-click the MarketDev database, click Tasks, and click Import Data. 

2. In the SQL Server Import and Export Wizard window, click Next. 

3. In the Choose a Data Source window, select Microsoft Excel from the Data source drop-down list, 

and click Browse. 

4. Navigate to the file D:\10775A_Labs\10775A_08_PRJ\10775A_08_PRJ\Currency.xls and click 

Open. 

5. In the Choose a Data Source window, make sure that the First row has column names checkbox is 

checked, and click Next. 

6. In the Choose a Destination window, make sure that the Server name is Proseware and the 

Database name is MarketDev, and click Next. 

7. In the Specify Table Copy or Query window, click Next. 

8. In the Select Source Tables and Views window, check the checkbox beside `Currency`, change the 

Destination to [DirectMarketing].[Currency] and click Edit Mappings. 

9. In the Column Mappings window. 

a. Change the Type for the CurrencyID row to int. 

b. Uncheck the Nullable column in each row. 

c. Change the Size for the CurrencyCode to 3. 

d. Change the Size for the CurrencyName to 50 and click OK. 

L8-35

L8-36 Module 8: Importing and Exporting Data 

10. In the Select Source Tables and Views window, click Next. 

11. In the Review Data Type Mapping window, click Next. 

12. In the Save and Run Package window, click Next. 

13. In the Complete the Wizard window, click Finish. 

Note One warning about potential data truncation may occur. This is normal. 

14. In the Execution is completed window, click Close. 

15. In Object Explorer, right-click the MarketDev database and click New Query. 

16. Type the code as shown in the snippet below: 

SELECT * FROM DirectMarketing.Currency; 

17. On the Toolbar, click Execute. 

Note 105 currencies should be returned. 

Exercise 2: Import the CSV File 

Task 1: Import the CSV file 


2. Review the T-SQL script. 


4. Wait for the query to complete and record the duration of the query. (The duration of the query is 

shown on the bottom right-hand side of the Status bar). 

Note A typical execution time on the VM would be approximately 3 minutes. 

Exercise 3: Create and Test an Extraction Package 

Task 1: Create and test an extraction package 

1. In SQL Server Management Studio, in Object Explorer, expand the Proseware server, expand 

Databases, right-click the MarketDev database, click Tasks, and click Export Data. 

2. In the SQL Server Import and Export Wizard window, click Next. 

3. In the Choose a Data Source window, click Next. 

4. In the Choose a Destination window, in the Destination drop down list, choose Flat File 

Destination. 

In the File name text box type the following location:D:\MKTG\ProspectsToContact.csv. 

5. Make sure that the Column names in the first data row checkbox is checked and click Next.

Lab 8: Importing and Exporting Data L8-37 

6. In the Specify Table Copy or Query window, click Write a query to specify the data to transfer, 


7. In the Provide a Source Query window, type the code as shown in the snippet below, and click 

Parse: 

SELECT ProspectID, FirstName, LastName, CellPhoneNumber, 

WorkPhoneNumber,EmailAddress, LatestContact 

FROM Marketing.Prospect 

WHERE LatestContact < DATEADD(MONTH,-1,SYSDATETIME()) 

OR LatestContact IS NULL 

ORDER BY ProspectID; 

8. In the SQL Server Import or Export Wizard window, make sure that the parsing succeeded and click 

OK. 

9. In the Provide a Source Query window, click Next. 

10. In the Configure Flat File Destination window, click Next. 

11. In the Save and Run Package window, make sure that Run immediately and Save SSIS Package 

checkboxes are checked, and that SQL Server option button is selected, and click Next. 

12. In the Save SSIS Package window, type Weekly Extract of Prospects to Contact in both the Name 

and Description textboxes, and click Next. 


Note One warning about potential data truncation and one error if the table does not 

already exist may occur. This is normal. 

14. In the Execution is completed window, click Close. 

Challenge Exercise 4: Compare Loading Performance (Only if time 

permits) 

Task 1: Re-execute load with indexes disabled 




4. Wait for the query to complete and record the duration of the query. (The duration of the query is 

shown on the bottom right-hand side of the Status bar). 

Note A typical execution time on the VM would be approximately 1.2 minutes.


Lab 9: Authenticating and Authorizing 

Users 

Lab Setup 













Exercise 1: Create Logins 


• Review the supplied security requirements in the supporting documentation. Determine the 

required Windows logins, Windows group logins and SQL logins. 

Task 2: Create the required logins 




Exercise 2: Correct an Application Login Issue 

Task 1: Correct an Application Login Issue 




L9-39

L9-40 Module 9: Authenticating and Authorizing Users 

Exercise 3: Create Database Users 


• Review the supplied security requirements in the supporting documentation. Determine the 

required Windows logins, Windows group logins and SQL logins. 

Task 2: Create the required database users 




Challenge Exercise 4: Correct Access to Restored Database (Only if time 

permits) 

Task 1: Correct Access to a Restored Database 





Lab 10: Assigning Server and Database 

Roles 

Lab Setup 













Exercise 1: Assign Server Roles 



Task 2: Assign any required server roles 




Exercise 2: Assign Fixed Database Roles 



Task 2: Assign any required fixed database roles 




L10-41

L10-42 Module 10: Assigning Server and Database Roles 

Exercise 3: Create and Assign User-defined Database Roles 



Task 2: Create and assign any required user-defined database roles 




Challenge Exercise 4: Check Role Assignments (Only if time permits) 

Task 1: Check the role assignments for Darren Parker 





Lab 11: Authorizing Users to Access 

Resources 

Lab Setup 













Exercise 1: Assign Schema-level Permissions 

Task 1: Review the security requirements that have been updated from the previous 

module 

1. Review the supplied security requirements in the supporting documentation. 

2. Determine the permissions that should be assigned at the schema level. (Note: that a sample 

solution is shown in Task 2). 





Exercise 2: Assign Object-level Permissions 

Task 1: Review the security requirements 

1. Review the supplied security requirements in the supporting documentation. 

L11-43 

2. Determine the permissions that should be assigned at the object level. (Note: that a sample solution 

is shown in Task 2).

L11-44 Module 11: Authorizing Users to Access Resources 





Challenge Exercise 3: Test Permissions (Only if time permits) 

Task 1: Design and execute a test 

1. In Solution Explorer, double-click the file 71 – Lab Exercise 3a.sql to open it. 



4. In Solution Explorer, double-click the file 72 – Lab Exercise 3b.sql to open it. 



Note An error is returned as April.Reagan does not have permission to select the rows 

from the DirectMarketing.Competitor table.


Lab 12: Auditing SQL Server Environments 

Lab Setup 













Exercise 1: Determine Audit Configuration and Create Audit 


• Review the supplied requirements in the supporting documentation for the exercise, noting 

requirements that relate to server audits. 

Task 2: Create the server audit 

1. Determine the configuration of the required server audit. 

2. Using Windows Explorer, create a folder C:\Audit. 

3. Using Windows Explorer, create a folder C:\Audit\AuditLog. 

4. In Object Explorer, expand the Proseware server, and expand Security. 

5. Right-click Audits and click New Audit. 

6. In the Create Audit window, type Proseware Compliance Audit in the Audit name textbox. 

7. In the Queue delay (in milliseconds) textbox, type 2000. 

8. For Audit Log Failure, select the Shut down server option. 

9. In the File path textbox, type C:\Audit\AuditLog. 

10. Uncheck the Unlimited checkbox for Maximum file size. 

11. In the Maximum file size drop-down list type 1. 

L12-45

L12-46 Module 12: Auditing SQL Server Environments 

12. Click the GB option button for Maximum file size and click OK. 

13. In Object Explorer, expand Audits, right-click Proseware Compliance Audit and click Enable 

Audit. 

14. In the Enable Audit window, click Close. 

Exercise 2: Create Server Audit Specifications 



requirements that relate to server audit specifications. 

Task 2: Create the server audit specifications 

1. Determine the configuration of the required server audit specifications. 

2. In Object Explorer, right-click Server Audit Specifications, and click New Server Audit 

Specification. 

3. In the Create Server Audit Specification window, type Proseware Compliance Server Audit 

Specification in the Name textbox. 

4. From the Audit drop-down list, select Proseware Compliance Audit. 

5. In the Actions list, in row 1, click the Audit Action Type drop-down, and click 

FAILED_LOGIN_GROUP. 


SERVER_PRINCIPAL_CHANGE_GROUP. 


SERVER_ROLE_MEMBER_CHANGE_GROUP. 


LOGIN_CHANGE_PASSWORD_GROUP, and click OK. 

9. In Object Explorer, expand Server Audit Specifications, right-click Proseware Compliance Server 

Audit Specification, and click Enable Server Audit Specification. 

10. In the Enable Server Audit Specification window, click Close. 

Exercise 3: Create database audit specifications 



requirements that relate to database audit specifications. 

Task 2: Create the database audit specifications 

1. Determine the configuration of the required database audit specifications. 

2. In Object Explorer, expand the Proseware server, expand Databases, expand the MarketDev 

database, expand Security, and expand Database Audit Specifications. 

3. Right-click Database Audit Specifications, and click New Database Audit Specifications.

Lab 12: Auditing SQL Server Environments L12-47 

4. In the Create Database Audit Specification window, type Proseware Compliance MarketDev 

Audit Specification in the Name textbox. 

5. From the Audit drop-down list, select Proseware Compliance Audit. 


BACKUP_RESTORE_GROUP. 


DATABASE_OWNERSHIP_CHANGE_GROUP. 


DATABASE_PERMISSION_CHANGE_GROUP. 


DATABASE_PRINCIPAL_CHANGE_GROUP. 


DATABASE_ROLE_MEMBER_CHANGE_GROUP. 

11. In the Actions list, in row 6, click the Audit Action Type drop-down, and click EXECUTE. 

12. In row 6, click the Object Class drop-down list and click OBJECT. 

13. In row 6, click the ellipsis in the Object Name column. 

14. In the Select Objects window, click Browse. 

15. In the Matching Objects pane, check the box beside [Marketing].[MoveCampaignBalance], and 

click OK. 

16. In the Select Objects window, click OK. 

17. In row 6, click the ellipsis in the Principal Name column. 


19. In the Matching Objects pane, check the box beside [public], and click OK. 


21. In the Actions list, in row 7, click the Audit Action Type drop-down, and click UPDATE. 

22. In row 7, click the Object Class drop-down list and click OBJECT. 

23. In row 7, click the ellipsis in the Object Name column. 


25. In the Matching Objects pane, check the box beside [Marketing].[CampaignBalance], and click 

OK. 


27. In row 7, click the ellipsis in the Principal Name column. 


29. In the Matching Objects pane, check the box beside [public], and click OK. 

30. In the Select Objects window, click OK.

L12-48 Module 12: Auditing SQL Server Environments 

31. In the Create Database Audit Specification window, click OK. 

32. In Object Explorer, right-click Proseware Compliance MarketDev Audit Specification and click 

Enable Database Audit Specification. 

33. In the Enable Database Audit Specification window, click Close. 

Challenge Exercise 4: Test Audit Functionality (Only if time permits) 

Task 1: Execute the workload script 


2. Review the T-SQL script. Note any actions that you would expect to be audited. In Task 2 you will 

see the actual list of audited actions. 


Task 2: Review the captured audit details 

1. In Object Explorer, expand the Proseware server, expand Security, expand Audits. 

2. Right-click the Proseware Compliance Audit, and click View Audit Logs. 

3. In the Log File Viewer – Proseware window, review the captured events and compare them to your 

list of expected events from Task 1. 

Note Make sure you scroll to the list of events to the right to see all available columns. 

4. In the Log File Viewer – Proseware window click Close. 



7. On the Toolbar click Execute. A list of audited events will be returned.


Lab 13: Automating SQL Server 

Management 

Lab Setup 













Exercise 1: Create a Data Extraction Job 

Task 1: Create the required job 

1. In Object Explorer, expand the Proseware server, expand SQL Server Agent, right-click Jobs and 

click New Job. 

2. In the New Job window, in the Name textbox type Extract Uncontacted Prospects. 

3. In the Select a page pane, click Steps, and then click New. 

4. In the Step name textbox, type Execute Prospect Extraction Package. 

5. From the Type drop-down list, select SQL Server Integration Services Package. 

6. In the General tab, from the Package source drop-down, select SQL Server. 

7. In the Server textbox type Proseware, and click the ellipsis beside the Package textbox. 

L13-49 

8. In the Select an SSIS Package window, click Weekly Extract of Prospects to Contact and click OK. 

9. In the New Job Step window, click OK. 

10. In the New Job window, click OK.

L13-50 Module 13: Automating SQL Server 2012 Management 

Task 2: Test that the job executes without error 

1. In Object Explorer, expand the Proseware server, expand SQL Server Agent, and expand Jobs. 

2. Right-click Jobs and click Refresh. 

3. Right-click Extract Uncontacted Prospects, and click Start Job at Step. 

4. In the Start Jobs - Proseware window, make sure that the job succeeds and click Close. 

Exercise 2: Schedule the Data Extraction Job 

Task 1: Schedule the data extraction job 



3. Right-click Extract Uncontacted Prospects, and click Properties. 

4. On the Select a page pane, click Schedules, and then click New. 

5. In the New Job Schedule window, in the Name textbox type Each Monday Morning at 8:30AM. 

6. Check the Monday checkbox; uncheck the Sunday checkbox. 

7. In the Occurs once at textbox, change the time to 8:30:00AM and press the Tab key. Note the 

contents of the Description textbox and click OK. 

8. In the Job Properties – Extract Uncontacted Prospects window, click New. 

9. In the New Job Schedule window, in the Name textbox type Each Tuesday Evening at 6:30PM. 

10. Check the Tuesday checkbox; uncheck the Sunday checkbox. 

11. In the Occurs once at textbox, change the time to 6:30:00PM and hit the Tab key. Note the 

contents of the Description textbox and click OK. 

12. In the Job Properties – Extract Uncontacted Prospects window, click OK. 

Challenge Exercise 3: Troubleshoot a Failing Job (Only if time permits) 

Task 1: Troubleshoot the failing job 



3. Right-click Extract Long Page Loads, and click View History. 

4. In the Log File Viewer – Proseware window, click the plus sign in a row that has a failing execution 

to expand the job steps. Note that step ID 2 has failed. 

5. Click on the row for step ID 2, and scroll through the Selected row details pane to find the error. 

Note that the error is caused by a reference to an invalid object name 

Marketing.RecentLongPageLoads. 

6. Click Close to close the Log File Viewer – Proseware window. 

7. Right-click Extract Long Page Loads, and click Properties. 

8. In the Select a page pane, click Steps.

9. In the Job step list, click the row for Step 2 and click Edit. 

Lab 13: Automating SQL Server Management L13-51 

10. Review the command that is being executed and note that Marketing.RecentLongPageLoads 

appears to be a table or view that the web log rows are being inserted into. 

11. In Object Explorer, expand Databases, expand MarketDev, and expand Tables. Note that the 

name of the table should be Marketing.RecentLongPageLoad. 

12. In the Job Step Properties – Copy Recent Long Page Loads window change the name of the table in 

the Command textbox from Marketing.RecentLongPageLoads to 

Marketing.RecentLongPageLoad and click OK. 

13. In the Job Properties – Extract Long Page Loads window, click OK. 

14. In Object Explorer, right-click the Extract Long Page Loads job and click Start Job at Step. 

15. In the Start Job on ‘Proseware’ window, click Start. 

16. In the Start Job on ‘Proseware’ window, make sure the job executed successfully and click Close. 

17. In Object Explorer, right-click Extract Long Page Loads, and click Properties. 

18. In the Select a page pane, click Schedules and note the difference between the name of the 

schedule and the description of the schedule, then click Edit. 

19. From the Occurs drop-down list box, click Weekly. 

20. Check the Monday checkbox and review the remaining settings, then click OK. 

21. In the Schedule list, note that the schedule name now relates to the schedule description. 

22. In the Job Properties – Extract Long Page Loads window, click OK.

L14-53 


Lab 14: Configuring Security for SQL Server 

Agent 

Lab Setup 













Exercise 1: Troubleshoot Job Execution Failure 

Task 1: Troubleshoot job execution failure 

1. Review the previous actions taken by Terry Adams as detailed in the supporting documentation for 

the exercise. 

2. In Object Explorer, expand the Proseware server, expand SQL Server Agent, expand Jobs, 

right-click Extract Uncontacted Prospects and click View History. 

3. In the Log File Viewer - Proseware window, click the plus sign in a failing row to expand the job 

steps. 

4. Click the row for Step ID 1. In the Selected row details pane, scroll the pane until you locate the 

error. 

Note The error indicates that Non-SysAdmins have been denied permission to run DTS 

Execution job steps without a proxy account. The step failed. 

5. You have determined that a proxy account is needed for the job step. Close the 

Log File Viewer - Proseware window.

L14-54 Module 14: Configuring Security for SQL Server Agent 

Exercise 2: Resolve the Security Issue 

Task 1: Create and assign proxy account 

1. In Object Explorer, expand the Proseware server, expand Security, and expand Credentials. 

2. Right-click Credentials and click New Credential. 

3. In the New Credential window, in the Credential name text box, type ExtractIdentity. 

4. In the Identity textbox, type MIA-SQL1\ExtractUser. 

5. In the Password and Confirm password textboxes, type Pa$$w0rd, and click OK. 

6. In Object Explorer, expand SQL Server Agent, right-click Proxies, and click New Proxy. 

7. In the New Proxy Account window, in the Proxy name textbox, type ExtractionProxy. 

8. In the Credential name textbox, type ExtractIdentity. 

9. In the Active to the following subsystems list, check the box beside SQL Server Integration 

Services Package. 

10. In the Select a page pane, click Principals, and click Add. 

11. In the Available principals list, check the box beside PromoteApp login, and click OK. 

12. In the New Proxy Account window, click OK. 

13. In Object Explorer, expand Jobs, right-click Extract Uncontacted Prospects and click Properties. 

14. In the Job Properties - Extract Uncontacted Prospects window, in the Select a page pane click 

Steps, then click Edit. 

15. In the Run as drop-down list, click ExtractionProxy, and click OK. 

16. In the Job Properties - Extract Uncontacted Prospects window, click OK. 

Task 2: Test to see if all problems have been resolved 

1. In Object Explorer, right-click the Extract Uncontacted Prospects job, and click Start Job at Step. 

2. In the Start Jobs - Proseware window, note that the job still fails, and click Close. 

3. In Object Explorer, right-click the Extract Uncontacted Prospects job, and click View History. 

4. In the Log File Viewer - Proseware window, click the plus sign beside the top entry in the list to 

expand the job steps. 

5. Click in the row for Step ID 1, in the Selected row details pane, scroll down to find the error. 

Note A SQL Statement is now failing because of a login issue. 

6. You have resolved the original problem. If you have time you should continue to Exercise 3 to 

resolve the remaining problem.

Lab 14: Configuring Security for SQL Server Agent L14-55 

Challenge Exercise 3: Perform Further Troubleshooting (Only if time 

permits) 

Task 1: Perform further troubleshooting 

1. In the Log File Viewer - Proseware window, in the Select row details pane, read the detail of the 

error message, determine the cause of the error and close the window. 

Note The most important error is Login failed for user ‘MIA-SQL1\ExtractUser’. Even 

though a Windows credential is required for the SSIS job to access the file system to write 

the extracted file, the credential also needs to be able to connect to SQL Server to retrieve 

the data from the Marketing.Prospects table. You need to create a login for the Windows 

user, create a database user for the login and then assign SELECT permission on the 

Marketing.Prospects table to the credential. 






8. In Object Explorer, right-click the Extract Uncontacted Prospects job, and click View History. 

9. In the Log File Viewer - Proseware window, click the plus sign beside the top entry in the list to 

expand the job steps. 

10. Click in the row for Step ID 1, in the Selected row details pane, scroll down to find the error. 

Note ExtractUser does not have permissions on the D:\MKTG folder. 

11. In Windows Explorer, navigate to the folder D:\MKTG, right-click the MKTG folder and click 

Properties. 

12. In the MKTG Properties window, click on the Security tab, click Edit. 

13. In the Permissions for MKTG window, click Add. 

14. In the Select Users, Computers, Services Accounts, or Groups window, in the Enter the object 

names to select textbox type MIA-SQL1\ExtractUser and click OK. 

15. In the Permissions for MKTG window, check the Allow checkbox for the Modify row and click OK. 

16. In the MKTG Properties window, click OK. 


18. In the Start Jobs - Proseware window, note that the job now completes successfully, and click Close.

Module 15: Monitoring SQL Server 2012 with Alerts and 

Notifications 

Lab 15: Monitoring SQL Agent Jobs with 

Alerts and Notifications 

Lab Setup 













Exercise 1: Configure Database Mail 

Task 1: Configure database mail 

1. Review the database mail configuration parameters in the supporting documentation for the 

exercise. 

L15-57 

2. In Object Explorer, expand the Proseware server, expand Management, right-click Database Mail, 

and click Configure Database Mail. 

3. In the Welcome to Database Mail Configuration Wizard window, click Next. 

4. In the Select Configuration Task window, click Next. 

5. In the Microsoft SQL Server Management Studio window, click Yes. 

6. In the New Profile window, in the Profile name textbox type Proseware SQL Server Agent 

Profile, and click Add. 

7. In the New Database Mail Account window, in the Account name textbox, type Proseware 

Administrator. 

8. In the E-mail address textbox, type prosewaresqladmin@adventureworks.com. 

9. In the Display name textbox, type Proseware SQL Server Administrator. 

10. In the Reply e-mail textbox, type prosewaresqladmin@adventureworks.com. 

11. In the Server name textbox type mailserver.adventureworks.com, and click OK.

L15-58 Module 15: Monitoring SQL Server 2012 with Alerts and Notifications 

12. In the New Profile window, click Add. 

13. In the New Database Mail Account window, in the Account name textbox, type AdventureWorks 

Administrator. 

14. In the E-mail address textbox, type adventureworkssqladmin@adventureworks.com. 

15. In the Display name textbox, type AdventureWorks SQL Server Administrator. 

16. In the Reply e-mail textbox, type adventureworkssqladmin@adventureworks.com. 

17. In the Server name textbox type mailserver.adventureworks.com, and click OK. 

18. In the New Profile window, click Next. 

19. In the Manage Profile Security window, check the box in the Public column and change the value 

in the Default Profile column to Yes. 

20. Click on the Private Profiles tab, and from the User name drop-down list, select 

ADVENTUREWORKS\pwservice. 

21. Check the box in the Access column, and change the value in the Default Profile column to Yes, 

then click Next. 

22. In the Configure System Parameters window, change the Maximum File Size (Bytes) to 4194304, 



24. In the Configuring window, click Close. 

Task 2: Test that database mail operates 

1. In Object Explorer, right-click Database Mail and click Send Test E-Mail. 

2. In the Send Test E-Mail from MIA-SQL1\MKTG window, in the To textbox type 

prosewaresqladmin@adventureworks.com, and click Send Test E-Mail. 

3. In the Database Mail Test E-Mail window, note the description and click OK. 




Note An email with the subject Database Mail Test should be returned by the query. 

Exercise 2: Implement Notifications 


• Review the supplied requirements in the supporting documentation for the exercise. In particular, 

note any required operators.

Task 2: Configure the required operators 

Lab 15: Monitoring SQL Server 2012 with Alerts and Notifications L15-59 

1. In Object Explorer, expand SQL Server Agent, right-click Operators and click New Operator. 

2. In the New Operator window, in the Name textbox, type IT Support Fail-safe Operator. 

3. In the Pager e-mail name, type itsupport.pager@adventureworks.com. 

4. In the Pager on duty schedule, check Monday, Tuesday, Wednesday, Thursday, Friday, 

Saturday, and Sunday. Change the Workday begin time to 12:00:00 AM and Workday end to 

11:59:59 PM for every row, and click OK. 

5. In Object Explorer, right-click Operators and click New Operator. 

6. In the New Operator window, in the Name textbox, type Jeff Hay. 

7. In the Pager e-mail name, type jeff.hay.pager@adventureworks.com. 




9. In Object Explorer, right-click Operators and click New Operator. 

10. In the New Operator window, in the Name textbox, type Palle Petersen. 

11. In the Pager e-mail name, type palle.petersen.pager@adventureworks.com. 




Task 3: Configure SQL Server Agent Mail 

1. In Object Explorer, right-click SQL Server Agent, and click Properties. 

2. In the Select a page pane click Alert System. In the Mail session options, click Enable mail 

profile. 

3. From the Mail profile drop-down list, select Proseware SQL Server Agent Profile. 

4. In the Fail-safe operator options, check Enable fail-safe operator. 

5. In the Operator drop-down list, select IT Support Fail-safe Operator. 

6. In the Notify using options, check Pager, and click OK. 

7. In Object Explorer, right-click SQL Server Agent and click Restart. 

8. In the SQL Server Management Studio window, click Yes. 

Task 4: Configure and Test Notifications in SQL Server Agent Jobs 

1. In Object Explorer, expand SQL Server Agent, expand Jobs, right-click Backup Log TestAlertDB 

and click Properties. 

2. In the Select a page pane, click Notifications. 

3. In the Actions to perform when the job completes option, check Page. 

4. In the Page drop-down list, select Jeff Hay.

L15-60 Module 15: Monitoring SQL Server 2012 with Alerts and Notifications 

5. In the Page actions drop-down list, select When the job completes, and click OK. 

6. In Object Explorer, right-click Job that Fails and click Properties. 



9. In the Page drop-down list, select Palle Petersen. 

10. In the Page actions drop-down list, select When the job fails, and click OK. 

11. In Object Explorer, right-click Job that Succeeds and click Properties. 



14. In the Page drop-down list, select Palle Petersen. 

15. In the Page actions drop-down list, select When the job fails, and click OK. 

16. In Object Explorer, right-click Backup Log TestAlertDB and click Start Job at Step. 

17. In the Start Jobs - Proseware window, click Close. 

18. In Object Explorer, right-click Job That Fails, and click Start Job at Step. 

19. In the Start Jobs - Proseware window, note that the job failed and click Close. 

20. In Object Explorer, right-click Job That Succeeds and click Start Job at Step. 

21. In the Start Jobs - Proseware window, click Close. 




Note Two additional emails should now appear in the list, an email from the backup job 

sent to Jeff Hay and an email from the job that fails sent to Palle Petersen. No email 

should be sent for the job called “Job That Succeeds”. 

Challenge Exercise 3: Implement Alerts (Only if time permits) 

Task 1: Configure and Test Alerts 

1. Review the supporting documentation for the alerting requirements. 

2. In Object Explorer, right-click Alerts and click New Alert. 

3. In the New Alert window, in the Name textbox, type Error Severity 17 Alert. 

4. In the Severity drop-down list, click 017 – Insufficient Resources. 

5. In the Select a page pane, click Response. 

6. Check Notify operators, check all checkboxes in the Pager column and click OK. 

7. In Object Explorer, right-click Alerts and click New Alert.

Lab 15: Monitoring SQL Server 2012 with Alerts and Notifications L15-61 

8. In the New Alert window, in the Name textbox, type Error Severity 18 Alert. 

9. In the Severity drop-down list, click 018 – Nonfatal Internal Error. 



12. In Object Explorer, right-click Alerts and click New Alert. 

13. In the New Alert window, in the Name textbox, type Transaction Log Full Alert. 

14. Click the Error number option, and in the Error number textbox type 9002. 






Note Executing this script will result in an error, indicating message 9002. 




Note Additional emails should be listed related to the SQL Server alert system.


Lab 16: Performing Ongoing Database 

Maintenance 

Lab Setup 













Exercise 1: Check Database Integrity Using DBCC CHECKDB 

Task 1: Check the consistency of the databases on the Proseware instance 




Note Errors will be returned from the CoreAdmin database. 

Task 2: Correct any issues found 




Note Errors will be returned from the CoreAdmin database during this process. 

L16-63

L16-64 Module 16: Performing Ongoing Database Maintenance 

Exercise 2: Correct Index Fragmentation 

Task 1: Review the fragmentation of indexes in the MarketDev database to determine 

which indexes should be defragmented and which indexes should be rebuilt 




Task 2: Defragment indexes as determined 




Task 3: Rebuild indexes as determined 

1. In Solution Explorer, double-click the file 63 – Lab Exercise 2c.sql to open it. 



Exercise 3: Create a Database Maintenance Plan 

Task 1: Create the required database maintenance plan 

1. In Object Explorer, expand Proseware, expand Management, right-click Maintenance Plans, and 

click Maintenance Plan Wizard. 

2. In the Maintenance Plan Wizard window, click Next. 

3. In the Select Plan Properties window, in the Name textbox, type Proseware Weekly Maintenance. 

Note the available scheduling options and click Change. 

4. In the New Job Schedule window, in the Name textbox, type 6PM Every Sunday. 

5. In the Occurs once at textbox, change the time to 6PM, and click OK. 

6. In the Select Plan Properties window, click Next. 

7. Review the available options and check Rebuild index and Check Database Integrity, and then 

click Next. 

8. In the Select Maintenance Task Order window, click Next. 

9. In the Define Database Check Integrity Task window, from the Databases drop-down list, select All 

databases, and click OK then click Next. 

10. In the Define Rebuild Index Task window, from the Databases drop-down list, check the 

MarketDev database, and click OK. 

11. In the Free space options, click Change free space per page to:. 

12. In the Change free space per page to: textbox, type 10.

13. Check Keep index online while reindexing, and click Next. 

Lab 16: Performing Ongoing Database Maintenance L16-65 

14. In the Select Report Options window, in the folder location textbox, type L:\MKTG, and click 

Next. 


16. In the Maintenance Plan Wizard Progress window, click Close. 

Challenge Exercise 4: Investigate Table Lock Performance (Only if time 

permits) 

Task 1: Execute DBCC CHECKDB using database snapshots 




Note Note the time taken to execute. A typical duration would be 42 seconds. 

Task 2: Execute DBCC CHECKDB using table locks 




Note Note the time taken to execute. A typical duration would be 7 seconds.


Lab 17: Tracing Access to SQL Server 2012 

Lab Setup 













Exercise 1: Capture a Trace Using SQL Server Profiler 

Task 1: Create and start a suitable SQL Server Profiler trace 

1. In Microsoft SQL Server Management Studio, on the Tools menu, click SQL Server Profiler. 

2. In the Connect to Server window, click Connect. 

3. In the Trace name, type Proseware Trace. 

4. In the Use the template drop-down, select Tuning. 

5. Check the Save to file option. 

6. In the Save As window, navigate to the desktop, and click Save. 

7. Uncheck the Enable file rollover option. 

8. Change the Set maximum file size (MB) option to 500. 

9. Click the Events Selection tab. Note the selected events. 

10. Click on the Database Name column heading to create a filter. 

11. Expand the Like node and enter MarketDev and click OK. 

12. In the Trace Properties window, click Run. 

13. From the Window menu, uncheck Auto scroll. 

L17-67

L17-68 Module 17: Tracing Access to SQL Server 2012 

Task 2: Execute the workload 



3. From the Query menu, select Query Options. 

4. In the Query Options window, click Grid. In the Grid options, check Discard results after 

execution. 

5. Click OK to close the Query Options window. 


7. Wait for the query to complete. 

Note The query is complete when Query executed successfully appears below the 

Messages tab. No output messages will be seen. 

Task 3: Stop the trace 

• In SQL Server Profiler, on the Toolbar, click the Stop Selected Trace icon, and close SQL Server 

Profiler. 

Exercise 2: Analyze a Trace Using Database Engine Tuning Advisor 

Task 1: Analyze the captured trace in Database Engine Tuning Advisor 

1. In Microsoft SQL Server Management Studio, from the Tools menu, click Database Engine Tuning 

Advisor. 


3. Maximize the Database Engine Tuning Advisor window. 

4. In the Workload group box, ensure that File is selected, and click the Browse for a Workload File 

button. 

5. Browse to the Desktop folder, select the Proseware Trace.trc file and click Open. 

6. In the Database for workload analysis drop-down, select MarketDev. 

7. In the Select databases and tables to tune list, check the MarketDev database. 

8. From the Toolbar, click the Start Analysis button to start the tuning analysis. 

Task 2: Review the suggested modifications 

1. Observe the tuning progress and when the analysis is complete, note the recommendations. The 

exact recommendations will vary but it is likely you will see both index and statistics 

recommendations. 

2. Scroll the recommendations output to the right and note the hyperlinks to sample code. 

3. Click each of the recommendations in turn and note the suggested index or statistics structures. 

4. Close Database Engine Tuning Advisor.

Lab 17: Tracing Access to SQL Server 2012 L17-69 

Challenge Exercise 3: Configure SQL Trace (Only if time permits) 

Task 1: Create a script that uses SQL Trace procedures to implement the same type of 

capture as you performed in Exercise 1 but with a different trace name 

1. In Microsoft SQL Server Management Studio, from the Tools menu, click SQL Server Profiler. 


3. In the Trace name, type ProsewareTrace2. 

4. In the Use the template drop-down, select Tuning. 

5. Check the Save to file option. 

6. In the Save As window, navigate to the desktop, and click Save. 

7. Uncheck the Enable file rollover option. 

8. Change the Set maximum file size (MB) option to 500. 

9. Click the Events Selection tab. Note the selected events. 

10. Click on the Database Name column heading to create a filter. 

11. Expand the Like node and enter MarketDev and click OK. 

12. In the Trace Properties window, click Run. 

13. From the Toolbar, click the Stop Selected Trace icon. 

14. From the File menu, click Export, click Script Trace Definition, click For SQL Server 2005 – 

SQL11. 

15. Navigate to the Desktop and in the File name text box, type ProsewareTrace2 and click Save. 

16. In the SQL Server Profiler window, click OK. 

17. Close SQL Server Profiler. 

Task 2: Test that the script works as expected by using the same workload 

1. In Solution Explorer, from the File menu, click Open, click File. 

2. In the Open File window, navigate to the Desktop, click Proseware Trace2.sql and click Open. 

3. In the first row that begins with an exec command, change the string InsertFileNameHere to 

D:\MKTG\ProsewareTrace2. 

4. On the Toolbar click Execute to start the trace. 

Note Record the Trace ID value that is returned. 



7. From the Query menu, select Query Options. 

8. In the Query Options window, click Grid. In the Grid options, check Discard results after 

execution.

L17-70 Module 17: Tracing Access to SQL Server 2012 

9. Click OK to close the Query Options window. 


11. Wait for the query to complete. 

Note The query is complete when Query executed successfully appears below the 

Messages tab. No output messages will be seen. 


13. Review the T-SQL script and replace the value of the @TraceID variable with the value you 

recorded earlier in this task. 


Task 3: Analyze the new captured output and note if the suggested changes are 

identical to those suggested in Exercise 2 

1. In Microsoft SQL Server Management Studio, from the Tools menu, click Database Engine Tuning 

Advisor. 


3. Maximize the Database Engine Tuning Advisor window. 

4. In the Workload group box, ensure that File is selected, and click the Browse for a Workload File 

button. 

5. Browse to the D:\MKTG folder, select the ProsewareTrace2.trc file and click Open. 

6. In the Database for workload analysis drop-down, select MarketDev. 

7. In the Select databases and tables to tune list, check the MarketDev database. 

8. From the Toolbar, click the Start Analysis button to start the tuning analysis. 

9. When the analysis is complete, compare the results to the results you saw earlier in Exercise 2. 

Note The results should be identical.


Lab 18: Monitoring SQL Server 2012 

Lab Setup 













Exercise 1: Investigating DMVs 

Task 1: Investigate the use of Dynamic Management Views and Functions 


2. Follow the instructions in the T-SQL script. 

Exercise 2: Configure Management Data Warehouse 

Task 1: Create a management data warehouse for central collection of performance 

data 

1. In Object Explorer, expand the Proseware server, expand Management, right-click Data 

Collection, and click Configure Management Data Warehouse. 

2. In the Configure Management Data Warehouse Wizard window, click Next. 

3. In the Select Configuration task window, click Next. 

4. In the Configure Management Data Warehouse Storage window, in the Server name textbox 

ensure Proseware has been entered, and click New. 

5. In the New Database window, in the Database name textbox, type MDW, and click OK. 

6. In the Configure Management Data Warehouse Storage window, click Next. 

7. In the Map Logins and Users window, review the options and click Next. 


9. In the Configure Data Collection Wizard Progress window, click Close. 

L18-71

L18-72 Module 18: Monitoring SQL Server 2012 

Exercise 3: Configure Instances for Data Collection 

Task 1: Configure data collection on each instance 




3. In the Select Configuration task window, click Set up data collection, and click Next. 

4. In the Configure Management Data Warehouse Storage window, click the ellipsis button beside 

the Server name textbox. 

5. In the Connect to Server window, in the Server name textbox, type Proseware, and click Connect. 

6. In the Database name drop-down list, select MDW, and click Next. 



9. In Object Explorer, click Connect, then click Database Engine. In the Connect to Server window, in 

the Server name textbox type AdventureWorks, and click Connect. 

10. In Object Explorer, expand the AdventureWorks server, expand Management, right-click Data 



12. In the Select Configuration task window, click Set up data collection, and click Next. 

13. In the Configure Management Data Warehouse Storage window, click the ellipsis button beside 

the Server name textbox. 

14. In the Connect to Server window, in the Server name textbox, type Proseware, and click Connect. 

15. In the Database name drop-down list, select MDW, and click Next. 



Challenge Exercise 4: Work with Data Collector Reports (Only if time 

permits) 

Task 1: Disable data collectors on both instances 


Collection, and click Disable Data Collection. If a confirmation window appears, click Close. 

2. In Object Explorer, expand the AdventureWorks server, expand Management, right-click Data 

Collection, and click Disable Data Collection. If a confirmation window appears, click Close.

Task 2: Restore a backup of the MDW database 

Lab 18: Monitoring SQL Server 2012 L18-73 

1. In Object Explorer, expand the Proseware server, expand Databases, right-click the MDW 

database and click Delete. 

2. In the Delete Object window, check the Close existing connections checkbox and click OK. 

3. In Object Explorer, expand the Proseware server, right-click Databases, and click Restore 

Database. 

4. In the Restore Database window, in the Source options click Device. 

5. Click the ellipsis beside the Device textbox. 


7. Navigate to the file D:\10775A_Labs\10775A_18_PRJ\10775A_18_PRJ\MDW.bak and click OK. 



10. In the Restore options, check Overwrite the existing database (WITH REPLACE), and click OK. 


Task 3: Review the available reports 

1. In Object Explorer, expand Proseware server, expand Databases. 

2. Right-click the MDW database, click Reports, click Management Data Warehouse, and click 

Management Data Warehouse overview. 

3. Review the Disk Usage Report for MIA-SQL1\MKTG. 

4. Close the report window. 

5. Right-click the MDW database, click Reports, click Management Data Warehouse, and click 

Management Data Warehouse overview. 

6. Review the Server Activity Report for MIA-SQL1\MKTG. 

7. Close the report window. Right-click the MDW database, click Reports, click Management Data 

Warehouse, and click Management Data Warehouse overview. 

8. Review the Query Statistics Report for MIA-SQL1\MKTG. 

9. Close the report window.


Lab 19: Managing Multiple Servers 

Lab Setup 













Exercise 1: Configure CMS and Execute Multi-server Queries 

Task 1: Create a central management server 

1. From the View menu in SQL Server Management Studio, click Registered Servers. 

2. In the Registered Servers window that opens, expand Database Engine. 

3. Right-click Central Management Servers, and click Register Central Management Server. 

4. In the New Server Registration window, in the Server name textbox, type Proseware and click 

Save. 

L19-75 

Task 2: Create a server group within the CMS 

1. In SQL Server Management Studio, in Registered Servers, expand Central Management Servers. 

2. Right-click Proseware and click New Server Group. 

3. In the New Server Group Properties window, in the Group name textbox, type Core Servers and 

click OK. 

4. In Registered Servers, right-click Core Servers and click New Server Registration. 

5. In the New Server Registration window, in the Server name textbox, type Proseware and click 

Save. 

6. In Registered Servers, right-click Core Servers and click New Server Registration. 

7. In the New Server Registration window, in the Server name textbox, type AdventureWorks and 

click Save.

L19-76 Module 19: Managing Multiple Servers 

Task 3: Execute a command to find all databases on any core server in full recovery 

model 

1. In Registered Servers, right-click Core Servers and click New Query. 

2. Type the following code into the new query window: 

SELECT * FROM sys.databases WHERE recovery_model_desc = ‘FULL’; 

3. From the Toolbar, click Execute. 

Note A list of databases in full recovery model is returned. 

Exercise 2: Deploy a Data-tier Application 

Task 1: Deploy the data-tier application using SSMS 

1. In Object Explorer, expand the Proseware server, expand Databases, right-click Databases, and 

click Deploy Data-tier Application. 

2. In the Introduction window, click Next. 

3. In the Select Package window, enter or select the path D:\10775A_Labs\10775A_19_PRJ 

\10775A_19_PRJ\CityCode.dacpac, and click Next. 

4. In the Update Configuration window, click Next. 

5. In the Summary window, click Next. 

6. In the Deploy DAC window, click Finish. 




Exercise 3: Register and extract a data-tier application 

Task 1: Register the existing database as a data-tier application 

1. In Object Explorer, expand the Proseware server, expand Databases, right-click the Research 

database, click Tasks, and click Register as Data-tier Application. 


3. In the Set Properties window, click Next. 

4. In the Validation and Summary window, click Next. 

5. In the Register DAC window, click Finish. 

Task 2: Extract a dacpac from the database to send to the development team 

1. In Object Explorer, expand the Proseware server, expand Databases, right-click the Research 

database, click Tasks, and click Extract Data-tier Application.


3. In the Set Properties window, in the Save to DAC package file textbox, type 

D:\MKTG\Research.dacpac, and then click Next. 

4. In the Validation and Summary window, click Next. 

5. In the Build Package window, click Finish. 

Lab 19: Managing Multiple Servers L19-77 

Challenge Exercise 4: Upgrade a Data-tier Application (Only if time 

permits) 

Task 1: Attempt to deploy the v2 upgrade 

1. In Object Explorer, expand the Proseware server, right-click Databases and click Refresh. 

2. Expand Databases, right-click the CityCode database, click Tasks, and click Upgrade Data-tier 

Application. 



\10775A_19_PRJ\CityCode_v2.dacpac, and click Next. 

5. In the Detect Change window, click Next. 

6. In the Options window, uncheck the Execute pre-deployment Script, check Rollback on failure 


7. In the Review Upgrade Plan window, check Proceed despite possible data loss and click Next. 



10. In the Upgrade DAC window, notice the failures and click Finish. 

11. In Object Explorer, right-click Databases, and click Refresh. 

Note All databases and data-tier applications have been left unchanged. 

Task 2: Deploy the v3 upgrade 

1. In Object Explorer, expand Databases, right-click the CityCode database, click Tasks, and click 

Upgrade Data-tier Application. 



\10775A_19_PRJ\CityCode_v3.dacpac, and click Next. 

4. In the Detect Change window, click Next. 

5. In the Options window, check Rollback on failure and click Next. 

6. In the Review Upgrade Plan window, click Next. 


8. In the Upgrade DAC window, click Finish. 

9. In Object Explorer, right-click Databases, and click Refresh. 

Note The data-tier application is upgraded.

Module 20: Troubleshooting Common SQL Server 2012 

Administrative Issues 

Lab 20: Troubleshooting Common Issues 

Lab Setup 













Exercises 1 – 5: Troubleshoot and Resolve SQL Server Administrative 

Issues 

Exercise 1 – Issue 1 




1. In Object Explorer, expand the Proseware server, expand Security, and expand Logins. 

2. Beside the PromoteApp user, note the icon with a red down arrow, the login is disabled. 

3. Right-click PromoteApp, and click Properties. 

4. In the Select a page pane, click Status, click Enabled, and click OK. 

5. In Object Explorer, right-click Logins, and click Refresh. Note that the login is now enabled. 

L20-79

L20-80 Module 20: Troubleshooting Common SQL Server 2012 Administrative Issues 





1. In Object Explorer, expand the Proseware server, expand Databases, and note the status of the 

AdminDB database. The database is in a restoring state, the junior DBA may have performed a taillog 

backup. 

2. In Object Explorer, right-click the AdminDB database, click Tasks, click Restore, and click 

Transaction Log. 

3. In the Restore Transaction Log – AdminDB window, click From file or tape, and click OK. 







2. Right-click the Get File List job, and click Start Job at Step. 

3. In the Start Jobs – Proseware window, note the failure, and click Close. 

4. In Object Explorer, right-click the Get File List job, and click View History. 

5. In the Log File Viewer – Proseware window, click on the plus sign in a failing row to expand the job 

steps. 

6. Click on the row for Step ID 1. 

7. In the Selected row details pane, scroll down to find the error (Logon failure: unknown user name 

or bad password). Note when using the proxy for David.Alexander. 

8. In the Log File Viewer - Proseware window, click Close. 

9. In Object Explorer, expand Security, expand Credentials, right-click DavidAlexanderCredential, 

and click Properties. 

10. In the Credential Properties - DavidAlexanderCredential window, in the Password textbox, and the 

Confirm password textbox, type Pa$$w0rd, and click OK. 

11. In Object Explorer, right-click the Get File List job, and click Start Job at Step. 


13. In Object Explorer, right-click the Get File List job, and click View History. 

14. In the Log File Viewer - Proseware window, click on the plus sign in a failing row to expand the job 

steps. 

15. Click on the row for Step ID 1.

16. In the Selected row details pane, scroll down to find the error (Access is denied). 

Lab 20: Troubleshooting Common Issues L20-81 

17. In the Log File Viewer - Proseware window, click Close. We need to investigate the job step to see 

why an Access is denied error could be returned. 

18. In Object Explorer, right-click the Get File List job, and click Properties. 

19. In the Select a page pane, click Steps, then click Edit. 

20. Note that the command being executed requires permission to read the directory entries in the 

D:\MKTG folder and permission to write to the L:\MKTG folder using the identity of David 

Alexander. 

21. Click Cancel and then click Cancel. 

22. On the basis that write permissions are less likely to be granted than read permissions, we will 

investigate the write permissions first. In Windows Explorer, right-click folder L:\MKTG and click 

Properties. 

23. In the MKTG Properties window, click the Security tab and note that David Alexander has no access 

to the folder, nor do any groups that he is likely to be a member of. 

24. Click Edit then in the Permissions for MKTG window, click Add. 

25. Ensure that the value of From this location is set to AdventureWorks.msft, then in the Enter the 

object names to select textbox, type David.Alexander and click OK. 

26. In the Permissions for MKTG window, click the Allow checkbox in the Modify row and click OK. 


28. Now we will test if the job runs. 



31. Now we need to check the read permissions. 

32. In Windows Explorer, right-click folder D:\MKTG and click Properties. 

33. In the MKTG Properties window, click the Security tab and note that David Alexander has no access 

to the folder, nor do any groups that he is likely to be a member of. 

34. Click Edit then in the Permissions for MKTG window, click Add. 

35. Ensure that the value of From this location is set to AdventureWorks.msft, then in the Enter the 

object names to select textbox, type David.Alexander and click OK. 

36. In the Permissions for MKTG window, click OK. 


38. Now we will test again whether or not the job runs. 


40. In the Start Jobs - Proseware window, note that the job now works, and click Close.

L20-82 Module 20: Troubleshooting Common SQL Server 2012 Administrative Issues 





1. In Object Explorer, expand the Proseware server, expand Databases, right-click AdminDB 

database, and click Properties. 


3. Review the options related to statistics. 

4. Change the Auto Create Statistics to True. 

5. Change the Auto Update Statistics to True, and click OK. 

Note The following steps cause statistics to be updated immediately rather than waiting 

for autostats to correct the situation. 

6. In Object Explorer, right-click AdminDB, and click New Query. 

7. In the Query window, type the following command: 

EXEC sp_updatestats; 

8. On the Toolbar, click Execute. 





1. In Object Explorer, expand the Proseware server, expand Databases, right-click CityDetails 

database, and click Properties. 


3. Review the options related to statistics. 

4. Change the Auto Close option to False and click OK.

Administering Microsoft® SQL Server® 2012 Database - Advanced ...

Create successful ePaper yourself

Delete template?

Save as template?