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 12»»

Custom Log Shipping Expand / Collapse
Author
Message
Posted Friday, November 21, 2003 12:00 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/ckempster/customlogshipping.asp


Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Post #18497
Posted Wednesday, November 26, 2003 2:37 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1
Hi all

Just a quick comment re the log shipping, we have been testing our large COM+ app against the log shipped db, after a restore of logs, the COM+ components seem to be caching the connections to the instance, a shutdown via component services of the affected compoments resolves the issue but is far from ideal. The senior AP's are investigating the issue and how the connections are being pooled/cached.

Just something to watch out for.

Cheers

Ck

Chris Kempster
www.chriskempster.com
Author of "SQL Server 2k for the Oracle DBA"



Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Post #88352
Posted Wednesday, November 26, 2003 8:48 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, November 26, 2003 12:00 AM
Points: 21, Visits: 1
At first blush, Chris has put together
a well thought solution for an option
of creating SQL log shipping.

Excellent work Chris!




Post #88353
Posted Wednesday, November 26, 2003 10:40 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 03, 2007 10:17 PM
Points: 210, Visits: 1
Hi,
Just wanted to say that the log shipping idea seems very sound in its implementation here. In the conclusion you say that having users still logged in while doing a recovery is bad, Im not sure if I would want Yukon to be allowing this, because (imho) why would you want people working on data that is about to change.. I sort of think that kicking everyone out is a good idea before recovery..I obviously cant see the good side to not kicking hem out... :)




------------------------------
Life is far too important to be taken seriously
Post #88354
Posted Wednesday, November 26, 2003 10:47 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 03, 2007 10:17 PM
Points: 210, Visits: 1
hem = them




------------------------------
Life is far too important to be taken seriously
Post #88355
Posted Wednesday, November 26, 2003 11:13 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1
Hi there

Well is a good point actually and (i suppose) really depends on your requirement for the standby DB.

In our case I wanted to avoid having 3 databases, the live OLTP, the standby and then the reporting database. If I can use the standby for all reporting functions (its not warehoused with time series data) and users dont mind the 10min cycle of data change by applying new logs, then its win win all round. Kicking users then becomes a problem, esp for those running long complex queries. To get around this I only restore every 2hrs and everyone is aware of the disconnection. If Yukon had an option to go either way, id see it as a "nice feature" more than anything that makes the standby more flexible and usable to my clients.

Cheers

Ck



Chris Kempster
www.chriskempster.com
Author of "SQL Server 2k for the Oracle DBA"



Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Post #88356
Posted Thursday, November 27, 2003 2:30 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, September 03, 2007 10:17 PM
Points: 210, Visits: 1
Oh yeah! i forgot about the long running queries scenario..!! I suppose it would be a good thing for Yukon to have (if indeed it will) once again sounds good :)




------------------------------
Life is far too important to be taken seriously
Post #88357
Posted Thursday, April 01, 2004 7:54 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, April 05, 2010 1:37 PM
Points: 38, Visits: 3

I really think this is a good set of routines and sp's for a log shipping solution. I ran across it while looking for a solution to keep 235 databases (53 gigs) within 24 hours of snyc at our standby server offsite. Replication wasn't an option as I had to leave the online databases user-changeable (add, delete tables, add, drop databases - as DBA I have no control of that, and I'm not notified so snapshot's really weren't in our business model).

I worked through mod's for Chris's script, and we emailed back and forth some - then decided it wasn't a viable option as I have other restrictions that just make it not possible (only a t-1 line, and only permitted to transfer 50 gigs a month).

If anyone out there has any suggestions as to how to do this, I'm open to them:
critenour@imapdata.com

Thanks for your help Chris.

 




Thanks, and don't forget to Chuckle
Post #109467
Posted Saturday, September 03, 2005 5:45 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, July 16, 2009 11:16 AM
Points: 4, Visits: 11

Chris, first let me thank you for this contribution, you have saved me literally days of work and its far better than I could have achieved on my own.

I have one small problem with it though. When gzip is called to zip up the BAK files it occasionally fails to delete the original file and therefore causes and error email to be sent.

I am using a Job running iunder the SQL Server agent and its last step is to also FTP and then MOVE the files. The MOVE command also returns an errorlevel (despite succeeding).

I suspect that this issue is caused by attempting to delete a file (i.e. a backup) that is still open.

Have you come across this problem and/or do you have any suggestions to get around it?

Many Thanks,

Jason

Post #216819
Posted Sunday, September 16, 2007 11:46 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, April 20, 2008 3:32 PM
Points: 1, Visits: 7

Chris

Excellent work on this! We have been using this for a couple of our databases which run the MSDE flavor and it works great.

Thanks

Ravi

Post #399600
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse