I will second this sentiment. This is a Admin's dream come true. Upgrade with Zero downtime! I totally fail to understand how people would not be interested in it even if they do not plan an upgrade in the near future. Has to happen sometimes! I will definitely vote for it.
Shafqat Ayaz >________________________________ >From: "richard....@bwc.state.oh.us" <richard....@bwc.state.oh.us> >To: arslist@ARSLIST.ORG >Sent: Tuesday, July 30, 2013 10:09 PM >Subject: Re: 7.6.04 Upgrade to 8.1 > > > >** >Given this description it brings up the question as to why you would NOT want >it. >Upgrades, etc. can take days of downtime during the process with no >availability while >it’s happening. It sounds like most of the synchronizing has been worked out >and not >much work remains – so why not do the sprint to the finish line with it? I’d >vote for it >especially so my customers can have a seamless experience (and so I don’t have >to spend >weekends at work and on the phone to get it up and running……). Why vote? >You’re >almost there. Do it. > >From:Action Request System discussion list(ARSList) >[mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug >Sent: Tuesday, July 30, 2013 3:00 PM >To: arslist@ARSLIST.ORG >Subject: Re: 7.6.04 Upgrade to 8.1 > >** >Tom (and others who responded), > >The "feature" of zero-down time and the demonstration at WWRUG 2012 was a lab >demo to show a >concept that we had taken from design into prototype to gage interest from the >customer base. > >To be clear, it is not present in any release of the product at this time. > >We are still gaging customer interest and I will say unfortunately, the >interest expressed in this topic has >not been as strong as several of us expected. There is interest – don't get >me wrong – but there are other >things that are generating much more concern from customers. There is still a >contingent struggling to get >this capability added to an upcoming release – but nothing has made it yet. > > >The functionality we demonstrated was true zero-down time. It creates >parallel metadata tables with new >and old definitions and different servers pointing to different sets – ALL ON >THE SAME DATA TABLES. Lots of >work went in to handle deleted fields (delete is deferred because the old >version is still using the fields) and >to even handle cases where archgid changes field IDs (extra view forms are put >in place so that both old and >new use the IDs they expect and all is in place). > >Both old and new versions of the applications were available and running >through different servers in the >server group so you could confirm that all was ready before you flipped the >switch. > >If any system went down, it came back up looking at its set of definitions so >everything is robust and >recoverable while in this mixed mode. > >We went so far as to have servers running the old app have a signal to load >and prepare the new definitions >in the background while continuing to run the old version so when they were >signaled to go live, they finished >any current API call in the old version and any new API call started working >with the new version for absolute >zero down time transition at the server. > >This means that any program or integration has zero interruption or disruption. > >Now, the interactive user through the mid-tier has the issue of caching. >Depending on whether an immediate >update occurs or you are just going to let the next interval check do it, it >may be instant to a few minutes >before the updates are reflected to the client and there is going to be a >performance slowdown that will be >noticeable as things are reloaded (kind of like a first time reload after >mid-tier startup) and then changed >screens will show up. So, they are never down, but there is a short time of >affect on interaction of users. > > >This is not fantasy as we have prototyped it and it was what was demonstrated >at WWRUG and it does work. > >If you have not entered your vote for this feature on the BMC Communities AR >System thread Ideas entry >for this feature (this is an area where you or BMC posts enhancement requests >and the community can vote >on it to show interest – higher vote totals help push features up the list for >implementation), please enter >your vote to show support for the idea. > > >This does not mean no work for the Administrator during an upgrade, but it >means no end user outage for >an upgrade. It should also help reliability and success of an upgrade in a >dramatic way as you can test and >verify and make any corrections in the new version before go live. It also >should remove the I have to do >everything under time pressure in the middle of the night on a weekend issue >to avoid customer downtime >as much as possible topic. So, a win for everyone all around. > > >I hope this confirms and clarifies this capability, what it is and where it is. > >Doug Mueller > >From:Action Request System discussion list(ARSList) >[mailto:arslist@ARSLIST.ORG] On Behalf Of Tom Shurmur >Sent: Monday, July 15, 2013 6:57 PM >To: arslist@ARSLIST.ORG >Subject: 7.6.04 Upgrade to 8.1 > >** >Howdy Listers, > >We are about to embark on upgrading from 7.6.04 to 8.1 on a windows platform >using MS-SQL. Has anyone used the No Downtime Upgrade method that was >presented at last year’s WWRUG to move from 7.6.04 to 8.1? If so, was it >smooth or bumpy ride? > >We will be standing up a test system with 2 app VMs and a DB to test this >approach. > >I look forward to your feedback > >Tom Shurmur >Sr Remedy Developer >Froedtert Health System >_ARSlist: "Where the Answers Are" and have been for 20 years_ >_ARSlist: "Where the Answers Are" and have been for 20 years_ Portions of this >message may be confidential under an exemption to Ohio's public records law or >under a legal privilege. If you have received this message in error or due to >an unauthorized transmission or interception, please delete all copies from >your system without disclosing, copying, or transmitting this message. >_ARSlist: "Where the Answers Are" and have been for 20 years_ > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
