I know, I know....#OMGShrinkingIsBadDontEverDoThatOrElseEtcEtcEtc
We all know that there are simply times you have to shrink some files. There are risks - blocking, significant I/O, fragmentation, and more - all of which mean you should not shrink a file willy-nilly without considering the impacts...but sometimes you are having a production issue and don't have any choice. Similarly, sometimes you are in Dev/Test and it is simply more practical to shrink a file than to add drive space or re-architect the full solution.
In many cases it comes down to that unfortunate reality that there's a way the book/class does it, and another way we have to do it "in the field."
 |
| http://twitchlol.com/wp-content/uploads/2013/09/Battle-Plan-for-kids.jpg |
Of course you also have to remember Law #9842 of being a DBA - all database systems are Production to someone. It may be a developer or a QA team rather than an end user, but it is still PROD to them!)
--
In this story, TempDB DATA files were using almost all of the space on the drive, meaning TempLog couldn't grow, but the DATA files were mostly empty by the time it escalated to me.
Even though the files were mostly empty, my attempts to shrink them were throwing an error and the files were not shrinking:
--
Msg 5054, Level 16, State 1, Line 1
Could not cleanup worktable IAM chains to allow shrink or remove file operation. Please try again when tempdb is idle.
--
 |
| www.deviantart.com/ieatatwaffenhouse/art/Skeletor-553757222 |
Googling the message led me to one of my top five authoritative sources, Paul Randal of SQLskills.com (@PaulRandal/blog). The relevant blog post is https://www.sqlskills.com/blogs/paul/shrinking-tempdb-longer-prohibited/
While my error message isn't featured in the body of the blog post, it *is* in the final comment and reply in the article. By that information, it appears that this error reflects that certain system structures are on pages that can't be moved without system restart, which means TempDB can't be manually shrunk on this instance w/o SQL service restart.
(Paul does describe in his article the old-school fear that "shrinking TempDB leads to corruption" and how his extensive experience leads him and Microsoft to now believe that is not true *on modern versions of SQL Server (2005+)*)
--
Hope this helps!
