Managing Aggregate Storage Applications and Databases Skip Navigation
Essbase® Analytic Services Database Administrator's Guide | Update Contents | Previous | Next | Print | ? |
Information Map

Managing Aggregate Storage Applications and Databases


Most processes for managing aggregate storage applications are the same as for managing block storage applications. This chapter describes differences in the following topics:

See also Table 1 for basic information about how aggregate storage applications are structured and managed.

Aggregate Storage Security

Defining and executing aggregations requires Calculation (Essbase Administration Services) or Execute (MaxL) permission or higher. Dimension builds clear the database and can be performed only by users with Write permissions. In all other areas, security for aggregate storage applications and security for block storage applications is the same.

For information about permissions, see the following documentation:


Topic
Location

Understanding Security and Permissions

Essbase Analytic Services Database Administrator's Guide

"Managing User/Group Permissions for Applications and Databases"

Essbase Administration Services Online Help

"Privileges and Roles"

Technical Reference

From the index, use the keyword privileges, defined.



Backing Up Aggregate Storage Applications

The file structure used by aggregate storage applications to store application and database information differs from the file structure used by block storage applications use. Table 1 lists the major directories and files associated with aggregate storage applications.


Table 1: Aggregate Storage Files

Directory or File
Location
Description

appname

\arborpath\app\

Application directory

appname.app

\arborpath\app\appname\

Application file containing application settings

appname.LOG

\arborpath\app\appname\

Application log file

dbname

\arborpath\app\appname\

Database directory

dbname.db

\arborpath\app\appname\dbname\

Database file containing database settings

dbname.dbb

\arborpath\app\appname\dbname\

Backup of database file

dbname.ddb

\arborpath\app\appname\dbname\

Partition definition file

dbname.otl

\arborpath\app\appname\dbname\

Outline file

trigger.trg

\arborpath\app\appname\dbname\

Trigger file

default

\arborpath\app\appname\

Tablespace directory: default

temp

\arborpath\app\appname\

Tablespace directory: temp

log

\arborpath\app\appname\

Log directory

metadata

\arborpath\app\appname\

Metadata directory

essn.dat

\arborpath\app\appname\default\

\arborpath\app\appname\log\

\arborpath\app\appname\metadata\

Data file



To back up an aggregate storage database, ensure that the application is stopped and use the operating system to copy the entire application directory: arborpath\app\appname\.

Note: The ESSCMD command BEGINARCHIVE and the MaxL statement alter database begin archive do not support aggregate storage databases.

Managing Storage for Aggregate Storage Applications

For aggregate storage applications, Tablespace Manager controls all aspects of retrieving and storing data. For information about how block storage is managed, see Understanding the Analytic Server Kernel.

Tablespace manager works with tablespace definitions to manage the physical disk for data storage and work areas. The following topics describe tablespaces and how to work with them:

Working with Tablespaces

Essbase Analytic Services uses tablespaces to optimize data storage and to optimize retrieval for data files and work files. Tablespaces define one or more location definitions that map data objects, such as aggregate views and aggregations, to files. Within each application directory, Analytic Services sets up directories for four tablespaces.

You cannot change the location or size of metadata and log, two of the tablespaces. You can specify sizes and multiple locations for the other tablespaces:

You can define the following tablespace properties:

Note: You can modify or delete the file locations used to store information within each tablespace. You cannot delete a file location if it contains data.

Defining a maximum disk space for a tablespace location defines an end point for the location. Files cannot be written past the end point. The maximum disk space definition does not reserve the entire amount of disk space specified. As needed, Tablespace Manager allocates disk space in fixed-size increments.

When Analytic Services extends a file or adds a file to a tablespace, it looks for space in the first location. If the disk space is not available, Analytic Services checks the next location, and so on. Analytic Services starts writing files to the first available space within the defined locations. When no space is available, because all file locations are used, an error is returned.

When values in a database are cleared, the files in the tablespaces shrink, releasing disk space. When work files are no longer needed, they are deleted and disk space in the tablespace is released. If space is unused, other computer programs can use it.

Based on the maximum size specified for files, Analytic Services writes multiple files; for example, ess00001.dat, ess00002.dat, and so on. If you back up database files to other media, you should not set the maximum file size for a tablespace to be greater than the maximum file size that the media can handle.

Defining Tablespaces

You define separate tablespace definitions for each aggregate storage application.

For further information about the methods for defining tablespaces, see the following topics:


Tool
Topic
Location

Administration Services

Managing Tablespaces

Essbase Administration Services Online Help

MaxL

alter tablespace

Technical Reference



Managing the Aggregate Storage Cache

Analytic Services uses the aggregate storage cache to facilitate use of memory during data loads, aggregations, and retrievals. The aggregate storage cache is the only cache relevant to aggregate storage databases.

Note: The cache memory locking feature is used only with block storage applications.

When an aggregate storage outline is started, Analytic Services allocates a small area in memory as the aggregate storage cache for the relevant application. As additional cache area is needed, Analytic Services increases the cache size incrementally until the maximum cache size specified for the application is used or until the operating system denies additional allocations.

Note: After additional aggregate cache memory allocations are denied, use of existing memory can still increase.

You can view the current aggregate cache memory allocation and the maximum aggregate cache size setting. In some situations, changing the current setting can optimize use of memory. By default, the maximum cache size is set at 32 MB, the minimum size for the setting. As a general guideline, you can use the size of input-level data to determine when to increase the maximum size for the cache. The size of input-level data is the size of level 0 values. The size of input-level data is a database statistic that both Administration Services and MaxL display as an aggregate storage database property.

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 that factor. For example, if the input-level data size is 3 GB (which is 2 GB * 1.5), multiply the aggregate storage cache size of 32 MB by 1.22 (which is approximately the square root of 1.5), and set the aggregate cache size to the result: 39.04 MB.

Another factor to consider is the number of threads set for parallel calculation. Essbase uses multiple threads during the aggregation materialization process. The threads divide up aggregate storage cache. If you increase the number of threads specified in the CALCPARALLEL configuration setting for aggregate storage applications or databases, consider the possible need to increase the size of the aggregate storage cache. For information about the CALCPARALLEL configuration setting, see the Technical Reference.

Note: It is possible, for aggregate storage applications, to improve performance by setting the number of threads higher than the number of processors.

Do not increase the maximum size of the aggregate storage cache if a greater size is not needed.

For further information about viewing and setting the aggregate storage cache size for an application, see the following topics:


Tool
Topic
Location

Administration Services

Sizing the Aggregate Storage Cache

Essbase Administration Services Online Help

MaxL

query application

alter application

Technical Reference



Note: A changed aggregate storage cache setting does not take effect until the application is restarted.



Hyperion Solutions Corporation link