In This Section:
Managing Storage for Aggregate Storage Applications
Managing the Aggregate Storage Cache
The information in this chapter applies only to aggregate storage databases and is not relevant to block storage databases.
Also see:
Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide for information on backing up an aggregate storage application
Defining and executing aggregations requires Calculation (Administration Services) or Execute (MaxL) permission or higher. Dimension builds that clear database values require Write permission.
For aggregate storage applications, Tablespace Manager controls data retrieval and storage, using tablespace definitions to manage data storage and work areas on the disk.
Tablespaces help optimize data file and work file storage and retrieval. Tablespaces define location definitions that map data artifacts, such as aggregate views and aggregations, to files. Each application directory contains directories for four tablespaces:
default—Contains database data structure and database values (After data is loaded, the tablespace location cannot be changed.)
log—Contains a binary transactional log of default tablespace updates
metadata—Contains a binary transactional log of default tablespace updates
temp—Provides a temporary workspace to be used during operations such as data loads, aggregations, and retrievals
Tablespace names are case-sensitive, regardless of operating system. You cannot change the location or size of metadata and log. For default and temp you can specify multiple locations and sizes, and you can define tablespace properties:
You can modify or delete file locations used to store information within a tablespace if the locations are empty.
Because Tablespace Manager allocates disk space in fixed-size increments, specifying the maximum disk space for a tablespace location specifies an end point but does not reserve the specified space.
When space is needed, Essbase checks file locations (in numerical order) and, when space is found, starts writing. When all locations are used, no space is available, and an error is returned. When database values are cleared, tablespace files shrink, releasing disk space. Work files that are no longer needed are deleted, making space available for other programs.
Based on the maximum size specified for files, Essbase writes multiple files; for example, ess00001.dat, ess00002.dat, and so on. If you back up database files to other media, do not set a maximum tablespace file size greater than the size that the media can handle.
You define tablespace definitions for each aggregate storage application.
To define tablespaces, use a tool:
UNIX platforms enforce a maximum 2 GB file limit. If, during a data load or an aggregate build, the .dat file limit is exceeded, this message is displayed: "Failed to extend file: file exceeds maximum file size for this system." Essbase closes the data file, creates the next file (essn+1), and continues.
Aggregate storage cache facilitates memory usage during data loads, aggregations, and retrievals. The cache memory locking feature is used only with block storage applications.
When an aggregate storage outline is started, a small area in memory is allocated as the aggregate storage cache for the relevant application. As additional cache area is needed, the cache size incrementally increases until the maximum cache size is used or the operating system denies additional allocations.
You can view the current aggregate cache memory allocation and the maximum aggregate cache size setting. Changing the setting may optimize memory use. The default maximum cache size, 32 MB, is the minimum setting size. You can use the size of input-level data to determine when to increase the maximum size for the cache. Administration Services and MaxL display the size of input-level data as the aggregate storage database property: Size of level 0 values.
A 32 MB cache setting supports a database with approximately 2 GB of input-level data. If the input-level data size is greater than 2 GB by some factor, the aggregate storage cache can be increased by the square root of the factor. For example, if the input-level data size is 3 GB (2 GB * 1.5), multiply the aggregate storage cache size of 32 MB by the square root of 1.5, and set the aggregate cache size to the result: 39.04 MB.
For aggregation materialization performance, consider the number of threads set for parallel calculation. The aggregation materialization process uses multiple threads that divide the aggregate storage cache. Increasing the number of threads specified in the CALCPARALLEL configuration setting for aggregate storage applications or databases may require an increase in aggregate storage cache size. See the CALCPARALLEL configuration setting in the Oracle Essbase Technical Reference.
Setting the number of threads higher than the number of processors may improve aggregate storage application performance.
Do not increase the maximum size of the aggregate storage cache beyond what is needed.
Database restructures may be forced by some aggregate storage database outline changes, including changes to hierarchies. A hierarchy comprises a top member and its descendants.
A dynamic hierarchy includes only one stored level. The Accounts dimension is a dynamic hierarchy.
An attribute dimension is one hierarchy. The generation 1 member is the top member of the hierarchy.
If a standard dimension is not tagged as multiple hierarchies enabled, it is one hierarchy. The generation 1 member is the top member of the hierarchy.
If a standard dimension is tagged as multiple hierarchies enabled, it contains multiple hierarchies. The generation 2 members are the top members of the hierarchies. For example, the Products dimension in ASOSamp.Sample contains two hierarchies. The top members are the generation 2 members All Merchandise and High End Merchandise.
To minimize the time and storage needed for database restructures, if a database outline changes frequently, analyze the outline and the types of outline changes.
Levels of restructuring for aggregate storage databases, listed from most to least expensive (in regard to time, storage, and data):
Clears data and aggregate views. and performs full outline restructure | User must reload input (level 0) data, select the aggregate views, and rerun the database aggregation. | |
| Clears aggregate views. and performs full outline restructure | Storage requirement is up to three times the size of the database file (.dat file). User must select the aggregate views and rerun the database aggregation. |
Perform a change that is not included in other categories; for example, delete or move a member | Storage requirement is up to three times the size of the database file (.dat file). | |
Perform a light restructure change (described below) to an alternate hierarchy or an attribute dimension | Clears aggregate views that are based on attribute dimensions or alternate hierarchies, and performs a light restructure | User must rerun the database aggregation for aggregate views that are based on attribute dimensions or on alternate hierarchies. Such aggregate views exist only if you used query tracking to select views based on usage. See Selecting Views Based on Usage. |
On nonattribute dimensions without stored level 0 members (for example, all level 0 members are shared or have formulas), add a child or child branch without changing the number of levels in the hierarchy On nonattribute dimensions with stored level 0 members:
|
Examples of the more complicated outline changes described in the table above follow.
Changing or not changing the number of stored levels in a hierarchy has different results.
In ASOSamp.Sample, the Measures dimension is tagged as accounts. Therefore, as a dynamic hierarchy, Measures includes only one stored level.
Adding the child member All to Ratios does not change the number of stored levels in the Measures dimension. Saving the outline triggers a light restructure.
In ASOSamp.Sample, Income Level is a stored hierarchy dimension.
Adding a child member does not change the number of levels (two) in the hierarchy. However, adding the seventh child member crosses the 2n boundary of 6 (see Addition of Child Members), requiring a full outline restructure.
If you delete the shared member Orange under Drinks by Category and do not delete its nonshared member under Drinks, the alternate hierarchy Drinks by Category is no longer a replica of the Drinks hierarchy. When the outline is saved, Essbase clears all aggregate views and performs a full outline restructure.
If you delete the shared and nonshared Orange members, the alternate hierarchy Drinks by Category remains a replica of the Drinks hierarchy. When the outline is saved, Essbase performs a full outline restructure but does not clear aggregate views.
In ASOSamp .Sample, adding a child member under Systems in the All Merchandise hierarchy increases the number of children under Systems to three, crossing the boundary 2. When the outline is saved, Essbase clears all aggregate views and performs a full outline restructure.
However, adding a child member under Computers and Peripherals increases the number of children under Computers and Peripherals from three to four. Adding a fourth child, which must be added after the existing members, does not cross the boundary of 2 or 4. The child must be added after existing members. When the outline is saved, Essbase performs a light restructure.
In ASOSamp.Sample, adding a child branch under Computers and Peripherals in the All Merchandise hierarchy increases the number of children to four. Adding a fourth child, which must be added after the existing members, does not cross the boundary of 2 or 4. The new member, called Other Peripherals, has two children. Systems (at the same level as Other Peripherals) has two children. Adding the child branch stays within the 2 boundary for children of members at the same level. When the outline is saved, Essbase performs a light restructure.
Adding a child branch with three child members crosses the 2 boundary and requires that Essbase clear all aggregate views and perform a full outline restructure.
If you have read permission for an aggregate storage database, you can export level 0 data from the database to a specified text file. The export file contains only uncompressed data, not control, outline, or security information. During data export, users can connect to Essbase Server and perform read-only operations on the database.
Exported data can be reloaded without a rules file if there are no outline changes. Consider exporting data for the following reasons:
The default location for export files is ARBORPATH/app/. You can specify an alternate location; see the Oracle Essbase Administration Services Online Help or the Oracle Essbase Technical Reference.
Aggregate storage database exports have limits:
To avoid creating export files larger than 2 GB, Essbase may create multiple export files that include a number suffix in the name, as follows: _1, _2, and so on. For example, if the first file name is /home/exportfile.txt, the next file is /home/exportfile_1.txt.