Microsoft SQL Server 2008 R2 Unleashed- P78 ppsx

For example, the following command changes the default filegroup for the mydb database: ALTER DATABASE [mydb] MODIFY FILEGROUP [UserData_FG] DEFAULT... You can also change the default fi

( NAME = N’mydb_index1’,

FILENAME = N’I:\mssql2008\data\mydb_index1.ndf’ ,

SIZE = 2048KB , FILEGROWTH = 1024KB ),

FILEGROUP [UserData_FG]

( NAME = N’mydb_userdata1’,

FILENAME = N’D:\mssql2008\data\mydb_userdata1.ndf’ ,

SIZE = 2048KB , FILEGROWTH = 1024KB ),

( NAME = N’mydb_userdata2’,

FILENAME = N’E:\mssql2008\data\mydb_userdata2.ndf’ ,

SIZE = 2048KB , FILEGROWTH = 1024KB ),

( NAME = N’mydb_userdata3’,

FILENAME = N’F:\mssql2008\data\mydb_userdata3.ndf’ ,

SIZE = 2048KB , FILEGROWTH = 1024KB )

LOG ON

( NAME = N’mydb_log’,

FILENAME = N’L:\mssql2008\log\mydb_log.ldf’ ,

SIZE = 1024KB , FILEGROWTH = 10%)

This example creates a database named mydb that has three filegroups The first filegroup,

PRIMARY, contains the mdf file Index_FG contains one file: I:\mssql2008\data\mydb_

index1.ndf The third filegroup, UserData_FG, contains three data files located on the D:,

E:, and F: drives This example demonstrates the relationship between databases,

file-groups, and the underlying operating system files (The T-SQL for creating a database is

discussed in detail later in this chapter.)

After you create a database with multiple filegroups, you can then create a database object

on a specific filegroup In the preceding example, you could use the filegroup named

UserData_FG to hold user-defined tables, and you could use the filegroup named Index_FG

for the database indexes You assign database objects at the time you create the object The

following example demonstrates the creation of a user-defined table on the UserData_FG

filegroup and the creation of an index for that table on the Index_FG filegroup:

CREATE TABLE dbo.Table1

(TableId int NULL,

TableDesc varchar(50) NULL)

ON [UserData_FG]

CREATE CLUSTERED INDEX [CI_Table1_TableID] ON [dbo].[Table1]

( [TableId] ASC)

ON [Index_FG]

Any objects not explicitly created on a filegroup are created on the default filegroup The

PRIMARY filegroup is the default filegroup when a database is created You can change the

default filegroup, if necessary If you want to change the default group to another group,

you can use the ALTER DATABASE command For example, the following command changes

the default filegroup for the mydb database:

ALTER DATABASE [mydb] MODIFY FILEGROUP [UserData_FG] DEFAULT

You can also change the default filegroup by right-clicking the database in the Object

Explorer, choosing Properties, and selecting the Filegroups page Then you select the

check box labeled Default to make the given filegroup the default Figure 23.1 shows the

filegroups for the AdventureWorks2008 database, with the primary filegroup selected as

the default

When creating filegroups, you should keep in mind the following restrictions:

You can’t move a data file to another filegroup after it has been added to the database

Filegroups apply only to data files and not to log files

A data file can be part of only one filegroup and cannot be spread across multiple

filegroups

You can have a maximum of 32,767 filegroups for each database

NOTE

Using SANs and RAID arrays for the database disk subsystem diminishes the need for

filegroups SAN and RAID systems typically have many disks mapped to a single data

drive This inherently allows for concurrent disk access without requiring the creation of

a filegroup with multiple data files

FIGURE 23.1 Setting the default filegroup in SQL Server Management Studio (SSMS)

Using Partitions

Partitioning in SQL Server 2008 allows for a single table or index to be aligned to more

than one filegroup This capability was introduced in SQL Server 2005 Prior to SQL

Server 2005, you could use filegroups to isolate a table or an index to a single filegroup,

but the table or index could not be spread across multiple filegroups or data files The

ability to spread a table or an index across multiple filegroups is particularly useful for

large tables You can partition a table across multiple filegroups and have data files live on

separate disk drives to improve performance Table partitioning is discussed in more detail

in Chapter 24, “Creating and Managing Tables.”

Transaction Log Files

A transaction is a mechanism for grouping a series of database changes into one logical

operation SQL Server keeps track of each transaction in a file called the transaction log

This log file usually has the extension ldf, but it can have a different extension

Typically, there is only one log file You can specify multiple log files, but these files are

accessed sequentially If multiple files are used, SQL Server fills one file before moving to

the next You realize no performance benefit by using multiple files, but you can use them

to extend the size of the log

NOTE

The transaction log file is not a text file that can be read by opening the file in a text

editor The file is proprietary, and you cannot easily view the transactions or changes

