Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Custom Log Shipping


Custom Log Shipping

Author
Message
ckempste
ckempste
SSC Eights!
SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)

Group: General Forum Members
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"
ckempste
ckempste
SSC Eights!
SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)

Group: General Forum Members
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"
Clark Cruz
Clark Cruz
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
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!



adamcrv
adamcrv
SSC Veteran
SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)

Group: General Forum Members
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... Smile


------------------------------
Life is far too important to be taken seriously
adamcrv
adamcrv
SSC Veteran
SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)

Group: General Forum Members
Points: 210 Visits: 1
hem = them


------------------------------
Life is far too important to be taken seriously
ckempste
ckempste
SSC Eights!
SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)SSC Eights! (885 reputation)

Group: General Forum Members
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"
adamcrv
adamcrv
SSC Veteran
SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)SSC Veteran (210 reputation)

Group: General Forum Members
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 Smile


------------------------------
Life is far too important to be taken seriously
Chuck Ritenour
Chuck Ritenour
SSC Rookie
SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)

Group: General Forum Members
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
Jason Steele
Jason Steele
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
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


Ravi Kosaraju
Ravi Kosaraju
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
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


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search