Hyperion Myth #3: Resolving Problems Requires Reboots During Production Hours
Author: 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.
The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.
Our database experts explain how to recover and restore a table from an Oracle 12c RMAN Backup with this step-by-step blog. Read more.
Which RAID should you use with SQL Server? Learn the differences between RAID 0, RAID 1, RAID 5, and RAID 10, along with best practices.