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).
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.
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.
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:
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:
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:
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.
• 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.
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