Microsoft SQL Server 2008 R2 Unleashed- P77 pps

Sample Templates and Real-World Examples The following sections illustrate the sample policy templates included with SQL Server 2008 and real-world examples for using Policy-Based Manage

CHAPTER 22 Administering Policy-Based Management

FIGURE 22.8 The Evaluation Results pane

Importing a policy from an XML file is just as simple Follow these steps to import a

policy with SQL Server Management Studio:

1 In Object Explorer, expand the Management folder, expand the Policy Management

node, and then select Policies

2 Right-click on the Policies folder and select Import

3 The import screen has three options you need to be aware of:

a First, provide the path of the file to import

b Second, enable the option Replace Duplicate Items When Imported

c Finally, in the Policy State drop-down box, specify the state of the policy being

imported The options include Preserve Policy State on Import, Enable All

Policies on Import, and Disable All Policies on Import

Sample Templates and Real-World Examples

The following sections illustrate the sample policy templates included with SQL Server

2008 and real-world examples for using Policy-Based Management

Sample Policy Templates

SQL Server 2008 includes a plethora of predefined sample policies, which can be leveraged

by importing them into a SQL Server 2008 system The policies available for import are

located in the default installation drive at C:\Program Files\Microsoft SQL

Sample Templates and Real-World Examples

Server\100\Tools\Policies As mentioned earlier, you can import the desired policies by

right-clicking the Policies node and selecting Import The sample templates are categorized

by SQL Server feature such as Database Engine, Reporting Services, and Analysis Services

Evaluating Recovery Models

Recovery models determine how SQL Server uses the transaction log On OLTP systems,

the most appropriate recovery model is generally the Full Recovery model For OLAP

systems, the most appropriate recovery model is generally the simple recovery model For

most development environments, the most appropriate recovery model is also the simple

recovery model

For mission-critical databases, or databases where point-in-time recovery is important,

having a transaction log backed up every five minutes may be required Policy-Based

Management can be used to determine whether the appropriate recovery model is in place

for each user database for each server type Central Management Servers could be created

for each server type and a policy can be created to ensure that the appropriate recovery

model is in place across all servers managed within a management server

Implementing Surface Area Configuration Checks

SQL Server 2005 shipped with the SQL Server Surface Area Configuration (SAC) tool This

tool allowed you to enable or disable various components and services on individual SQL

2005 Servers This feature was deprecated in SQL Server 2008 because the Microsoft team

felt that the better way to handle these configuration tasks was through Policy-Based

Management

If you want to implement the Surface Area Configuration feature in SQL Server 2008 to

configure components and services, import the following policies:

Surface Area Configuration for Database Engine 2005 and 2000 Features.xml

Surface Area Configuration for Database Engine 2008 Features.xml

Surface Area Configuration for Service Broker Endpoints.xml

Surface Area Configuration for SOAP Endpoints.xml

SQL Server Health Checks

One of the SQL Server Support Engineers has posted blog entries on how to perform

server health checks using Policy-Based Management You can access his blog using this

URL:

http://blogs.msdn.com/bartd/archive/2008/09/11/defining-complex-server-health-policies-in-sql-2008.aspx

The main part of the SQL Server health check revolves around ensuring the disk response

times are less than 100ms The Policy uses ExecuteSQL to query the dynamic management

view sys.dm_io_virtual_file_stats to ensure that the disk response time is within this

limit You can extend this policy to query other DMVs for other health checks—for

example, the use of excessive parallelism or checking to ensure that cumulative wait stats

have not exceeded desired boundaries

CHAPTER 22 Administering Policy-Based Management

Ensuring Object Naming Conventions

Your company may have standards for naming objects For example, stored procedures

must start with the prefix usp, tables must start with the prefix tbl, and functions must

start with the prefix ufn Policy-Based Management can be used to ensure that all objects

are compliant with this policy This policy can be implemented to execute as On Change

Prevent, which prevents the creation of such noncompliant objects

Checking Best Practices Compliance

You can implement policies that check for SQL Server best practices For example,

data-bases can be configured with the autoclose and autoshrink options Although these

options have their place on some systems, they are not recommended to be enabled in

production environments because the autoclose option causes a time delay while the

data-base is opened by a connection trying to access it This can lead to timeouts The

