Michael,

Thanks for the comment. This blog post is almost 8 years old now. It could use some updating.

There are some valid reasons for wanting to reclaim disk space. The scenario I wrote about here is not one of them. The scenario you mention could be one, sure.

I don’t believe that this is a fault of the SQL Server design. I’m not certain I’d want a RDBMS to be actively trying to prune space, that seems to me to be more overhead than necessary. I would also consider the issue of fragmentation, but with flash storage fragmentation isn’t much of an issue anymore.

Thanks again for the comment. I should consider writing an updated post.

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.