I have used Shrink DB quite regularly in the past with a satisfying reduction in file size. I have seen debate recently that this is not necessarily a good thing to do. Is it the case that the unused space in an MDF file is simply reserved for future growth and not necessarily "lost" space from deletes and updates that needs to be reclaimed and reorganised (as with file system (disk) fragmentation).
This has come to a head with a recent database that had grown ro 250 GB is size. After shrinking it, the size was halved to 125 GB. I am puzzled as to why this would be so because the only large table was 125 GB in size and it had very low fragmnentation. Also, this is a database in which 99.99% of all activity is to INSERT data with almost no DELETES or UPDATES, which I would expect to result in very little (even zero) fragmentation.
Because the file is so large, I experimented with table partitioning (on the single large table). Data was moved to the new partitions but didn't seem to be removed from the primary partition. I must own up to killing the process when the computer seemed to be unresponsive after running overnight. I am now running Shrink, to see if this reduces the size of the primary partition. To implement the partitioning, first created the file groups/files, partiton function and partition scheme then dropped and recreated the primary key (which includes the partition column). This procedure appeared to work on a smaller test database.
R Campbell