autoshrink option can lead to fragmentation and is in general not recommended A policy

can check for these settings and other settings to ensure that all your databases are

follow-ing best practices

Policy-Based Management Best Practices

Following are some best practices to consider when implementing Policy-Based

Management in SQL Server 2008:

When deploying Policy-Based Management in your environment, you should be

very careful about using On Change Prevent For example, a policy that prevents

stored procedure creation with the sp_ prefix prevents the enabling of replication on

a SQL Server

When you create a policy that you want enforced on all user databases, you should

place this policy in the default category so that it is subscribed to all databases

Otherwise, you need to manually subscribe all databases to the categories that

contain the policies you want enforced

You should make use of multiple Configuration Servers or Server Groups to group your

SQL Servers according to logical groupings on which you want to group your policies

Importing policies into centralized SQL Server 2008 servers makes it easier to deploy

groups of policies against groups of servers using Central Management Servers—for

example, to store data warehouse policies on Server A You should use this server as

a source when selecting policies to evaluate against your data warehouse servers

registered in the Data Warehousing Central Management Server

You might find that your environment contains third-party user

applications/data-bases that are not in compliance with the policies you have created for your

enter-prise Policy-Based Management uses the opt-in metaphor such that all policies are

enforced by default For databases on which you do not want the policy to be

enforced, you need to tag the database, perhaps with an extended property or a

Summary

specially named table that the server exception category or target will detect and

exempt that server or database from the policy

You should use the ExecuteWSQL task to issue WMI queries to extend conditions and

policies beyond the SQL Server environment—for example, to check what other

ser-vices may be running on a server hosting SQL Server

Summary

Policy-Based Management is a new component in SQL Server 2008 that allows you to

manage your SQL 2000, 2005, and 2008 servers by creating policies that can be used to

enforce compliance to best practices or to report on out-of-compliance servers It provides

a highly granular, flexible, and extensible toolset that allows you to manage all aspects of

your SQL Server Properly used, it is a great tool to enforce standardization in your

envi-ronment and to ease the management burden

The next part of this book, Part IV, “Database Administration,” explores the tasks involved

in creating and managing databases and database objects, just the sorts of things you want

to apply many of your best practices and policies against

This page intentionally left blank

CHAPTER 23 Creating and Managing

Databases

IN THIS CHAPTER

What’s New in Creating and Managing Databases

Data Storage in SQL Server

Database Files

Creating Databases

Setting Database Options

Managing Databases

A database is a collection of tables and related objects that

help protect and organize data It must exist before you can

create all database objects, including tables, indexes, and

stored procedures This chapter focuses on how to create a

sound database that can house database objects and how to

manage the database after the objects are created The

creation and management of the various database objects is

discussed in the remaining chapters in Part IV, “Database

Administration.”

NOTE

It is important to remember that SQL Server actually

uses its own set of databases that are installed by

default when SQL Server is installed These databases

are referred to as system databases The databases

that users create are aptly named user databases The

system databases include master, model, msdb,

tempdb, and resource Each of these databases

per-forms a key function in the operation of SQL Server

For example, the master database contains an entry

for every user database created and contains

server-wide information critical to the operation of SQL

Server The model database is basically a template

database for any newly created databases Each

sys-tem database is based on a structure similar to user

databases and contain database objects like those

contained in user databases The system databases

are discussed in detail in Chapter 7, “SQL Server

System and Database Administration.”

CHAPTER 23 Creating and Managing Databases

What’s New in Creating and Managing Databases

SQL Server 2008 offers several new features that provide improved security and

manage-ability The primary security enhancement is the capability to encrypt an entire database

using Transparent Data Encryption (TDE) This transparent data encryption applies to the

data files and log files that make up a database It allows for an entire database to be

secure via encryption without the need to change existing applications or the individual

database objects Transparent Data Encription is covered in Chapter 12, “Data Encryption.”

The manageability improvements in SQL Server 2008 are centered around data

compres-sion and enhanced database mirroring The data comprescompres-sion improvements help reduce

the amount of space that your database files occupy The enhancements in database

mirroring include automatic page repair, improved performance, and enhanced

supporta-bility via additional performance counters and new dynamic management views Database

