APPENDIX

SQL Server 2008

Considerations

A t the time of this writing, SQL Server 2008 is well into the CTP process. The goal with
the CTP process is to expose only features that are considered near completion—no beta
features with significant issues. This means that we won’t know everything about what
the final product will include until the release to manufacturing (RTM), which is the offi-
cial release.
This also means that by the time you read this appendix, chances are it will be
slightly out of date. No worries. The fundamental changes in most features have been
revealed by this point, and any that haven’t been will be covered in an appendix available
on the Apress web site (www.apress.com).

■Note All information in this appendix is based on the November CTP.

Backup/Restore Improvements
The majority of the backup/restore features remain the same in SQL Server 2008. It still
features full, differential, and log backups; file and filegroup backups; piecemeal and
page-level restores; and so on. It still offers the same basic Full Recovery, Bulk-Logged
Recovery, and Simple Recovery modes. For the most part, Chapters 2, 3, and 4 still apply,
even syntactically.
However, there are some notable improvements to backup and recovery in SQL
Server 2008. These improvements make your job easier and enable you to protect your
database against loss and damage more efficiently. The subsections that follow describe
these new features.

321
322 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS

Tail-Log Backups
SQL Server 2005 was nice enough to warn you to back up the tail of the transaction log
(those transactions in between log backups) if you tried to overwrite an active database.
SQL Server 2008 brings even greater attention to the tail-log within the GUI. As Figure A-1
shows, you now have the option within the GUI of backing up the tail-log and leaving the
database in a NO RECOVERY state.

Figure A-1. The option to back up the tail-log and leave the database in a NO RECOVERY state

This new ability to leave the database in a NO RECOVERY state after backing up the tail-
log may seem like a relatively insignificant change, but I’ve seen far too many tail-logs
destroyed by accident (usually followed by the question, “So how do I get those changes
back?”). Anything that raises awareness of the need to perform a tail-log backup is good,
to my mind.

Native Backup Compression

SQL Server 2008 finally provides a native method for compressing backups. If you’ve ever
looked closely at the size of an uncompressed backup, you’ve seen that it is generally the
same size as the original database. Since everyone seems to agree with the mantra, “Disk
is cheap,” databases tend to grow at an alarming rate. That means the backups of those
databases grow as well.
 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS 323

To compress backups with SQL Server 2005 and earlier, you had to either purchase
a third-party SQL Server backup utility or include some sort of file-based compression
action after the initial native SQL Server backup. With SQL Server 2008, compression is
now supported with each and every backup (see Figure A-2).

Figure A-2. Every SQL instance has a default compression setting (on or off), which you can
override during each individual backup command.

Backup compression is either on or off; there are no varying levels of compression to

set. To enable backup compression at the instance level, you would use the sp_configure
command (I’m hoping that by the time of release, you’ll also be able to use the ALTER
SYSTEM command):

sp_configure 'backup compression default', '1'

Even with compression enabled, your backups will not necessarily shrink by the
same ratio. For example, if the database contains lots of character data, it should have
a high rate of compression (plain text compresses nicely). If the database contains binary
324 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS

data types such as TEXT, IMAGE, or VARCHAR(MAX), the ratio may be slightly less. To check the
ratio of any current backup, a new field called Compressed_Backup_Size has been added to
the MSDB..BACKUPSET table. The following simple query gives you a compression ratio for
an individual backup:

SELECT backup_size/compressed_backup_size FROM msdb..backupset;

If you wish to explicitly include or exclude compression from a single backup, you
simply override the default compression setting for the instance using WITH COMPRESSION
or WITH NO_COMPRESSION in conjunction with a BACKUP DATABASE or BACKUP LOG command.
Unlike the WITH RECOVERY clause, which is the default if not specified, the default com-
pression setting is determined by a SQL Server instance-level setting.
There are a few caveats when it comes to SQL 2008 compression (I think I just heard
a collective sigh of relief from all of the third-party backup vendors out there):

• You may create compressed backups only with SQL Server 2008 Enterprise Edition,
although other editions of SQL Server 2008 will be able to restore them.

• You currently can’t include compressed and uncompressed backups in the same
backup set.

• A tape holding a compressed backup cannot hold any other NTBackup files.

Even with these caveats, backup compression is a feature you’ll want to consider tak-
ing advantage of in order to use disk space (or tape) more efficiently.

■Note Encryption is a feature that is sometimes thought of as going hand in hand with compression.
SQL Server 2008 still doesn’t provide encryption for a backup (just the same basic password protection),
so I see a lot of room for improvement here. Let’s hope we see that improvement soon.

FILESTREAM Data
One of the more significant improvements in SQL Server 2008 is the ability to store
binary objects as files on the operating system, not within 8K data pages. Previous to SQL
Server 2008, all binary objects, such as Word documents and image files, had to be stored
 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS 325

as either TEXT, NTEXT, IMAGE, VARCHAR(MAX), or VARBINARY(MAX). Each of these data types
organized information in terms of 8K pages, which led to a lot of wasted space. A 9K .jpg
file, for example, resulted in 16K minimum in terms of storage space used. This not only
meant a larger database and, hence, a larger backup, but also a slower application.
A traditional alternative to storing binary objects within the database would be to
simply have a VARCHAR field record the literal or relative path to the binary file itself (e.g., a
value such as C:\WordFiles\WordDoc01.doc). The path approach had drawbacks of its own:

• Files were not controlled by SQL Server.

• Files were not included with a SQL Server backup.

Because there was no direct relationship between the file and the database in the tra-
ditional scenario, disaster for one (a lost database or lost file) meant disaster for both.
With the inclusion of FILESTREAM storage in SQL Server 2008, you can combine the
benefit of efficient file storage with the benefits of tightly coupled data stored within
the database itself. When you make use of FILESTREAM storage, you need to also make
use of a filegroup—for example:

FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM

( NAME = FileStreamDBResumes,
FILENAME = N'D:\test\Resumes')

