Microsoft SQL Server 2008 R2 Unleashed- P78 ppsx

ptg
714
CHAPTER 23 Creating and Managing Databases
( 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
Download from www.wowebook.com
ptg
715
Database Files
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.
23
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).
Download from www.wowebook.com
ptg
716
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 transaction log. This option 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.”
CHAPTER 23 Creating and Managing Databases
Download from www.wowebook.com
ptg
717
Creating Databases
23
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 recovery 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 database 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.
Download from www.wowebook.com
ptg
718
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.
CHAPTER 23 Creating and Managing Databases
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
Download from www.wowebook.com
ptg

719
Creating Databases
23
(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.
Download from www.wowebook.com
ptg
720
CHAPTER 23 Creating and Managing Databases
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.
Download from www.wowebook.com
ptg
721
Creating Databases
23
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 databases 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.
Download from www.wowebook.com
ptg
722
CHAPTER 23 Creating and Managing Databases
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
Download from www.wowebook.com
ptg
723
Setting Database Options
23
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
Download from www.wowebook.com