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

many rows inserted over time and then have rows purged back out of it as the transactions become old
enough to delete. In this case, we’ll reorganize all the indexes on the table in one simple command:
ALTER INDEX ALL
ON Production.TransactionHistory
REORGANIZE;
You should get back essentially nothing from the database — just a simple message: Command(s)
completed successfully.
How It Works
The ALTER INDEX command sees that ALL was supplied instead of a specific index name and looks up
which indexes are available for our Production.TransactionHistory table (leaving out any that are
disabled since a reorganization will do nothing for them). It then enumerates each index behind the
scenes and performs the reorganization on each, reorganizing just the leaf level of each index (including
reorganizing the actual data since the clustered index on this table will also be reorganized).
Archiving Data
Ooh — here’s a tricky one. There are as many ways of archiving data as there are database engineers. If
you’re building an OLAP database, for example, to utilize with Analysis Services, then that will often
address what you need to know as far as archiving for long-term reporting goes. Regardless of how you’re
making sure the data you need long term is available, there will likely come a day when you need to deal
with the issue of your data becoming simply too voluminous for your system to perform well.
As I said, there are just too many ways to go about archiving because every database is a little bit different.
The key is to think about archiving needs at the time that you create your database. Realize that, as
you start to delete records, you’re going to be hitting referential integrity constraints and/or orphaning
records; design in a logical path to delete or move records at archive time. Here are some things to think
about as you write your archive scripts:
❑ If you already have the data in an OLAP database, then you probably don’t need to worry about
saving it anywhere else; talk to your boss and your attorney on that one.
❑ How often is the data really used? Is it worth keeping? Human beings are natural born pack rats —
just a bit larger than the rodent version. Simply put, we hate giving things up; that includes our
data. If you’re only worried about legal requirements, think about just saving a copy of never or
rarely used data to tape (I’d suggest multiple backups for archive data) and reducing the amount of
data you have online; your users will love you for it when they see improved performance.
❑ Don’t leave orphans. As you start deleting data, your referential integrity constraints should
keep you from leaving that many orphans, but you’ll wind up with some where referential
integrity didn’t apply. This situation can lead to serious system errors.
❑ Realize that your archive program will probably need a long time to run. The length of time it
runs and the number of rows affected may create concurrency issues with the data your online
users are trying to get at; plan on running it at a time where your system will have not be used.
❑ TEST! TEST! TEST!
Chapter 19: Playing Administrator
583