The FILENAME property for the filegroup points to a directory structure. The final
directory listed (Resumes, in the example) is created automatically; the rest of the
directories must already exist. Within the base directory, SQL Server 2008 places a
filestream.hdr file and a subfolder called $FSLOG. SQL Server 2008 uses these to
control the FILESTREAM data and ensure transactional consistency when working with
FILESTREAM data. When SQL Server is running, all FILESTREAM directories are locked and
controlled only by SQL Server.
How does the ability to store large objects as files in the operating system affect the
disaster recovery landscape? For starters, you need to take care not to allow users to
manipulate those files outside of the context of SQL Server. Also, when the database is
backed up and later restored, all of the FILESTREAM data moves along with it. Finally, since
a FILESTREAM is represented within SQL Server as a filegroup, it is possible to include or
exclude that FILESTREAM from a complex filegroup backup/recovery plan, to use piece-
meal restore, and so on. This ability to include or exclude data from backups is a
significant improvement when it comes to working with binary data.
326 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS

A WISH LIST

Unfortunately, SQL Server 2008 still retains a number of misleading features. I would like to think that
by the time SQL Server 2008 is finally released, some of these annoying features will be changed:

• Default recovery after a restore: It is still far too easy to recover the database in the midst of a
restore process. If left unspecified, the default action for a RESTORE DATABASE or RESTORE LOG
command is WITH RECOVERY.

• Misleading Backup and Restore screens in the GUI: SQL Server 2008 uses the same GUI tool
design for the Backup and Restore screens. The Backup screen still has that same Backup Loca-
tion list box, which can give the impression that selecting a file in that list box means that the
backup will be stored in that file. In reality, having multiple files in the Backup Location list box
means that the backup will be striped across all files.

Both of these examples seem simple enough to change, but perhaps I shouldn’t complain. At least
what I’ve said in Chapters 2 and 3 still applies to SQL 2008.

Database Mirroring Improvements

As you might expect, SQL Server 2008 also makes improvements to database mirroring.
There aren’t any fundamental changes: mirroring still works basically the same, and the
different modes of mirroring available remain the same. Rather, the changes lean more
toward fine-tuning than redesign.

Automatic Page Repair

The one exception to what I just said about fine-tuning is the new feature of automatic
page repair. If the principal and mirror are in a synchronized state, page-level errors
occurring at either node are repaired automatically. If a mirror detects a corrupt page, it
will request a replacement from the principal. If the principal detects a corrupted page,
it will request a replacement from the mirror. It’s like having an off-site mechanic con-
tinually fixing your car.
 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS 327

Database Mirroring Tuning

SQL Server 2008 also includes some much-needed improvements to the speed of data-
base mirroring operations. These improvements include

• Log compression: Data changes sent over the network from the principal to the
mirror are now compressed. Given that those data changes represent fully logged
actions that are sent over the network (including an image of the before data, the
text of the statement making the change, and the after data), this compression can
result in a significant speed improvement.

• Mirror server write-ahead: The mirror server now moves ahead asynchronously,
writing log information out to its transaction log, regardless of whether it’s waiting
for further log buffers from the principal.

• Log cache tuning: Improvements to in-memory log caches maximize the amount
of log data that can be sent from a principal to a mirror at any given time.

What do all of these changes mean? For one, synchronous, two-phase commit opera-
tions will have less of an impact on the user experience, meaning fewer lags between data
entry operations. Also, asynchronous configurations are more likely to stay in a synchro-
nized state. The bottom line is that these changes are good news for everyone using
database mirroring.

Change Tracking
With the growing emphasis on legal requirements, as noted by the Sarbanes-Oxley Act of
2002 and the Health Insurance Portability and Accountability Act (HIPAA), being able to
have true change history is critical. SQL Server 2000 and SQL Server 2005 offered C2
auditing, a government specification (see the Divisions and Classes section at http://en.
wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria). SQL Server 2005
included even more attempts at tracking changes, such as Data Definition Language
(DDL) triggers and event notifications. SQL Server 2008 includes a new feature called
Change Tracking, which comes much closer to meeting many legal requirements for
auditing than any of the earlier features.
You can enable Change Tracking at the entire database level, as shown in Figure A-3,
or at the individual table level. Once enabled, tracking is maintained for a set amount of
time and is performed synchronously when Data Manipulation Language (DML) events
occur.
328 APPENDIX ■ SQL SERVER 2008 CONSIDERATIONS

Figure A-3. The new Change Tracking feature provides automated cleanup.

AUDITING TO MITIGATE USER DISASTERS?

Many of the existing features in SQL Server 2005, such as DDL triggers, event notification, and the
OUTPUT clauses, are geared more toward auditing data rather than mitigating or responding to user
disasters. At the moment (and I reserve the right to change my mind in the future), I include SQL Server
2008’s Change Tracking feature in the same category of data auditing rather than one that relates to
disaster recovery. The problem with user disasters is that the actual problem is rarely known. Yes, you
could use Change Tracking to attempt to recover specific changes, but you would need to know exactly
what the issues are to determine exactly what changes need to be recovered.
I may change my mind on the utility of Change Tracking as a disaster recovery tool the more I
work with it as SQL Server 2008 becomes prevalent in the workforce. It’s good to keep an open mind
on new features like this.

Change Tracking can potentially place a heavy load on your storage system and on
your server in general. Unlike Change Data Capture, a SQL Server 2008 feature that pro-
vides similar functionality, Change Tracking is performed using a sort of two-phase
commit. Change Data Capture, on the other hand, works by reading from the transaction
log. These features definitely add to the ability to handle user disasters, but upon initial
review, I wouldn’t consider them a panacea to the problem.
Index

■A partial backups and restores, 92–93

