Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Log shipping hybrid Expand / Collapse
Author
Message
Posted Sunday, October 14, 2012 4:14 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 7:59 PM
Points: 596, Visits: 1,678
Within a few months we hope to be using Netapp's Snap Manager for Sql Server to "replicate" changes in our production database ( at remote server facility ) to our secondary Netapp filer at our office location. Sql 2005 Enterprise 64-bit

For now I'm thinking of setting up log shipping since I've used it before. There is mirroring but since this is an interim solution I thought I'd stick with what I've used.

Since our entire native sql backup folder on the primary is already being "snapped" to the secondary filer with Netapp tools, I'm wondering if after setting up log shipping I could disable the copy job, and either point the log shipping setup at the folder Netapp is using on the secondary filer, or come up with a job that copies the transaction log backups to where log shipping expects to find them.

Of course the broader question is whether log shipping will hold up when larger indexes are being rebuilt, but the 250MB pipe between the facilities should be able to handle a transaction log backup of 200GB ( largest I've seen) within the 15-minute log backup interval. Rebuilding of such indexes is fairly rare, and we could shorten the log shipping interval.

Everyone boasts about how technology like Netapp's just moves the data blocks that have changed, but with backup files, you're creating a new one ( trn ) every few minutes so I'm guessing it would still have to "snap" the entire file.

Certainly no need to have both Netapp Snap and log shipping copying the same files over this limited bandwidth.




Post #1372544
Posted Monday, October 15, 2012 5:37 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 10:15 AM
Points: 6,182, Visits: 13,329
The log shipping meta data keeps a trcak of files copied and restored. Start messing with the plan itself and it will likely fail. If you want to run LS run it as a separate plan.

If using snapmanager create a set of scripts that will restore the files for you


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

"Ya can't make an omelette without breaking just a few eggs"
Post #1372661
Posted Monday, October 15, 2012 5:42 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 25, 2014 7:59 PM
Points: 596, Visits: 1,678
Yes it might be easier to just leave our current native sql backups in place for now on the primary, restore a copy of the database on the standby filer ( in either recovery or standby mode), and hand craft some restore scripts. These scripts would need to either determine which trn files in a Netapp "snap" folder are to be restored and possibly move trn files to another folder after restore to avoid failed restore attempts.


Post #1372665
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse