Understanding Partitioning
A partition is the region of a database that is shared with another database. An Essbase partitioned application can span multiple servers, processors, or computers.
See:
Partition Types
The following types of partitions are supported in Essbase:
Table 10-1 Partition Types
| Partition Type | Description | Applies To |
|---|---|---|
|
Replicated |
A copy of a portion of the data source that is stored in the data target. |
Block storage cubes Aggregate storage cubes |
|
Transparent |
Allows users to access data from the data source as though it were stored in the data target. The data is, however, stored at the data source, which can be in another application or Essbase cube, or on another Essbase Server. |
Block storage cubes Aggregate storage cubes |
| Federated |
Federated partitions enable you to integrate Essbase cubes with Autonomous Data Warehouse, to combine Essbase's analytical power with the fast aggregation of Autonomous Database. This chapter does not discuss federated partitions; instead, see Integrate Essbase with Autonomous Database Using Federated Partitions. |
Block storage cubes Aggregate storage cubes |
Use the information in the following table to help you choose which type of partition to use:
Table 10-2 Features Supported by Partition Type
| Feature | Replicated | Transparent |
|---|---|---|
|
Up-to-the-minute data |
x |
|
|
Reduced network traffic |
x |
|
|
Reduced disk space |
x |
|
|
Increased calculation speed |
x |
|
|
Smaller databases |
x |
|
|
Improved query speed |
x |
|
|
Invisible to end users |
x |
x |
|
Easier to recover |
x |
|
|
Ability to query data based on its attributes |
x |
|
|
Ability to use front-end tools that are not distributed OLAP-aware |
x |
x |
|
Easy to perform frequent updates and calculations |
x |
|
|
Ability to update data at the data target |
x |
|
|
Perform batch updates and simple aggregations |
x |
Parts of a Partition
Partitions contain the following parts.
Figure 10-1 Parts of a Partition
Table 10-3 Parts of a Partition
| Part | Description |
|---|---|
|
Type of partition |
A flag indicating whether the partition is replicated or transparent. |
|
Data source information |
The server, application, and database name of the data source. |
|
Data target information |
The server, application, and database name of the data target. |
|
Login and password |
The login and password information for the data source and the data target. This information is used for internal requests between the two databases to execute administrative and end-user operations. |
|
Shared areas |
A definition of one or more areas, or regions, shared between the data source and the data target. To share multiple noncontiguous portions of a database, define multiple areas in a single partition. This information determines which parts of the data source and data target are shared so that Essbase can put the proper data into the data target and keep the outlines for the shared areas synchronized. |
|
Member mapping information |
A description of how the members in the data source map to members in the data target. Essbase uses this information to determine how to put data into the data target if the data target and the data source use different names for some members and dimensions. |
|
State of the partition |
Information about whether the partition is up-to-date and when the partition was last updated. |
Data Sources and Data Targets
Partitioned databases contain at least one data source (the primary site of the data) and at least one data target (the secondary site of the data). One database can serve as the data source for one partition and the data target for another partition. When defining a partition, you map cells in the data source to their counterparts in the data target.
Figure 10-2 Data Source and Data Target
An Essbase database can contain many partitions, as well as data that is not shared with any other Essbase database. You can define partitions between the following databases:
-
Different databases in different applications, as long as each database uses the same language and the same Unicode-related mode.
The applications can be on the same computer or different computers.
-
Different databases in one block storage application.
This practice is not recommended, because the full benefits of partitioning databases are realized when each database is in a separate application.
One database can serve as the data source or data target for multiple partitions. To share data among many databases, create multiple partitions, each with the same data source and a different data target, as illustrated here:
Figure 10-3 Data Shared at Multiple Targets
The following table lists the combinations of block storage and aggregate storage databases as data target and data source that are supported by each partition type:
Table 10-4 Combinations of Data Sources and Data Targets Supported by Partition Type
| Source | Target | Replicated | Transparent |
|---|---|---|---|
| Block storage | Block storage | Yes | Yes |
| Aggregate storage | Block storage | No | Yes |
| Aggregate storage | Aggregate storage | No | Yes |
| Block storage | Aggregate storage | Yes | Yes |
Attributes in Partitions
For block storage databases, you can use attribute functions for partitioning on attribute values, but you cannot partition an attribute dimension. Use attribute values to partition a database to access members of a dimension according to their characteristics.
For example, in the Sample.Basic database, you cannot partition the Pkg Type attribute dimension, but you can create a partition that contains all the members of the Product dimension that are associated with either or both members (Bottle and Can) of the Pkg Type dimension. If you create a partition that contains members associated with Can, you can access data only on Product members that are packaged in cans; namely, 100-10, 100-20, and 300-30.
Note:
Retrieving data on attribute members of block storage databases may result in missing data. See the entry for "Dense Dynamic Calc members in nonexisting stored blocks" in Comparing Attribute and Standard Dimensions.
You can use the @ATTRIBUTE and @WITHATTR calculation functions to define partitions.
For example, to extract data on all members of the Product dimension that are associated with the Caffeinated attribute dimension, you can create a partition such as @ATTRIBUTE (Caffeinated). But you cannot partition the Caffeinated attribute dimension.
Based on the previous example, this partition is correct:
Source Target
@ATTRIBUTE(Caffeinated) @ATTRIBUTE(Caffeinated)This partition is incorrect:
Source Target
Caffeinated Caffeinated