acceptable data loss, 305 piecemeal restores, 94–95
acceptable downtime, 305 restoring, 91–92
accidents, 6 files, 87–90
Active Directory domain, 158 database files, 87–89
active/active configuration, 185–186 differential backups, 88–90
active/active/active/ . . . configuration, 186 overview, 87
active/passive configuration, 183–184 full-text indexes, 95–96
Address Windowing Extensions (AWE) overview, 75
memory, 191 Backup and Restore screen, 326
Advanced Encryption Standard (AES), 202 BACKUP command, 25, 44, 63, 290
Advanced Technology Attachment (ATA), 247 BACKUP DATABASE command, 29, 32, 87,
AES (Advanced Encryption Standard), 202 92, 324
agent proxies, 117–122 backup devices. See logical backup devices
alerts, 122–123 backup file, 47–52
allies, 317 RESTORE FILELISTONLY command, 50
ALTER DATABASE SET PARTNER OFF clause, RESTORE HEADERONLY command,
208 47–50
ALTER DATABASE statement, 68, 76 RESTORE LABELONLY command, 51
ALTER statement, 84 RESTORE VERIFYONLY command, 51–52
ALTER SYSTEM command, 323 backup file sizes, 29–30
ALTER TABLE statement, 84 backup locations, 38–39
Analysis Services, 182 BACKUP LOG statement, 32, 89, 324
architecture backup methods, 39
of database snapshots, 229–231 Backup Settings button, 158
log shipping, 148–150 BACKUP statement, 45, 48
basic, 149–150 BACKUP VERIFYONLY command, 63
multiple standby servers, 150 BackupFinishDate field, 49
archiving, 258, 268 backup/recovery plans (BRPs), 99–139, 277
array still function, 253 base BRPs, 124–137
ATA (Advanced Technology Attachment), 247 fast restore, 128–131
authentication, 263–264 flexible portability, 133–134
automated backup failure, 8 full-text catalogs, 136–137
automated failover, 200 general template for, 124–125
automatic failback, 192 minimal data loss, 131–133
automatic page repair, 326 overview, 124
AWBackup command, 26 short backup window, 125–128
AW.bak file, 28, 53 tables, 135–136
AW.dif file, 29 business constraints for, 102–108
AWE (Address Windowing Extensions) cost, 105
memory, 191 data loss, 104–105
overview, 102–103
■B time to back up, 103–104
backing up and restoring, 75–97 time to restore, 104
disaster scenarios, 96 caveats and recommendations, 139
filegroups, 90–95 components of, 100–102
backing up, 90–91 enhancing basic scenarios, 138
overview, 90 initial and periodic testing, 137
329
330 ■INDEX

overview, 99–100 block size, 245–246

SQL Agent, 113–123 BRPs. See backup/recovery plans (BRPs)
agent proxies, 117–122 BULK clause, 19
alerts, 122–123 Bulk Copy Program (BCP), 19
job schedules, 114 BULK INSERT command, 19
job step tokens, 116–117 Bulk-Logged Recovery mode, 18–20, 28, 87,
jobs and job steps, 114–116 89, 321
overview, 113 restoring differential backups in, 59–60
technical constraints for, 113 restoring full backups in, 56
cost, 111–113 business constraints, for BRPs
hardware capabilities, 109–110 cost, 105
overview, 108–109 data loss, 104–105
personnel availability, 110 overview, 102–103
portability, 110–111 time to back up, 103–104
backup/restore, improvements to, 321–326 time to restore, 104
FILESTREAM data, 324–326 business continuity, 3–5
native backup compression, 322–324 business liaison, 317
tail-log backups, 322 business organizations, 293
Backup/restore planning, 259 buzzronyms, 315, 318
backups
cold, 37 ■C
copy-only, 36 CDP (continuous data protection), 259
database, 13–41 Change Data Capture, 328
differential, 29 Change Tracking feature, 327–328
full, 28 checkpoint, 15, 46
full-text, 37 CHECKPOINT command, 15, 46
log, 28 CheckpointLSN field, 49
mirroring, 35–36, 62 checksum or torn-page error, 246
securing, 32 checksum validation, 31, 73
striped, 32–34 cluster node, 275
striping, 63 cluster utilities, 193
structure, 37 clustered indexes, 85
T-SQL, 21–27 clustering, 11, 144, 175–194, 269, 274
verifying, 63–64 architecture, 176–181
BackupStartDate field, 49 heartbeat, 179
BackupType field, 49 mount points, 179–181
.bak extension, 21 overview, 176–177
bandwidth, 261–262, 267 quorum, 178–179
banging the gong roadblock, 318 resources, 177–178
barriers, 304 cluster-unaware applications, 182–183
base BRPs, 124 configurations, 183–187
fast restore, 128–131 active/active, 185–186
overview, 128 active/active/active/ . . ., 186
potential approach, 129–130 active/passive, 183–184
requirements, 128–129 multiple instances, 187
risks, 130–131 overview, 183
flexible portability, 133–134 database mirroring and, 275
full-text catalogs, 136–137 database snapshots and, 275
general template for, 124–125 disaster categories and, 192–193
minimal data loss, 131–133 failback in, 191–192
overview, 124 failover in, 188–191
short backup window, 125–128 planning for, 188–190
tables, 135–136 server resource planning, 190
batch file, 178 SQL clustering and AWE memory, 191
batch job, 183 log shipping and, 275
BCP (Bulk Copy Program), 19 overview, 175–176
big picture, 270 SQL Server, 181–182

