essbase.cfg memory settings Let's now take a look at those essbase.cfg memory specific settings that will directly affect the performance of your Essbase system: • MULTIPLEBITMAPMEMCHECK
Trang 1One of the single largest users of system memory is the database outline itself By its very nature, the larger the outline, the more server memory is consumed just to load the database into memory
We highly advise using extreme care in determining the data elements and data categories you will use for your database outline
Fewer dimensions are always preferable to more dimensions For every new dimension in the outline the potential size of the data and the actual size of the outline grow exponentially It is always better to have fewer dimensions with lots of members, than it is to have more dimensions with less members Think about it!
essbase.cfg memory settings
Let's now take a look at those essbase.cfg memory specific settings that will
directly affect the performance of your Essbase system:
• MULTIPLEBITMAPMEMCHECK: Tells analytic services to enforce the size limit
for the amount of memory that is used for the calculator cache when analytic services selects the multiple bitmap cache option
• VLBREPORT: Tells Essbase to dynamically determine the retrieval buffer
size, between 100KB and 10MB, for retrievals from databases without
Dynamic Calc, Attribute, or Dynamic Time Series members This memory
is only used when needed, so it does not take away from continuous
system resource availability
• TRIGMAXMEMSIZE: This setting tells Essbase how much memory it can use to perform the trigger function While the triggering function is a great feature,
it can be very memory intensive at the expense of other system operations
This memory is reserved by the application that has the trigger set up and is
no longer available to the rest of the server
• SSPROCROWLIMIT: Controls the maximum number of spreadsheet rows
analytic services processes on an individual user spreadsheet request from
Microsoft Excel The default is 250,000, which is extraordinarily high for
a spreadsheet request You do not want a spreadsheet retrieval slowing
down your entire server, so we recommend starting with 5,000 rows, and
increasing as needed from there
Trang 2Chapter 9
[ 361 ]
• CALCLIMITFORMULARECURSION: Now here is a little known setting What it
does is prevent the server from executing calculation scripts that perform
recursive operations deeper than the system specified number of 31 levels
If you add this setting to the essbase.cfg file with a TRUE parameter, the
system will enforce the 31 level rules If you add this setting with a FALSE
parameter, there will be no limit, and a lowly database calculation script
could actually be responsible for bringing down your analytic server Try
explaining that to your boss! Besides, rarely do you code a calculation script that even uses half that many levels
• DATACACHESIZE: This sets the data cache size for all of the new databases
that are created on the server This cache holds the data blocks in memory
This cache setting is not applied to all of the existing databases that are
already created on the server The data cache size can be specified in Bytes (B), Kilobytes (K), Megabytes (M), or Gigabytes (G) This will take place after
the analytical service is restarted or after the server reboot
Syntax:
DATACACHESIZE n
n is an integer value in B, K, M, or G
Code Sample:
DATACACHESIZE 4M
This sets the data cache size to 4 Megabytes for all new databases that are
created after the service is restarted with this setting
• DATAFILECACHESIZE: This sets the data file cache size for all of the new
databases that are created on the server This cache holds the data files in
the memory The data file cache size can be specified in Bytes (B), Kilobytes
(K), Megabytes (M), or Gigabytes (G) This will take place after the analytic
service is restarted or after a server reboot
Syntax:
DATAFILECACHESIZE n
n is an integer value in B, K, M, or G
Code Sample:
DATAFILECACHESIZE 400M
This sets the data file cache size to 400 Megabytes for all of the new databases that are created after the service is restarted to have a data file cache size
of 400 MB
Trang 3• INDEXCACHESIZE: This sets the index cache size for all of the new databases that are created on the server This cache holds the index pages in the
memory The index cache size can also be specified in Bytes (B), Kilobytes
(K), Megabytes (M), or Gigabytes (G) Again, this setting will take effect
after the analytic service is restarted or after a server reboot
Syntax:
INDEXCACHESIZE n
n is an integer value in B, K, M, or G
Code Sample:
INDEXCACHESIZE 400M
This sets the index cache size to 400 Megabytes for all new databases that
are created after the service is restarted
Well, that wraps it up for the system memory and its management We know
you've heard this before, but here it goes Always buy the most memory you can
afford at the time you are purchasing it If you believe you will do fine with 32 GB,
then buy 64GB
Summary
Goodness, you must be an Essbase expert by now! No, there is no such thing
as an Essbase expert In real life, maybe an Essbase Guru would most accurately
describe someone who is more proficient with Essbase than others
By now, we believe that you now realize that Essbase is not all about reading
and memorizing recommended settings and sizes, but instead Essbase is more
about using what resources you have available to you to get the job done A Guru
is someone who possesses far more than just the so-called technical knowledge
A Guru is also someone who possesses intelligence and wisdom
Yes, someone could create a test for Essbase to gauge your overall technical
knowledge, but what really counts is your good judgment based on your experience Figuring out how to accomplish the same task several different ways based on the
situation is how you advertise your Essbase Guru-ability (is that even a word)
Here is an example of Essbase Guru-ability Consider that you are a reasonably capable technical person who now has Essbase knowledge added to his repertoire of skills You are performing a large data load from a relational database (we're talking Gigabytes) It seems like the load is taking much too long to complete What do you do?
Trang 4Chapter 9
[ 363 ]
Well, you know that a multi-threaded process will execute faster than a
single-threaded process You also know that there are specific data load settings
that you can use in the essbase.cfg file that may help alleviate this performance
issue Then, you remember that you read about the DLSINGLETHREADSPERSTAGE,
DLTHREADSPREPARE, and DLTHREADSWRITE settings that can be coded in the
essbase.cfg file These settings allow you to set up your data loads to use
multiple-threading while processing You quickly make the appropriate entries
in the essbase.cfg file, restart your server, and start your data load process
again You are now amazed and happy that the data load processes to completion
significantly faster
Just remember these now familiar words on your long and exciting Essbase journey,
"Essbase is an art, not a science."
Next up, we jump into a discussion on a relatively new database structure concept
First rolled out with Hyperion Essbase version 7.x, the Aggregate Storage Option
(ASO) is an option that is gaining considerable ground as a means to provide your
business customer with superior system performance, while still delivering the
expected Essbase level of data quantity, quality, and integrity