With several “mirror” databases supporting the main analysis process, shrinking any transaction logs and datafiles in these dbs before archiving is essentially a requirement – the integrity of the data tables themselves is all that really matters.

Likewise discrete analyses are done in separate databases extracted from an appended set. In these DBs many process tables are created that are not required for the final reporting, and likewise a number of statistics and indices are generated that will not be used after the reporting is complete. The overhead objects can be lost entirely, and the space released before detaching and archiving.

While this is a very atypical scenario – if you work in an environment where the ability to reproduce exactly a certain result set is necessary this can be fairly bullet proof, but it DOES eat up quite a bit of storage space – so removing the unnecessary information and then compacting the files as much as possible is sort of an implicit requirement.

And as Brant says – every once in a while someone might need to do a query on one of these historical sets which has not yet been shipped off to archive.