cluster-unaware application, 182
cluster-unaware applications, 182–183
CMDExecProxy proxy, 121
Codepage field, 49
cold backup, 37
Collation field, 49
communication, 317
communication protocol, 256
Community Technology Preview (CTP)
programs, 195
Compressed_Backup_Size field, 324
Compression field, 49
Configure Security wizard, 214–220
configuring
database mirroring feature, 211–223
log shipping, 151–172
disaster categories and, 171–172
failback to primary server, 169–170
failover, 164–169
manual, 152
manual log shipping, 155
monitoring environment, 170–171
overview, 151–152
in SQL Server 2000, 155–156, 163
consulting cost, 106–108
CONTINUE_ON_ERROR clause, 63
CONTINUE_ON_ERROR command, 31
CONTINUE_ON_ERROR option, 65
continuous data protection (CDP), 259
conversant, 267
COPY_ONLY command, 36
copying dependent items, 166
copy-only backup, 36
copy-on-write process, 229
corrupted active backup tape, 7
cost, for BRPs, 105–113
consulting cost, 106–108
design, 112
hardware cost, 106
maintenance and troubleshooting, 113
overview, 105–111
software cost, 106
testing, 112
training, 111
cost-justification, 311, 313
cost-of-business spending, 312
CREATE DATABASE command, 76, 231, 242
Create Endpoint wizard, 215
CREATE INDEX statement, 81
CREATE statement, 76, 81
CREATE TABLE statement, 81
Creation_Date field, 238
credential proxies, 119
CTP (Community Technology Preview)
programs, 195
■INDEX 331
■D
damaged archival tape, 7
damaged cables, 7
Data Definition Language (DDL), 327
Data Encryption Standard (DES), 202
data loss, 104–105, 131–133, 142, 146
Data Manipulation Language (DML), 327
data pages, restoring, 64–65
data partitioning, 258
Data Source Names (DSNs), 166, 167, 169
data transfer, 142
database administration (DBA), 4, 283
database backups, 13–41
additional considerations, 37
backup file sizes, 29–30
copy-only backup, 36
differential backup, 29
disaster categories and, 38–39
error checking, 31–32
full backup, 28
log backup, 28
mirrored backup, 35–36
overview, 13–14
securing backups, 32
SQL Server Recovery modes
Bulk-Logged Recovery, 18–20
changing, 20
Full Recovery, 17
overview, 16
Simple Recovery, 17–18
SQL Server storage, 14–16
striped backup, 32–34
T-SQL backup, 21–27
backup locations, 22–24
comparison of backup locations, 24–25
logical backup devices, 25–27
media sets/backup sets, 27
naming conventions, 21
overview, 21
DATABASE command, 25
database console command (DBCC), 64
Database Maintenance Plan Wizard, 156
database mirroring, 11, 143, 269, 274, 285
clustering and, 275
improvements to, 326–327
log shipping and, 275–276
database mirroring feature
architecture of, 206
client connections with SNAC, 204–206
connections, 201
endpoints, 201–202
message queuing, 203–204
mirror databases, 198–199
overview, 196
ports, 201–202
332 ■INDEX
principal databases, 197–198
witness servers, 200
configuring, 211–223
disaster categories, 225–226
modes, 206–211
High Availability, 209–211
High Performance, 206–207
High Protection, 207–209
overview, 206
selecting, 223–225
overview, 195
database snapshots, 11, 229–242, 269
architecture of, 229–231
clustering and, 275
creating, 231–233
disaster scenarios and, 240–241
with environmental errors, 241
five disaster categories, 240
with hardware errors, 241
managing, 234–238
linking to databases, 237–238
naming conventions, 236–237
with media failures, 241
overview, 229
with process errors, 241
restoring, 233–234
with user errors, 241
uses for, 238–240
creating reporting interface to mirrored
database, 240
dealing with process errors, 238
dealing with user errors, 239
leveraging snapshots in development,
240
point-in-time reporting, 239
restoring, 240
database states, identifying, 165
DatabaseBackupLSN field, 49
databases
linking database snapshots to, 237–238
mirror, 198–199
principal, 197–198
size limitations, 148
standby, 146
multiple, 145
recovering, 165–166
data-protection requirements, 100
DBA (database administration), 4, 283
DBCC (database console command), 64
DBCC CHECKDB command, 64
DBName_SS naming convention, 232
DDL (Data Definition Language), 327
DDL triggers, 328
default filegroups, 80–81, 97
DEFAULT property, 81, 90
defaults, 280
DELETE clause, 193
DELETE command, 44
DELETE FROM Order command, 44
DELETE FROM TABLE command, 238
DELETE statement, 8, 15, 45, 233
dependent items, copying, 166
DES (Data Encryption Standard), 202
design, 112
DeviceType field, 49
differential backups, 29, 149, 321
creating file-specific, 88
restoring, 89–90
in Bulk-Logged Recovery mode, 59–60
in Full Recovery mode, 59–60
in Simple Recovery mode, 59
Digital Linear Tape (DLT), 257
disaster categories, 38–39, 72, 225–226
backup locations, 38–39
backup methods, 39
configuring log shipping and, 171–172
hardware, 266–267
overview, 38
recovery modes, 38
disaster drills, 278
disaster recovery, 3, 12
defined, 1–2
disaster categories, 5–10
environmental, 6
hardware, 6–7
media, 7
overview, 5–6
predictability, probability, and impact,
9–10
process, 7–8
user, 8–9
overview, 1
relationship to high availability and
business continuity, 3–5
technical perspective, 10–11
disaster recovery planning, 269–319
complementary technologies, 274–276
clustering and database mirroring, 275
clustering and database snapshots, 275
clustering and log shipping, 275
database mirroring and log shipping,
276
defining mitigation plans, 274
developing response plans, 273–274
documentation for, 276–277
guiding principles, 270
identifying risk, 271–273
overview, 269–270, 293–294
personality archetypes, 294–304
doomsayers, 296–297
holists, 301–302
information hoarders, 298–300
 ■INDEX 333

isolationists, 297–298 Environment failure, 9

overview, 294 environmental, 72
pacifists, 302–304 backup location, 38
perfectionists, 295–296 backup method, 39
territorialists, 300–301 recovery mode, 38
roadblocks, 304–318 environmental disasters, 6, 281–287
banging the gong, 318 environmental failure, 96, 192
ineffective discovery process, 315 environmental log shipping, 171
ineffective communication of risk, 316 error checking, 31–32
issues with job role vs. project, 314–315 ESCAPE_NONE macro, 117
lack of awareness, 305–311 event notification, 328
lack of management/executive buy-in, ExpirationDate field, 49
311–313 external heat issues, 266
lack of staff buy-in, 313–314 external storage system, 192
overview, 304–305 external support, 277
silos, 317
scenarios, 278–290 ■F
environmental disasters, 286–287 failback, 148, 173
environmental/hardware disasters, in clusters, 191–192
281–285 High Availability mode, 210–211
media disasters, 289–290 High Performance mode, 207
overview, 278 High Protection mode, 208–209
process disasters, 287–289 to primary server, 169–170
user/process disasters, 278–281 failed failover, 190
testing, 277–278 failed motherboard, 7
disaster scenarios, 96, 240–241 failed node, 191
disaster-mitigation technique, 172 failing disk drive, 7
disasters failover, 148, 164–169, 173
environmental, 281–287 in clusters, 188–191
hardware, 281–285 planning for, 188–190
media, 289–290 server resource planning, 190
process, 278–281, 287–289 SQL clustering and AWE memory, 191
user, 278–281 copying dependent items, 166
“Disconnect users” option, 163 High Availability mode, 210
discord, 303 High Performance mode, 207
distribution databases, restoring, 68 High Protection mode, 208
DLT (Digital Linear Tape), 257 identifying database state, 165
DML (Data Manipulation Language), 327 overview, 164
DNS (domain name system), 5 recovering standby databases, 165–166
documentation, 276 redirecting clients to new primary server,
domain name system (DNS), 5 166–169
doomsayers, 296–297 changing DSNs on client machines,
DROP command, 233 166–167
DROP DATABASE command, 233 overview, 166
DSNs (Data Source Names), 166, 167, 169 redirecting DNS, 169
DUMP LOG command, 25 renaming server and changing IP
address, 167–169
■E restoring log backups, 165
eight-node cluster, 181, 186 failover clustering, 274
electromagnetic fields, 289 failover event, 181
electronic documentation, 276 Failover Partner fallback, 206
emergency mode, 37 failover scenarios, 193
encryption, 217 FamilyCount field, 51
end documentation, 272 FamilySequenceNumber field, 51
endpoints, 201–202 fast file initialization, 58–59
endpoints table, 208
334 ■INDEX

fast restore, 128–131 full backups, 28, 149

overview, 128 restoring, 53–59
potential approach, 129–130 in Bulk-Logged Recovery mode, 56
requirements, 128–129 with fast file initialization, 58–59
risks, 130–131 in Full Recovery mode, 55–56
file backups, 321 to new location, 56–58
File Transfer Protocol over SSL (FTPS), 150 in Simple Recovery mode, 53–54
file/filegroup backups, 11, 149, 321 Full Recovery mode, 17, 20, 28, 87, 89, 197,
Filegroup column, 79 321
FileGroupName field, 50 restoring differential backups in, 59–60
filegroups, 76–87, 234 restoring full backups in, 55–56
assigning objects to, 81–84 full-file backup, 88
creating objects in, 81–83 full-text backup, 37, 97
moving objects to, 83–84 full-text catalogs, 136–137, 188, 234
backing up, 90–95 full-text indexes, 95–96
overview, 90 full-text search service, 188
partial, 92–93 fully qualified domain names (FQDNs), 222
creating, 76–79
default, 80–81 ■G
overview, 76 GAM (Global Allocation Map), 64
restoring, 90–95 general template, for base BRPs, 124–125
overview, 90 geo-clustering, 192
partial, 92–93 Global Allocation Map (GAM), 64
piecemeal, 94–95 Group Policy Object (GPO), 167
strategies, 84–87 GUI tool design, 326
isolating specific tables, 86
partitioning tables, 86 ■H
reducing backup/restore time, 86–87 hardware considerations
separating clustered from nonclustered archival storage, 258
indexes, 85 continuous data protection (CDP), 259
separating read-only and read/write disaster categories, 266–267
tables, 85 heat, 265–266
FileID field, 50 network issues, 260–264
FILENAME property, 325 authentication, 263–264
files, backing up and restoring, 87–90 firewalls, 263
database files, 87–89 latency versus bandwidth, 261–262
differential backups, 88–90 name resolution, 262–263
overview, 87 overview, 260
FILESTREAM data, 324–326 routing, 263
filestream.hdr file, 325 online disk storage, 244–257
financial perspective, 311 block size versus stripe size, 245–246
firewalls, 263 locally attached, 246–248
FireWire connections, 248 overview, 244–245
FirstLSN field, 49 RAID configurations, 248–254
Flags field, 49 remote, 254–256
FOR DATA_MIRRORING clause, 217 tape, 257
FOR DATABASE_MIRRORING clause, 204 overview, 244
four-node clusters, 186 power, 264–265
FQDNs (fully qualified domain names), 222 virtualization, 259–260
FROM clause, 237 hardware cost, 106
FROM DATABASE_SNAPSHOT command, hardware disasters, 6–7, 192, 281–285
233 hardware log shipping, 171
$FSLOG subfolder, 325 HBAs (Host bus adapters), 256
FTPS (File Transfer Protocol over SSL), 150 Health Insurance Portability and
Accountability Act (HIPAA), 327
heartbeat, 179
 ■INDEX 335

heartbeat network connection, 200 ■K

