Essbase® Analytic Services Database Administrator's Guide | | Update Contents | Previous | Next | Print | ? | |
Information Map | |
This chapter provides information on using triggers to monitor data changes in a database and detailed information on using logs to monitor server, application and database activities.
This chapter includes the following topics:
The triggers feature provided by Essbase Analytic Services enables efficient monitoring of data changes in a database.
If data breaks rules specified in a trigger, Analytic Services can log relevant information in a file, or, for some triggers, can send an e-mail alert (to a user or system administrator). For example, you might want to notify the sales manager if, in the Western region, sales for a month fall below sales for the equivalent month in the previous year.
There are two types of triggers: on-update triggers and after-update triggers. On-update triggers are activated during the update process, when the block containing the data referenced by the trigger is brought into memory. After-update triggers are activated after the update transaction is complete.
Note: On-update triggers are supported only on block storage databases.
This topic contains the following subtopics:
To administer triggers, a user must have Database Designer security privilege. Analytic Services monitors and potentially activates triggers during the following activities:
Analytic Services does not activate triggers during a database restructure.
To create, change, display, and delete triggers, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
You can see information on enabled and disabled triggers in the application log file when you start Essbase Analytic Server.
When creating on-update triggers, consider the following information:
Note: E-mails related to Unicode-mode applications are encoded in UTF-8 and require a UTF-8-capable e-mail reader.
Consider data security when sending e-mail alerts. When Analytic Services activates a trigger and sends an e-mail, it cannot check whether the e-mail recipient is authorized to see the data referenced by the trigger condition.
Avoid referencing a sparse dimension member in a trigger condition. When Analytic Services executes a trigger on one data block, it has to read another data block that may or may not be updated. Depending on the state of the second block, Analytic Services may activate the trigger in error.
The following example is based on the Sample Basic database. Assume that East and West are sparse dimensions and that the following statement defines the trigger condition:
FIX (East, West, Sales, Jan, Actual, Cola)
IF ((Sales->East + Sales->West) > 20)
EMAIL sales@hyperion.com
Assume that the following Sales data values are stored for East and West:
Now assume that a user does a lock and send request to update the data values:
When Sales->East is updated to 15, temporarily the database contains the following values:
So Analytic Services activates the trigger because 15+6 > 20. Subsequently Analytic Services updates Sales->West to 3. Now the data does not meet the trigger condition because 15+3 < 20. However, Analytic Services has already activated the trigger.
When a data load is followed by a calculation, if both the loaded data and the calculated data meet the trigger condition, Analytic Services activates the trigger twice, once on the data load and once on the calculation.
When creating after-update triggers, consider the following information:
Depending on the number of enabled triggers in a database, there may be a small decrease in performance of calculation and data load. You can control the maximum amount of memory used by the triggers feature by specifying the TRIGMAXMEMSIZE configuration setting in the essbase.cfg
file. By default, TRIGMAXMEMSIZE is set to 4096 bytes. Choosing to log information in a file, rather than sending e-mail, may improve calculation and data load performance by reducing network traffic.
The following examples are based on the Sample Basic database.
Note: You cannot define a trigger that requires data from hybrid analysis members. You cannot define an on-update trigger that requires data from Dynamic Calc members or from members from another partition.
Example 1 tracks the Actual, Sales value for the following month, product, and region:
When the member being calculated is Jan and when the Actual, Sales value of Colas for January exceeds 20, the example sends an e-mail to two e-mail accounts.
create trigger Sample.Basic.Trigger_Jan_20 where "(Jan,Sales,[100],East,Actual)" when Jan > 20 and is(Year.currentmember,Jan) then mail ([Docs.Company.com],[trgsales@company.com], [inventory@company.com], [Mail sent by trigger_Jan_20]) end;
Example 2 tracks the Actual, Sales value for the following months, product, and region:
When the member being calculated is Jan, Feb, or Mar and when the Actual, Sales value of Colas for the month January, February, or March exceeds 20, the example logs an entry in the file Trigger_Jan_Sales_20, Trigger_Feb_Sales_20, or Trigger_Mar_Sales_20. On subsequent trigger activations, both old and new log values are retained in the log files.
create or replace trigger Sample.Basic.Trigger_Qtr1_Sales log_value on Where "(crossjoin(Qtr1.children, {(Measures.Sales, [100], East, Scenario.Actual)}))" When Year.Jan > 20 and is(Year.currentmember, Jan) then spool Trigger_Jan_Sales_20 When Year.Feb > 20 and is(Year.currentmember, Feb) then spool Trigger_Feb_Sales_20 When Year.Mar > 20 and is(Year.currentmember, Mar) then spool Trigger_Mar_Sales_20 end;
Example 3 tracks the inventory level for the following product, region, and months:
The trigger is activated after the update action is complete. If the inventory of Colas in the eastern region falls below 500,000, the example logs an entry in the file Inventory_East.
create after update trigger Sample.Basic.Inventory_east where "(crossjoin ({children([Qtr1])}, {([Market].[East], [Product].[100], [Inventory].[Ending Inventory])}))" when [Ending Inventory] < 500000 then spool Inventory_East end;
This topic describes the logs that Analytic Server creates to record information about server, application, and database activities. Table 43 briefly describes each log:
Type of Log |
Location of Log |
Information Included |
---|---|---|
|
||
|
||
One of these locations (See Table 54):
|
This topic describes the information written to a log and explains how you can use that information to maintain, tune, or troubleshoot Analytic Server.
This topic includes the following subtopics:
For information about Essbase Administration Services logs, see "About the Administration Server Log" in Essbase Administration Services Online Help.
Analytic Server writes activities that occur in Analytic Server and application logs. The Analytic Server log is a text file in the ARBORPATH directory named essbase.log
. In a standard installation, for example, the Analytic Server log is hyperion\essbase\essbase.log
.
Each application on Analytic Server has its own application log. An application log is a text file in the ARBORPATH\
app
\application_name
directory named application_name
.log
. For the Sample Basic database, for example, the application log is hyperion\essbase\app\sample\sample.log
. Information in application logs can help you to pinpoint where and why an error occurred.
The following topics describe Analytic Server and application logs:
For information about the actions that you can perform on server and application logs, see Using Analytic Server and Application Logs. For information on viewing or analyzing logs using Administration Services, see "About Log Viewer" or "About Log Analyzer" in Essbase Administration Services Online Help. For information about specific error messages, see the Error Messages Guide in \docs\errmsgs
in the Analytic Services installation.
Analytic Server writes activities that occur on Analytic Server in ARBORPATH
\essbase.log
. Use essbase.log
to find out more about the activities on Analytic Server. These are some of the activities that you can assess:
Table 44 lists the types of actions logged and the information included in the log message. For information about specific error messages, see the Error Messages Guide in \docs\errmsgs
in the Essbase installation.
Figure 219 shows examples of entries written to essbase.log
when Analytic Server starts. First, the Sample application and the Basic database are loaded. The log includes information about the time the application and database are loaded, the process ID assigned to the application by the operating system, and the startup of the security authentication module.
Note: You can use the process ID to stop the application improperly if you are unable to perform a normal shutdown. See Stopping an Application Improperly.
Figure 219: Startup Messages in the Analytic Server Log
[Tue Nov 06 07:54:16 2001]Local/ESSBASE0///Info(1054014) Database Basic loaded [Tue Nov 06 07:54:16 2001]Local/ESSBASE0///Info(1051061) Application Sample loaded - connection established [Tue Nov 06 07:54:16 2001]Local/ESSBASE0///Info(1054027) Application [Sample] started with process id [1300] [Tue Nov 06 07:54:18 2001]Local/ESSBASE0///Info(1054014) Database Basic loaded [Tue Nov 06 07:54:23 2001]Local/ESSBASE0///Info(1051134) External Authentication Module: [LDAP] enabled [Tue Nov 06 07:54:23 2001]Local/ESSBASE0///Info(1051051) Hyperion Essbase Analytic Server - started
Figure 220 shows a single error. The admin user tried to rename an application using a name that already exists on Analytic Server. The log includes information about the username, the time of the error, and the operation that failed and caused the error.
Figure 220: Error Messages in the Analytic Server Log
[Tue Nov 06 08:00:04 2001]Local/ESSBASE0///Info(1051001) Received client request: Rename Application (from user admin) [Tue Nov 06 08:00:04 2001]Local/ESSBASE0///Error(1051031) Application Testing already exists [Tue Nov 06 08:00:04 2001]Local/ESSBASE0///Warning(1051003) Error 1051031 processing request [Rename Application] - disconnecting
Finally, Figure 221 shows a shutdown. The log includes information about the name of the application shut down and the time of the shutdown.
Figure 221: Shut Down Messages in the Analytic Server Log
[Tue Nov 06 08:00:46 2001]Local/ESSBASE0///Info(1054005) Shutting down application Sample [Tue Nov 06 08:00:52 2001]Local/ESSBASE0///Info(1051052) Hyperion Essbase Analytic Server - finished
Analytic Server writes application activities that occur, such as calculations, on the server in ARBORPATH
\app\
application_name
\
application_name
.log
. For the Sample Basic database, for example, the application log is hyperion\essbase\app\sample\sample.log
. For information about specific error messages, see the Error Messages Guide in \docs\errmsgs
in the Essbase installation.
Use application_name
.log
to find out more about the activities in an application. These are some of the activities you can assess:
Table 45 lists the types of actions logged and the information included in the log message.
The following topics show example entries in the application log, including a standard startup and shutdown, and an example of the messages logged when an error occurs.
Figure 222 shows all the entries written to application_name
.log
when Analytic Server starts. The log includes information such as the time the application starts, when application and database information is read and written, when the application is ready for login requests, and when the database is loaded.
Figure 222: Initials Startup Messages in the Application Log
[Tue Nov 06 08:47:14 2001]Local/Sample///Info(1002035) Starting Essbase Server - Application [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1200480) Loaded and initialized JVM module [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019008) Reading Application Definition For [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019009) Reading Database Definition For [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019021) Reading Database Mapping For [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019010) Writing Application Definition For [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019011) Writing Database Definition For [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019022) Writing Database Mapping For [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013202) Waiting for Login Requests [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [Load Database] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019018) Writing Parameters For Database [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019017) Reading Parameters For Database [Basic]
After Analytic Server starts, Analytic Server writes information about the dimensions and members in the outline, such as the dimension sizes and dynamic calculation information, to the application log:
Figure 223: Database Outline Messages in the Application Log
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019012)
Reading Outline For Database [Basic]
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1007043)
Declared Dimension Sizes = [20 17 23 25 5 3 5 3 15 8 6 ]
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1007042)
Actual Dimension Sizes = [20 14 20 25 4 3 5 3 15 8 5 ]
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1007125)
The number of Dynamic Calc Non-Store Members = [8 6 0 0 2 ]
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1007126)
The number of Dynamic Calc Store Members = [0 0 0 0 0 ]
Next, Analytic Server writes information about the blocks in the database, including the block size, the number of declared and possible blocks, and the number of blocks needed to perform calculations (you can use this information to estimate the retrieval performance for members of sparse dimensions tagged as Dynamic Calc) to the application log:
Figure 224: Block-Related Messages in the Application Log
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1007127) The logical block size is [1120] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1010008) Maximum Declared Blocks is [575] with data block size of [1700] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1010007) Maximum Actual Possible Blocks is [500] with data block size of [192] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1200481) Formula for member [Opening Inventory] will be executed in [CELL] mode [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1012710) Essbase needs to retrieve [1] Essbase Kernel blocks in order to calculate the top dynamically-calculated block.
Next, Analytic Server writes information about the caches set for each database to the application log, as illustrated in Figure 225.
Figure 225: Cache Messages in the Application Log
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1012736) The Dyn.Calc.Cache for database [Basic] can hold a maximum of [2340] blocks. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1012737) The Dyn.Calc.Cache for database [Basic], when full, will result in [allocation from non-Dyn.Calc.Cache memory]. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019018) Writing Parameters For Database [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019017) Reading Parameters For Database [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1070013) Index cache size ==> [1048576] bytes, [1024] index pages. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1070014) Index page size ==> [8192] bytes. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1070081) Using buffered I/O for the index and data files. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1070083) Using waited I/O for the index and data files. [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019019) Reading Data File Free Space Information For Database [Basic]... [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1006025) Data cache size ==> [3145728] bytes, [2048] data pages [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1006026) Data file cache size ==> [0] bytes, [0] data file pages
The final messages logged at startup refer to general database information:
Figure 226: General Database Messages in the Application Log
[Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [Get Database Volumes] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [Set Database State] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019018) Writing Parameters For Database [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019018) Writing Parameters For Database [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [Get Database State] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [Get Database Info] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1013205) Received Command [SetApplicationState] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019010) Writing Application Definition For [Sample] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019011) Writing Database Definition For [Basic] [Tue Nov 06 08:47:15 2001]Local/Sample///Info(1019022) Writing Database Mapping For [Sample]
The following example shows a single error. An unknown member was found in the data load file; the presence of an unknown member caused the load to fail. First, you see the request for the data load, then the error message, and, finally, information messages describing the data values changed by the data load and the data load elapsed time.
[Tue Nov 06 08:49:52 2001]Local/Sample///Info(1013210) User [admin] set active on database [Basic] [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Info(1013091) Received Command [DataLoad] from user [admin] [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Info(1003040) Parallel dataload enabled: [1] block prepare threads, [1] block write threads. [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Error(1003000) Unknown Item [500-10] in Data Load, [0] Records Completed [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Warning(1003035) No data values modified by load of this data file [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Info(1003024) Data Load Elapsed Time : [0.11] seconds [Tue Nov 06 08:49:52 2001] Local/Sample/Basic/admin/Info(1019018) Writing Parameters For Database [Basic]
The following messages are logged when Analytic Server performs a normal shut down. First information about the database is retrieved, then the database is unloaded, free space information is written, and the server shuts down.
[Tue Nov 06 08:50:26 2001]Local/Sample///Info(1013214) Clear Active on User [admin] Instance [1] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Get Database Info] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Get Database State] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Get Database Volumes] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Get Database State] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Get Database Volumes] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013205) Received Command [Unload Database] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1019018) Writing Parameters For Database [Basic] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1019020) Writing Free Space Information For Database [Basic] [Tue Nov 06 08:50:34 2001]Local/Sample///Info(1013207) RECEIVED SHUTDOWN COMMAND - SERVER TERMINATING
Table 46 provides error message categories for each error number range that is shown in the first column. When you receive an error message, use this table to identify the Analytic Services component to which the error is related. For information about specific error messages, see the Error Messages Guide in \docs\errmsgs\erhelp.htm
in the Essbase installation.
Error Message Number Range |
Component That Generated the Error |
---|---|
The following topics describe the actions you can perform on server and application logs.
For a comprehensive discussion of server and application logs, see Analytic Server and Application Logs. For information about specific error messages, see the Error Messages Guide in \docs\errmsgs\erhelp.htm
in the Essbase installation.
You can also view logs using Administration Services. For more information, see "About Log Viewer" in Essbase Administration Services Online Help.
By default, the Analytic Server log, ARBORPATH
\essbase.log
, lists the following types of messages:
In the following example, the admin user logged out.
[Sun Oct 21 16:00:55 2001]Local/ESSBASE0///Info(1051037) Logging out user admin, active for 144 minutes
Warnings often follow errors. In the following example, the rename operation did not complete due to a previous error in the log.
[Fri Nov 02 13:38:14 2001]Local/ESSBASE0///Warning(1051003) Error 1051031 processing request [Rename Application] - disconnecting
In the following example, the rename operation failed because the application name already existed.
[Fri Nov 02 13:38:14 2001]Local/ESSBASE0///Error(1051031) Application Testing already exists
This table lists the settings that you specify in the essbase.cfg
file to determine what types of messages Analytic Server writes to the Analytic Server log. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
By default, the application log, ARBORPATH\app\
application_name
\
application_name
.log
, lists the following types of messages:
In the following example, Analytic Server writes the amount of time elapsed during a data load to the application log:
[Fri Nov 02 13:04:15 2001] Local/Sample/Basic/admin/Info(1003024) Data Load Elapsed Time : [3.014] seconds
In the following example, Analytic Server writes a statement that no data values were changed during a data load to the application log:
[Fri Nov 02 12:43:44 2001] Local/Sample/Basic/admin/Warning(1003035) No data values modified by load of this data file
Error messages can range from serious, such as a file not loading correctly, to very serious, such as a disk space error that causes Analytic Server to crash. In the following example, Analytic Server writes a statement to the application log indicating that a data value was encountered before all dimensions in the outline were specified:
[Fri Nov 02 12:53:32 2001] Local/Sample/Basic/admin/Error(1003007) Data Value [678] Encountered Before All Dimensions Selected, [2] Records Completed
This table lists settings that you specify in the essbase.cfg
file and a command that you can use in a calculation script to determine what types of messages Analytic Server writes to the application log. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
When you view a log, you are viewing a snapshot. To view an updated version of a log, close and reopen the log. You can choose to view a log from a specific date to the present or to view the entire log.
You must have Supervisor permissions to view Analytic Server logs, and you must have at least Application Designer permissions to view application logs.
To view a server or application log, use either of the following methods:
Tool |
Topic |
Location |
---|---|---|
The server and application logs use disk space on the server. Occasionally, you may need to clear entries from a log before it grows too large. Clearing the server log removes all entries in the log, but does not remove the server log itself. Clearing the application log removes all the entries in the application log and deletes the application log itself. Be sure to back up each log before you clear it.
You must have Supervisor permissions to clear server and application logs.
To clear a server or application log immediately, use any of the following methods:
Tool |
Topic |
Location |
---|---|---|
Note: To clear a server or application log each time the server or application restarts, see Clearing the Analytic Server and Application Logs Upon Restart. To conserve space by limiting the items logged in the Analytic Server log or application log, see Setting the Type of Analytic Server Messages Logged or Setting the Type of Application Messages Logged.
By default, Analytic Server appends messages to the end of the server and application logs. As described in Table 48, you can set Analytic Server to clear the Analytic Server log each time the server is restarted or the application log each time the application is restarted. If you change the essbase.cfg
file, restart Analytic Server to apply the change.
Note: To clear a server or application log without restarting the server or application, see Clearing the Analytic Server and Application Logs Immediately. To conserve space by limiting the items logged in the Analytic Server log or application log, see Setting the Type of Analytic Server Messages Logged or Setting the Type of Application Messages Logged.
You can change the symbol used to delimit log entries for server and application logs. Changing the delimiter also affects messages logged in the server console window. By default, Analytic Server uses spaces to delimit fields in a log, as in the following example:
[Thu May 10 20:14:46 2001]Local/ESSBASE0///Info(1051051) Hyperion Essbase Analytic Server - started
You can also use tildes, carets, colons, ampersands, or asterisks to delimit the entries in the server and application logs. If possible, choose a delimiter that does not occur frequently in the data, application, or database. The following example shows a log entry delimited by tildes (~):
Thu~May~10~20:16:13~2001~Local~ESSBASE0~~~Info~(1051051)~ \\ Hyperion Essbase Analytic Server - started
Note: If you set delimiters to anything other than spaces, you can no longer sort the log entries by date in Log Viewer.
This table lists settings that you specify in the essbase.cfg
file to determine the delimiters that Analytic Server uses in the server and application logs. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
You can use Log Analyzer to filter, search, and analyze Analytic Server logs and application logs. Based on filters you choose or create, you can view robust graphical charts for a log. An auto-refresh option enables you to monitor log information dynamically.
To use Log Analyzer, see "About Log Analyzer" in Essbase Administration Services Online Help.
Essbase enables memory management by providing controls on the maximum amount of memory an application can use. Essbase also writes messages to an application log as soon as the application's memory use exceeds 90% of the limit that you set. After the limit is met 100%, Analytic Server stops the application.
To enable Analytic Server to manage application memory use:
config.mem
, containing the MEMORYLIMIT setting, or edit an existing memory configuration file.ARBORPATH
/bin
directory. When 90% of the value in the memory configuration file is reached, Analytic Server writes the following warning message to the application log:
Application is using [n] bytes of memory. It is more than 90 percent of the limit set in the memory config file.
If the application uses 100% of the memory as limited by the memory configuration file, Analytic Server writes the following error message to the application log and stops the application:
Application is using [n] bytes of memory, and is requesting a new memory block of [n] bytes. The memory has exceeded the limit.
When the 90% warning messages are displayed in the log, the database administrator may wish to take corrective action:
For more information about the memory configuration file and MEMORYLIMIT setting, see the Technical Reference.
Query logging provides a way for Essbase administrators to track query patterns of an Essbase database. The query log file tracks all queries performed against the database regardless of whether the query originated from Spreadsheet Add-in or Report Writer. Query logging can track members, generation or level numbers of members belonging to specific generations or levels, and Hybrid Analysis members. Query logging also offers the flexibility to exclude logging of certain dimensions and members belonging to generations or levels. Because the query log file output is an XML document, you can import the log file to any XML-enabled tool to view the log. For details about the query log file structure, refer to querylog.dtd in the ARBORPATH
/bin
directory.
To enable query logging, create a query configuration file (distinct from the essbase.cfg
file) and add to the file the configuration settings that control how query logging is performed.
In the ARBORPATH
\App\
appname
\
dbname
directory of Essbase, create a query log configuration file. The configuration file must be named dbname.cfg
, where dbname matches the name of the database. For example, the query log configuration file for Sample Basic is basic.cfg. The output query log file is located at, by default, ARBORPATH
\App\
appname
\
dbname
00001.qlg
.
For more information about query logging and how to set up the query log configuration file, see the Technical Reference.
You can set Analytic Server to create an outline change log that saves outline modification information to a text file. You can review the outline change log at any time to see all the changes that have been made to an outline since the log was first created. This information helps you to roll back an outline to a previous version. The outline change log is a text file in the ARBORPATH
\app\
application_name
\
database_name
directory named database_name
.olg
. For the Sample Basic database, for example, the outline change log is hyperion\essbase\app\sample\basic\basic.olg
.
The following topics describe the outline change log and the actions that you can perform on it.
You can set Analytic Server to write changes to the outline to ARBORPATH
\app\
application_name
\database_name\
database_name
.olg
.
This table lists the types of actions written to the outline change log and the information included in the log message.
The outline change log program reads outline information from left to right. If you are looking at an outline, the left sibling is the sibling directly above (to the left of) the newly added dimension or member. This rule does not apply if the immediately preceding dimension or member is a parent. If a newly added (or moved) member is the first child of its parent or if the member is the first dimension in the outline, the outline change log identifies the old location of the dimension or member as None.
When a user makes and saves changes to an outline, Analytic Services writes the change information into the outline change log as a group of entries. Each group of entries begins and ends with identifying information so that you can easily identify each revision, from newest to oldest.
Figure 227 shows one record, indicating that since the outline change log was started, the outline was modified once. First, the outline change log lists the beginning of the change, including the application and database changed; the time of the change; and the user making the change. Next, the outline change log lists the change-a member named 100-50 was added to 100 member of the Product dimension. Finally, the outline log lists the end of the change, including the application and database changed; the time of the change; and the user making the change.
Figure 227: Sample Outline Change Log
[Begin Outline Change for Sample/Basic, Sat Nov 03 12:49:31 2001, By admin] Number of member changes for dimension "Product" : 1 Added new member "100-50" to "100" : Left sibling - "100-40" Status - Store Data Added alias "Cherry Cola" to alias table "Default" Unary calc symbol - Add Level Number - 0 Generation Number - 3 [End Outline Change for Sample/Basic, Sat Nov 03 12:49:32 2001, By admin]
By default, Analytic Server does not create an outline change log. Table 50 lists the setting that you specify in the essbase.cfg
file to create an outline change log. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
Setting |
Description |
For More Information |
---|---|---|
An |
Note: During a restructure, Analytic Services holds outline change information in memory until all updates have been made to the outline change log. Turning on the outline change log may, therefore, affect restructure performance. Conditions Affecting Database Restructuring discusses other conditions that affect restructure performance.
Because the outline change log is an ASCII text file, you can view it by opening it in any text editor. The outline change log is located in the ARBORPATH
\app\
application_name
\
database_name
directory and is named database_name
.olg
. For the Sample Basic database, for example, the outline change log is located in hyperion\essbase\app\sample\basic\
.
basic.olg
The default size for the outline change log is 64,000 bytes. When the log reaches this size, Analytic Services copies the contents of database_name
.olg
to a new file with the .olb
extension. For example, when basic.olg
reaches 64,000 bytes the contents are copied to basic.olb
. After this copy, basic.olg
is cleared. New log entries are written to basic.olg
.
Each time the outline change log reaches its maximum file size, Analytic Services writes over the existing database_name
.olb
with the current database_name
.olg
. Retrieve information from database_name
.olb
before database_name
.olg
fills up.
The default, minimum, and maximum file sizes for the database_name
.olb
file are the same as the corresponding defaults specified for the database_name
.olg
file. For example, if you change the maximum size of the outline change log to 2 MB, you automatically set the .olb
file to the same maximum size.
Table 51 lists the setting that you specify in the essbase.cfg
file to set the size of the database_name
.olg
file. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
Setting |
Instructions |
For More Information |
---|---|---|
An |
When an Analytic Server, an application, or a database shuts down abnormally, Analytic Server sometimes creates an exception log as a text file named log0000
n
.xcp
. The following topics describe the server, application, and database exception logs and the actions that you can perform on them.
If an Analytic Server, an application, or a database shuts down abnormally and cannot restart, Analytic Server generates an exception log to help troubleshoot the problem. The location of the exception log depends on the component that shut down abnormally and the amount of information that Analytic Server had available at the time of the abnormal shutdown. Table 53 describes the location of the exception log for each type of abnormal shutdown.
This table lists the sections of the exception log and the information included in each section. If Analytic Server could not retrieve all the information before the shutdown finished, some of the later sections may be blank.
The following example is of an exception log. The first section of the log lists general information about the application and database. In this example, the Analytic Server shut down:
----- Exception Error Log Begin ----- Current Date & Time: Sat Nov 24 13:25:13 2001 Process Type: Server Application Name: Sample Database Name: Basic Exception Log File: C:\HYPERION\ESSBASE\log00001.xcp Current Thread Id: 1116 Exception Code: 0xC0000005=Access Violation Exception Flags: 0x00000000=Continuable Exception Address: 0x002D2249 Exception Parameters: 2 Exception Parameter 0: 0x00000000=Read Violation Exception Parameter 1: 0x0000220A (Virtual Address)
The next section of the log lists register and stack trace information. Hyperion Technical Support can examine this section of the log to assist in determining why an abnormal shutdown may have occurred.
----- Machine Registers ----- General Registers: EAX=0x00000000 EBX=0x01358008 ECX=0x00002200 Control Registers: CS =0x0000001B EIP=0x002D2249 Flg=0x00010202 Segment Registers: DS =0x00000023 ES =0x00000023 FS =0x00000038 Floating Point Registers: CWD=0xFFFF027F SWD=0xFFFF0000 TWD=0xFFFFFFFF Register Area (Hex): 00 00 00 00 00 00 00 00 00 00 ...continued hexadecimal listings... Debug Registers: DR0=0x2F75C73B DR1=0x75E07D39 DR2=0x1475FF16 DR3=0x00000000 DR6=0x0000E00B DR7=0x00000000 ----- Stack ----- Stack Trace: 0: 0x002D2249 1: 0x002D202D ...continued stack trace listings... Stack Dump (Hex): (Stack dump truncated from 1397 to 1024 bytes.) 0x0012EA2C: 00000000 01358008 01358008 FFFFFFFF 0x0012EA3C: 00002200 002D728C 0012EC6C 002D202D ...continued stack dump listings...
The following section of the log lists application information:
----- Application-Wide Configuration ----- Server Name: ASPEN Application Name: Sample Elapsed App Time: 00:00:01:28 Module Count: 6 Module 0: 0x00241000 = C:\HYPERION\ESSBASE\BIN\ESSSEC.DLL Module 1: 0x002C1000 = C:\HYPERION\ESSBASE\BIN\ESSNET.DLL ...continued module listings...
The following section of the log lists operating system information. You can determine how much memory is available, how much swap space is used, and how much memory is available on each drive:
----- Operating System Resources ----- System Date & Time: Sat Nov 24 13:25:13 2001 Elapsed OS Time: 02:03:03:10 OS Name & Version: Windows NT 5.00 CPU Count: 1 CPU Type: Pentium Total Physical Memory: 327024 KB (334872576) Free Physical Memory: 155760 KB (159498240) Used Physical Memory: 171264 KB (175374336) Swap Flags: Enabled: Y Disabled: N File Found: Y Denied: N Swap file(s): C:\pagefile.sys Total Swap Space: 467192 KB (478404608) Free Swap Space: 421528 KB (431644672) Used Swap Space: 45664 KB (46759936) Total Drives: 5 Current Drive: 3 Drive 1: Drive Name: C Volume Label: Drive Type: Fixed File System: NTFS Total Drive Space: 11778448 KB Free Drive Space: 8592548 KB Used Drive Space: 3185900 KB ...continued drive listings...
The following section of the log lists system configuration information, such as paths or essbase.cfg
settings:
----- System-Wide Configuration ----- Elapsed Essbase Time: 00:00:01:33 Essbase Version: 6.2.0 Essbase Description: Ess62P0B128 Network Type: Windows Sockets Environment Variable: ARBORPATH = C:\HYPERION\ESSBASE Environment Variable: ARBORMSGPATH = C:\HYPERION\ESSBASE\bin Module Count: 13 Module 0: Module Name: C:\HYPERION\ESSBASE\BIN\ESSUTL.DLL Module Version: 6.2.0.1 Module Description: Ess62P0B128.1 Module Use Count: 5 ...continued module listings... ----- ESSBASE.CFG Configuration Values ----- Configuration Value: JvmModuleLocation = C:\Hyperion\Essbase\java\jre13\bin\hotspot\jvm.dll Configuration Value: AuthenticationModule = LDAP essldap.dll x Configuration Value: OUTLINECHANGELOG = TRUE
The following section of the log lists license information (such as a serial number), the Essbase options (such as ports purchased), and Hyperion products purchased (such as Enterprise Integration Services):
----- License Information ----- Serial Number: xxx License Expiry Date: Port Count: 10 Ports In Use Count: 0 Limited Use Version: N Read-Only SS: N ...continued Essbase options and Hyperion product listings...
The following section of the log lists client activity, such as using Administration Services to view databases or using the Spreadsheet Add-in to view databases:
----- Client Request Activity ----- Server Name: ASPEN Application Name: Sample Total Request Threads: 5 Avail Request Threads: 6 Total Requests: 56 Average Requests: 48.000000 Weighted Average: 7.440000 Statistics Per Minute: Current Requests: 48 Minimum Requests: 48.000000 Maximum Requests: 48.000000 Thread Count: 5 Thread Id 1444: Request Name: List Objects Database Name: Basic User Name: admin Start Time: Sat Nov 24 13:24:37 2001 End Time: Sat Nov 24 13:24:37 2001 ...continued thread listings... ----- Exception Error Log End -----
Because the exception change log is an ASCII text file, you can view it by opening it in any text editor. The location of the exception log depends on the component that shut down abnormally and the amount of information that Analytic Server had available at the time of the abnormal shutdown.
This table describes the location of the exception log.
By default, Analytic Server creates one or more new exception logs each time it shuts down abnormally. Subsequent exception logs are numbered sequentially; for example, if log00001.xcp
exists, the next log is named log00002.xcp
, the next is log00003.xcp
, and so on.
You can change a setting in the essbase.cfg
file to overwrite the existing exception log instead of creating a new log. If you change an essbase.cfg
setting, restart Analytic Server to apply the change.
Hyperion recommends that you use the default setting of FALSE. An abnormal shutdown may create multiple exception logs and the first log created during the shutdown is often the most descriptive.
Use this table for more information about creating new exception logs:
Setting |
Description |
For More Information |
---|---|---|
An When set to TRUE, Analytic Server overwrites the existing exception log. |
Analytic Server writes errors that occur during a dimension build or data load in error logs. The log that Analytic Server chooses for errors depends on the operation that you perform, such as a dimension build or a data load, and how you perform it, such as using Administration Services, or MaxL. The following topics describe the location of dimension build and data load errors and the actions that you can perform on dimension build and data load error logs:
The dataload.err
log contains errors that occurred during a dimension build or a data load. The logs also contain the records that failed to load. After you fix the errors, you can reload the logs. For instructions, see Loading Dimension Build and Data Load Error Logs.
Analytic Server writes errors that occur during a dimension build or data load to the following error logs:
Operation |
Location of Error Log |
---|---|
Note: If the data load or dimension build fails and there is no error log, see Checking Error Logs for a description of possible causes.
To set the location and file name of dimension build and data load error logs, see "Performing a Data Load or Dimension Build for Block Storage Databases" or "Performing a Data Load or Dimension Build for Aggregate Storage Databases" in the Essbase Administration Services Online Help.
To view the dimension build and data load error logs, open them in any text editor.
Figure 228 shows an entry in a data load log. The 500 member did not exist in the outline, so no data was loaded to it.
Figure 228: Error Message in the Data Load Log
\\ Member 500 Not Found In Database 500 500-10 500-10-10
To solve this problem, you can perform either of the following actions and then restart the load:
Figure 229 shows an entry in a dimension build log. The 600-20 member is not the parent of the 600 member. Make sure that you use the correct rules file with the correct text file. The record looks like it is for a level (bottom-up) build, but the error message indicates that Analytic Server is trying to perform a generation (top-down) build. When you correct the problem, restart the dimension build.
Figure 229: Error Message in the Dimension Build Log
\\Record #2 - Incorrect Parent [600-20] For Member [600] (3307) 600-20-10 600-20 600
The default size of the dataload.err
files is 1,000 records. When the log reaches this size, Analytic Server does not write any other errors that it encounters to the log. The dimension build or data load, however, continues. Any subsequent errors are lost. You can set Analytic Server to write 1 to 65,000 records in the dataload.err
files. If you change the essbase.cfg
file, restart Analytic Server to apply the change.
Setting |
Description |
For More Information |
---|---|---|
An |
If the dimension build or data load fails, you must determine whether the Isolation Level transaction setting is Committed or Uncommitted. If the Isolation Level transaction setting is Committed, you must restart the data load from the beginning. If the Isolation Level is Uncommitted, you can load only the records that failed by loading the error log. Only reloading the failed records is much faster than reloading every record, including those records that succeeded during the first load.
To reload the error log, perform the following steps:
.err
to .txt
. For example, change the dataload.err
file to dataload.txt
.
If you load from the client, you can leave the .err
extension.
Check to see if the following conditions are true:
![]() |