In This Section:
Also see the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.
An application is a management structure that contains one or more Essbase databases and related files. Essbase applications and databases usually reside on the Essbase Server. The server computer can store multiple applications.
An Essbase database is a data repository that contains a multidimensional data storage array. A multidimensional database supports multiple views of data so that users can analyze the data and make meaningful business decisions.
Files that are related to Essbase databases are called artifacts or objects. Database artifacts perform actions against one or more Essbase databases, such as defining calculations or reporting against data. By default, artifacts are stored in their associated database folder on the server. Some artifacts also can be saved to a client computer or to other available network directories. See Understanding How Essbase Files Are Stored.
For a complete description of each database artifact, see Understanding Database Artifacts.
Essbase installation files and files that are created when using Essbase are stored in the following locations:
MIDDLEWARE_HOME—Oracle WebLogic Server home, and, optionally, one or more Oracle homes, including EPM Oracle home.
In a default installation, MIDDLEWARE_HOME is:
EPM_ORACLE_HOME—Directory under which all EPM System products are installed.
In a default installation, EPM_ORACLE_HOME is:
EPM_ORACLE_INSTANCE—Deployed product location (includes data and applications, deployed Java web applications, and log files).
In a default installation, EPM_ORACLE_INSTANCE is:
ESSBASEPATH—The Essbase installation directory.
In a default installation, the ESSBASEPATH directories are:
For Essbase Server:
For Essbase Client:
For a list of directories that are created under ESSBASEPATH, see the Oracle Enterprise Performance Management System Installation and Configuration Guide.
The app directory location where Essbase application files (as they are created) and sample applications and databases (provided with Essbase) are stored.
The bin directory location where Essbase configuration setting (essbase.cfg) and security (essbase.sec and essbase_timestamp.bak) files (as they are created) are stored.
In a default installation, ARBORPATH is:
EPM_ORACLE_INSTANCE/common—Directory where common internal and third-party components are stored.
EPM_ORACLE_INSTANCE/diagnostics/logs—Directory where log files are stored.
For more information about MIDDLEWARE_HOME, EPM_ORACLE_HOME, and ESSBASE_ORACLE_INSTANCE, see the Oracle Enterprise Performance Management System Installation and Configuration Guide.
Table 134 lists the types of Essbase Server files:
Table 134. Essbase File Types
Table 135 lists the file types that Essbase uses to store applications, databases, and their related artifacts.
Table 135. Essbase File Types for Applications and Databases
Table 136 lists the types of Essbase files stored in the ESSBASEPATH/api subdirectories:
Table 136. Essbase File Types in the api Directory
Regular Essbase backups, which should be integrated into production server maintenance, are key to database maintenance. Backup frequency should be determined by the volatility of the database and server environment and the need for rapid database restoration (should a server interruption occur).
To back up and restore block storage databases, you can use either of the following methods:
Automated database backup and restore and transaction logging and replay
Backup and restore provides the equivalent functionality of manually backing up and restoring a database. When a backed-up database is restored, transactions that occurred after the backup procedure are not recovered. However, with transaction logging and replay, post-backup transactions are captured and can be replayed. Thus, a backed-up database can be recovered to the most-recent state before the interruption occurred.
The use of the database backup and restore and transaction logging and replay features eliminates the need for various manual steps and, therefore, enables administrators to back up and recover databases more efficiently. Oracle recommends incorporating these features in your backup and recovery strategy.
Manual backup and restore
Essbase customers who have designed a backup and restore strategy that uses manual procedures and who do not need the functionality of transaction logging and replay can continue using their manual strategy.
To back up and restore aggregate storage applications, you must use manual procedures.
See the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.
You should not use the platform file system to copy, move, rename, or delete applications and databases. When an application or database is altered through the file system, the Essbase security file is unable to recognize the changes. This situation creates a mismatch between what actually exists on the hard drive and what exists according to Essbase.
To copy or move an outline file (.otl), you must use Administration Services. See “Copying Outlines” in the Oracle Essbase Administration Services Online Help.
The only time the file system should be used to manage applications and databases is during backup, when the entire directory for an application or database is copied and stored elsewhere. See the Oracle Hyperion Enterprise Performance Management System Backup and Recovery Guide.
Each application that is loaded is an open task or process in the operating system. On Windows platforms, the application is displayed in a command-line window. On UNIX platforms, the application server is a child process of ESSBASE. When the application starts, ESSBASE starts the esssvr process. See Starting an Application.
Essbase Server records application-level activities in an application log. See Using Essbase Logs.
When you start Administration Services Console, the Enterprise View tree is displayed in the navigation panel. Enterprise View is a graphical tree view of the Essbase environment. It displays the Administration Servers and Essbase Servers that you select. Your view of the Essbase environment may look different from that of other administrators.
Applications and databases, and their associated artifacts, are represented as nodes beneath the Essbase Server node. Artifacts are grouped into container nodes. For example, individual applications are contained in the Applications node, and databases are contained in the Databases container node. If sample applications and databases are installed with Essbase Server, they appear in Enterprise View along with your organization’s applications and databases.
You can copy an application to any Essbase Server to which you have appropriate access. You can copy (migrate) an entire application to another Essbase Server, or you can copy an application on the same Essbase Server. For example, you may need to migrate an entire application from a development server to a production server. Or, you may want to copy an application on the same server for testing or for backup purposes.
Essbase copies applications differently, depending on whether you are copying to the same Essbase Server or to a different Essbase Server. When you migrate applications, you can select the artifacts to migrate, such as calculation scripts, report scripts, rules files, custom-defined macros and functions, substitution variables, and filters. You can also specify how user and group security is migrated.
When you rename an application, the application and its associated directory (ARBORPATH/app/appname) are renamed. All artifacts within the application (for example, databases or calculation scripts) with the same name as the application are not renamed. Before you rename an application, see Naming Restrictions for Applications and Databases.
You can copy a database in an application to any Essbase Server and application to which you have appropriate access. You can copy (migrate) an entire database to another Essbase Server, or you can copy a database on the same Essbase Server. For example, you may need to migrate an entire database from a development server to a production server. Or, you may want to copy a database on the same server for testing or for backup purposes. Essbase copies databases differently depending on whether you are copying to the same Essbase Server or to a different Essbase Server. See “Copying Databases” in Oracle Essbase Administration Services Online Help.
When you copy a database, all files associated with the database, except data files (.pag and .ind), are copied to the destination application. Before copying, make sure you have enough disk space to contain a full copy of the database and its related files.
To copy a database, use a tool:
Essbase allows copying a non-Unicode database to a Unicode application; however, copying a Unicode database to a non-Unicode application is not allowed.
Before you copy an aggregate storage application, you must merge all incremental data slices into the main database slice. Data in unmerged incremental data slices is not copied. See Merging Incremental Data Slices.
When you rename a database, the database and its associated directory (ARBORPATH/app/appname/dbname), and the outline file (.otl) are renamed. All other artifacts in the database (for example, calculation scripts) with the same name as the database are not renamed.
This section describes copying, renaming, and deleting artifacts, such as outlines, calculation scripts, report scripts, rules files, and data sources. See Understanding Database Artifacts.
The only time the file system should be used to manage applications is during backup, when the entire directory for an application or database is copied and stored elsewhere.
You can copy any database artifact, except an outline, to another application, database, server, or client location. For instructions on copying outlines, see Creating and Editing Outlines.
To rename an artifact, use a tool:
To delete an artifact, use a tool:
Essbase uses a checkout facility for database artifacts to ensure that only one user modifies an artifact simultaneously. This section describes how to lock and unlock artifacts, with the exception of outlines. See Locking and Unlocking Outlines.
Locking artifacts is not the same as locking data blocks. The Essbase kernel handles locking for data blocks but not for artifacts. See Data Locks.
By default, whenever you open a database artifact, Essbase prompts you to lock the artifact. You can change this default behavior for some artifacts; see “Setting Essbase Default Options” in Oracle Essbase Administration Services Online Help.
When an artifact is locked, Essbase does not allow other users to save over, rename, or delete the artifact. You can open a locked artifact and edit it, but you cannot save over the existing artifact. To save changes made to a locked artifact, save the modified artifact to a different location. You can execute and copy locked artifacts.
Using Administration Services, you can migrate applications to any Essbase Server to which you have appropriate access, regardless of platform. For example, you may need to migrate an application from a development server to a production server. When you migrate applications, you can select the artifacts to migrate, such as calculation scripts, report scripts, rules files, custom-defined macros and functions, substitution variables, and filters. You can also specify how user and group security is migrated.
Essbase runs on multiple platforms, including Windows and UNIX. For a list of supported platforms, see the Oracle Hyperion Enterprise Performance Management System Certification Matrix (http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html).
After you create an application, you may want to port the application to a server that runs a different operating system. This section describes how to port an application to another Essbase computer.
If you are using the Linked Reporting Objects feature, you must relink any files or cell notes on the new server. For a comprehensive discussion of how LROs are used, see Linking Objects to Essbase Data.
When transferring files to a UNIX system, be aware of the case-sensitivity of file names. UNIX is a case-sensitive operating system, and files are recognized only if file names are in the correct case. For example, in certain MaxL and ESSCMD operations, you must specify a file name, and the file name must be entered in the correct case.
Essbase files on UNIX systems are capitalized with proper case—the first letter is uppercase, and the remaining letters are lowercase. Table 137 gives examples of names for different file types:
Table 137. File Naming Examples for UNIX
The application name is an exception to the above rule. The application name can be in lowercase.
Table 138 lists several examples of valid and invalid file names on UNIX systems:
Table 138. Valid and Invalid File Names on UNIX
If two servers are connected, you can create the application and database directories on the new server and use either FTP (File Transfer Protocol) or Administration Services to transfer the compatible application files. If the servers are not connected, you must redefine server information on the new server before reloading the database.
Using FTP, you can transfer files directly between operating systems. You should transfer only the files that are compatible between operating systems, and you should transfer the files in binary mode.
If you have files with the wrong case on a UNIX server, Administration Services can see them but cannot open them. After you use FTP to transfer files, rename the files on the server to ensure that they are capitalized in the proper case. Alternatively, you can use FTP to rename the file when you transfer the file. For example:
ftp>put oldfile Newfile
To redefine server information:
Copy the outline files (.otl) for the databases that you want to port from the old server to the same directory location on the new server. Ensure that the application is not running while you copy these files.
Database files, such as .db, .pag, .esm, and .ind, are not included when copying an application or database between servers and are not compatible between operating systems. If you copy an application or database between servers or port an application to a server on a different operating system, you must repopulate the database by reloading the data from a data file and a rules file (if applicable). One way you can reload is to export the data to a text file, transfer the text file to the new server, and then use the text file to load data. After the load is complete, calculate the new database.