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
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

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

Group: General Forum Members
Points: 504851 Visits: 44238
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-Dedicated
SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)SSC-Dedicated (31K reputation)

Group: General Forum Members
Points: 31652 Visits: 15140
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
SSCertifiable
SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)SSCertifiable (6.8K reputation)

Group: General Forum Members
Points: 6793 Visits: 4386
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 (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)SSC Guru (156K reputation)

Group: General Forum Members
Points: 156270 Visits: 11645
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
SSC Rookie
SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)SSC Rookie (33 reputation)

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

Group: General Forum Members
Points: 136018 Visits: 18192
short answer is don't!!

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

"Ya can't make an omelette without breaking just a few eggs" ;-)
RandomStream
RandomStream
SSChasing Mays
SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)SSChasing Mays (641 reputation)

Group: General Forum Members
Points: 641 Visits: 421
Jeff's right but don't be discouraged.
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