A replicated partition is a copy of a portion of the data source that is stored in the data target. Some users can then access the data in the data source while others access it in the data target.
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. See Case Study 1: Partitioning an Existing Database.
Changes to the data in a replicated partition flow from the data source to the data target. 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 data target 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. The default behavior of the update setting depends on whether you create the replicated partition using MaxL or EAS Console. See Setting up End-User Security.
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