heat, 265–266 Kerberos, 263
heat fans, 281
heat sinks, 265, 281 ■L
High Availability mode, 209–211, 225 lack of awareness roadblock, 305–311
high availability, relationship to disaster description of, 306–308
recovery and business continuity, 3–5 business units, 308
High Performance mode, 206–207, 225 executive management, 308
High Protection mode, 207–209, 225 management, 307
HIPAA (Health Insurance Portability and overview, 306
Accountability Act), 327 peers, 307
holists, 301–302 team, 306–307
hops, 147 overview, 305
Host bus adapters (HBAs), 256 removing, 309–311
HTTP over Secure Sockets Layer (SSL) business units, 310–311
(HTTPS), 150 executive management, 310
management, 309–310
■I overview, 309
IBM WebSphere MQ, 204 peers, 309
IIS (Internet Information Services), 153 team, 309
IMAGE binary data type, 324–325 lack of management/executive buy-in
IMAGE type, 81 roadblock, 311–313
impact of failures, 9–10 lack of staff buy-in roadblock, 313–314
indexes landslide effect, 318
full-text, backing up and restoring, 95–96 lapses, power, 264
separating clustered from nonclustered, Large object (LOB) operations, 19
85 LastLSN field, 49
ineffective communication of risk roadblock, latency, 261–262, 267
316 .ldf extension, 14, 76
ineffective discovery process roadblock, 315 leveraging snapshots in development, 240
informal discussions, 309 licensing, 277
information hoarders, 298–300 Linear Tape-Open (LTO), 257
dealing with, 299–300 linking database snapshots to databases,
overview, 298 237–238
problems created by, 299 LOB (Large object) operations, 19
what they value, 299 ‘local’ clause, 168
Information Systems (IS), 305 local disks, 22, 24
Information Technology (IT), 305 locally attached storage, 246–248
initial testing, 137 ATA versus SCSI, 247
INSERT statement, 15, 18 overview, 246–247
installing media, 277 USB and FireWire connections, 248
internal system heat, 265–266 location boundaries, 145
Internet Information Services (IIS), 153 log backups, 28, 149, 165, 321
investment spending, 312 log cache tuning, 327
IP addresses, 167–169 log compression, 327
IS (Information Systems), 305 log marks, 60, 61–62
isolationists, 297–298 Log Sequence Number (LSN), 28, 61
IT (Information Technology), 305 log shipping, 11, 141–173, 274
architecture, 148–150
■J basic, 149–150
job role, 314–315 multiple standby servers, 150
job schedules, 114 benefits of, 143–146
job step tokens, 116–117 low resource overhead, 145
job tokens, 116 multiple standby databases, 145
jobs and job steps, 114–116 no location boundaries, 145
336 ■INDEX
standby databases accessibility, 146
stateless system, 143–144
clustering and, 275
configuring, 151–172
disaster categories and, 171–172
failback to primary server, 169–170
failover, 164–169
manual, 152–155
monitoring environment, 170–171
overview, 151–152
in SQL Server 2000, 155–156, 163
database mirroring and, 276
drawbacks of, 146–148
data loss, 146
database size limitations, 148
failback, 148
failover, 148
network latency, 146
overview, 141
versus replication, 142–143
logical backup devices, 25–27
advantages of, 26
dropping, 26
managing, 26–27
overview, 25
logical dependencies, 188
logical failover, 189–190
logical unit numbers (LUNs), 256
LogicalName field, 50
LogMarkAfterUpdate transaction, 61
loopback address, 222
loosely coupled systems, 144
low system downtime, 225
low user downtime, 225
LSN (Log Sequence Number), 28, 61
LTO (Linear Tape-Open), 257
LUNs (logical unit numbers), 256
■M
magnetic media, 244
maintenance, 113
manual log shipping, 152–155
mapped network drive letters, 22–23
master copy, 276
master databases, restoring, 65–66
.mdf file, 14, 15, 76, 80, 126, 231, 262
mean time to failure (MTTF), 251
measurable downtime, 224
media, 72
backup location, 39
backup method, 39
recovery mode, 38
media disasters, 193, 289–290
media failures, 5, 7, 9, 96
media log shipping, 171
media sets/backup sets, 27
MediaLabelPresent field, 51
MEDIANAME property, 27
message queuing, 203–204
Microsoft Cluster Server (MSCS), 176
Microsoft Message Queuing (MSMQ), 204
mirror databases, 198–199
mirror server write-ahead, 327
MIRROR TO clause, 105, 116, 132, 290
MirrorCount field, 51
mirrored backup, 35–36
mirroring. See database mirroring feature
Mitigation column, 273
mitigation plans, 274, 277
mitigation technologies, 10–11
model databases, restoring, 67
monitoring server, 144, 170
mount points, 176, 179–181
MSCS (Microsoft Cluster Server), 176
MSDB
information contained in, 52–53
restoring databases, 66–67
MSDB.BACKUPSET table, 324
msdb.dbo.backuphistory table, 171
msdb.dbo.sp_add_log_shipping_monitoring
_jobs stored procedure, 171
MSDB.SUSPECT_PAGE table, 31, 52, 64
MSMQ (Microsoft Message Queuing), 204
mssqlsystemresource.ldf file, 69
mssqlsystemresource.mdf file, 69
MTTF (mean time to failure), 251
multiplexing, 32
■N
N+1 formula, 186
NAME option, 232
NAME property, 27
name resolution, 262–263
naming conventions, 241
database snapshots, 236–237
four guideline questions, 236
T-SQL backup, 21
NAS (network-attached storage), 177,
254–255, 258
native backup compression, 322–324
natural disasters, 6
.ndf files, 14, 15, 76, 126, 231
net send command, 122
network cards, 179
network failure, 7
network latency, 146
network-attached storage (NAS), 177,
254–255, 258
networks, 179, 260–264
authentication, 263–264
latency versus bandwidth, 261–262
 ■INDEX 337

name resolution, 262–263 ■P

