What's New In MaxL Release 6.5.1?New In 6.5.1
New In 6.5
MaxL Home
What's New In MaxL Release 6.5.1?
Improved Security File Backup |
Top |
In the event that Essbase security file corruption occurs, Essbase provides an improved way of restoring security information. The security backup file can be synchronized to the security file regularly, rather than each time the OLAP Server starts. This ensures that the security backup file is as up-to-date as possible.
Essbase compares the security backup file essbase.bak to the security file essbase.sec at specified intervals and on demand, instead of only when the OLAP Server starts. When Essbase compares the files, Essbase updates the backup file to match the security file if there are any differences.
To synchronize the security backup file on-demand to the current state
of Essbase security, use
alter system sync security_backup;
To set a frequency for automatic comparisons and synchronizations of the security backup file to the security file, use the session_idle_poll setting in alter system. The time interval you specify in the session idle poll tells Essbase both of the following:
ZLIB as Database Compression Algorithm |
Top |
In addition to the database compression options previously being provided (RLE, bitmap compression, or no compression), OLAP Server now supports ZLIB compression. This method is used in packages like PNG, Zip, and gzip.
To set ZLIB as the compression type for a database, use
alter database DBS-NAME set compression zlib;
See alter database.
Reset Database Functionality |
Top |
Previous database reset functionality cleared all data from the database. Now you can optionally clear the database of data and metadata (index files, page files, and outline) and preserve any partition definitions, calculation scripts, load rules, and other associated database objects that you want to keep.
To clear only data (including linked reporting objects), use
alter database dbs-name reset data;
To clear data (including linked reporting objects) and the outline,
use
alter database dbs-name reset all;
See alter database
Invalid Block Header Correction |
Top |
Now you can assess the severity of "invalid block header" errors, and use MaxL to repair the corruption indicated by the presence of invalid block headers. For information about types of invalid block header errors and about how to find invalid block headers, see New Features for Essbase OLAP Server.
To search for the cause of invalid block header errors, use
alter database DBS-NAME validate data to local logfile 'FILE-NAME';
Essbase creates a local log file with all index combinations for which blocks contain invalid block headers.To repair invalid block header corruption, use
Essbase deletes all blocks that have invalid headers.See alter database.
Outline Synchronization for Partitioned Databases |
Top |
Outline synchronization for partitioned databases is now available through
MaxL, using the refresh outline grammar.
Advanced Display Partition Shows More Details |
Top |
When the advanced keyword is used, the display output generated
by display partition contains two new
fields of information. The new fields are time_source_updated
and time_target_updated. The times can be compared, enabling you
to determine if the outline needs to be synchronized. If the ouline needs
to be synchronized, use refresh outline.
Export-LRO Directory Cleanup |
Top |
The following grammar deletes directories created for linked-reporting
objects exported from a database to a directory created in $ARBORPATH\app:
alter system delete export_directory EXPORT-DIR;
Use the export-directory cleanup statement after the exported LROs have already been migrated into a database (using import lro) and the directories containing the exported LRO information are no longer needed.
To view a list of names of exported linked-reporting-objects directories in $ARBORPATH\app, use display system export_directory.
See alter system and display
system.
What's New In MaxL Release 6.5?
With Release 6.2, you could switch to direct I/O for all databases by using a essbase.cfg setting, DIRECTIO TRUE. With Release 6.5, the DIRECTIO config-file setting becomes obsolete. With Release 6.5, if a DIRECTIO setting exists in the .cfg file, all newly created Release 6.5 databases and all databases migrated to Release 6.5 will read the I/O access mode specification from essbase.cfg one time, and copy that information to the Essbase security file (essbase.sec). Thereafter, if you wish to change the I/O access mode used by any database, you must change it at the database level using the database settings.
The database setting for I/O access mode in MaxL is part of the alter
database statement.
Example: alter database Sample.Basic set io_access_mode direct;
Changes to the I/O access mode are effective the next time the database
is started. If you set a database to use direct I/O, Essbase will attempt
to use direct I/O the next time the database is started. If direct I/O
is not available on your platform at the time the database is started,
Essbase will use buffered I/O, which is the default. However, Essbase will
store the I/O access mode setting that you specified in the security file,
and will attempt to use that I/O access mode each time the database is
started.
Example:
create user 'O\'Brian' identified by 'password';
See complete quoting and escape-sequence rules for both MaxL
and the MaxL Shell.
The MaxL Shell has invocation flags that can be used to accomplish various tasks in advance before the shell is launched; for example, the -l flag allows you to specify a login host as an argument to the shell. With Release 6.5, setting the message level returned by the shell is also available as an invocation option, the -m flag.
Example:
essmsh -m error
Sets error messages as the only type of message to be returned by the
MaxL Shell. Values for the -m flag include: default, all,
warning,
error, and fatal. The default value is all (same as
default).
In the MaxL Shell, you can use variables as placeholders for any data that is subject to change or to which you refer often. Prior to Release 6.5, the MaxL Shell allowed variables to be either positional parameters or environment variables. In Release 6.5, the flexibility of positional parameters is increased; also, a new type of variable can be used: locally defined shell variables.
Positional Parameters:
These variables are passed in to the shell at invocation time as arguments,
and can be referred to generically by the subsequent script or interactive
MaxL Shell session using $n, where n is the number representing the order
in which the argument was passed on the command line.
For example, if the shell is started with the variable values provided,
essmsh -a arg1 arg2
The MaxL statements in the subsequent session can use $1 to refer to
arg1, $2 to refer to arg2.
Additionally, with Release 6.5, you can change $1 to mean arg_new in
the same MaxL Shell session, using the following syntax:
set 1 = arg_new;
In other words, you can reset the value associated with the positional
parameters, without needing to exit the shell and start again, passing
new arguments.
Note: If you nest MaxL Shell scripts or interactive sessions,
the nested shell does not recognize positional parameters of the parent
shell. The nested shell should be passed separate arguments, if positional
parameters are to be used.
Locally Defined Shell Variables:
With Release 6.5, you can create variables of any name in the MaxL Shell without the use of arguments or positional parameters. These variables persist for the duration of the shell session, including in any nested shell sessions.
Example:
MaxL>login user1 identified by password1;
MaxL>set var1 = sample;
MaxL>echo $var1; /* see what the value of $var1 is */
sample
MaxL>display application $var1; /* MaxL displays application "sample"
*/
Note: Locally defined variables can be named using alphabetic characters, numbers, and the underscore (_). Variable values can be any characters, but take note of the usual quoting and syntax rules that apply for the MaxL Shell.