An interesting issue appeared for me recently. What happens when after a server crash / restart, Essbase refuses to start? The service shows Running, but Essbase isn’t listening and not responding. The start attempt produces no errors, no logs, it simply does not start.
From time to time you may find that your user’s account no longer appears to allow you to log into HFM from the web. Oh, they can log in without an error, but what the browser displays may appear to be miniature, garbled or completely corrupt. You may even get an “ADF error”. The problem follows the user from device to device, while others are able to access the same application without error.
When you do your first WebLogic deploy, you have the option to ‘Deploy the Java web applications to a single managed server.’ What does that mean and when should you use it?
Large Environment OHS Configuration in 126.96.36.199
Running Oracle HTTP Server (OHS) on multiple servers helps environments run faster, be more stable and allows the environment to continue running if one server goes down. However, configuration and customization have always been made more difficult as a result. Every server added means repeating the steps and changes. When you run the Configuration Utility to make a change, it’s easy to forget you have to repeat it on every server running OHS.
“Nothing changed.” How often have you heard those words when trying to run down a new problem in an environment? When something breaks, the natural question to ask is “What changed?” Unfortunately, it’s very common that everybody denies anything changed.
Often “Infrastructure” is seen as installing the software, patching, tuning and turning it over to others to use. But when you limit it to that, you miss great opportunities that help protect your system and keep it running smoothly. A big opportunity often overlooked is automation.
Upgrading a Hyperion environment has never been for the faint of heart. Often the upgrade process is rather involved, scarce on documentation and one misstep leaves you starting over. Each version has had its own version of this gauntlet to run. Having recently done this in 188.8.131.52, I’m afraid the process isn’t much better in this version. In fact, this version has several new twists.
Upgrades in 184.108.40.206 are limited to specific versions, can’t be done “in place” and can only be done during installation / configuration. Some of these limitations aren’t new to the upgrade process and some are. Walking through each of them and the process itself will help explain limitations and some workarounds that are available.
We’ll discuss the newest and most significant limitation first – that you can ONLY upgrade during installation and configuration. This is significant. In previous versions, there were often migration utilities and processes to bring items from an existing environment into the new environment after the new environment was running. This allowed for the “controlled” migration of applications over a period of time. Now the only time a migration from a previous version is allowed is during installation and configuration.
There are a few workarounds available, but they are limited and will require a bit of work. Planning applications have a supported “upgrade later” path that is complicated, but possible. Essbase is Essbase – you can connect with EAS, copy application outline, then use a level 0 export / import to bring data in. Both of these solutions work and are supported. Officially, every other migration must be done at the initial installation; however there’s no reason the solution given for Planning applications could not be used for all other products.
What is the “solution” to import Planning (and other products) from an existing environment into an existing 220.127.116.11 installation? Build a new (temporary) 18.104.22.168 environment and perform the upgrade during installation and configuration of this new temporary environment. Once done, you can use LCM to migrate to the existing 22.214.171.124 environment (LCM is only supported to migrate between environments that are the same version). This may not sound like much of a “solution” – after all, building a new environment sounds more like “starting over” than a “solution”, but it does work and it does preserve both the running environments.
The bad news is that you need to build a new environment. The good news is that this temporary environment can be small – just big enough to install / configure and run the products being upgraded. This is not a simple, fast or easy process, so it is recommended to do as much at once as possible. If more than one upgrade wave is required, try to combine and upgrade in as few “waves” as possible.
While there are scripts and processes to move Essbase into the new environment, they are rather involved. After looking at the process and what we were moving, we made the determination to recreate the Essbase cubes used for our Planning apps after the Planning migration. We then imported the data using a level 0 export from the existing environment. This worked even with an export from a 4.x Essbase environment. The process of copying the outline and using the data export/import process was simpler than the migration provided in the Oracle documentation. Your mileage may vary in this area.
Now to discuss the more familiar restrictions: The upgrade path is limited to three releases – 9.2.1, 9.3.3 and 126.96.36.199. If you are not at one of these release levels, an intermediate installation and upgrade has to be done before upgrading to 188.8.131.52. This isn’t as horrible as it may sound – all that is needed is a small, temporary environment (the kind of thing VMWare does wonderfully). If you don’t plan to upgrade all your applications at once, keep a copy of this environment to use again in the future.
In some previous version upgrades, there was an option to do an “in-place” upgrade. While I would always discourage this path because of the risk to a working, existing environment, that path has been completely removed in 184.108.40.206. While you can still do a “maintenance release” upgrade in place from 220.127.116.11 to 18.104.22.168, I would continue to discourage this approach. In-place upgrades behave slightly different than “clean installations” and the risk of corruption during an upgrade is always there. The primary (road most travelled) path is the clean installation. Following the “clean installation” path will keep you on this road and help make your upgrade successful.
With this restriction, you can’t just use the current servers. If your plans include using your current hardware, you will need to find a temporary environment for your existing servers (i.e. using Physical-to-Virtual conversion to move to VMWare, and then reformat the original servers, etc.). However, because 22.214.171.124 is now supported on 2008, this is a perfect opportunity to upgrade hardware, OS and application all at once.
An upgrade of Hyperion is traditionally a time to revisit applications – get rid of the old forms, unused reports, etc. The result is that often applications are rebuilt in the new environment to clean them up and take advantage of the features of the new system. With the upgrade restrictions of 126.96.36.199, the incentive to do this is even stronger. An upgrade is supported and there is a path to the new version no matter what version you’re currently on, it just may be a long road. There are restrictions and pitfalls. And even after you have finished the Hyperion upgrade, you are likely to have a lot of work yet to do to fix the forms, reports, etc. that didn’t upgrade as expected. Be prepared and plan for the “after the upgrade” work.
Having travelled the upgrade road recently, I know that it’s a long road. No two upgrades go exactly the same way – even if you are upgrading the same products from the same version. You have to be ready for detours along the way, it’s always good to have a roadmap before starting.
Author, Tony Moyers
A set of WebLogic patches have been released to addressed the issue. However, since the overall risk is very low to the average Hyperion users, application of this patch is does not need to be a high priority unless the WebLogic server is publicly accessible (not firewalled). WebLogic patch ID is 13583186 and has only been publically available for one week.
--Author, Tony Moyers