Filters in Essbase

When the security levels defined for applications, databases, users, and groups are not enough, Essbase security filters give you control over security at the most detailed level. Filters let you control access to individual data within a database, by defining what kind of access is allowed to which parts of the database, and to whom these settings apply.
If you have Administrator permissions, you can define and assign any filters to any users or groups. Filters do not affect you.If you have Create/Delete Applications permissions, you can assign and define filters for applications you created.
If you have Application Manager or Database Manager permissions, you can define and assign filters within your applications or databases.

How Filters Define Permissions

Filters control security access to data values, or cells. You create filters to accommodate security needs for specific parts of a database. When you define a filter, you are designating a set of restrictions upon particular database cells. When you save the filter, you give it a unique name to distinguish it from other filters, and the server stores it in essbase.sec, the security file. You can then assign the filters to any users or groups on the server.
For example, a manager designs a filter named RED, and associates it with a particular database to limit access to cells containing profit information. The filter is assigned to a visiting group called REVIEWERS, so that they can read, but cannot alter, most of the database, while they have no access at all to Profit data values.
Filters are composed of one or more access settings for database members. You can specify the following access levels and apply them to data ranging from a list of members to an individual cell.

None --> No data can be retrieved or updated for the specified member list.
Read -->Data can be retrieved but not updated for the specified member list.
Write--> Data can be retrieved and updated for the specified member list.
Metaread--> Metadata (dimension and member names) can be retrieved and updated for the corresponding member specification.

Creating Filters
You can create a filter for each set of access restrictions you need to place on database values.There is no need to create separate filters for users with the same access needs—once you havecreated a filter, you can assign it to multiple users or groups of users. However, only one filter
per database can be assigned to a user or group.

Note:
If you use a calculation function that returns a set of members, such as children or descendants, and it evaluates to an empty set, the security filter is not created. An error is written to the application log stating that the region definition evaluated to an empty set.
Before creating a filter perform the following actions:
● Connect to the server and select the database associated with the filter.
● Check the naming rules for filters

To create a filter, use a tool:

Tool	Topic	Location
Administration Services	Creating or Editing Filters	Essbase Administration Services Online Help
MaxL	create filter	Essbase Technical Reference

Essbase Recovery Data

This section discusses recovery procedures.
Restoring the File Backup
To restore a database, replace the files on disk with the corresponding files from backup.The application should be stopped, unless you are restoring from an export file. In that case,ensure the application is not accepting client connections.
Restoring the Data Backup
➤ To reload exported data, use a tool:

Tool	Topic	Location
Administration Services	Performing a Data Load or Dimension Build	Essbase Administration Services Online Help
ESSCMD	IMPORT	Essbase Technical Reference
MaxL	import data	Essbase Technical Reference
Calculation script	DATAIMPORTBIN (exported binary files only)	Essbase Technical Reference

When you reload data that has been exported, the data is marked as input data. If you reload data exported from level 0 blocks or input blocks, you must recalculate the database after reloading. When Essbase recalculates the database, it recalculates every data block.
If you export all data in a database and then reload, Essbase marks all blocks in the database as input blocks. Consequently, if you try to clear data, no data is cleared because the database contains no non-input blocks.
When you reload data that has been exported, Essbase also marks the data blocks as dirty. If you had calculated the database prior to exporting it, to save time during the next calculation, you should set the status of the blocks as clean. If you had not calculated the database prior to exporting it, it is not necessary to set the status of the blocks as clean.

➤ To clean block status in a database after exporting all data and reloading, you can run the following calculation script:
Set ClearUpdateStatus Only;
Calc All;

Restoring Corrupted Databases
If there is a problem with any one of the following essential database files, the entire database becomes corrupted and Essbase Server cannot start the database:
● essn.pag
● essn.ind
● dbname.esm
● dbname.tct
● dbname.ind
To restore the database, delete these file, restart the database, and reload from data files or from export files backed up prior to the corruption.

Database Restructuring

