Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
Gopher
Yak Posting Veteran
83 Posts |
Posted - 2010-03-03 : 05:13:30
|
Hi AllI have a question which I think I know that answer to, but I need someone else to confirm that this should work.We have one large database (2.4TB) which is currently being log shipped to 2 other servers off site. Currently I am working on some updates, table changes, Alter Index etc and from my initial testing I know that the Log file will grow from a healthy 70GB to not health 290GB. Now what I want to do, to keep the log file to a managable size, is perform a shrink log on the Primary server and I am hoping that this command and action will be replicated to the other log shipping servers and shrink their servers.Will this work?Thanks all in advance. |
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2010-03-03 : 16:14:05
|
You can shrink the log on the primary server as long as you don't truncate it. But this is such a bad idea. It will grow to 290GB again as soon as that job runs again. This is a huge performance penalty as growing that file out to 290GB is going to take some time. 290GB is not an unhealthy size. For your system, 290GB is what it needs so that's its healthy size.I'd highly recommend not shrinking the log and instead make sure you have enough disk space on each of the servers to handle the 290GB file size. Production systems should never have a scheduled job that does shrinks. Manage shrinks manually instead as shrinks should only be done in rare circumstances.Yes the shrink command gets log shipped to the secondary servers.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog"Let's begin with the premise that everything you've done up until this point is wrong." |
|
|
|
|
|