December 6, 2012 at 8:51 am
I have a vendor supplied database driven application, I need to place a copy in another city for DR purposes, replication doesnt work because the around 30% of the tables do not have primary keys and I can't change the table schemas in case the app falls over, Mirroring disconnects everytime I put the server under heavy load. Log shipping seems to be ok but I dont like being left with huge numbers of TRN files and no regular BAK files. I have scripted a set of daily bak and trn routines that i can schedule to build fresh copy every day but this leaves me humping 90Gb across a WAN link everyday, which makes the Infrastructure team a little cross.
What other options have I got and what do other people do? I am expected to provide failover to within an hour or so if it all goes wrong
December 6, 2012 at 9:09 am
Martin Stephenson (12/6/2012)
Log shipping seems to be ok but I dont like being left with huge numbers of TRN files and no regular BAK files.
Log shipping does not remove the need for full backups.
You need regular full backups, not for the log shipping, but for normal recovery strategies. In the case of a disaster or accidental delete, you absolutely do not want to be restoring a full backup then months of log backups.
I have scripted a set of daily bak and trn routines that i can schedule to build fresh copy every day but this leaves me humping 90Gb across a WAN link everyday, which makes the Infrastructure team a little cross.
Why do you need to copy all 90 GB every day? Are you doing something odd like switching to simple recovery model before taking backups?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 6, 2012 at 9:14 am
If I set up log shipping, the translogs are applied to the target database, if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?
December 6, 2012 at 9:43 am
Martin Stephenson (12/6/2012)
if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?
No.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 6, 2012 at 10:17 am
In that case I'll just go and get it setup then 🙂
December 6, 2012 at 2:06 pm
The only time you need to send your full to secondary is if you need a reinit. Otherwise take your fulls nightly and store locally, tran log baks will never be interrupted to secondary.
Frequently take log baks, every 15min, watch sizes, e.g. during maint when we rebuild indexes those logs get big and latency backs up just a bit so this process is managed closely.
Regards,
Chris
mssqlconsulting.com
Chris Becker bcsdata.net
December 6, 2012 at 11:54 pm
I you have SANS from the same company at each site, you can do SAN replication and relieve SQL Server a bit. That'll also work for non-SQL Server files, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2012 at 4:04 am
Martin Stephenson (12/6/2012)
If I set up log shipping, the translogs are applied to the target database, if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?
No, what it does do is to reset the differential backup chain by incrementing the differential base LSN.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 7, 2012 at 2:01 pm
Martin Stephenson (12/6/2012)
Mirroring disconnects everytime I put the server under heavy load.
Are you setting it up as asynchronous(high-performance)?
December 10, 2012 at 2:59 am
It was set up as high performance, I dont have a spare server to act as a witness at the moment . It does document management and everytime there was intense file movement and sql activity the mirror would be suspended and never be able to re-sync. The application is not mirror aware so any failover would be manual, log shipping seems the to be the path of least resistance at the moment.
According to the vendor the latest version is SQL2012 compliant and mirror aware so maybe next year 🙂 I shall be revisiting the mirror options
December 12, 2012 at 12:54 am
No it doesn't break the log chain. A full backup contains only enough transaction log necessary to be able to restore that database to a transactionally consistent time - the time at which the data reading portion of the full backup completed.
Paul has explained this very clearly in his blog.
Read the gail link above.
Regards,
RamaSankar,
MCTS,MCITP Sql Server 2008.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply