Link to home
Start Free TrialLog in
Avatar of DavidHannen
DavidHannenFlag for United Kingdom of Great Britain and Northern Ireland

asked on

How to shrink SQL 2005 transaction log of a database that is Primary DB in Log Shipping set up

According to BOL, when using Log Shipping, backing up the transaction log independantly of the log ship process will disrupt thel restore process on the secondary server. (which makes sense).

As a transaction log back up followed by a file shrink - is the method used to shrink bloated transaction files. How does one shrink the tranaction log  goal if log shipping process is running?

Thanks
Avatar of RiteshShah
RiteshShah
Flag of India image

You can get your answer in this thread where I have given the commannds as to how to shrink it.

https://www.experts-exchange.com/questions/24398614/How-to-create-a-Log-Reader-Agent-for-exisiting-replication-when-there-is-not-one.html

Hope this helps.
Avatar of DavidHannen

ASKER

Thanks both for the posts:

My question is NOT 'How to shrink the transaction log' I have that covered. My issue is that I may need to shrink the log of a database that is primary DB in a Log Ship Set up. The documentation says Do Not  back up the log in this instance as it will interupt the chain of logs in the restore on the secondary server.

How do I get around this scenario.

Thanks
You can set your secondary database's Recovery Model to SIMPLE which does not break\effect the log chain, at least I haven't seen a side effect of this setting for the secondary database. (I assume you do not back up your transaction logs on the secondary database, because you can not do this when
your database's RM is SIMPLE.)

I hope this helps. Let me know if you have any more questions.
And can you reduce the time for the log shipping so that it happens frequently and does not over grow the log file? This is a preventive measure. :)
Bull Rider,

Am I right in saying that when a transaction log is backed up (in full recovery model) , the log is automatically truncated to the point of the last record being sucessfully applied to the database file.

If I am right with this, does that mean that shrinkfile could be used straight after the transaction log ship as there will be space in the file. Am I anywhere near correct here?

Thanks
A transaction log backup backs up all transactions since either the previous transaction log backup, or the complete database backup if there have been no transaction log backups performed for the database in the past. This backup may then be used to apply the backed-up changes, in case disaster recovery is required. Transaction log backups may only be applied to a database in an unrecovered state. A database may be in an unrecovered state if it is being restored from a set of backups as part of a disaster recovery procedure, or if it is configured as a standby database on a warm backup server. A transaction log backup also truncates the inactive portion of the transaction log, unless the database is configured as a Publisher in transactional replication and there are transactions pending propagation to Subscribers.

Shrinkfile might interrupt the chain of logs as you said and I have seen many instances of that and it really creates a havoc. Please follow what I said in the previous comment.
ASKER CERTIFIED SOLUTION
Avatar of bull_rider
bull_rider
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks very much for your input - much appreciated. I'm still learning and trying to assimilate best practice in all these different scenarios.