mirroring is discussed in more detail in Chapter 20, “Database Mirroring.”

Data Storage in SQL Server

A database is a storage structure for database objects It is made up of at least two files

One file, referred to as a data file, stores the database objects, such as tables and indexes

The second file, referred to as the transaction log file, records changes to the data A data

file or log file can belong to only one database

SQL Server stores data on the data file in 8KB blocks, known as pages A page is the

small-est unit of input/output (I/O) that SQL Server uses to transfer data to and from disk An

8KB page is equal to 1024 bytes × 8, or 8192 bytes There is some overhead associated with

each data page, so the maximum number of bytes of data that can be stored on a page is

8060 bytes The overhead on a data page includes a 96-byte page header that contains

system information about the page This system information includes the page number,

page type, and amount of free space on the page

Generally, a row of data in a SQL Server database is limited to the 8060-byte maximum

With SQL Server 2008, there are some exceptions to this 8060-byte limit if the table

contains columns that have the data types text/image, varchar, nvarchar, varbinary, or

sql variant With these data types, SQL Server can store the data in a separate data

struc-ture when the size of the row exceeds the 8060-byte limit When the 8060-byte limit is

exceeded, SQL Server stores a pointer to the separate data structure so that the information

in these columns can be accessed

In an effort to reduce internal operations and increase I/O efficiency, SQL Server, when

allocating space to a table or an index, allocates space in extents An extent is eight

contigu-ous pages, or 64KB of storage There are actually two types of extents Every table or index

is initially allocated space in a mixed extent As the name implies, mixed extents store pages

from more than one object When an index or a table is first created, it is assigned an

index allocation map (IAM), which is used to track space usage for the object, and at least

one data page The IAM and data page are assigned to a mixed extent in an effort to save

Database Files

space because dedicating an extent to a table with a few small rows would be wasteful Up

to eight initial pages are assigned this way When an object requires more than eight pages

of storage, all further space is allocated from uniform extents A uniform extent stores pages

for only a single index or table This allows SQL Server to optimize read and write

opera-tions and reduce fragmentation because the data is stored in units of 64KB (that is, eight

pages) as opposed to individual 8KB pages being scattered throughout the data file

For more detailed information on the internal storage structures and how to manage them

in SQL Server databases, see Chapter 38, “Database Design and Performance.”

Database Files

SQL Server maps a database over a set of operating system files visible to the SQL Server

machine Microsoft recommends that the files be located on a storage area network (SAN),

on an iSCSI-based network, or on a locally attached disk These three storage options

provide the best performance and reliability for a SQL Server database You have an option

of storing database files on a network, but this option is turned off by default You can use

the trace flag 1807 to enable network-based database files, but it is generally not

recom-mended that you do so

Each database can contain a maximum of 32,767 files Each database file serves a different

purpose for the database engine These files have a standard layout that allows SQL Server

to organize and read the data within the files SQL Server needs to keep track of the

allo-cated space in each data file; it does so by allocating special pages in the first extent of

each file Because the data stored on these pages is dense and the files are accessed often,

they are usually found in memory; therefore, they can be retrieved quickly

The first page (page 0) in every file is the file header page This page contains information

about the file, such as the database to which the file belongs, the filegroup it is in, the

minimum size, and its growth increment

The second page (page 1) in each file is the page free space (PFS) page The PFS page keeps

track of the other pages in the database file The PFS uses 1 byte for each page This byte

keeps track of whether the page is allocated, whether it is empty, and, if it is not empty,

how full the page is A single PFS page can keep track of 8,000 contiguous pages

Additional PFS pages are created as needed

The third page (page 2) in each file is the global allocation map (GAM) page This page

tracks allocated extents Each GAM page tracks 64,000 extents, and additional GAM pages

are allocated as needed The GAM page contains 1 bit for each extent, which is set to 0 if

the extent is allocated to an object and to 1 if it is free

The fourth page (page 3) is the secondary GAM (SGAM) page The SGAM page tracks

allo-cated mixed extents Each SGAM page tracks 64,000 mixed extents, and additional SGAM

pages are allocated as needed A bit set to 1 for an extent indicates a mixed extent with

pages available

CHAPTER 23 Creating and Managing Databases

Primary Files

