Greetings, I have a situation regarding unused v. unallocated space. When viewing my db size in EM TaskPad view, I used Profiler to figure out that the bar graph is being fed data by the undocumented command DBCC ShowFileStats. It#%92s a very cool thing. I was able with relative ease to match up the command#%92s output with the bar graph. The space allocated by the OS to SQL Server matches up with the DB size, and within each filegroup I could see how much unused space was available. That turned out to be about 20% of our 300 GB DB. We#%92re going to start manually growing our files, but for now, we use AutoGrow. We do NOT use AutoShrink. Of course, these features work at the filegroup level. Then I used sp_SpaceUsed to examine some individual objects. We typically defrag the objects once each week. It turns out that the unused space for some of the objects is several GBs each. Looking at three of our biggest objects, I found several dozen GB of unused space--more than the free space reported by DBCC ShowFileStats for the entire DB. Here#%92s what I#%92m thinking is going on. The free space reported by DBCC ShowFileStats is completely independent of the unused space at the object level. Every week when we defrag, purge old rows, etc., the space that#%92s liberated still belongs to the individual objects. If we were to use DBCC ShrinkFile and target the filegroups to which these big objects belong, we could recover this object-level free space and increased the free space reported by DBCC ShowFileStats. First of all, is my analysis correct? Second, can I reclaim space at the object level, or is the file level as granular as I can get (I#%92d like to leave a little free space in the file, but might want to target a few of the big objects). Third, is DBCC ShrinkFile contentious; in other words, when space is being reclaimed from a table, is a table lock applied. Is the operations pretty quick for GB of space (like truncating a log) or does it take a while? Thanks for your help!