1. Database Administrator's Guide for Oracle Essbase
  2. Designing Aggregate Storage Applications
  3. Aggregate Storage Applications, Cubes, and Outlines
  4. Outline Paging in Aggregate Storage Cubes

Outline Paging in Aggregate Storage Cubes

Aggregate storage (ASO) cube outlines are pageable, significantly reducing memory usage for very large cubes. Essbase preloads part of the outline into memory. During data retrieval, Essbase pages other parts of the outline into memory as needed.

When you create an aggregate storage cube, the outline is created in a pageable format.

Paging an outline into memory enables Essbase to handle very large outlines (for example, 10 million or more members), but potentially increases data retrieval time.

Note:

Aggregate storage cubes that have pageable outlines contain memory pages, and therefore their outline files may be larger than binary block storage outline files.

Outline Paging Limits

The maximum size of a buildable outline (the number of members) depends on several factors:

  • The available memory for Essbase

  • The amount of memory in Essbase allocated for other uses

  • The amount of memory required for each member (and aliases for each member)

Essbase uses about 40 MB of memory on startup. In addition, the various caches require the following memory allocations:

  • Outline paging cache: 8 MB

  • Aggregate storage data cache: 32 MB

  • Aggregate storage aggregation cache: 10 MB

Therefore, the initial memory footprint for Essbase is about 90 MB. In addition, memory must be allocated to process incoming query requests. Typical memory to reserve for this purpose is about 300 MB. The total memory allocated for Essbase is therefore 390 MB.

On a Windows system with 1.85 GB of addressable memory, the amount available to build and load the outline is about 1.46 GB (1.85 GB - 390 MB = 1.46 GB).

The maximum outline size depends on whether it is built using a dimension build or from an outline already loaded into Essbase.

Dimension Build Outline Paging Limit

To build the outline by using a dimension build, Essbase allocates about 100 bytes per member, plus the size of the member name, plus the size of all alias names for the member (up to 10 aliases are allowed).

For a sample outline (using a single byte codepage) where the average member name is 15 characters and there is one alias (of 20 characters) per member, the memory requirement for each member that is added:

100 + 15 + 20 bytes = 135 bytes

The total number of members that can be added in a dimension build is the available memory (1.46 GB, or 153,092,060 bytes) divided by the number of bytes per member (135), approximately 11 million members.

On systems with more than 2 GB of addressable memory, the outline can be larger in proportion to the extra memory that is available.

When the dimension build is complete, a dbname.otn file is saved in the cube directory. The .otn file is used as input for the outline restructuring process, which replaces the old outline with the new one. During restructuring, two copies of the outline are loaded into memory, the old one (potentially empty), and the new one, so the maximum size of an outline that can be restructured depends on the size of the old outline.

In a dimension build, which starts with an empty outline, only one outline is loaded into memory.

Loaded Outline Paging Limit

The memory requirement for an outline loaded into Essbase at runtime or during restructuring is different from the memory requirements for a dimension build. Essbase allocates about 60 bytes per member, plus the size of the member name plus 5 bytes, plus the size of all alias names for the member (up to 10 aliases are allowed) plus 5 bytes. For a sample outline where the average member name is 15 characters and there is one alias (of 20 characters) per member, the memory requirement for each member that is added:

60 + 15 + 5 + 20 + 5 bytes = 105 bytes per member

Assuming 1.46 GB of available memory, the maximum size of an outline that can be loaded is one with 14 million members (1.46 GB/105 bytes).

The 14 million members are the sum of two outlines that are loaded during restructuring. For example, if an existing outline has 5 million members, the new outline can have a maximum of 9 million members. In an incremental dimension build, it is recommended to build the smaller dimensions first and the larger ones last to allow for a maximum outline size.