routing, 263 pacifists, 302–304
NO RECOVERY clause, 161 dealing with, 303–304
NO RECOVERY state, 322 overview, 302–303
nonclustered indexes, 85 problems created by, 303
NORECOVERY clause, 53 what they value, 303
NORECOVERY statement, 89 Page Free Space (PFS), 64
NOUNLOAD|UNLOAD command, 23 PARTIAL clause, 94
NT LAN Manager (NTLM), 263 PARTIAL keyword, 93
NTEXT binary data type, 325 partial restore, 94
NTEXT type, 81 PASSWORD property, 32
NTLM (NT LAN Manager), 263 peer-to-peer model, 142
perceived downtime, 128
■O perfectionists, 295–296
objects, assigning to filegroups, 81–84 periodic testing, 137
creating objects in, 81–83 persistence, 304
moving objects to, 83–84 personality archetypes, 294–304
OLTP (online transaction processing) doomsayers, 296–297
database, 85 holists, 301–302
ON clause, 81, 97 information hoarders, 298–300
online disk storage, 244–257 isolationists, 297–298
block size versus stripe size, 245–246 overview, 294
locally attached, 246–248 pacifists, 302–304
ATA versus SCSI, 247 perfectionists, 295–296
overview, 246–247 territorialists, 300–301
USB and FireWire connections, 248 personality conflicts, 294
overview, 244–245 personnel availability, 110
RAID configurations, 248–254 PFS (Page Free Space), 64
overview, 248 physical failover, 188–189
RAID 0, 248–249 PhysicalName field, 50
RAID 0+1, 252–253 planning, 269
RAID 1, 249 point-in-time reporting, 239
RAID 1+0, 252–253 point-in-time view, 229
RAID 5, 250 points in time, restoring to, 60–62
RAID 5+1, 253–254 creating log marks, 61–62
RAID 6, 251 jumping to LSN number, 61
vendor-specific, 254 specifying time, 60–61
remote, 254–256 port number, 201
NAS, 254–255 portability, flexible, 133–134
overview, 254 overview, 133
SAN, 255–256 potential approach, 133–134
tape, 257 requirements, 133
ONLINE mode, 71 risks, 134
online transaction processing (OLTP) ports, 201–202
database, 85 Position field, 49
OPENROWSET command, 19 POST (power-on self-test), 7
Order Detail table, 135 power, 264–265
Order table, 92, 135 power-on self-test (POST), 7
Order_FG filegroup, 135 predictability of events, 9–10
OrderHistory table, 92 primary data files, 14, 76
OutgoingCredential credential, 120 primary database, 196
OUTPUT clauses, 328 PRIMARY filegroup, 77, 90, 94, 97, 126, 135
principal databases, 197–198
principle proxies, 119
priority list, 271
338 ■INDEX
probability of occurrence, 9–10
problematic environment, 318
process disasters, 278–281, 287–289
process errors, 7–8, 193, 238
process log shipping, 172
Product Support Services (PSS), 37
proprietary storage structure, 178
PSS (Product Support Services), 37
■Q
quorum, 178–179
■R
RAID, 40, 247–253
raising awareness, 306
READ_WRITE_FILEGROUPS keyword, 92
read-only tables, 85
read/write tables, 85
Recover Interval instance setting, 15
recovery
availability during, 46–47
versus restoring, 44–45
RECOVERY clause, 45, 61, 73
Recovery column, 52
RECOVERY INTERVAL setting, 46
recovery modes, 38
redundancy, 268
registry update, 167
release-to-manufacturing (RTM), 204, 321
remote standby database, 276
remote storage, 254–256
NAS, 254–255
SAN, 255–256
Replace column, in MSDB restorehistory
table, 52
REPLACE option, 55
replacement hardware, 193
replication method, 172
replication, versus log shipping, 142–143
reporting interfaces, 240
ReportServer databases, restoring, 70
ReportServerTempDB databases, restoring,
70
resource databases, restoring, 69–70
resource dependencies, 188
resources, cluster, 177–178
Response column, 273
response plans, 273–274
response technologies, 11
Restart column, in MSDB restorehistory
table, 52
restore categories, 72
RESTORE command, 43–70
backup file, 47–52
RESTORE FILELISTONLY command, 50
RESTORE HEADERONLY command,
47–50
RESTORE LABELONLY command, 51
RESTORE VERIFYONLY command,
51–52
data pages, 64–65
differential backups, 59–60
full backups, 53–59
Bulk-Logged Recovery mode, 56
fast file initialization, 58–59
Full Recovery mode, 55–56
restoring to new location, 56–58
Simple Recovery mode, 53–54
mirroring backups, 62
MSDB, 52–53
restoring to specific point in time, 60–62
creating log marks, 61–62
jumping to LSN number, 61
specifying time, 60–61
striping backups, 63
system databases, 65–70
distribution, 68
master, 65–66
model, 67
MSDB, 66–67
ReportServer, 70
ReportServerTempDB, 70
resource, 69–70
tempdb, 68
verifying backups, 63–64
RESTORE DATABASE command, 60, 93, 326
RESTORE FILELISTONLY command, 47, 50
RESTORE HEADERONLY command, 47–50,
61
RESTORE LABELONLY command, 47, 51
RESTORE LOG command, 326
Restore Options dialog box, 161
RESTORE statement, 45, 48
RESTORE VERIFYONLY command, 47, 51–52,
63
Restore_Database_Name column, 52
Restore_Date column, 52
Restore_Type column, 52
restorefile table, 52
restorefilegroup table, 52
restorehistory table, 52
restoring. See backing up and restoring
restoring database snapshots, 233–234, 240
restoring databases, 43–73
availability during recovery, 46–47
caveats and recommendations, 72–73
overview, 43–44
versus recovery, 44–45
restore and disaster categories, 72
SUSPECT status, 71–72
T-SQL’s RESTORE command, 47–70
 ■INDEX 339

backup files, 47–52 server-room design, 6

data pages, 64–65 servers
differential backups, 59–60 renaming, 167–169
full backups, 53–59 standby, multiple, 150
mirroring backups, 62 witness, 200
MSDB, 52–53 Service Broker, 204
restoring to specific point in time, 60–62 service pack installation issues, 8
striping backups, 63 Service Principal Name (SPN), 264
system databases, 65–70 SFTP (Secure File Transfer Protocol), 150
verifying backups, 63–64 SGAM (Secondary Global Allocation Map), 64
RESTRICTED_USER mode, 71 short backup window, 125–128
REWIND|NOREWIND command, 23, 47 overview, 125
risk identification, 271–273 potential approach, 125–127
risk management, 271 requirements, 125
risk matrix, 277 risks, 127
roadblocks, 304–318 SID (Security Identifier), 211
banging the gong, 318 sign-off document, 316
ineffective discovery process, 315 silos roadblock, 317
ineffective communication of risk, 316 Simple Recovery mode, 17–18, 20, 87, 321
issues with job role vs. project, 314–315 restoring differential backups in, 59
lack of awareness, 305–311 restoring full backups in, 53–54
lack of management/executive buy-in, SINGLE_USER mode, 71
311–313 Small Computer System Interface (SCSI), 247
lack of staff buy-in, 313–314 SNAC (SQL Native Access Client), 167,
overview, 304–305 204–206, 226
silos, 317 snapping back, 240
routers, 179 snapshots, 167, 241, 242
routers and switches, 263 software cost, 106
routing, 263 SoftwareVendorID field, 49
RSKEYMGMT.EXE utility, 70 SortOrder field, 49
RTM (release-to-manufacturing), 204, 321 source database, 234
SourceDB column, 237
■S sp_adddumpdevice procedure, 25
SAN (storage area network), 254, 255–256, sp_change_users_login stored procedure,
258 211
Sarbanes-Oxley Act of 2002, 327 sp_configure command, 46, 323
SATA (Serial Advanced Technology space management, 246
Attachment), 247, 251 sparse file, 230
scare tactics, 319 SPN (Service Principal Name), 264
Script Configuration button scripts, 164 SPYGLASSTAB\jluetke command-line, 122
SCSI (Small Computer System Interface), 247 SQL Agent, 113–123, 183
secondary data files, 14 agent proxies, 117–122
secondary databases, for reporting, 173 alerts, 122–123
Secondary Global Allocation Map (SGAM), 64 job schedules, 114
Secure File Transfer Protocol (SFTP), 150 job step tokens, 116–117
securing backups, 32 jobs and job steps, 114–116
Security Identifier (SID), 211 overview, 113
SELECT @@SERVERNAME property, 168 SQL Agent service, 113
SELECT INTO statement, 19 SQL Native Access Client (SNAC), 167,
SELECT queries, 230 204–206, 226
separate log backups, 172 SQL Server 2000, 155–156, 163
Serial Advanced Technology Attachment SQL Server 2008, 321–328
(SATA), 247, 251 backup/restore improvements, 321–326
server environment, 283 FILESTREAM data, 324–326
server instance, 180 native backup compression, 322–324
server resource planning, 190
340 ■INDEX