within it However, you can use the undocumented DBCC LOG (database name)

com-mand to list the log contents The output is relatively cryptic, but it can give you some

idea of the type of information that is stored in the log file

Because the transaction log file keeps track of all changes applied to a database, it is very

important for database recovery The transaction log is your friend: it can prevent

signifi-cant data loss and provide recovery that is not possible without it Consider, for example,

a case in which a database is put in simple recovery mode In short, this causes

transac-tion detail to be automatically removed from the transactransac-tion log This optransac-tion is often

selected because the transaction log is seen as taking too much disk space The problem

with simple mode is that it limits your ability to recover transactions If a catastrophic

failure occurs, you can restore your last database backup, but that may be it If that backup

was taken the night before, all the database work done that day is lost

If your database is not in simple mode (Full or Bulk-Logged), and the transaction log is

intact, you have much better recovery options For example, if you back up your

transac-tion log periodically (for example, every hour) and a catastrophic error occurs, your data

loss is limited You still need to restore your last database backup, but you have the option

of applying all the database changes stored in your transaction log With hourly backups,

you should lose no more than an hour’s worth of work This topic is covered in detail in

Chapter 14, “Database Backup and Restore.”

How the Transaction Log Works

SQL Server utilizes a write-ahead log As changes are made to data through transactions,

those changes are written immediately to the transaction log when the transaction is

complete The write-ahead log guarantees that all data modifications are written to the log

prior to being written to disk By writing each change to the transaction log before it is

written to the database, SQL Server can increase I/O efficiency to the data files and ensure

data integrity in case of system failure

To fully understand the write-ahead log, you must first understand the role of SQL Server’s

cache or memory as it relates to database updates SQL Server does not write updates

directly to the data page on disk Instead, SQL Server writes a change to a copy of the data

page that has been placed in memory Pages changed in memory and not yet written to

disk are called dirty pages The same basic approach is used for transaction log updates The

update to the log is performed in the log cache first, and it is written to disk at a later

time The time when the updates are actually written from cache to disk is called a

checkpoint The checkpoint occurs periodically, and SQL Server ensures that dirty pages are

not written to disk before the corresponding log entry is written to disk

The write-ahead log was designed for performance reasons, and it is critical for the

recov-ery process after a system failure If the system fails, an automatic recovrecov-ery process is

initi-ated when SQL Server restarts This recovery process can use the checkpoint marker in the

log file as a starting point for recovery SQL Server examines all transactions after the

checkpoint If they are committed transactions, they are rolled forward; if they are

incom-plete transactions, they are rolled back, or undone

NOTE

Changes were made in SQL Server 2005 that improve the availability of the database

during the recovery process These changes have been carried forward to SQL Server

2008 In versions prior to SQL Server 2005, the database was not available until it

was completely recovered and the roll-forward and roll-back processes were complete

In versions following SQL Server 2005, the database is made available right after the

roll-forward process The roll-back or undo process can occur while users are in the

database This feature, known as Fast Recovery, is available only with the Enterprise

Edition of SQL Server 2008

For more detailed information on this topic, see Chapter 31, “Transaction Management

and the Transaction Log.”

Creating Databases

Database creation is a relatively straightforward operation that you can perform by using

T-SQL statements or SSMS Because the data and log files are created at the time the

data-base is created, the time it takes for the datadata-base to be created depends on the size and

number of files you specify when you create the database If there is not enough disk

space to create any of the files specified, SQL Server returns an error, and none of the files

are created

FIGURE 23.2 Creating a database by using SSMS

NOTE

Enhancements that were added in SQL Server 2005 and still exist in SQL Server 2008

have reduced the amount of time it takes to create a database The reduction in

cre-ation time is attributed to a change in the way the database files are initialized The

ini-tialization of the file with binary zeros is now deferred until the file is accessed via SQL

queries This results in much faster database creation and expansion For example, we

created a database with a 1GB data file on a machine running SQL Server 2008 The

database was created in approximately 1 second The same database was then

creat-ed in SQL Server 2000, running on the same machine The creation of the database

on SQL Server 2000 took approximately 36 seconds This new feature will make a lot

of folks who create and support large databases very happy

Using SSMS to Create a Database

The Object Explorer in SSMS makes creating a database simple You right-click the

Databases node and select New Database The New Database dialog appears, as shown in

Figure 23.2 The General page is selected by default It allows you to select the essential

information needed to create a database, including the database name, database owner,

and location of the database files

Some related information is populated when you enter the database name For example,

the logical name of the database files is populated using the database name The data file

(which is identified with the file type Data) is named the same as the database The log file

(file type Log) has a database name with the suffix _log The logical filename can be

changed, but it must be unique within the database

The location of the database files is an important decision The location for each file is

entered in the Path column in the Database Files grid This column, located on the right

side of the Database Files grid, includes an ellipsis that can help you navigate the directory