As your business changes, you change the Essbase database outline to capture new product lines,provide information on new scenarios, reflect new time periods, etc. Some changes to a database outline affect the data storage arrangement, forcing Essbase to restructure the database.
Because changes that require restructuring the database are very time-consuming, (unless you discard the data before restructuring), you may wish to make decisions about these kinds of changes, based on how much they affect performance. This section provides the information you need to understand how restructuring affects performance, and describes tasks you can perform related to database restructuring:
● Types of Database Restructuring
● Conditions Affecting Database Restructuring
● Temporary Files Used During Restructuring
● Dense Restructures
● Sparse Restructures

Types of Database Restructuring
This section describes the two ways that a database restructure is triggered:
● Implicit Restructures
● Explicit Restructures

Implicit Restructures
Essbase initiates an implicit restructure of the database files after an outline is changed using Outline Editor or Dimension Build. The type of restructure that is performed depends on the type of changes made to the outline:
● Dense restructure: If a member of a dense dimension is moved, deleted, or added, Essbase restructures the blocks in the data files and creates new data files. When Essbase restructures the data blocks, it regenerates the index automatically so that index entries point to the new data blocks. Empty blocks are not removed. Essbase marks all restructured blocks as dirty,so after a dense restructure you need to recalculate the database. Dense restructuring is the most time-consuming of the restructures and, for large databases, can take a very long time to complete.
● Sparse restructure: If a member of a sparse dimension is moved, deleted, or added, Essbase restructures the index and creates new index files. Restructuring the index is relatively fast; the amount of time required depends on the size of the index.
● Outline-only restructure: If a change affects only the database outline, Essbase does not restructure the index or data files. Member name changes, creation of aliases, and dynamic calculation formula changes are examples of changes that affect only the database outline.
If you use incremental restructuring, Essbase defers dense restructuring. If you change a database outline frequently, consider enabling incremental restructuring.

Explicit Restructures
When you manually initiate a database restructure, you perform an explicit restructure. An explicit restructure forces a full restructure of the database. A full restructure comprises a dense restructure plus removal of empty blocks.

Conditions Affecting Database Restructuring
Intelligent Calculation, name changes, and formula changes affect database restructuring:
● If you use Intelligent Calculation in the database, all restructured blocks are marked as dirty whenever data blocks are restructured. Marking the blocks as dirty forces the next default Intelligent Calculation to be a full calculation.
● If you change a name or a formula, Essbase does not mark the affected blocks as dirty.Therefore, you must use a method other than full calculation to recalculate the member or the database.

Dense Restructures
To perform a dense restructure, Essbase does the following:
1. Creates temporary files that are copies of the .ind, .pag, .otl, .esm, and .tct files. Each temporary file substitutes either N or U for the last character of the file extension, so the temporary file names are .inn, essxxxxx.inn, essxxxxx.pan, dbname.otn, dbname.esn, and dbname.tcu.
2. Reads the blocks from the database files copied in step 1, restructures the blocks in memory,and then stores them in the new temporary files. This step takes the most time.
3. Removes the database files copied in step 1,including .ind, .pag, .otl, .esm, and .tct files.
4. Renames the temporary files to the correct file names: .ind, .pag, .otl, .esm, and .tct.

Sparse Restructures
When Essbase does a sparse restructure (restructures just the index), it uses the following files:
● essxxxxx.ind
● dbname.otl
● dbname.esm
To perform a sparse restructure, Essbase does the following:
1. Renames the dbame.esm file to dbname.esr
2. Renames the essxxxxx.ind files to essxxxxx.inm.
3. Creates new index files (essxxxxx.ind) to store index information that is changed by the restructuring operation.
4. Removes dbname.esr and essxxxxx.inm created in 1.

Eliminating Fragmentation in Hyperion Essbase

Fragmentation is unused disk space. Fragmentation is created when Essbase writes a data block to a new location on disk and leaves unused space in the former location of the data block. Block size increases because data from a data load or calculation is appended to the blocks; the blocks
must therefore be written to the end of a data file.
The Essbase Kernel merges adjacent fragments into increasingly larger fragments so that unused space is more likely to be re-used.
In some cases, fragmentation cannot be reduced completely. Fragmentation is likely to occur with the following:
● Read/write databases that users are constantly updating with data
● Databases that execute calculations around the clock
● Databases that frequently update and recalculate dense members
● Data loads that are poorly designed
● Databases that contain a significant number of Dynamic Calc and Store members
● Databases that use an isolation level of uncommitted access with commit block set to zero
If you experience performance slow-downs, you can check to see if there is too much fragmentation of the database, and if there is, you can take steps to reduce the fragmentation:
● Measuring Fragmentation
● Preventing or Removing Fragmentation

