October 8, 2008 at 3:53 am
Hi,
We're looking at implementing Log Shipping as part of a DR plan.
I've read:
"...make sure that the log shipped database does not have other backup jobs or maintenance plans running against it"
and
"..do not use other maintenance plan options within your log shipping maintenance plan..."
So where can we do a full backup (so we can copy it to tape) and/or optimization job etc?
October 8, 2008 at 5:15 am
Maint plans (such as full db backup) should be on the primary server.
I normally make a copy of all these plans on the secondary server but leave them disabled. This way, should I need to move over to the secondary server as the result of a nuclear blast 😉 taking out the primary I don't have to spend hours recreating the maint plans whilst panicked managers pace up and down the office. :w00t:
What's are the requirements / reasons creating a log shipped copy?
October 8, 2008 at 5:41 am
Hi thanks for the reply,
I know the maint plans should be on the primary but I've read that...
"In SQL Server 2000 you won’t be able to take full backup of log shipped database, because this will break the LSN chain and it directly affects the log shipping."
Is this true or am I reading too much? 😉
Our requirements are basically several warm standby (vmware) servers for both SQL Server 2000 & 2005 at a remote location. We can afford to lose a day's worth of data and we want it as automated as possible.
I thought that Log Shipping or at least custom scripts would be the best solution although we have about 30 databases to cater for at the moment and this will grow over time. Not having done this in anger before I just wanted to find everything out before I commit 😀
October 9, 2008 at 4:27 am
If there are connections open on the secondary database then the logshipping will fail. The logshipping jobs need exclusive access while they're restoring the transaction log.
Let's say your backup to tape on the secondary database takes 3 hours...
"One of them is going to die, which one will be up to you"
For systems I watch over, I always backup the live servers no matter what log shipping, mirroring or otherwise is going on. Why? Because despite all attempts to the contrary at some point in time, someone, somewhere, somehow always manages to change stuff on the live server which becomes "business critical" in about 3 minutes. When the brown stuff hits the spinning blades, the primary server has just caught fire and the business is losing millions by the second, that is not the time to find the documented details of this change are missing and the change control was bypassed.
October 9, 2008 at 4:39 am
OK Cheers 😀
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply