Hyperion Myth #3: Resolving Problems Requires Reboots During Production Hours
Jonathan Berry | | January 30, 2018
Despite the pain and frustration that it sometimes causes, Oracle’s Hyperion suite of business process management and business intelligence software is definitely worth it — but you’d probably prefer to have a little less pain.
Unfortunately, when it comes to troubleshooting Hyperion performance issues, far too many organizations’ first choice is to use that basic yet effective IT strategy: “Have you tried rebooting?” Here’s why that’s not a good idea when it comes to Hyperion and what you should be doing instead.
Root cause analysis — which is the subject of its own Hyperion myth — is a tried-and-true strategy for IT troubleshooting. Because it involves tracing a problem back from the symptoms to the root causes, too many IT teams are under the mistaken impression that it’s too difficult and time-consuming to use for most cases. Rather than going through the cumbersome RCA process, a number of organizations simply choose to flip the switch a few times and hope that rebooting will fix the problem.
Although it can be an effective solution, rebooting should also be treated as the nuclear option. Any system downtime will disrupt your users’ activities — and the longer it is, the more inefficiencies and lost productivity will result. Rebooting during the year-end financial close, for example, will likely have a drastic effect on the finance team’s schedule, devolving their workflow into chaos. In addition, the root cause of the problem will go unidentified which will lead to further reboots.
The Myth-Buster: Datavail’s APM Software Platform
Datavail’s Application Performance Management (APM) platform, developed by Hyperion specialists at recent acquisition Accelatis, has two strategies for addressing the rebooting myth. To begin with, as discussed in the article about the RCA myth, our software can drastically cut down on the time and effort needed for RCA, making it a viable and preferable strategy to rebooting.
In some cases, however, rebooting is truly the best option. If you find that this is a necessary step, then Datavail is ready to help. First, our product’s proactive monitoring allows you to accurately pinpoint the sources of performance issues so that you can restart only the affected subsystems rather than the entire system. Second, users can create scripts that automatically perform reboots when one of these proactive alerts is generated so that you can solve the problem faster and get back to work.
Before using our software platform, one of our clients experienced such severe Hyperion performance issues that it felt the need to reboot the system several times a week, with each outage lasting 45 minutes across the entire business. Datavail helped the client find the root causes of these pain points and identify only certain subsystems that needed restarting. Thanks to our software, the client’s Hyperion downtime decreased significantly — from 45 minutes several times per week for all users to only 20 or 30 minutes once a week for some users.
Not only can Datavail’s APM software make rebooting less painful, it can also eliminate the need to do it by making root cause analysis a viable option. Improving reboots during troubleshooting is just one of the many benefits of investing in Datavail.
For more detail on how to debunk this and 8 other Hyperion myths, watch our on-demand webinar: 9 Hyperion Myths That Are Making You Less Effective.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.