Measuring Fragmentation
You can measure fragmentation using the average clustering ratio or average fragmentation
quotient statistic:
● Using the Average Fragmentation Quotient
● Using the Average Clustering Ratio

Using the Average Fragmentation Quotient
In ESSCMD, look at the Average Fragmentation Quotient that is returned when you execute GETDBSTATS command. Use this table to evaluate whether the level of fragmentation is likely to be causing performance problems:

Database Size	Fragmentation Quotient Threshold
Small (up to 200 MB)	60% or higher
Medium (up to 2 GB)	40% or higher
Large (greater than 2 GB)	30% or higher

Any quotient above the high end of the range indicates that reducing fragmentation may help performance, with the following qualifications:
● The reported value of the Fragmentation Quotient is more accurate when there are no other write transactions running on the database.
● For databases less than 50 MB using the Direct I/O access mode, the fragmentation quotient tends to be high. A high fragmentation quotient does not necessarily indicate a need to reduce fragmentation, because the free space is created in 8 MB chunks and all of it might not get used right away.

Using the Average Clustering Ratio
The average clustering ratio database statistic indicates the fragmentation level of the data (.pag) files. The maximum value, 1, indicates no fragmentation.
To view the average clustering ratio for a database, use a tool:

Tool	Topic	Location
Administration Services	Viewing Fragmentation Statistics	Essbase Administration Services Online Help
ESSCMD	GETDBSTATS	Essbase Technical Reference

Preventing or Removing Fragmentation
You can prevent and remove fragmentation:
● To prevent fragmentation, optimize data loads by sorting load records based upon sparse dimension members. For a comprehensive discussion of optimizing data load by grouping sparse members
● To remove fragmentation, perform an export of the database, delete all data in the database with CLEARDATA, and reload the export file.
● To remove fragmentation, force a dense restructure of the database.

Using MDX Formulas on Aggregate Storage Outlines

An MDX formula must always be an MDX numeric value expression. In MDX, a numeric value expression is any combination of functions, operators, and member names that does one of the following:
● Calculates a value
● Tests for a condition
● Performs a mathematical operation
A numeric value expression is different from a set expression. A set expression is used on query axes and describes members and member combinations. A numeric value expression is used to specify a value.
A numeric value expression is used in queries to build calculated members. Calculated members are logical members created for analytical purposes in the WITH section of the query, but which do not exist in the outline.
The following query defines a calculated member and uses a numeric value expression to provide a value for it:
WITH MEMBER
[Measures].[Prod Count]
AS
'Count (
Crossjoin (
{[Units]},
{[Products].children}
)
)', SOLVE_ORDER=1
SELECT
{[Geography].children}
ON COLUMNS,
{
Crossjoin (
{[Units]},
{[Products].children}
),
([Measures].[Prod Count], [Products])
}
ON ROWS
FROM
ASOSamp.Sample
In the sample query, the WITH clause defines a calculated member, Product Count, in the Measures dimension, as follows:
WITH MEMBER
[Measures].[Prod Count]
The numeric value expression follows the WITH clause and is enclosed in single quotation marks. In the sample query, the numeric value expression is specified as follows:

'Count (
Crossjoin (
{[Units]},
{[Products].children}
)
)'
The SOLVE_ORDER property specifies the order in which members and formulas are evaluated.

Note:
For an explanation of the syntax rules used to build the numeric value expression in the example,see the documentation in the Essbase Technical Reference for the Count, CrossJoin, and Children functions.
A numeric value expression can also be used as an MDX formula to calculate the value of an existing outline member.
Therefore, rather than creating the example query, you can create an outline member on the Measures dimension called Prod Count that is calculated in the outline in the same way that the hypothetical Prod Count was calculated in the sample query.

➤ To create a calculated member with a formula:
1 Create a member.
2 Attach an MDX formula to the member.
Assuming that you created the example Prod Count member, you would use the following formula, which is the equivalent of the numeric value expression used to create the calculated member in the example query:
Count(Crossjoin ( {[Units]}, {[Products].children}))
3 Verify the formula by verifying the outline.
When you retrieve data from the aggregate storage database, the formula is used to calculate themember value.
You can use substitution variables within formulas. For example, you could define a substitutionvariable named “EstimatedPercent” and provide different percentages as substitution variable values.
Before applying formulas to members in the outline, you can write MDX queries that contain calculated members. When you can write an MDX query that returns the calculated member results that you want, you are ready to apply the logic of the numeric value expression to an outline member and validate and test the expression.

Compression Dimension for Aggregate Storage Databases

By default, the compression dimension in an aggregate storage database is the Accounts dimension. Changing the compression dimension triggers a full restructure of the database. Essbase requires the compression dimension to be a single, dynamic hierarchy. If the dimension has a different hierarchy setting, such as multiple hierarchies, it will be set to single dynamic
hierarchy automatically. The original hierarchy setting is lost (setting a different dimension as compression does not return the original hierarchy setting). Attribute dimensions cannot be compression dimensions, nor can dimensions with attributes associated to them.
The choice of compression dimension can significantly affect performance. A good candidate for a compression dimension is one that optimizes data compression while maintaining retrieval performance. This topic provides information about choosing an optimal compression dimension.
Maintaining Retrieval Performance
Because compression dimensions are dynamically calculated, you must take into account design considerations for dynamically calculated dimensions when choosing a compression dimension.Dynamic dimensions are calculated at the time of retrieval, so the data retrieval time is longerthan for stored hierarchies.
If a dimension with a large number of level 0 members is tagged as compression, upper level queries take longer because they require many level 0 members to be retrieved. If users will be doing many upper level retrievals on a large dimension, it is not a good candidate for a compression dimension.
Managing Database Compression While Maintaining Retrieval Performance
Another consideration when choosing a compression dimension is how well it is expected to compress the database. The size of the compressed database changes depending on which dimension you tag as compression.
In Administration Services, you can view compression estimates and then choose a compression dimension in the same dialog box. Selecting a new compression dimension in Administration Services restructures the outline automatically.

To view the expected level 0 size of the database for each dimension when hypothetically tagged as compression, and to choose a compression dimension, see “Selecting a Compression Dimension for Aggregate Storage” in the Essbase Administration Services Online Help.
Viewing Compression Estimation Statistics
In Administration Services and in MaxL, you can view detailed compression and query statistics.You can view the number of stored level 0 members, which affects retrieval performance, the average bundle fill and average value length which affect compression, and the level 0 size.

The following topics describe each of the compression and query related statistics:
● Stored level 0 members
● Average bundle fill
● Average value length
● Expected level 0 size

Stored level 0 members
Dimensions with a large number of stored level 0 members do not perform well if tagged Compression. As with any dynamically calculated dimension, upper level retrievals from compression dimensions are generally slow.

Average bundle fill
Compression is more effective if values are grouped together in consecutive members on dimensions or hierarchies rather than spread throughout the outline with lots of #missing data between values. Essbase saves memory by storing information about the location and contents
of the groups rather than storing it separately for each of the members. The average bundle fill is the average number of values stored in the groups. It can vary between 1 and 16 with 16 being the best. Choosing a compression dimension that has a higher average bundle fill means that the database compresses better.
In some outlines, you can improve compression by ordering the numbers in the compression dimension so that members that are frequently populated are grouped together. When populated members are grouped together, more values fit into each bundle, increasing the average bundle fill and thereby improving compression.

Average value length
The average value length is the average storage size, in bytes, required for the stored values in the cells. It can vary between 2 and 8 bytes with 2 being the best. Without compression, it takes 8 bytes to store a value in a cell. With compression, it can take fewer bytes depending on the
value length. For example, 10.050001 might take 8 bytes to store even when compressed, but 10.05 may only take 2-4 bytes to store when compressed. Dimensions with a smaller average value length compress the database better.
Rounding the data values to no more that two digits after the decimal point can reduce the average value length, improving compression.

Expected level 0 size
This is the field that indicates the estimated size of the compressed database. A smaller expected level 0 size indicates that choosing this dimension is expected to enable better compression.

Differences Between Aggregate and Block Storage

Aggregate storage applications differ from block storage applications in both concept and design.Additionally, aggregate storage applications have some limitations that do not apply to block storage applications. The following tables describe the differences between aggregate and block
storage.
1.Inherent Differences Between Aggregate Storage and Block Storage

Inherent Differences	Aggregate Storage	Block Storage
Storage kernel	Architecture that supports rapid aggregation, optimized to support high dimensionality and sparse data	Multiple blocks defined by dense and sparse dimensions and their members, optimized for financial applications
Physical storage definition	Through the Application Properties window,Tablespaces tab in Administration Services	Through the Database Properties window,Storage tab in Administration Services
Database creation	Migrate a block storage outline or define after application creation Note: Do not use the file system to copy a block storage outline into an aggregate storage application. Use the migration wizard in Administration Services to migrate the outline.	Define after application creation
Databases supported per application	One	Several (one recommended)
Application and database names	Names reserved for tablespaces, cannot be used as application or database names: ● default ● log ● metadata ● temp	Follow the Naming Restrictions for Applications and Databases
Application and database information display	Displayed in the Application Properties window and the Database Properties window in Administration Services. (Information not supported by or relevant to aggregate storage applications is not shown. For a description of aggregate storage specific information, see the Essbase Administration Services Online Help for the Application Properties window and Database Properties window.)	Displayed in the Application Properties window and the Database Properties window in Administration Services
Configuration settings (essbase.cfg)	For a list of the settings that apply to aggregate storage databases,	For a list of the settings that do not apply to block storage databases,

2.Outline Differences Between Aggregate Storage and Block Storage

