Hyperion Essbase 188.8.131.52 – Partitioning and its use cases – Transparent, Replicated and Linked partitions – Introduction
Posted by Venkatakrishnan J on March 17, 2009
I was working with one customer this week who basically wanted to find out ways of tuning their existing Hyperion Planning BSO cubes. Multiple options were discussed like loading parts of the BSO cube into an ASO cube, partitioning etc. That too, since they were on the 184.108.40.206 release of EPM, it made the task even more simpler and broader in terms of the options available. One of the major advantages of the new release of Essbase is that quite a few excellent enhancements have been made with regard to partitioning. I thought it would be worth covering the various aspects of partitioning in Essbase through another series of blog entries. Today we shall see what are the partitioning techniques that are available and which options (ASO or BSO) does each partitioning technique support.
Basically Essbase supports 3 types of partitions.
1. Transparent Partition
2. Replicated Partition
3. Linked Partition
If you have worked with Oracle OLAP and are familiar with the partition techniques available there, you would realize that partitioning of Essbase is fundamentally way too different, though it achieves the goal of providing more performance/scalability depending on the technique chosen. With Oracle OLAP partitioning is generally always recommended for bigger AWs, but in the case of Essbase it is not always the case. Each of the partitioning techniques above have their own pros and cons, and they need to be understood in detail before using any one of them.
This is an excellent partition technique which basically provides the same cube’s data from across multiple outlines. The other advantage is that it can be used to provide a consolidated view of data from multiple databases. To understand this better, look at the screenshot below
As you see above transparent partition basically is used to consolidate data from multiple databases. This technique is typically used to provide smaller versions of a bigger database. Also, there can be cases wherein a new database a created to store every year’s worth of data. A transparent partition provides a seamless way of looking at all the year’s data without loading them completely into a new database. In addition, the transparent partition target can have its own data as well. So, in effect whenever a calculation is triggered in the target database, if the calculation requires data from the transparent partition source, then Essbase automatically gets the data out of the transparent partition and combines it with the local data. The other advantage of using this technique is that data loads can be done directly from data source or data target. In the coming blog entries i would discuss a couple of use cases
1. Using ASO as a transparent partition target
2. Using BSO as a transparent partition target
This is generally the most commonly used partition technique which copies a portion of the source database’s data to the target. This does not always ensure that the users are looking at the latest data as there are possibilities of the source and the target going out of sync. This partition technique supports data load only in the source. If the data is loaded in the target, that target data would be over-written after the sychronization with the source. A transparent partition target can use a replicated partition target as a source. But a replicate partition target cannot use a transparent partition target as a source.
Though this is called as a partition technique, it does not provide the generic partitioning capabilities. This basically provides a link to other databases (using XREF) and based on the mapping done while creating the partition, this partition provides the capability to drill from one cell in a source database to another cell in the target database. Since it provides only a linkage, it does not have all the limitations of replicated and transparent partitions. This is illustrated as shown below
We would go into details of each of these partition techniques in future blog entries. Each of the partition technique above have certain limitations and are supported only on certain configs. This is provided below (this is for 220.127.116.11 release).
As you see above, ASO is now supported as a partition target for both replicated and transparent partitions. This opens a lot of possible tuning opportunities especially in cases wherein both the complex calculation abilities of BSO and quick aggregation capabilities of ASO are required.