overview, 321 SUSPECT_PAGE table, 31, 64, 73

tail-log backups, 322 sys.database_mirroring_endpoints table, 208
Change Tracking feature, 327–328 sys.databases, 237
database mirroring improvements, sysjobschedules schedule, 114
326–327 SYS.MASTER_FILES table, 68
automatic page repair, 326 sys.sysdatabases, 237
overview, 326 system databases, 65–70
speed, 327 distribution, 68
overview, 321 master, 65–66
SQL Server clustering, 181–182, 191 model, 67
SQL Server error log, 198 MSDB, 66–67
SQL Server Integration Services (SSIS), 66 ReportServer, 70
SQL Server Recovery modes, 16–20 ReportServerTempDB, 70
Bulk-Logged Recovery, 18–20 resource, 69–70
changing, 20 tempdb, 68
Full Recovery, 17
overview, 16 ■T
Simple Recovery, 17–18 tables, 135–136
SQL Server storage, 14–16 isolating specific, 86
sqlservr -m command, 65 overview, 135
SSIS (SQL Server Integration Services), 66 partitioning, 86
SSL (HTTP over Secure Sockets Layer)HTTPS potential approach, 135
(), 150 requirements, 135
standby databases, 196 risks, 135–136
multiple, 145 separating read/write and read-only, 85
recovering, 165–166 tail-log, 280
“Standby mode” option, 162 tail-log backups, 322
standby recovery mode, 146 tape storage, 23–24, 243, 257–258
standby servers, 142, 150, 165 technical constraints, for BRPs, 113
stateless system, 143–144 cost, 111–113
Stop_At column, 52 hardware capabilities, 109–110
Stop_At_Mark_Name column, 52 overview, 108–109
Stop_Before column, 52 personnel availability, 110
STOP_ON_ERROR command, 31, 63 portability, 110–111
STOPAFTERMARK option, 62 tempdb databases, restoring, 68
STOPAT clause, 61 TEMPDEV file, 68
STOPBEFOREMARK option, 62 temperature control, 281
storage area network (SAN), 254, 255–256, template, general, for base BRPs, 124–125
258 TEMPLOG file, 68
storage devices, 111 territorialists, 300–301
stored procedures, 240 dealing with, 301
strategies, filegroup, 84–87 overview, 300
isolating specific tables, 86 problems created by, 300–301
partitioning tables, 86 what they value, 300
reducing backup/restore time, 86–87 testing, 112, 137
separating clustered indexes/heaps from TEXT binary data type, 324–325
nonclustered indexes, 85 TEXT type, 81
separating read-only and read/write third-party backup products, 111
tables, 85 tightly coupled systems, 144
stripe set, 253 training, 111, 283
stripe size, 245–246 Transact SQL. See T-SQL
striped backup, 32–34, 63 Transaction Log Backup Settings screen, 159
structure backup, 37 transaction log file, 76
surges, power, 264 Transaction Log Shipping Status report, 171
SUSPECT mode, 112 transaction logs, 14, 97
SUSPECT status, 71–73, 86 .trn extension, 28
 ■INDEX 341

troubleshooting, 113 UPS (Uninterruptible Power Supply), 264,

T-SQL (Transact SQL), 234. See also T-SQL 265, 284
backup USB connections, 248
RESTORE command, 47–70 USB drives, 248
data pages, 64–65 user downtime, 224
differential backups, 59–60 user errors, 8–9, 193, 239
full backups, 53–59 User failure, 10, 96
information contained in MSDB, 52–53 user log shipping, 172
information in backup file, 47–52 User_Name column, 52
mirroring backups, 62
restoring to specific point in time, 60–62 ■V
striping backups, 63 VARBINARY(MAX) binary data type, 325
system databases, 65–70 VARCHAR field, 325
verifying backups, 63–64 VARCHAR(MAX) binary data type, 324–325
scripts, 113, 234 vendor-specific RAID, 254
T-SQL (Transact SQL) backup, 21–27 verifying backups, 63–64
backup locations, 22–24 VERIFYONLY command, 64
local disks, 22 virtual server, 187
mapped network drive letters, 22–23 virtualization, 259–260
overview, 22
tape, 23–24 ■W
UNC share, 23 weighting technique, 272
comparison of locations, 24–25 WHERE clause, 8, 45, 193, 238
logical backup devices, 25–27 WHERE statement, 287
advantages of, 26 WINS (Windows Internet Name Service)
dropping, 26 resolution, 262
managing, 26–27 WITH clause, 47, 166
overview, 25 WITH COMPRESSION compression setting,
media sets/backup sets, 27 324
naming conventions, 21 WITH COPY_ONLY clause, 60, 132, 212, 281
overview, 21 WITH ENCRYPTION clause, 202
two-node clustering, 181, 186 WITH FILE file, 48
Type field, 50 WITH INIT clause, 28
WITH MEDIANAME file, 48
■U WITH MOVE clause, 161
UNC (Uniform Naming Convention) path, 23 WITH NO RECOVERY clause, 166
uncoupled systems, 144 WITH NO_COMPRESSION compression
UnicodeComparisonStyle field, 49 setting, 324
UnicodeLocaleID field, 49 WITH NORECOVERY clause, 45
Uniform Naming Convention (UNC) path, 23 WITH RECOVERY clause, 45, 53, 57, 73, 149,
Uninterruptible Power Supply (UPS), 264, 165, 324
265, 284 WITH REPLACE clause, 56
UNLOAD|NOUNLOAD option, 47 WITH STOPAT clause, 56
UPDATE PRODUCT SET PRICE=1*1.1 witness servers, 200
command, 287 worst-case scenario, 22, 316
UPDATE statement, 8, 15, 233, 287