The primary data file is the data file that keeps track of all the other data files used by the

database It is an operating system file that typically has the file extension mdf SQL

Server does not require that it have this mdf extension, but it is recommended for

consis-tency The primary data file is the first file created for a database Each database must have

only one primary file This file stores data for any database objects mapped to it, and it

contains references to any other database files created

In many cases, the primary data file is the only data file There is no requirement to have

more than one data file, and often, a database contains only one primary data file (for

example, C:\mssql\mydb.mdf) and only one log file (for example, C:\mssql\mydb_log.ldf)

Secondary Files

You can create zero or more secondary data files in a database These files, by default, are

identified with the ndf extension, but the extension can be different Secondary data files

provide an opportunity to spread the data that SQL Server stores over more than one

phys-ical file This capability can be particularly useful for larger databases and can help with

performance and management of database files Consider, for example, a situation in

which a database server has four physical drives available for the data file(s) Each drive is

1GB in size, but the database you are creating is 2GB In this example, the database will not

fit on one drive A solution to this problem is to create a primary data file on one of the

drives and a secondary data file on each of the three remaining drives SQL Server

automat-ically spreads the 2GB database across the four data files located on four separate drives

Secondary files also provide some added flexibility for backing up or copying databases

This is most apparent with large databases For example, let’s say you have a 100GB

data-base, and it contains only a primary data file If you want to move this database to

another environment, you must have a drive that is at least 100GB to store the primary

data file If you want to copy the database to a server that has 10 50GB drives, you cannot

do it You have the space across all 10 drives, but you do not have a single drive that can

hold the primary data file If, however, you create the database with several secondary

files, you have the option of placing each of the secondary files on a separate drive

TIP

You can use the sys.master_files catalog view to list the database files for all the

databases For example, SELECT db_name(database_id),* from

sys.master_files order by 1 returns all the database files, ordered by the name

of the database they belong to You can change the sort order for the SELECT

state-ment and order it by physical_name to quickly locate a database file and find which

database is using that file

Database Files

Using Filegroups

Filegroups allow you to align certain database objects with specific data files Tables,

indexes, and large object (LOB) data can be assigned to a filegroup A filegroup can be

associated with one or more data files The alignment of data and indexes to filegroups

can provide performance benefits and improve manageability Each database has at least

one filegroup, called the primary filegroup This filegroup, by default, contains the primary

data file and any other secondary data files that have not been specifically aligned with

another filegroup Any database object that you create without specifying a filegroup is

created in the primary filegroup

Additional filegroups can be created and aligned with secondary data files There is no

requirement to have more than one filegroup, but additional filegroups give you added

flex-ibility Filegroups can be aligned with data files that can be stored on separate disk drives to

improve data access This improvement is facilitated by concurrent disk access across the

disk drives assigned to the filegroups

TIP

If too many outstanding I/Os are causing bottlenecks in the disk I/O subsystem, you

might want to consider spreading the files across more disk drives Performance

Monitor can identify I/O bottlenecks by monitoring the PhysicalDisk object and Disk

Queue Length counter You should consider spreading the files across multiple disk

drives if the Disk Queue Length counter is greater than two times the number of

spin-dles on the disk For more information on monitoring SQL Server performance, see

Chapter 39, “Monitoring SQL Server Performance.”

For example, you could create a filegroup called UserData_FG, consisting of three files

spread over three physical drives You could create another filegroup named Index_FG,

with a single file, on a fourth drive Then, when you create the tables, you can create

them on the UserData_FG filegroup You can create indexes on the Index_FG filegroup

This reduces contention between tables because the data is spread over three disks and can

be accessed independently of the indexes If more storage is required in the future, you

can easily add additional files to the index or data filegroup, as appropriate

You can create filegroups at the time the database is created, or you can add them after

the database is created When you create filegroups along with the database, the definition

for the filegroup is contained in the CREATE DATABASE statement Following is an example

of a CREATE DATABASE statement with filegroup definitions:

CREATE DATABASE [mydb] ON PRIMARY

( NAME = N’mydb’,

FILENAME = N’C:\mssql2008\data\mydb.mdf’ ,

SIZE = 2048KB , FILEGROWTH = 1024KB ),

FILEGROUP [Index_FG]