Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 19: Playing Administrator
Restoring to a Different Location
Things get tricky when you want to change something about where you’re restoring to. As part of the
backup process, the backup knows what the name of the database that was backed up, and, perhaps
more importantly, it knows the path(s) to the physical files that it was supposed to be using.
Changing the destination database name is right there — no biggie — the problem is that changing the
destination database name does nothing to change which physical files (the MDF and LDF files) it’s
going to try and store to. To deal with this, go to the Options node of the Restore dialog box.
Again, most of the options here are self-describing, but, in particular, notice the Restore As column. In
this part of the dialog box, you can replace every original file’s destination location and name, providing
you with the way to deal with restoring multiple copies of a database to the same server (perhaps for
test purposes) or installing your database to a new volume or even a new system.
Recovery Status
This one is merely about the state you want to have the database be in when you are done with this
restore. This has particular relevance when you are restoring a database and still have logs to apply to
the database later.
If you go with the default option (which translates to using the WITH RECOVERY option if you were
using T-SQL), the database would immediately be in a full online status when the restore operation is
complete. If, for example, you wanted to restore logs after your initial restore was done, you would want
to select one of the two other options. Both of these prevent updates from happening to the database,
and leave it in a state where more recovery can be done; the difference is merely one of whether users
are allowed to access the database in a “read only” mode or whether the database should be appear as
still being offline.
The issue of availability is a larger one than you probably think it is. As big of a deal as I’m sure it
already seems, it’s really amazing how quickly users will find their way into your system when the
restore operation suddenly marks the database as available. Quite often, even if you know that you will
be “done” after the current restore is completed, you’d like a chance to look over the database prior to
actual users being in there. If this is the case, then be sure and use the NO RECOVERY method of restoring.
You can later run a restore that is purely for a WITH RECOVERY option and get the database fully
back online once you’re certain you have things just as you want them.
Index Maintenance
580
Back in Chapter 9, we talked about the issue of how indexes can become fragmented. This can become a
major impediment to the performance of your database over time, and it’s something that you need to
have a strategy in place to deal with. Fortunately, SQL Server has commands that will reorganize your
data and indexes to clean things up. Couple that with the job scheduling that we’ve already learned about,
and you can automate routine defragmentation.
You may still run into maintenance scripts that use the old DBCC DBREINDEX or DBCC INDEXDE-
FRAG commands. Both of these have been replaced by functionality within the ALTER INDEX command.