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<mailto: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. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"