Databases Reference
In-Depth Information
• To control data level security more effectively
• To increase system performance when retrieving high use data
Caution:
Partitioning databases is a very real method of improving performance.
You must be very careful not to get carried away and have too many
source databases included in your partitioned target database. Essbase
will load into memory all source databases in a transparent partition
and this can actually have a negative effect on system performance!
Essbase offers three types of database partitioning options. They are:
•
Replicated
: A replicated database partition copies a portion of the
source database to be stored in a target database. Users can access the
target database as if it were the source. The database administrator must
occasionally refresh the target database from the source database.
•
Transparent
: A transparent partition allows users to manipulate their data
that is stored in a target database as if it were part of the actual source
database. The remote data is retrieved from the source database each time
the users of the target database request it. Write backs to the target database
also flow through back to the source database.
•
Linked
: A linked partition enables users to navigate from one data value in
one database to a subset of the data in another database. The two databases
may contain very different outlines.
As you can see there are three very different partitioning methods available to you
with your Essbase system. This may sound tired by now, but truly, even partitioning
your databases is something that is really only needed on the largest of systems.
Partitioning is a valid performance tuning consideration for sure but its use should
be governed more by your Essbase knowledge and experience than by any sort of
formula that says if your database is this size it should do this or that.
Let us consider the first scenario, where the database is large and cumbersome and
you need to split the data. In this scenario we have 5 years worth of data in the
database. For the earliest 3 years of the data, the users do not need to use it on a
day-to-day basis for analysis but only need it once in a while. This scenario seems to
be best suited for the transparent partition where we partition the data by the time
dimension. We are going to have the
Current
and
Prior
years in one cube and the
remaining 3 years in a different cube. Let us call the
Current
and
Prior
year cube our
ESSCAR
cube and the
Prior
cube the
ESSCARP
cube. Current and Prior year data
will be loaded into the
ESSCAR
and the prior 3 year's data will be loaded into the
ESSCARP
cube. In this example, the
ESSCARP
database or cube is the source data
and
ESSCAR
database is the target database. Now, let's see step-by-step how we set
up the transparent partition.
