Database Reference
In-Depth Information
Table 1.4
Release Reco
mmendations
Installation Type
Recommendation
Patch
Individual patch applications usually take less than an hour and the system can be
tested in less than a day. only apply patches that have been released for longer
than one month. Always apply patches to your nonproduction environment and
allow it to burn in for two weeks.
new install
Select the most recent version when you are implementing Essbase for the first
time and your timeline is greater than three months. This will provide the best
feature set, support the most recent client software, support the most recent
server software, and provide more longevity over older releases.
Service pack
A service pack is a mini in-place upgrade. Wait at least one month before applying
a service pack. Perform full regression testing in your nonproduction
environment and attain formal sign-off to install in production.
major upgrade
(migration)
Select the most recent version that has over three months of release time.
major upgrades can run from a few weeks for a very small user base with a
minimal number of applications to several months for a large global user base
with hundreds of applications.
A few upgrade good practices:
• Enact a change freeze
• Do not upgrade in-place; use new environments
• Perform full regression test using a PoC environment
1.4 essBase arChiteCture anD sizing
The basic architecture for modern Essbase consists of a Web server, application server,
and relational database server (Figure 1.2). When scaling the system up, place print ser-
vices on dedicated servers, continue to locate Web and Java services on like servers, and
continue to keep application servers on dedicated servers.
The logical view in Figure 1.3 shows Essbase's software dependencies. For instance,
if either Essbase or the supporting relational database is down, most components in the
system will not function. If reporting and Analysis framework malfunctioned, then
Financial reporting would be impacted; however, Essbase access via Smart view would
be unaffected.
1.4.1 A Few essbase.cfg File Settings
review the Essbase technical reference for in-depth descriptions of the essbase.cfg
settings below.
Essbase is, in general, a multithreaded application. you will see single-thread
behavior with cube restructures and management of the Essbase security file. The
single-threaded behavior (at least through version 11.1.2) for management of the
security file will cause new logins to the ESSBASE process to queue until the cur-
rent action affecting the security files is completed. Some other actions that can cause
the queuing behavior include: creation of filters (noticeably seen in Planning Filter
refresh), copy of application, and copy of database. Cube restructures do not cause the
queuing behavior, but are notable as you will note only one processor is used during a
restructure operation.
Each thread will take up a certain amount of memory on a given operating system.
For instance, one thread on Windows uses one megabyte. This means if you have the
