Use the following information to help you determine whether to partition a database.
It takes too long to perform calculations after new data is loaded, and you want to improve performance by spreading calculations across multiple processors or computers.
Users want to see the data in different application contexts, and you want to control how users navigate between databases.
You plan to add new organizational units that would benefit from having their own databases.
You want to save disk space by giving users access to data stored in a remote location.
You want to reduce network traffic by replicating data in several locations.
You need to control database outlines from a central location.
You need client write-back functionality on an aggregate storage database.
See Using a Transparent Partition to Enable Write-Back for Aggregate Storage Databases.
Do not partition a database when:
You have disk space, network bandwidth, and administrative resource concerns.
You perform complex allocations where unit level values are derived from total values.
You are required to keep all databases online at all times.
Keeping databases online can be a problem if you have databases in several time zones, because peak user load may differ between time zones. Using linked and transparent partitions exacerbate this problem, but using replicated partitions might help.
Databases are in different languages or Unicode-related modes.
Essbase can partition databases only if each database uses the same language, or each database uses the same Unicode or non-Unicode mode.