Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
This chapter describes the files that are associated with Analytic Services and describes operations that you can perform to manage Analytic Services applications, databases, and database objects.
This chapter contains the following sections:
An application is a management structure that contains one or more Analytic Services databases and related files. Analytic Services applications and databases usually reside on the Analytic Server. The server computer can store multiple applications.
An Analytic Services 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 Analytic Services databases are called objects. Database objects perform actions against one or more Analytic Services databases, such as defining calculations or reporting against data. By default, objects are stored in their associated database folder on the server. Some objects can also be saved to a client computer or to other available network directories. For a detailed description of how Analytic Services stores files, see Understanding How Analytic Services Files Are Stored.
In Analytic Services, the common types of database objects include the following:
Some of these objects are optional, such as calculation scripts, filters, and linked reporting objects.
For a complete description of each database object, see Understanding Database Objects.
In order to manage applications and databases, you need to know how Analytic Services stores server, application, database, and database object files. In particular, there are a few key directories that you should know about.
These directories are created under the root directory of the Analytic Services installation (the directory path named by the value of ARBORPATH):
App
directory stores Analytic Services application files as they are created. Each application is stored in a subdirectory under the App
directory (for example, \essbase\App\Sample
).
Each database in an application is stored in a subdirectory under the application subdirectory (for example, \essbase\App\Sample\Basic
). Database objects, such as outlines, calculation scripts, report scripts, rules files, and data sources, are typically stored on the server in the appname or dbname directory, on a client computer, or on a network.
See Table 39 for a list of application and database files.
bin
directory contains the Analytic Services software. See Table 38 for a list of files stored in this directory.client
directory contains client-based applications and databases. This folder is created during installation of Spreadsheet Add-in or the Runtime Client.docs
directory is created if you choose to install online HTML or PDF documentation. This directory contains numerous subdirectories and files.eas
directory is created if you installed Administration Services on the same computer as Analytic Services. For more information about the contents of this directory, see Essbase Administration Services Installation Guide.locale
directory contains the character-set files necessary for all languages that are supported by Analytic Services, including English. odbcdocs
directory in PDF format.Note: On Windows platforms, these directory names may appear with different case.
For more information about all directories created on the server and for information about platform differences, see the Essbase Analytic Services Installation Guide.
This table lists the types of Analytic Services files that are stored in the \essbase\bin
directory:
File Extension |
Description |
---|---|
Microsoft ODBC file for SQL Interface installation using a DB2 database |
|
The following table lists the file types that Analytic Services uses to store applications, databases, and their related objects.
The following table lists the types of Analytic Services files that are stored in the \
ARBORPATH
\api
sub-directories:
This section explains how to manage applications, databases, and database objects:
For a description of Analytic Services applications, databases, and database objects, see Understanding Applications and Databases and Understanding Database Objects.
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 Analytic Services 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 Analytic Services.
Caution: Do not move, copy, modify, or delete any of these files- ess
n
.ind
, ess
n
.pag
, dbname
.ind
, dbname
.esm
, dbname
.tct
. Doing so may result in data corruption.
The only time the file system should be used to manage applications and databases is during the backup process, where the entire directory for an application or database is copied and stored elsewhere. For a comprehensive discussion of backups, see Backing Up and Restoring Data.
Certain application and database files can be successfully managed through the file system:
.rul
).csc
).rep
).mxl
or any extension)
To copy or move an outline file (.otl
), you must use Administration Services. For instructions, see "Copying Outlines" in Essbase Administration Services Online Help.
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. For more information, see Starting an Application.
On Windows platforms, when an application starts, a new icon is displayed in the task bar. You can double-click the icon to view the server window.
Analytic Server records application-level activities in an application log. For more information, see Using Analytic Services Logs.
To view application activities as they occur, use either of the following methods:
Tool |
Instruction |
---|---|
Select the command-line window that bears the name of the application. |
|
This section describes managing applications and databases. It contains the following sections:
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 Analytic Services environment. It displays the Administration Servers and Analytic Servers that you select. Your view of the Analytic Services environment may look different from that of other administrators.
Applications and databases, and their associated objects, are represented as nodes beneath the Analytic Server node. Objects 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 Analytic Server, they appear in Enterprise View along with your organization's applications and databases.
For more information about operating on applications and databases from Enterprise View, see "About Enterprise View" in Essbase Administration Services Online Help.
To create a new application, see "Creating Applications" in the Essbase Administration Services Online Help.
You can copy an application to any Analytic Server to which you have appropriate access. You can copy (migrate) an entire application to another Analytic Server, or you can copy an application on the same Analytic 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.
Analytic Services copies applications differently depending on whether you are copying to the same Analytic Server or to a different Analytic Server. When you migrate applications, you can select the objects 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.
Administration Services provides a Migration Wizard that helps you migrate applications. See "Migration Wizard" in Essbase Administration Services Online Help.
To copy an application, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
When you rename an application, the application and its associated directory (essbase\app\
appname
) are renamed. All objects 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 Rules for Naming Applications and Databases.
To rename an application, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
When you delete an application, all objects within the application are also deleted. The \essbase\app\
appname
directory and all files located in the directory are deleted.
To delete an application, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can copy a database in an application to any Analytic Server and application to which you have appropriate access. You can copy (migrate) an entire database to another Analytic Server, or you can copy a database on the same Analytic 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. Analytic Services copies databases differently depending on whether you are copying to the same Analytic Server or to a different Analytic Server. For more information, see "Copying Databases" in Essbase Administration Services Online Help.
Administration Services provides a Migration Wizard that helps you migrate applications and databases. See "Migration Wizard" in 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 any of the following methods:
Tool |
Topic |
Location |
---|---|---|
When you rename a database, the database and its associated directory (essbase\app\
appname
\
dbname
), and the outline file (.otl
) are renamed. All other objects in the database (for example, calculation scripts) with the same name as the database are not renamed.
To rename a database, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
When you delete a database, all objects within the database are also deleted. The \essbase\app\
appname
\
dbname
directory and all files located in the directory are deleted.
To delete a database, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
This section describes copying, renaming, and deleting objects, such as outlines, calculation scripts, report scripts, rules files, and data sources:
For descriptions of Analytic Services database objects, see Understanding Database Objects.
Caution: The only time the file system should be used to manage applications is during the backup process, where the entire directory for an application or database is copied and stored elsewhere.
You can copy any database object, except an outline, to another application, database, server, or client location. For instructions on copying outlines, see Creating and Editing Outlines.
To copy an object, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
Topics on copying the specific object; for example, Copying a Rules File |
||
You can rename any object, except an outline. An outline always has the same name as the database, so you need to rename the database to rename the outline.
To rename an object, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
Topics on renaming the specific object; for example, Renaming a Rules File |
||
You can delete any object, except an outline. An outline is a required part of a database, so you need to delete the database to delete the outline.
Tool |
Topic |
Location |
---|---|---|
Topics on deleting the specific object; for example, Deleting a Rules File |
||
Analytic Services uses a check-out facility for database objects to ensure that only one user modifies an object at one time. This section describes how to lock and unlock objects, with the exception of outlines. For information about locking outlines, see Locking and Unlocking Outlines.
Note: Locking objects is not the same as locking data blocks. The Analytic Services kernel handles locking for data blocks, but not for objects. See Data Locks for information about locking data blocks.
By default, whenever you open a database object, Analytic Services prompts you to lock the object. You can change this default behavior for some objects; see "Setting Analytic Services Default Options" in Essbase Administration Services Online Help.
When an object is locked, Analytic Services does not allow other users to save over, rename, or delete the object. You can open a locked object and edit it, but you cannot save over the existing object. If you want to save changes made to a locked object, save the modified object to a different location. You can execute and copy objects that are locked.
You can unlock objects according to your permissions. In Administration Services, you can view all object locks for an Analytic Server, application, or database.
To unlock an object, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
Using Administration Services, you can migrate applications to any Analytic 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 objects 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.
To migrate an application, see "Copying Applications" in the Essbase Administration Services Online Help.
Analytic Services runs on multiple platforms, including Windows and UNIX. For a list of supported platforms and information on how to install and configure Analytic Services on each platform, see the Essbase Analytic Services Installation Guide.
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 Analytic Services computer.
Porting Analytic Services applications across servers involves these steps:
If you are porting an Analytic Services application to a server that uses a different operating system, you need to identify which Analytic Services files are compatible with the new operating system.
The following file types are compatible between operating systems:
.csc
) and report scripts (.rep
), and any MaxL or ESSCMD scripts you have developed. Also, data files can be text files..rul
..otl
.The following file types are incompatible between operating systems and need to be redefined or reloaded on the new server:
.db
and .dbb
.pag
.ind
.sec
.app
and .apb
.esm
Note: If you are using the Linked Reporting Objects feature, you need to relink any files or cell notes on the new server. For a comprehensive discussion of how linked reporting objects are used, see Linking Objects to Analytic Services Data.
When transferring files to a UNIX system, you need to be aware of the case of file names. UNIX is a case-sensitive operating system, and files are recognized only if they have the correct case. For example, in certain MaxL and ESSCMD operations, you need to specify a file name, and the file name must be entered with the correct case.
The Analytic Services system files use the following naming conventions on UNIX systems:
ESSBASE
, ESSCMD
)..a
and are in lowercase (for example, libessnet.a
)..sl
on HP-UX, .so
on Solaris, and .a
on AIX. These file names are in lowercase (for example, libesscur.sl
)..sec
and are in lowercase (for example, essbase.sec
)..mdb
and are in lowercase (for example, essbase.mdb
)..hlp
and are in lowercase (for example, esscmd.hlp
).Analytic Services files on UNIX systems are capitalized with proper case-the first letter is uppercase, and the remaining letters are lowercase. The following table gives examples of names for different file types:
File Type |
Example |
---|---|
Note: The application name is an exception to the above rule. The application name can be in lower case.
Table 42 lists several examples of valid and invalid file names on UNIX systems:
Valid File Names |
Invalid File Names |
Note: Analytic Services does not allow long file names for applications, databases, calculation scripts, reports, and other database files. All file names for objects you create must conform to the Windows 8.3 convention.
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 need to 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 these files but cannot open them. After you use FTP to transfer files, you should rename the files on the server to ensure that they are capitalized with proper case. Alternatively, you can use FTP to rename the file when you transfer the file:
ftp>put oldfile Newfile
Using Administration Services, you can transfer files from the client computer to the server in the following ways:
If the server you are porting to is not connected to the existing server, you need to redefine some information on the new server.
To redefine server information, follow these steps:
.otl
) for the databases that you want to port from the old server to the same directory location on the new server. Make sure the application is not running while you copy these files. See Creating and Editing Outlines.
Database files, such as .db
, .pag
, .esm
, and .ind
, are not compatible between operating systems. If you port an application to a server on a different operating system, you need to 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.
![]() |