Basically Essbase supports 3 types of partitions.
- Transparent Partition
- Replicated Partition
- 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 has 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, the transparent partition 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
- Using ASO as a transparent partition target
- 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 synchronization 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 below.
We would go into details of each of these partition techniques in future blog entries. Each of the partition technique above has certain limitations and is supported only on certain configs. This is provided below (this is for 184.108.40.206 release). Read the blog: What’s New in Essbase 19c
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 where in both the complex calculation abilities of BSO and quick aggregation capabilities of ASO are required.