Believe it or not, the shape of your outline is one of the most important considerations for overall database performance, but it is still a guideline.. Well in most cases, you want your
Trang 1When you actually get to tuning your system always keep in mind that what you
read here, learn from others, or even glean from Oracle system documentation, is
in most cases to be taken as guidelines for your own individual situation
The actual actions you'll be performing, when you are tuning your database, are
items like adjusting several optional cache sizes through both the EAS and in the
Essbase system configuration file or Essbase.cfg You may also be taking steps
to alter the order of the dimensions in the database outline
We know this isn't really performance related but it is very important! If there were anything that could be considered as a weakness anywhere
in Essbase, it would be the Essbase security file or Essbase.sec
Because this file is more or less open all the time for system I/O operations, there is a high potential for the file to become corrupted
in the event of a power outage or other serious event
If you do encounter a situation where the server needs to be rebooted unexpectedly, we highly recommend that before you restart the server
or the Essbase service, you make a backup copy of the Essbase.sec file The file itself can be found in the Essbase\bin folder
The shape of your database outline
What are they talking about when we refer to the shape of an Essbase outline?
How can an Essbase database outline have a shape? Well conceptually every
Essbase database outline has a shape What you want to be concerned with is
what shape your outline has
Believe it or not, the shape of your outline is one of the most important considerations for overall database performance, but it is still a guideline There will be times when
this guideline simply will not work for you
Everyone knows what an hourglass looks like, right? An hourglass is wide at the
ends and narrow in the middle Well in most cases, you want your Essbase database outline to have the shape of an hourglass, really
The hourglass outline
Here is what we mean by all of this shape nonsense The shape is determined by
the size and storage type of the dimensions in the Essbase database outline It is
generally recognized in the Essbase community that the optimal arrangement for
your database outline is as follows:
Trang 2• Largest Dense dimensions Ñ Most members
• Smallest Dense dimensions Ñ Least members
• Smallest aggregating Sparse dimensions Ñ Least members and
usual consolidations
• Largest aggregating Sparse dimensions Ñ Most members and
usual consolidations
• Non-aggregating Sparse dimensions Ñ Can have many or few
members but little to no consolidations
By looking at the following screenshot, you will see the recommended dimension
structure, as seen in the EAS Database Properties screen:
Notice how even with relatively few members, the database outline has the
dimensions structured as recommended, wide at the ends and narrow in the
middle Just like an hourglass
The reason for this is the same as was given in Chapter 5 on calculation scripts The structure of the database is extremely important to the functioning of the database
What the hourglass shape will tend to do is help keep the database block size down
to manageable levels for optimal performance during calculations and data loads
Trang 3While this database outline shape methodology will work for most situations,
there are times when it will not For example, in a large parts database, you may
need to place your parts dimension last, regardless of the fact that it may have many parent/child consolidations
Database block size
As previously mentioned, database block size is an important and integral part of
overall database performance From calculating the database, to retrieving data into
a Microsoft Excel spreadsheet, bigger data blocks in an Essbase database usually
mean slower performance Of course, the number and type of dimensions directly
affect the database data block size
The suggested ideal database data block size is between 50KB and 200KB The
really ideal block size is less than 100KB or in the 50KB to 80KB range The number
of dense dimensions in the database greatly affects the data block size, so the ideal
recommended number of data dimensions in an Essbase database should be from
5 to 7 Of course, there are times when these recommendations are just not possible, but most applications will fit within these parameters
Looking at the previous screenshot you can see the Statistics page of the Database
Properties screen from the EAS tool This screen tells you all there is to know about
your database data block set up It will be on this screen you will verify if the changes you have made to your Essbase outline have actually helped with block size, block
Trang 4Database configuration settings
There are many database caches and settings available to help you with optimizing your database
As you know, optimally storing your data is the job of a properly configured
database outline A properly configured outline can also have an effect on
calculation performance, data load performance, and data retrieval performance
Data retrieval buffers
When it comes to loading, retrieving, calculating, and extracting your data,
performance optimizing is the job of caches and buffers During reporting, data
retrieval cache and buffer settings are used to obtain optimal retrievals of the data
One pair of settings that you cannot go wrong with is the Data retrieval buffers
settings, found on the General tab of the Database Properties screen (seen below).
The memory used by these buffers is only allocated when an Essbase retrieve is
executed from a Microsoft Excel spreadsheet or when an Essbase report script is
executed Because of this you can increase the retrieval buffer and the retrieval sort
buffer sizes until you get the results you need, all the way upto the maximum size of 100,000 KB, which is 100MB Best of all you will not rob the system of memory when they are not in use These data cache settings are particularly useful when you are
reporting on or retrieving larger amounts of dynamically calculated data
Trang 5Data cache settings
On the Caches tab of the Database Properties screen (seen below), you will find
an assortment of database cache settings that are configurable by the administrator
through EAS
The first option, Cache memory locking, will actually retain the memory needed for
the database caches at all times In order to set the Cache memory locking to true, you should use the Direct I/O memory setting on the Storage tab The Direct I/O setting
uses the memory set by the File Cache and does not consume Essbase server memory
when not in use By default, this is set to false While this may give slight improvement during data loads, we have never noticed any real difference in day-to-day operations
by checking this option You may as well let the system enjoy the use of the memory
until it is needed by one of these caches
One thing you will notice about Essbase is that it is certainly not bashful Essbase
will almost always use as much of the system resources that you allow
For the Index cache setting, you might as well use the maximum of 10240KB, which
is 10MB The Index cache setting sets the size of the buffer that is used to hold index
page files in memory The system will only grab this extra memory when it needs it and it will certainly use it, especially during large data loads