structure on your server When you select the location of these files, you should keep in

mind the following:

Disk space—Databases, by nature, grow over time You need to make sure the

loca-tion where you place your database files has sufficient space for growth

Performance—The location of your database files can affect performance

Generally, the data and log files should be placed on separate disk drives (with

sepa-rate controllers) to maximize performance

Organization—Choosing a common location or directory for your database files

can help keep things organized For example, you could choose to place your data

files in directories named \mssql\data\ and \mssql\log instead of using the long

pathname that SQL Server uses by default

There are several restrictions related to the database files specified Each filename must be

unique and cannot be used by another database The files specified for a database must be

located on a local drive of the machine where SQL Server is installed, a SAN drive, or an

iSCSI-based network drive Finally, you need to make sure the path specified exists on the

drive prior to creating the database

NOTE

The default path for the database files is populated based on database settings

val-ues specified in the Server Properties dialog To open this dialog, you right-click the

server in the Object Explorer and choose Properties When the Server Properties

dia-log appears, you choose the Database Settings page, where you see the database

default locations If the database default locations for the log and data files are not

specified, the paths to the master database files are used You can determine the

paths to the master database files by looking at the startup parameters for the SQL

Server instance You can view these startup parameters within the SQL Server

Configuration Manager After you open this application, you right-click the SQL Server

service and select Properties On the Advanced tab of the Properties dialog that

appears, you find the setting named Startup Parameters The –d parameter identifies

the location of the data file for the master database The –l parameter identifies the

location of the log file for the master database

The remaining pages in the New Database dialog allow you to set database options, utilize

filegroups, and set extended properties The Options page contains many settings

discussed in the “Setting Database Options” section later in this chapter Three settings at

the top of the Options page deserve special attention: Collation, Recovery Model, and

Compatibility Level Figure 23.3 shows the Options page

ptg FIGURE 23.3 The Options page for creating a database

Collation specifies how strings are sorted and compared The selection of collation is

language dependent and addresses differences in the way characters are ordered The

default collation for a database is based on the server default, which is set during the

installation of SQL Server The server default for many U.S.-based installations is

SQL_Latin1_General_CP1_CI_AS The collation name provides some insight into how the

collation will work For example, CI is an acronym for Case Insensitive, and AS indicates

that the collation will be Accent Sensitive The following SELECT statement can be used to

list all the available collations and relates details about how the collation behaves:

SELECT * from ::fn_helpcollations()

The Recovery Model setting is critical in determining how much data can be recovered in

the event of a media failure The default is Full, which provides the greatest level of

recov-ery With Full recovery, all changes to the database (inserts, updates, and deletions) are

written to the transaction log, and so are any changes that may have occurred using BCP or

BULK INSERT If a failure occurs on one of the database files, you can restore the database

by using the last full backup All the changes captured in the transaction log since the last

full backup can be reapplied to the database as well

The Bulk-Logged recovery setting is similar to Full recovery but has some differences in

the way that operations (BCP or BULK INSERT) are logged With Bulk-Logged recovery, you

can still restore all the transaction log backups to recover your database to a point in time

NOTE

When either Full recovery or Bulk-Logged settings is selected, it is important to set up

a job or maintenance plan that performs periodic backups of the transaction log A

backup of the transaction log removes data from the log and keeps the size of the

transaction log manageable If regular backups of the transaction log are not made, the

transaction log will continue to grow as every change in the database is written to it

Simple recovery mode offers the simplest backup/recovery model but the greatest

possibil-ity of losing changes to the database This is based on the fact that changes recorded in

the transaction log are automatically truncated when the database is placed in Simple

recovery mode Recovery with Simple mode is limited to using full or differential database

backups that have been taken Simple recovery mode is a good option for read-only

data-bases and for development datadata-bases that can afford the loss of changes since the last

database backup All the recovery models are discussed in detail in Chapter 14

The last setting on the Options page that deserves special attention is Compatibility Level

The Compatibility Level determines the level of backward compatibility the database

engine uses For many newly created databases in SQL Server 2008, the default of SQL

Server 2008 (100) will suffice With this setting, all the new features available with SQL

Server 2008 are utilized In some situations, however, you might want a SQL Server 2008

database to behave as though it were a SQL Server 2005 database or SQL Server 2000

data-base You can accomplish this by setting Compatibility Level to SQL Server 2005 (90) or

SQL Server 2000 (80) Generally, you select older compatibility levels to allow code that

was developed for prior versions of SQL Server to work as it did with those versions

NOTE

The Compatibility Level setting is intended to allow a database to behave as if it were

running in a previous version of SQL Server by providing similar query behavior or by

allowing deprecated features to still work as they did in the previous version However,

setting the Compatibility Level to a prior version does not prevent new SQL Server

2008 features from being implemented in the database The intent of this functionality

is to provide a means for moving a database and application developed for a previous

release of SQL Server to SQL Server 2008 and allow it to work as it did while enabling

you to start taking advantage of new features and capabilities as you migrate the

sys-tem to SQL Server 2008

Using T-SQL to Create Databases

Instead of using SSMS, you can use T-SQL to create a database The T-SQL command to do

this is CREATE DATABASE The CREATE DATABASE syntax is extensive and is best illustrated

with an example Listing 23.1 shows a sample script to create a database called mydb This

script was generated using the Script option available on the New Database screen

LISTING 23.1 Using T-SQL to Create a Database

CREATE DATABASE [mydb] ON PRIMARY

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

SIZE = 2048KB , FILEGROWTH = 1024KB )

LOG ON

( NAME = N’mydb_log’, FILENAME = N’C:\mssql2008\log\mydb_log.ldf’,

SIZE = 1024KB , FILEGROWTH = 10%)

GO

The database created in Listing 23.1 is relatively simple It is named mydb and contains one

data file and one log file The data file is created on the PRIMARY filegroup; it is named

mydb.mdf and is created in the C:\mssql2008\data folder The mydb.mdf file is initially

created with a size of 2048KB, or 2MB If the database utilizes the entire 2MB, the file can

be expanded by the amount specified in the FILEGROWTH parameter In this case, the file

can grow in 1MB increments (Managing file growth is discussed in the section “Managing

Databases,” later in this chapter.)

The log file is defined using the LOG ON clause in the CREATE DATABASE command The

mydb database created in Listing 23.1 has a log file named mydb_log.ldf that is also

created in the C:\mssql2008\data folder The initial size of the file is 1MB, and it can

expand by 10% of the current log file size You need to use caution with large databases

when using a percentage to define FILEGROWTH For example, you may have problems if

you have a large database that has a 30GB log file and a FILEGROWTH of 10% If the

data-base file is set to autogrow, and the 30GB log file is full, it attempts to expand the log file

by 3GB An expansion of this size could be detrimental to performance, and the disk drive

where the log file is located might not have that much disk space remaining

You can specify many of the other options that define a database after the database is

created by using the ALTER DATABASE statement The T-SQL scripting option available on

the CREATE DATABASE screen generates the basic CREATE DATABASE syntax shown in Listing

23.1, and then it generates a series of ALTER DATABASE commands that further define the

database These options are discussed in the next section

Setting Database Options

You can use an abundance of database options to refine the behavior of a database These

options fall into the following categories, which are part of the option specification:

Auto Options

Cursor Options

Database Availability Options

Date Correlation Optimization Options

External Access Options

Parameterization Options

Recovery Options

Service Broker Options

Snapshot Isolation Options

SQL Options

For each category, you can set one or more options You can find a full list of options for

each category in the section “Setting Database Options” in SQL Server Books Online

Some of the options are discussed in further detail in the chapters of this book that relate

to the database options For example, the recovery options are discussed in detail in

Chapter 14, the Service Broker options are discussed in Chapter 49, “SQL Server Service

Broker” (on the CD), and database mirroring options are discussed in Chapter 20,

“Database Mirroring.”

The following section focuses on the database options displayed on the Options page

in SSMS

The Database Options

You can access many of the most common database options via the Options page of the

Database Properties dialog To get to this dialog, you right-click a database in the SSMS

Object Explorer and select Properties When the dialog appears, you select the Options page

from the list on the left side of the Database Properties dialog Figure 23.4 shows the

Options page for the AdventureWorks2008 database The options listed under Other

Options can be listed alphabetically or by category The default display mode is by category

The default settings for these options suffice for most installations However, some options

deserve special attention The options listed under the Automatic category are among

these options The Auto Close option could cause problems in prior versions of SQL

Server This option is intended for desktop implementations in which the database does

not need to be online all the time When users are not accessing the database and this

option is selected, the database files are closed When the first user accesses the database,

the database is brought back online The problem in prior versions was that the

synchro-nous operation of opening and closing the database files caused performance problems

This issue has been addressed in SQL Server 2008 because the operations are now

performed asynchronously The Auto Close option defaults to true only for SQL Server

2008 Express Edition and should generally be left set to false for all other versions

The Auto Create Statistics and Auto Update Statistics options also deserve special attention

in situations in which the creation or updating of statistics is affecting performance

Generally, the creation or updating of statistics improves performance These statistics

enable the Query Optimizer to make the best decisions when determining the access path

to the data In some rare circumstances, there may be performance problems at the time

statistics are created or updated automatically When these situations arise, you can turn off

the Auto Statistics options and schedule the statistics operations to occur during off-hours

Enabling the Auto Shrink option is a good idea for keeping a nonproduction database as

small as possible This option automatically performs a database shrink operation against

the database files when more than 25% of a file contains unused space The default setting