Database Reference
In-Depth Information
application. This management includes the vital processes of development, testing,
and patching.
Why is testing critical? Essbase is a very powerful tool and, as such, testing calcula-
tions and outline changes are critical. As an example, if you create a Calc Script and do
not focus (FIx) on a specific dataset, it refers to all data in the cube.
Imagine the Essbase Calc Script below:
Sales = 0;
If there were no FIx statements around this code or if certain members were omitted,
Essbase will affect a much larger dataset than intended. This kind of potential disas-
ter (users who have seen all of their precious numbers turn to zero tend not to accept:
“We're too poor for multiple environments,” as an excuse) means that it is critical to
both perform proper testing and also have good backups.
1.3.5 Which Essbase Release?
A question I often hear is: “What version should I choose?” The underlying question is:
Will my system be stable? I will make a blanket statement: Every nontrivial software
program contains defects. you may treat nontrivial as anything containing greater than
1000 lines of code.
typical code bases for commercial software have hundreds of thousands of lines of
code and can run into the millions of lines of code. There is intensive effort in software
quality assurance in order to reduce, locate, categorize, and resolve defects. When releas-
ing software, vendors weigh the severity of known defects to their potential impact. If
there are no “show stopper” defects and the product passes their quality tests within
acceptable parameters, it will go to a generally available status. In the case of the oracle
hyperion suite of products, the known defects are communicated to end users in the
product rEADmE documentation.
At the time of this writing there are two main supported Essbase code lines: 11.1.1.4
and 11.1.2.1; both versions are “dot” releases from the 11.1.1 and 11.1.2 major versions.
Since both releases have been on the market for over three months, either are very
good selections. given an equal level of maturity, I will always choose the higher
release version due to its longevity, additional features, and better architecture
(table 1.4).
1.3.6 When an Upgrade Is Not an Upgrade
When selecting the target hardware, you must think about it in terms relative to the
older hardware. The expectation of an upgrade is that the system will work better than
before. Better usually means faster, more features, and more reliable. A client decides
to “upgrade” his system and selects an existing virtualized platform to migrate from a
physical server. If the old physical server is faster in terms of clock speed than the clock
speed of the physical server the virtualized host resides on, you will see a net decrease in
performance and a net increase in unhappy users.
1.3.7 Core Essbase Processes
This section describes the major processes for any Essbase environment. It is not
a replacement for formal oracle documentation nor an attempt to be exhaustive
(table 1.5).
