|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885,
Visits: 1
|
|
|
|
|
|
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"
|
|
|
|
|
Grasshopper
      
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!
|
|
|
|
|
SSC 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
|
|
|
|
|
SSC 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
|
|
|
|
|
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"
|
|
|
|
|
SSC 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
|
|
|
|
|
SSC 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
|
|
|
|
|
Forum 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
|
|
|
|
|
Forum 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
|
|
|
|