Microsoft SQL Server 2008 R2 Unleashed- P77 pps

ptg
704
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
Download from www.wowebook.com
ptg
705
Sample Templates and Real-World Examples
22
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: />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.
Download from www.wowebook.com
ptg
706
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
Download from www.wowebook.com
ptg
707
Summary
22
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.
Download from www.wowebook.com
ptg
This page intentionally left blank
Download from www.wowebook.com
ptg
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.”
Download from www.wowebook.com
ptg
710
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 compression 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
Download from www.wowebook.com
ptg
711
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.
23
Download from www.wowebook.com
ptg
712
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 secondar y 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.
Download from www.wowebook.com
ptg
713

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]
23
Download from www.wowebook.com