Replicated Partitions

For example, in the Samppart and Sampeast sample applications, the DBA at The Beverage Company (TBC) created a replicated partition between the East database and the Company database containing Actual, Budget, Variance, and Variance%. Users in the eastern region now store their budget data locally. Because they do not have to retrieve this data live from corporate headquarters, response times are faster, and they have more control over the downtimes and administration of local data.

Changes to the data in a replicated partition flow from the source cube to the target cube. Changes made to replicated data in the data target do not flow back to the data source. If users change the data at the data target, Essbase overwrites their changes when the DBA updates the replicated partition.

When a replicated partition is defined, the DBA can select a setting to prevent the data in the replicated portion of the target cube from being updated. The update setting (which allows or disallows updates) takes precedence over access provided by security filters and is also honored by batch operations, such as data load and calculation.

Use a replicated partition to achieve any of the following goals:

Decrease network activity
Decrease query response times
Decrease calculation times
Recover more easily from system failures

Rules for Replicated Partitions

You must be able to map the shared replicated areas of the source and target outlines, although the shared areas need not be identical. You must tell Essbase how each dimension and member in the source maps to each dimension and member in the target.

The source and target outlines for the non-shared areas do not have to be mappable.

Because none of the areas that you use as a replicated partition target can come from a transparent partition source, you cannot create a replicated partition on top of a transparent partition, as shown in the illustration:

Figure 9-4 Invalid Replicated Partition

This image illustrates how a replicated partition target cannot contain data from a transparent partition source.

The cells in the target of a replicated partition cannot come from two sources; the cells in one partition must come from one cube. To replicate cells from multiple cubes, create a different partition for each source of data.

The cells in a target cube can be the source for a different replicated partition. For example, if the Samppart.Company database contains a replicated partition from the Sampeast.East database, you can replicate the cells in Sampeast.East into a third database, such as Sampwest.West.

You cannot use attribute members to define a replicated partition. For example, associated with the Market dimension, the Market Type attribute dimension members are Urban, Suburban, and Rural. You cannot define a partition on Urban, Suburban, or Rural, because a replicated partition contains dynamic data, not stored data. Therefore, an attempt to map attributes in replicated partitions results in an error message. However, you can use the WITHATTR command to replicate attribute data.

Advantages of Replicated Partitions

Because data is stored closer to end users, in the target cube, replicated partitions can decrease network activity, resulting in improved retrieval times.

The data is more easily accessible to all users. Some users access the data at the source cube, others at the target cube.

Failures are not as catastrophic. Because the data is in multiple places, if one database fails, only the users connected to that database are unable to access the information. Data is still available at and can be retrieved from the other sites.

Local administrators control the downtime. For example, because users in the eastern region are accessing their own replicated data instead of the Company database, an administrator can bring down the Company database without affecting users in the eastern region.

Because only the relevant data is kept at each site, databases can be smaller. For example, users in the eastern region can replicate only the eastern budget information, instead of accessing a larger company database containing budget information for all regions.

Disadvantages of Replicated Partitions

You need more disk space because data is stored in multiple locations.

Because the partition administrator must manually refresh data regularly, users may not see the latest version of the data.

Performance Considerations for Replicated Partitions

To improve the performance of replicated partitions, follow these guidelines:

Do not replicate members that are dynamically calculated in the source cube, because Essbase must probe the outline to find dynamically calculated members and their children to determine how to perform the calculation.

Do not replicate derived data from the source cube. Instead, replicate the lowest practical level of each dimension and perform the calculations on the target cube after you complete the replication.

For example, to replicate the database along the Market dimension:

Define the shared area as the lowest-level members of the Market dimension that you care about, for example, East, West, South, and Central and the level 0 members of the other dimensions.
After you complete the replication, calculate the values for Market and the upper-level values in the other dimensions at the target.

Sometimes you cannot calculate derived data at the target cube. In that case, replicate it from the source cube. You cannot calculate derived data at the source if the data meets any of the following criteria:
- Requires that data outside the replicated area be calculated.
- Requires calculation scripts from which you cannot extract only the portion to be calculated at the target.
- Is being replicated onto a computer with little processing power, such as a laptop.

To optimize the replication of an aggregate storage (ASO) cube that is the replicated target while a block storage database is the source cube, and the two outlines are identical, use the "replication assume identical outline" method, in one of the following ways.

Enable the REPLICATIONASSUMEIDENTICALOUTLINE configuration setting. The syntax is as follows:
```
REPLICATIONASSUMEIDENTICALOUTLINE [appname [dbname]] TRUE | FALSE
```
Issue the alter database MaxL statement with the replication_assume_identical_outline grammar. The statement can be issued only to an ASO cube and does not apply to block storage replication. The syntax is as follows:
```
alter database appname.dbname enable | disable replication_assume_identical_outline;
```

Partitioning along a dense dimension takes longer than partitioning along a sparse dimension. When Essbase replicates data partitioned along a dense dimension, it must access every block in the data source and then create each block in the data target during the replication operation.

You cannot replicate data into a member that is dynamically calculated at the target cube. Essbase does not load or replicate into Dynamic Calc members, because these members do not contain data until a user requests it at runtime. Essbase avoids sending replicated data for both dynamic dense and dynamic sparse members on the replication target, because this data is not stored on the target.

To replicate only the data values that have changed instead of the entire partition, see Populate or Update Replicated Partitions.

Replicated Partitions and Port Usage

With replicated partitions, users connect to the target cube only. When data is updated on the target, the process of replicating data from the source cube to the target cube utilizes one port, and this connection is based on the user name declared in the partition definition (partition user).

Note:

Because of the short-term nature of replication, replicated partitions and ports are rarely a problem.