Outline Functionality	Aggregate Storage	Block Storage
Multiple hierarchies enabled, dynamic hierarchy, or stored hierarchy designation	Relevant	Not relevant
Accounts dimensions and members on dynamic hierarchies	Support with the following exceptions: ● No two-pass calculation (however, for information on specifying the calculation order. ● No association of attribute dimensions with the dimension tagged as Accounts ● Additional restrictions for shared members.	Full support
Members on stored hierarchies	Support with the following exceptions: ● Support for the ~ (no consolidation) operator (underneath label-only members only) and the + (addition) operator ● Cannot have formulas ● Restrictions on label only members ● No Dynamic Time Series members ● Stored hierarchy dimensions cannot have shared members. Stored hierarchies within a multiple hierarchies dimension can have shared members.	Full support
Member storage types	Support with the following exceptions: ● Dynamic Calc and Store not relevant ● On stored hierarchies, two limitations if a member is label only: ❍ All dimension members at the same level as the member must be label only ❍ The parents of the member must be label only. Note: On dynamic hierarchies, ability to tag any member as label only Note: On conversion from a block storage database, attribute dimension members are tagged as Dynamic Calc. On standard dimension members Dynamic Calc tags are converted and tagged as stored members,which changes the Members Stored value on the Dimensions tab of the Database Properties window in Administration Services.	Support for all member storage types in all types of dimensions except attribute dimensions
Ragged hierarchies and hierarchies with more than 10 levels	Support, with possible performance impact	Support
Outline validation	● When database is started ● When outline is saved ● When block storage outline is converted to aggregate storage outline ● When user requests	● When outline is saved ● When user requests
Outline paging	Support	No Support
Database restructure	There are several levels of restructure; see “Aggregate Storage Database Restructuring"	There are levels of restructure; see “Optimizing Database Restructuring”.

3.Calculation Differences Between Aggregate Storage and Block Storage

Calculation Functionality	Aggregate Storage	Block Storage
Database calculation	Aggregation of the database, which can be predefined by defining aggregate views	Calculation script or outline consolidation
Formulas	Allowed with the following restrictions: ● Must be valid numeric value expressions written in MDX (cannot contain % operator, replace with expression: (value1/value2)*100) ● No support for Essbase calculation functions ● On dynamic hierarchy members, formulas are allowed without further restrictions	Support for Essbase calculation functions
Calculation scripts	Not supported	supported
Attribute calculations dimension	Support for Sum	Support for Sum, Count, Min, Max, and Average
Calculation order	Member formula calculation order can be defined by the user using the solve order member property	Defined by the user in the outline consolidation order or in a calculation script

4.Partitioning and Write Back Differences Between Aggregate Storage and Block Storage

Partitioning and Write-Back Functionality	Aggregate Storage	Block Storage
Partitioning	Support with the following restrictions: ● Transparent partitions and Linked partitions are supported ● Replicated partitions are not supported ● Aggregate storage database as the source database only for transparent partitions ● No outline synchronization	Support with no restrictions
User ability to change data (write back)	Transparent partition technique used to enable limited write back	Full support

5.Data Load Differences Between Aggregate Storage and Block Storage

Data Load Functionality	Aggregate Storage	Block Storage
Cells loaded through data loads	Only level 0 cells whose values do not depend on formulas in the outline are loaded	Cells at all levels can be loaded (except Dynamic Calc members)
Update of database values	At the end of a data load, if an aggregation exists, the values in the aggregation are recalculated	No automatic update of values. To update data values you must execute all necessary calculation scripts
Data load buffers	The loading of multiple data sources into aggregate storage databases is managed through temporary data load buffers.	Not supported.
Atomic replacement of the contents of a database	When loading data into an aggregate storage database, you can replace the contents of the database or the contents of all incremental data slices in the database.	Not supported.
Data slices	Aggregate storage databases can contain multiple slices of data. Data slices can be merged.	Not supported.
Dimension build for shared members	Full support for parent-child build method.Duplicate generation (DUPGEN) build method limited to building alternate hierarchies up to generation 2 (DUPGEN2).	Support for all build methods
Loading data mapped to dates	In a date-time dimension, you can load data into level-0 members using supported dateformat strings instead of member names.	Date-time dimension type is not supported.

6.Query Differences Between Aggregate Storage and Block Storage

Query Functionality	Aggregate Storage	Block Storage
Report Writer	Supported, except for commands related to sparsity and density of data	Fully supported
Spreadsheet Toolkit	Supported, with limited ability to change data (write back)	Fully supported
API	Supported	Supported
Export	Support with the following restrictions: ● Export of level 0 data only (no upper-levelexport) ● No columnar export	Supported
MDX queries	Supported	Supported
Queries on attribute members that are associated with non-level 0 members	Returns values for descendants of the nonlevel 0 member.	Returns #MISSING for descendants of the non-level 0 member
Queries on attribute members and shared members	A shared member automatically shares the attribute associations of its non-shared member	A shared member does not share the attribute associations of its non-shared member
Query logging	Not supported	supported
Query performance	Considerations when querying data from a dimension that has multiple hierarchies	Hierarchies not relevant

Migrating Essbase to Shared Services

After installation, both Essbase and Administration Services are in native security mode. To use Shared Services, you must migrate to Shared Services security mode. For Essbase, migration is done at the Essbase Server level. Once you have converted to Shared Services security mode,you cannot convert back to native security mode.
Essbase Administration Server can run in Shared Services security mode with Essbase Server running in native security mode. However, if any Essbase Server that you administer from Administration Services Console runs in Shared Services security mode, Essbase Administration Server must also.
To migrate Essbase Server, Essbase Administration Server, and users and groups to Shared Services, use a tool:
Tool
Administration Services
Topic
Converting Essbase Server and Migrating Users to Shared Services
Location
Essbase Administration Services Online Help
Tool
MaxL
Topic
alter system
Location
Essbase Technical Reference

You must be an Essbase Administrator to run a migration. For Essbase Administration Server, if you ran the Oracle's Hyperion® Configuration Utility™ after installation and specified a Shared Services server and login, Essbase Administration Server is converted to Shared Services security mode at that point. You can view the Shared Services configuration information in the Essbase Administration Server properties window (Configuration tab). You can then choose to migrate Administration Services users to Shared Services.

➤ To migrate Administration Services users or to remigrate any Essbase users and groups that failed migration, use a tool:
Tool
Administration Services
Topic
Migrating Users to Shared Services
Location
Essbase Administration Services Online Help
Tool
MaxL
Topic
display user,display group,alter user,alter group
Location
Essbase Technical Reference

You must be an Administration Services Administrator to migrate Administration Services users.
Note:
Before migrating users, groups, and applications to Shared Services, ensure that the NETDELAY and NETRETRYCOUNT configuration settings are high enough to allow the migration to complete. Set NETDELAY to at least 3 hours, possibly more depending on the size of the security file. Return the settings to their original values once the migration is complete. Specify these settings in the client essbase.cfg file, which you place in the ARBORPATH\bin folder of the client computer from which you launch the migration. For example, if you use Administration Services Console to launch the migration, the client essbase.cfg file must be in the
ARBORPATH\bin folder on the computer on which Essbase Administration Server is installed.
Essbase automatically creates a backup of the security file before and after migration (essbase.bak_preUPM and essbase.bak_postUPM). We suggest that you manually back up these files to a safe location.
The Administration Services Essbase Server Properties window displays information on whether the server is in Shared Services security mode.

User Roles in Shared Servies With essbase

Shared Services provides a centralized system for managing user and group access to Hyperion products, and consists of corporate or native Shared Services user directories and a common UI, called Oracle's Hyperion® Shared Services User Management Console. Provisioning refers to the process of assigning roles and access permissions to users for Essbase applications. You can use Shared Services to provide security for Essbase applications, databases, and artifacts.

By default, after installation, Essbase Administration Server and Essbase Server are in native security mode. To use Shared Services security, you must migrate any Essbase Server applications and any existing Essbase users and groups to Shared Services.

USER ROLES
Roles determine the tasks that users can perform, and can be grouped in the following ways:
● Product-specific roles

Examples of Essbase roles are Administrator and Database Manager. All Essbase roles are specific to a Shared Services application (the permissions granted to the user by the role apply only to the specific application for which the role is assigned, and not to all applications).
● Shared Services roles
Examples of Shared Services roles are Project Manager or Provisioning Manager. Most Shared Services roles are global (the role applies to all Shared Services applications). An exception is the Provisioning Manager role, which is specific to an application.
The following Essbase roles provide different levels of authority to perform tasks in Essbase.
You can provision a user with the following roles for an Essbase Server:
● Administrator
● Create/Delete Application
● Server Access
You can provision a user with the following roles for an application:
● Application Manager
● Database Manager
● Calc
● Write
● Read
● Filter
● Start/Stop Application

Essbase User Role and Task For Shared Services:
User Role
Provisioning Manager
Provisioning Manager is a Shared Services applicationspecific role. Users who are assigned this role can provision users and groups with roles for applications. See the Hyperion Security Administration Guide.

Note: The Provisioning Manager role is automatically assigned when you migrate Essbase Administrators (previously known as Supervisors) and Application Managers. However, when you create an Essbase Administrator or Application Manager in User Management Console, you must manually assign the Provisioning.
Manager role.
Administrator (previously Supervisor) Full access to administer the server, applications and databases.
Create/Delete Application
Ability to create and delete applications and databases within the applications. Includes Application Manager and Database Manager permissions for the applications and databases created by this user.
Server Access
Ability to access any application or database that has a minimum access permission other than none.
Note: When you assign security at the Essbase application level, you must also assign the user the Server Access role for the Essbase Server that contains the application (unless the user already has another Essbase Server level role, for example Create/Delete Application).
Application Manager (previously Application Designer)
Ability to create, delete and modify databases and application settings within the particular application.Includes Database Manager permissions for databases within the application.
Note: The Provisioning Manager role is automatically assigned when you migrate Essbase Application Managers.However, when you create an Essbase Application Manager in User Management Console, you must manually assign
the Provisioning Manager role.
Database Manager (previously Database Designer)
Ability to manage the database(s) (for example, to change the database properties or cache settings), database artifacts, locks and sessions within the assigned application.
Calc
Ability to calculate, update, and read data values based on the assigned scope, using any assigned calculations and filter.
Write
Ability to update and read data values based on the assigned scope, using any assigned filter.
Read
Ability to read data values.
Filter
Ability to access specific data and metadata according to the restrictions of a filter.
Start/Stop Application
Ability to start and stop an application or database.