SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Shrink all user database files


Shrink all user database files

Author
Message
boubkhaled
boubkhaled
SSC Rookie
SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)SSC Rookie (31 reputation)

Group: General Forum Members
Points: 31 Visits: 15
Comments posted to this topic are about the item Shrink all user database files
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)

Group: General Forum Members
Points: 817339 Visits: 46293
I appreciate you sharing but, be advised, shrinking databases every day is a form of "Death by SQL".

1. It can and usually will cause a type of fragmentation that can absolutely cripple your database for performance. The only way to recover from that is to do the necessary index maintenance and that can cause wanton growth of the MDF file if you use REBUILD or wanton growth of the LDF file if you use REORGANIZE.
2. Except when there has been accidental and incredible growth of either the MDF or LDF files, shrinking the database on a daily basis is totally fruitless unless you find out what is causing the excessive growth. It's a whole lot like washing your clothes and then drying them on a clothesline in the rain with the occasional dog lifting his leg on the basket you also left outside.
3. Shrinking the databases takes valuable time away from more useful and more critical maintenance such as finding stats the need to be updated and then updating them.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
pietlinden
pietlinden
SSC-Forever
SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)SSC-Forever (49K reputation)

Group: General Forum Members
Points: 49735 Visits: 16189
Why would you want to do that? I can see shrinking a database if you have to move it and space is at a premium. But that's hopefully a rare occurrence. One would be much better tracking growth rates and projecting when a server is projected to run out of space at the current growth rate, and then addressing the problem proactively.
HappyGeek
HappyGeek
SSChampion
SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)SSChampion (13K reputation)

Group: General Forum Members
Points: 13461 Visits: 6387
Jeff Moden - Wednesday, December 27, 2017 7:07 PM
I appreciate you sharing but, be advised, shrinking databases every day is a form of "Death by SQL".

1. It can and usually will cause a type of fragmentation that can absolutely cripple your database for performance. The only way to recover from that is to do the necessary index maintenance and that can cause wanton growth of the MDF file if you use REBUILD or wanton growth of the LDF file if you use REORGANIZE.
2. Except when there has been accidental and incredible growth of either the MDF or LDF files, shrinking the database on a daily basis is totally fruitless unless you find out what is causing the excessive growth. It's a whole lot like washing your clothes and then drying them on a clothesline in the rain with the occasional dog lifting his leg on the basket you also left outside.
3. Shrinking the databases takes valuable time away from more useful and more critical maintenance such as finding stats the need to be updated and then updating them.

+ 10000


...
Ed Wagner
Ed Wagner
SSC Guru
SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)SSC Guru (251K reputation)

Group: General Forum Members
Points: 251612 Visits: 12111
Jeff Moden - Wednesday, December 27, 2017 7:07 PM
I appreciate you sharing but, be advised, shrinking databases every day is a form of "Death by SQL".

1. It can and usually will cause a type of fragmentation that can absolutely cripple your database for performance. The only way to recover from that is to do the necessary index maintenance and that can cause wanton growth of the MDF file if you use REBUILD or wanton growth of the LDF file if you use REORGANIZE.
2. Except when there has been accidental and incredible growth of either the MDF or LDF files, shrinking the database on a daily basis is totally fruitless unless you find out what is causing the excessive growth. It's a whole lot like washing your clothes and then drying them on a clothesline in the rain with the occasional dog lifting his leg on the basket you also left outside.
3. Shrinking the databases takes valuable time away from more useful and more critical maintenance such as finding stats the need to be updated and then updating them.

Agreed 1000%. Except in rare instances, it's not worth the space you get back. When it is worth the space, you give a bunch of it away by doing the rebuilds. I think the wasted space is generally about 120% the size of your biggest table.



Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
pierre.bonhomme
pierre.bonhomme
Valued Member
Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)Valued Member (71 reputation)

Group: General Forum Members
Points: 71 Visits: 71
Why do that ??? Buy some HD
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)SSC Guru (202K reputation)

Group: General Forum Members
Points: 202802 Visits: 18548
short answer is don't!!

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
RandomStream
RandomStream
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2787 Visits: 648
Jeff's right but don't be discouraged.
Arsh
Arsh
SSCarpal Tunnel
SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)SSCarpal Tunnel (4.6K reputation)

Group: General Forum Members
Points: 4627 Visits: 917
Not encouraged , unless the downside of this resulting in fragmentation and other stuff put by Jeff , can be dealt with. The lower costs of storage these days make it all the more avoidable. Also , SQL server reuses the empty space. Probably when one is sure that large amounts of spaces is not going to be used for long time. Overall , shrinking the database files is a no-no.

Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)SSC Guru (817K reputation)

Group: General Forum Members
Points: 817339 Visits: 46293
RandomStream - Tuesday, January 2, 2018 5:23 PM
Jeff's right but don't be discouraged.

If you're talking about not being discouraged from writing articles, I absolutely agree! If contrary opinion were a deterrent, I'd have never made it past my first article. I actually embrace contrary opinion (although I embrace and value contrary proof in the form of code much more) because it normally causes discussions that flush out some really great ideas or confirms that some ideas aren't so great.


--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search