The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P59 pdf

272 Chapter7•MaintainingYourDatabase
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
DBCC results for 'sys.sysrscols'.
There are 1483 rows in 17 pages for object "sys.sysrscols".
DBCC results for 'sys.sysrowsets'.
There are 286 rows in 3 pages for object "sys.sysrowsets".
DBCC results for 'sys.sysallocunits'.
There are 334 rows in 5 pages for object "sys.sysallocunits".
DBCC results for 'sys.sysfiles1'.
(Truncated for brevity)
ALTER DATABASE AdventureWorks
SET MULTI_USER;
GO
Using the DBCC
SHRINKFILE Option to Reclaim Database Space
DBCC SHRINKFILE shrinks a database file or a log file by rearranging data in the
file to reclaim empty space. It can also move all data from a data file to another data
file in the same filegroup, allowing you to remove the empty file. Using DBCC
SHRINKFILE, you can shrink the file to a smaller size than its minimum size
setting. The minimum size setting will then be reset to reflect the actual size. Use
the syntax shown in Example 7.20 to run DBCC SHRINKFILE.
Example 7.20
Using the DBCC SHRINKFILE—Syntax
DBCC SHRINKFILE ( file_name | file_id, [EMPTYFILE],

[target_size], [NOTRUNCATE | TRUNCATEONLY] )
[ WITH NO_INFOMSGS]
When running DBCC SHRINKFILE, you can specify various options to alter
the command behavior. You must specify the logical file name or file ID of the
database or log file you wish to manipulate. When the EMPTYFILE option is spec-
MaintainingYourDatabase•Chapter7 273
ified, the DBCC moves all data from the specified file to other files in the same
filegroup. SQL Server will no longer write to the file you have just emptied, allow-
ing you to remove the empty file using the ALTER DATABASE statement.
You can specify the target_size in megabytes. The DBCC will then attempt to
shrink the file to the target size. It does so by moving all data from throughout the
end pages to free space earlier in the file. The file shrinkage will only be achieved if
enough free space is available in the file.
The NOTRUNCATE option specifies that although the data in the file will be
rearranged, the free space will not be released back to the operating system. This
means that the actual file size of the file will not change. On the other hand,
TRUNCATEONLY will rearrange the data and reclaim the free space to the oper-
ating system, thereby shrinking the file. TRUNCATEONLY ignores the target_size,
reclaiming all possible space. Both NOTRUNCATE and TRUNCATEONLY are
applicable only to database files.
The NO_INFOMSGS specifies that no informational messages are to be shown
by the DBCC.
Example 7.21 demonstrates the use of DBCC SHRINKFILE.
Example 7.21
Using the DBCC SHRINKFILE
USE AdventureWorks;
GO
SELECT file_id, name
FROM sys.database_files;
GO

Reclaim all available free space from the data file
DBCC SHRINKFILE ('AdventureWorks_Data', TRUNCATEONLY);
Results:
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages

5 1 21760 21760 21432 21432
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Shrink the log file to 5 MB
DBCC SHRINKFILE (AdventureWorks_Log, 5);
GO
Empty a file
ALTER DATABASE AdventureWorks
ADD FILE ( NAME = NewData, FILENAME = 'C:\temp\newdata.ndf', SIZE = 5MB);
GO
Empty the data file.
274 Chapter7•MaintainingYourDatabase
DBCC SHRINKFILE (NewData, EMPTYFILE);
GO
Remove the data file from the database.
ALTER DATABASE AdventureWorks
REMOVE FILE NewData;
GO
Results:
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages

5 3 640 640 0 0
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your

system administrator.
The file 'NewData' has been removed.
Backing Up and Restoring Data
Every organization that values its databases must have a disaster recovery strategy
that works when needed. The disaster recovery strategy defines procedures for
backing up and restoring SQL Server databases. Defining and adhering to the
disaster recovery strategy is a primary task of any database administrator. In this
section, you will learn about various types of backup available with SQL Server,
best practices for performing backups, and restoring databases from backup.
Understanding
Database Recovery Models
The database recovery model determines how transaction logs are used by SQL
Server for a specified database. Your choice of recovery model affects which
operations are performed as nonlogged and whether the database can be recovered
to a point in time. Three recovery models are available for SQL Server 2008
databases:
Simple recovery model

Full recovery model

Bulk-Logged recovery model

When the database recovery model is set to Simple, log files are reused as soon
as they become full. This means that very little space is consumed by the transaction
MaintainingYourDatabase•Chapter7 275
logs, and you don’t need to worry about log file management. However, when a
database is set to Simple recovery model and the database file is lost, you will not be
able to recover any changes made after the last full backup. You will also not be able
to recover to a point in time as transaction details are stored in transaction logs that
have been overwritten in this case.

The Full recovery model could be said to be the opposite of the Simple
recovery model. Transaction logs are kept, and all transactions without exception
are written to the logs. This includes nonlogged operations like TRUNCATE
TABLE and SELECT…INTO. Although you lose the performance advantages
of nonlogged operations with this recovery model, all data is recoverable
provided transaction logs are intact. You can also restore to a point-in-time
if necessary.
The Bulk-Logged recovery model is similar to Full recovery model, except that
nonlogged operations are performed as nonlogged. This provides a performance
advantage for Bulk-Logged operations. However, if a Bulk-Logged operation has
occurred since the last full backup, you will not be able to recover any changes
made since the last full backup. The Bulk-Logged recovery model does not support
point-in-time recovery.
In production environments, the full database recovery model is generally used as
it ensures maximum recoverability. However, if the administrator wishes to perform a
high performance nonlogged operation, they would temporarily switch the recovery
model to Bulk-Logged, perform the operation, switch the recovery model back to
Full, and perform a full backup. The Full recovery model is the default when
creating databases in SQL Server.
Backup Types
SQL Server databases can be backed up using the Backup Database Wizard or the
BACKUP DATABASE Transact-SQL statement. By specifying a particular backup
type, you designate what data should be backed up. For example, you may choose
to back up all data in a database or only the differences from the last full backup.
All SQL Server backups are performed online. This means that users can continue to
read and write to and from the database while the backup is being performed.
However, backup is a resource and time intensive operation, especially for large
databases. Therefore, backups should be scheduled at off-peak times to avoid
performance degradation. Table 7.2 describes the types of backup available with
SQL Server 2008.

276 Chapter7•MaintainingYourDatabase
Backup Type Functionality
Purpose
Full Backup Backup all data stored
in data files and a small
part of the transaction
log generated while the
backup operation was
taking place.
To back up an entire
database that can be
restored as a whole. The
most disk intensive and
time consuming backup
type.
Differential
Backup
Backup the extents that
were modified since the
last full backup.
Provides the ability
to create a frequent,
incremental backup which
can then be restored into
an earlier version of a
database restored from
full backup.
Partial Backup Backup of the primary
filegroup, all writeable
filegroups, and

optionally specified
read-only filegroups.
Also available in
differential partial
backup, which backs
up only the extents
changed since the last
full or partial backup
of the corresponding
filegroup.
Perform a more efficient,
full or differential backup
affecting only change-
able data. Especially useful
for large partitioned
databases consisting of
historical data that does
not change and current
data that does. Using
partial backup, you can
back up historical data
only once and perform
frequent partial backups
of the current data.
File or Filegroup
A full backup of a
specified database file
or filegroup.
Allows you to granularly
back up specific files or

file groups for databases
consisting of multiple files.
When database files are
distributed across mul-
tiple disks, you can restore
the data file to the failed
disk only, which is more
efficient than restoring the
entire database.
Table 7.2 SQL Server 2008 Backup Types
Continued