>>To reclaim wasted space you can use DBCC SHRINKDATABASE
>
>And whenever I search for that, the same two or three articles pop up where it's claimed that truncating the log is somehow bad because you disrupt the statistics and some queries may run suboptimally (my favorite stupid word of redmondspeak), your ears may rewrinkle in a wrong pattern, your buttonholes may spontaneously heal and vanish and your toaster may become a random brown color generator. My prime suspicion is that since it's the same two gurus pushing their names on this subject and probably trying to gain/justify their MVP rating, and that since I can find nothing else on the subject, it's most probably something that happened to a few people, in some special situation/configuration etc etc, and is not a general rule as they claim. Besides, IIRC those article applied to SQL 2005 - enough things have happened meanwhile to require re-evaluation of those claims.
>
>Speaking of shrinking... I'm running 2008 and 2012 in parallel, and have found that shrinking sometimes works spectacularly, sometimes not at all. I wonder if there's some kind of rule, or settings that affect that.

Hi Dragan,

Yes, I read those warnings too, long time ago, but I think if you not automate, schedule or set autoshrink on and only use this "cada muerte de obispo" (once in a blue moon) should be ok, as I see it, it is a command to fix a set up error, let's say you thought your database would need 1 Gb and then you realize that with 10Mb you are dandy, then you shrink it, but you never do it just to get back some space that would be needed back (lets say from 1 Gb you shrink it to 900Mb, but because you have auto increment size by 10%, next time someone adds records the table goes back to 1Gb). Oops, I forgot you are a mathematician, you go back to 990 Mb. (and I probably got it wrong anyways, darn 1024)