Mondrian has a properties file to allow you to configure how it executes. The
mondrian.properties
file is loaded when the executing Mondrian JAR detects it
needs properties, but can also be done explicitly in your code. It looks in
several places, in the following order:
These properties are stored as system properties, so they can be set during
JVM startup via -D<property>=<value>
.
Not all of the properties in this table are of interest to the end-user. For
example, those in the 'Testing' are only applicable if are running Mondrian's
suite of regression tests.
Property |
Type |
Default value |
Description |
Aggregate tables |
mondrian.rolap.aggregates.rule.tag |
string |
default |
String property that is the AggRule element's tag value.
Normally, this property is not set by a user.
|
mondrian.rolap.aggregates.rules |
string |
/DefaultRules.xml |
String property containing the name of the file which defines the
rules for recognizing an aggregate table. Can be either a resource in
the Mondrian jar or a URL.
The default value is "/DefaultRules.xml", which is in the
mondrian.rolap.aggmatcher package in Mondrian.jar.
Normally, this property is not set by a user.
|
mondrian.rolap.aggregates.ChooseByVolume |
boolean |
false |
Boolean property that controls whether aggregate tables
are ordered by their volume or row count.
If true, Mondrian uses the aggregate table with the smallest volume
(number of rows multiplied by number of columns); if false, Mondrian
uses the aggregate table with the fewest rows.
|
mondrian.rolap.aggregates.generateSql |
boolean |
false |
Boolean property that controls whether to print the SQL code
generated for aggregate tables.
If set, then as each aggregate request is processed, both the lost
and collapsed dimension create and insert sql code is printed.
This is for use in the CmdRunner allowing one to create aggregate table
generation sql.
|
mondrian.rolap.aggregates.jdbcFactoryClass |
string |
- |
Property that defines the JdbcSchema factory class which
determines the list of tables and columns of a specific datasource.
@see mondrian.rolap.aggmatcher.JdbcSchema
|
mondrian.rolap.aggregates.optimizePredicates |
boolean |
true |
Boolean property that determines whether Mondrian optimizes predicates.
If true, Mondrian may retrieve a little more data than specified in
MDX query and cache it for future use. For example, if you ask for
data on 48 states of the United States for 3 quarters of 2011,
Mondrian will round out to all 50 states and all 4 quarters. If
false, Mondrian still optimizes queries that involve all members of a
dimension.
|
mondrian.rolap.aggregates.Read |
boolean |
false |
Boolean property that determines whether Mondrian should read
aggregate tables.
If set to true, then Mondrian scans the database for aggregate tables.
Unless mondrian.rolap.aggregates.Use is set to true, the aggregates
found will not be used.
|
mondrian.rolap.aggregates.Use |
boolean |
false |
Boolean property that controls whether Mondrian uses aggregate
tables.
If true, then Mondrian uses aggregate tables. This property is
queried prior to each aggregate query so that changing the value of this
property dynamically (not just at startup) is meaningful.
Aggregates can be read from the database using the
{@link #ReadAggregates} property but will not be used unless this
property is set to true.
|
Caching |
mondrian.rolap.star.disableCaching |
boolean |
false |
Boolean property that controls whether a RolapStar's
aggregate data cache is cleared after each query.
If true, no RolapStar will cache aggregate data from one
query to the next (the cache is cleared after each query).
|
mondrian.rolap.star.disableLocalSegmentCache |
boolean |
false |
Boolean property that controls whether the data from segments
is cached locally. To create custom caches, look for the
SegmentCache SPI.
|
mondrian.expCache.enable |
boolean |
true |
Boolean property that controls whether to use a cache for frequently
evaluated expressions. With the cache disabled, an expression like
Rank([Product].CurrentMember,
Order([Product].MEMBERS, [Measures].[Unit Sales])) would perform
many redundant sorts. The default is true.
|
mondrian.rolap.EnableRolapCubeMemberCache |
boolean |
true |
Property that determines whether to cache RolapCubeMember objects,
each of which associates a member of a shared hierarchy with a
particular cube in which it is being used.
The default is {@code true}, that is, use a cache. If you wish to use
the member cache control aspects of {@link mondrian.olap.CacheControl},
you must set this property to {@code false}.
RolapCubeMember has recently become more lightweight to
construct, and we may obsolete this cache and this
property.
|
Factories |
mondrian.spi.dataSourceResolverClass |
string |
- |
Property that defines
the name of the plugin class that resolves data source names to
{@link javax.sql.DataSource} objects. The class must implement the
{@link mondrian.spi.DataSourceResolver} interface. If not specified,
the default implementation uses JNDI to perform resolution.
Example:
mondrian.spi.dataSourceResolverClass=mondrian.spi.impl.JndiDataSourceResolver
|
mondrian.calc.ExpCompiler.class |
string |
- |
Property that defines
the name of the class used to compile scalar expressions.
If the value is
non-null, it is used by the ExpCompiler.Factory
to create the implementation.
To test that for all test MDX queries that all functions can
handle requests for ITERABLE, LIST and MUTABLE_LIST evaluation
results, use the following:
mondrian.calc.ExpCompiler.class=mondrian.olap.fun.ResultStyleCompiler
|
mondrian.util.MemoryMonitor.class |
string |
- |
Property that defines
the name of the class used as a memory monitor.
If the value is
non-null, it is used by the MemoryMonitorFactory
to create the implementation.
|
mondrian.rolap.RolapMember.PropertyValueMapFactory.class |
string |
- |
Property that defines the name of the factory class used
to create maps of member properties to their respective values.
If the value is
non-null, it is used by the PropertyValueFactory
to create the implementation. If unset,
{@link mondrian.rolap.RolapMemberBase.DefaultPropertyValueMapFactory}
will be used.
|
mondrian.rolap.SqlMemberSource.ValuePoolFactory.class |
string |
- |
Property that defines the name of the class used in SqlMemberSource
to pool common values.
If the value is non-null, it is used by the
SqlMemberSource.ValueMapFactory
to create the implementation. If it is not set, then
{@link mondrian.rolap.SqlMemberSource.NullValuePoolFactory}
will be used, meaning common values will not be pooled.
|
Miscellaneous |
mondrian.olap.case.sensitive |
boolean |
false |
Boolean property that controls whether the MDX parser resolves uses
case-sensitive matching when looking up identifiers. The default is
false.
|
mondrian.rolap.cellBatchSize |
int |
-1 |
Integer property that, if set to a value greater than zero, sets a hard limit on the
number of cells that are batched together when building segments.
|
mondrian.rolap.compareSiblingsByOrderKey |
boolean |
false |
Boolean property that controls whether sibling members are
compared according to order key value fetched from their ordinal
expression. The default is false (only database ORDER BY is used).
|
mondrian.olap.fun.crossjoin.optimizer.size |
int |
0 |
Property that defines
when to apply the crossjoin optimization algorithm.
If a crossjoin input list's size is larger than this property's
value and the axis has the "NON EMPTY" qualifier, then
the crossjoin non-empty optimizer is applied.
Setting this value to '0' means that for all crossjoin
input lists in non-empty axes will have the optimizer applied.
On the other hand, if the value is set larger than any possible
list, say Integer.MAX_VALUE , then the optimizer
will never be applied.
|
mondrian.rolap.agg.enableCacheHitCounters |
boolean |
false |
Property that controls whether aggregation cache hit / miss
counters will be enabled.
Note that this will affect performance due to existence of sync
blocks.
@deprecated This property is no longer used, and will be removed in
mondrian-4.0.
|
mondrian.drillthrough.enable |
boolean |
true |
If disabled, Mondrian will throw an exception if someone attempts to
perform a drillthrough of any kind.
|
mondrian.rolap.EnableInMemoryRollup |
boolean |
true |
Property which turns on or off the in-memory rollup
of segment data. Defaults to true .
|
mondrian.rolap.nonempty |
boolean |
false |
Boolean property that controls whether each query axis implicit has the
NON EMPTY option set. The default is false.
|
mondrian.olap.triggers.enable |
boolean |
true |
Boolean property that controls whether to notify the Mondrian system
when a {@link MondrianProperties property value} changes.
This allows objects dependent on Mondrian properties to react (that
is, reload), when a given property changes via, say,
MondrianProperties.instance().populate(null) or
MondrianProperties.instance().QueryLimit.set(50) .
|
mondrian.result.highCardChunkSize |
int |
1 |
Property that establishes the amount of chunks for querying cells
involving high-cardinality dimensions.
Should prime with {@link #ResultLimit mondrian.result.limit}.
|
mondrian.rolap.ignoreInvalidMembers |
boolean |
false |
Property that defines whether non-existent member errors should be
ignored during schema load. If so, the non-existent member is treated
as a null member.
|
mondrian.rolap.ignoreInvalidMembersDuringQuery |
boolean |
false |
Property that defines whether non-existent member errors should be
ignored during query validation. If so, the non-existent member is
treated as a null member.
|
mondrian.olap.agg.IgnoreMeasureForNonJoiningDimension |
boolean |
false |
Property that defines whether to ignore measure when non joining
dimension is in the tuple during aggregation.
If there are unrelated dimensions to a measure in context during
aggregation, the measure is ignored in the evaluation context. This
behaviour kicks in only if the CubeUsage for this measure has
IgnoreUnrelatedDimensions attribute set to false.
For example, Gender doesn't join with [Warehouse Sales] measure.
With mondrian.olap.agg.IgnoreMeasureForNonJoiningDimension=true
Warehouse Sales gets eliminated and is ignored in the aggregate
value.
[Store Sales] + [Warehouse Sales]
SUM({Product.members * Gender.members}) 7,913,333.82
With mondrian.olap.agg.IgnoreMeasureForNonJoiningDimension=false
Warehouse Sales with Gender All level member contributes to the aggregate
value.
[Store Sales] + [Warehouse Sales]
SUM({Product.members * Gender.members}) 9,290,730.03
On a report where Gender M, F and All members exist a user will see a
large aggregated value compared to the aggregated value that can be
arrived at by summing up values against Gender M and F. This can be
confusing to the user. This feature can be used to eliminate such a
situation.
|
mondrian.rolap.iterationLimit |
int |
0 |
Integer property indicating the maximum number of iterations
allowed when iterating over members to compute aggregates. A value of
0 (the default) indicates no limit.
|
mondrian.jdbcDrivers |
string |
sun.jdbc.odbc.JdbcOdbcDriver,org.hsqldb.jdbcDriver,oracle.jdbc.OracleDriver,com.mysql.jdbc.Driver |
Property containing a list of JDBC drivers to load automatically.
Must be a comma-separated list of class names, and the classes must be
on the class path.
|
mondrian.rolap.localePropFile |
string |
- |
String property that holds the
name of the class whose resource bundle is to be used to for this
schema. For example, if the class is {@code com.acme.MyResource},
mondrian will look for a resource bundle called
{@code com/acme/MyResource_locale.properties} on the class path.
(This property has a confusing name because in a previous release it
actually held a file name.)
Used for the {@link mondrian.i18n.LocalizingDynamicSchemaProcessor};
see Internationalization
for more details.
Default value is null.
|
log4j.configuration |
string |
- |
Set mondrian logging information if not provided by containing application.
Examples:
log4j.configuration=file://full/path/log4j.xml
log4j.configuration=file:log4j.properties
|
mondrian.rolap.evaluate.MaxEvalDepth |
int |
10 |
Boolean property that defines the maximum number of passes
allowable while evaluating an MDX expression.
If evaluation exceeds this depth (for example, while evaluating a
very complex calculated member), Mondrian will throw an error.
|
mondrian.native.NativizeMaxResults |
int |
150,000 |
Property that controls the maximum number of results contained in a
NativizeSet result set.
If the number of tuples contained in the result set exceeds this
value Mondrian throws a LimitExceededDuringCrossjoin error.
|
mondrian.native.NativizeMinThreshold |
int |
100,000 |
Property that controls minimum expected cardinality required in
order for NativizeSet to natively evaluate a query.
If the expected cardinality falls below this level the query is
executed non-natively.
It is possible for the actual cardinality to fall below this
threshold even though the expected cardinality falls above this
threshold. In this case the query will be natively evaluated.
|
mondrian.olap.elements.NeedDimensionPrefix |
boolean |
false |
Property determines if elements of dimension (levels, hierarchies,
members) need to be prefixed with dimension name in MDX query.
For example when the property is true, the following queries
will error out. The same queries will work when this property
is set to false.
select {[M]} on 0 from sales
select {[USA]} on 0 from sales
select {[USA].[CA].[Santa Monica]} on 0 from sales
When the property is set to true, any query where elements are
prefixed with dimension name as below will work
select {[Gender].[F]} on 0 from sales
select {[Customers].[Santa Monica]} on 0 from sales
Please note that this property does not govern the behaviour
wherein
[Gender].[M]
is resolved into a fully qualified
[Gender].[M]
In a scenario where the schema is very large and dimensions have
large number of members a MDX query that has a invalid member in it will
cause mondrian to to go through all the dimensions, levels, hierarchies,
members and properties trying to resolve the element name. This behavior
consumes considerable time and resources on the server. Setting this
property to true will make it fail fast in a scenario where it is
desirable.
|
mondrian.olap.NullDenominatorProducesNull |
boolean |
false |
Property that defines
the behavior of division if the denominator evaluates to zero.
If false (the default), if a division has a non-null numerator and
a null denominator, it evaluates to "Infinity", which conforms to SSAS
behavior.
If true, the result is null if the denominator is null. Setting to
true enables the old semantics of evaluating this to null; this does
not conform to SSAS, but is useful in some applications.
|
mondrian.olap.NullMemberRepresentation |
string |
#null |
Property that determines how a null member value is represented in the
result output.
AS 2000 shows this as empty value
AS 2005 shows this as "(null)" value
|
mondrian.query.limit |
int |
40 |
Maximum number of simultaneous queries the system will allow.
Oracle fails if you try to run more than the 'processes' parameter in
init.ora, typically 150. The throughput of Oracle and other databases
will probably reduce long before you get to their limit.
|
mondrian.rolap.queryTimeout |
int |
0 |
Property that defines the timeout value (in seconds) for queries. A
value of 0 (the default) indicates no timeout.
|
mondrian.result.limit |
int |
0 |
Integer property that, if set to a value greater than zero, limits the
maximum size of a result set.
|
mondrian.rolap.maxQueryThreads |
int |
10 |
Maximum number of MDX query threads per Mondrian server instance.
Defaults to 10.
|
mondrian.rolap.shepherdThreadPollingInterval |
string |
1000ms |
Property that defines the interval value between
polling operations performed by the RolapConnection shepherd thread.
This controls query timeouts and cancellation, so a small value
(a few milliseconds) is best. Setting this to a value higher than
mondrian.rolap.queryTimeout will result the timeout not being enforced
as expected.
Default value is "1000ms". Default time unit is "ms".
|
mondrian.rolap.SegmentCache |
string |
- |
Property which defines which SegmentCache implementation to use.
Specify the value as a fully qualified class name, such as
org.example.SegmentCacheImpl where SegmentCacheImpl
is an implementation of {@link mondrian.spi.SegmentCache}.
|
mondrian.rolap.maxCacheThreads |
int |
100 |
Maximum number of threads per Mondrian server instance that
are used to run perform operations on the external caches.
Defaults to 100.
|
mondrian.rolap.maxSqlThreads |
int |
100 |
Maximum number of threads per Mondrian server instance that
are used to run SQL queries when populating segments.
Defaults to 100.
|
mondrian.rolap.SolveOrderMode |
string |
ABSOLUTE |
Property that controls the behavior of
{@link Property#SOLVE_ORDER solve order} of calculated members and sets.
Valid values are "absolute" and "scoped" (the default). See
{@link mondrian.olap.SolveOrderMode} for details.
|
mondrian.rolap.SparseSegmentValueThreshold |
int |
1,000 |
Property that, with {@link #SparseSegmentDensityThreshold}, determines
whether to choose a sparse or dense representation when storing
collections of cell values in memory.
When storing collections of cell values, Mondrian has to choose
between a sparse and a dense representation, based upon the
possible and actual number of values.
The density is actual / possible .
We use a sparse representation if
(possible -
{@link #SparseSegmentCountThreshold countThreshold}) *
{@link #SparseSegmentDensityThreshold densityThreshold} >
actual
For example, at the default values
({@link #SparseSegmentCountThreshold countThreshold} = 1000,
{@link #SparseSegmentDensityThreshold} = 0.5),
we use a dense representation for
- (1000 possible, 0 actual), or
- (2000 possible, 500 actual), or
- (3000 possible, 1000 actual).
Any fewer actual values, or any more
possible values, and Mondrian will use a sparse representation.
|
mondrian.rolap.SparseSegmentDensityThreshold |
double |
0.5 |
Property that, with {@link #SparseSegmentCountThreshold},
determines whether to choose a sparse or dense representation when
storing collections of cell values in memory.
|
mondrian.olap.SsasCompatibleNaming |
boolean |
false |
Property that defines
whether to enable new naming behavior.
If true, hierarchies are named [Dimension].[Hierarchy]; if false,
[Dimension.Hierarchy].
|
mondrian.statistics.providers |
string |
- |
Comma-separated list of classes to be used to get statistics about the
number of rows in a table, or the number of distinct values in a column.
If there is a value for mondrian.statistics.providers.DATABASE, where
DAtABASE is the current database name (e.g. MYSQL or ORACLE), then that
property overrides.
Example:
mondrian.statistics.providers=mondrian.spi.impl.JdbcStatisticsProvider
mondrian.statistics.providers.MYSQL=mondrian.spi.impl.JdbcStatisticsProvider,mondrian.spi.impl.JdbcStatisticsProvider
This would use JDBC's statistics (via the
java.sql.DatabaseMetaData.getIndexInfo method) for most
databases, but for connections to a MySQL database, would use
external statistics first, and fall back to JDBC statistics
only if external statistics were not available.
|
mondrian.test.highCardDimensions |
string |
- |
Property containing a list of dimensions in the Sales cube that should
be treated as high-cardinality dimensions by the testing infrastructure.
This allows us to run the full suite of tests with high-cardinality
functionality enabled.
|
mondrian.webapp.connectString |
string |
Provider=mondrian;Jdbc=jdbc:odbc:MondrianFoodMart;Catalog=/WEB-INF/queries/FoodMart.xml;JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver |
Connect string for the webapp. (Used by the webapp only.)
To achieve access control, append say ;Role='California
manager' to the connect string.
|
mondrian.webapp.deploy |
string |
- |
Where mondrian.war will be deployed to. (Used by mondrian's build.xml ant file only.)
Example: mondrian.webapp.deploy=C:/jboss-4.0.2/server/default/deploy
|
mondrian.xmla.SchemaRefreshInterval |
string |
3000ms |
Interval at which to refresh the
list of XML/A catalogs. (Usually known as the
datasources.xml file.)
It is not an active process; no threads will be created. It only
serves as a rate limiter. The refresh process is triggered by requests
to the doPost() servlet method.
Values may have time unit suffixes such as 's' (second) or 'ms'
(milliseconds). Default value is 3000 milliseconds (3 seconds).
Default time unit is milliseconds.
See also
{@link mondrian.xmla.impl.DynamicDatasourceXmlaServlet}.
|
Monitoring |
mondrian.server.monitor.executionHistorySize |
int |
1,000 |
Property that defines how many previous execution instances the
Monitor keeps in its history so that it can send the events
which happen after the fact. Setting this property too high will make the
JVM run out of memory. Setting it too low might prevent some events from
reaching the listeners of the monitor.
This property is for internal use only and should not be changed
unless required. Defaults to 1,000.
|
mondrian.util.memoryMonitor.enable |
boolean |
false |
Property that defines whether the MemoryMonitor should
be enabled. By default it is disabled; memory monitor is not available
before Java version 1.5.
|
mondrian.util.memoryMonitor.percentage.threshold |
int |
90 |
Property that defines the default MemoryMonitor
percentage threshold. If enabled, when Java's memory monitor detects
that post-garbage collection is above this value, notifications are
generated.
|
SQL generation |
mondrian.native.unsupported.alert |
string |
OFF |
Alerting action to take in case native evaluation of a function is
enabled but not supported for that function's usage in a particular
query. (No alert is ever raised in cases where native evaluation would
definitely have been wasted effort.)
Recognized actions:
OFF : do nothing (default action, also used if
unrecognized action is specified)
WARN : log a warning to RolapUtil logger
ERROR : throw an instance of
{@link NativeEvaluationUnsupportedException}
|
mondrian.rolap.groupingsets.enable |
boolean |
false |
Property that defines
whether to generate SQL queries using the GROUPING SETS
construct for rollup. By default it is not enabled.
Ignored on databases which do not support the
GROUPING SETS construct (see
{@link mondrian.spi.Dialect#supportsGroupingSets}).
|
mondrian.native.crossjoin.enable |
boolean |
true |
If enabled some NON EMPTY CrossJoin will be computed in SQL.
|
mondrian.native.filter.enable |
boolean |
true |
If enabled some Filter() will be computed in SQL.
|
mondrian.native.nonempty.enable |
boolean |
true |
If enabled some NON EMPTY set operations like member.children,
level.members and member descendants will be computed in SQL.
|
mondrian.native.topcount.enable |
boolean |
true |
If enabled some TopCount will be computed in SQL.
|
mondrian.native.ExpandNonNative |
boolean |
false |
If this property is true, when looking for native evaluation of an
expression, Mondrian will expand non-native sub-expressions into
lists of members.
|
mondrian.rolap.FilterChildlessSnowflakeMembers |
boolean |
true |
Property that defines
whether to generate joins to filter out members in a snowflake
dimension that do not have any children.
If true (the default), some queries to query members of high
levels snowflake dimensions will be more expensive. If false, and if
there are rows in an outer snowflake table that are not referenced by
a row in an inner snowflake table, then some queries will return members
that have no children.
Our recommendation, for best performance, is to remove rows outer
snowflake tables are not referenced by any row in an inner snowflake
table, during your ETL process, and to set this property to
{@code false}.
|
mondrian.rolap.generate.formatted.sql |
boolean |
false |
Boolean property that controls pretty-print mode.
If true, the all SqlQuery SQL strings will be generated in
pretty-print mode, formatted for ease of reading.
|
mondrian.rolap.maxConstraints |
int |
1,000 |
Max number of constraints in a single 'IN' SQL clause.
This value may be variant among database products and their runtime
settings. Oracle, for example, gives the error "ORA-01795: maximum
number of expressions in a list is 1000".
Recommended values:
- Oracle: 1,000
- DB2: 2,500
- Other: 10,000
|
Testing |
mondrian.catalogURL |
string |
- |
Property that contains the URL of the catalog to be used by
{@link mondrian.tui.CmdRunner} and XML/A Test.
|
mondrian.foodmart.jdbcURL |
string |
jdbc:odbc:MondrianFoodMart |
Property containing the JDBC URL of the FoodMart database.
The default value is to connect to an ODBC data source called
"MondrianFoodMart".
To run the test suite, first load the FoodMart data set into the
database of your choice. Then set the driver.classpath,
mondrian.foodmart.jdbcURL and mondrian.jdbcDrivers properties, by
un-commenting and modifying one of the sections below.
Put the JDBC driver jar into mondrian/testlib.
Here are example property settings for various databases.
Derby: needs user and password
mondrian.foodmart.jdbcURL=jdbc:derby:demo/derby/foodmart
mondrian.foodmart.jdbcUser=sa
mondrian.foodmart.jdbcPassword=sa
mondrian.jdbcDrivers=org.apache.derby.jdbc.EmbeddedDriver
driver.classpath=testlib/derby.jar
FireBirdSQL
mondrian.foodmart.jdbcURL=jdbc:firebirdsql:localhost/3050:/mondrian/foodmart.gdb
mondrian.jdbcDrivers=org.firebirdsql.jdbc.FBDriver
driver.classpath=/jdbc/fb/firebirdsql-full.jar
Greenplum (similar to Postgres)
mondrian.foodmart.jdbcURL=jdbc:postgresql://localhost/foodmart?user=gpadmin&password=xxxx
mondrian.foodmart.jdbcUser=foodmart
mondrian.foodmart.jdbcPassword=foodmart
mondrian.jdbcDrivers=org.postgresql.Driver
driver.classpath=lib/postgresql-8.2-504.jdbc3.jar
mondrian.foodmart.jdbcURL=jdbc:luciddb:http://localhost
mondrian.foodmart.jdbcUser=foodmart
mondrian.jdbcDrivers=org.luciddb.jdbc.LucidDbClientDriver
driver.classpath=/path/to/luciddb/plugin/LucidDbClient.jar
Oracle (needs user and password)
oracle.home=G:/oracle/product/10.1.0/Db_1
mondrian.foodmart.jdbcURL.oracle=jdbc:oracle:thin:@//host:port/service_name
mondrian.foodmart.jdbcURL=jdbc:oracle:thin:foodmart/foodmart@//stilton:1521/orcl
mondrian.foodmart.jdbcURL=jdbc:oracle:oci8:foodmart/foodmart@orcl
mondrian.foodmart.jdbcUser=FOODMART
mondrian.foodmart.jdbcPassword=oracle
mondrian.jdbcDrivers=oracle.jdbc.OracleDriver
driver.classpath=/home/jhyde/open/mondrian/lib/ojdbc14.jar
ODBC (Microsoft Access)
mondrian.foodmart.jdbcURL=jdbc:odbc:MondrianFoodMart
mondrian.jdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver
driver.classpath=
Hypersonic
mondrian.foodmart.jdbcURL=jdbc:hsqldb:demo/hsql/FoodMart
mondrian.jdbcDrivers=org.hsqldb.jdbcDriver
driver.classpath=xx
MySQL: can have user and password set in JDBC URL
mondrian.foodmart.jdbcURL=jdbc:mysql://localhost/foodmart?user=foodmart&password=foodmart
mondrian.foodmart.jdbcURL=jdbc:mysql://localhost/foodmart
mondrian.foodmart.jdbcUser=foodmart
mondrian.foodmart.jdbcPassword=foodmart
mondrian.jdbcDrivers=com.mysql.jdbc.Driver
driver.classpath=D:/mysql-connector-3.1.12
Infobright
As MySQL. (Infobright uses a MySQL driver, version 5.1 and later.)
Ingres
mondrian.foodmart.jdbcURL=jdbc:ingres://192.168.200.129:II7/MondrianFoodMart;LOOP=on;AUTO=multi;UID=ingres;PWD=sergni
mondrian.jdbcDrivers=com.ingres.jdbc.IngresDriver
driver.classpath=c:/ingres2006/ingres/lib/iijdbc.jar
Postgres: needs user and password
mondrian.foodmart.jdbcURL=jdbc:postgresql://localhost/FM3
mondrian.foodmart.jdbcUser=postgres
mondrian.foodmart.jdbcPassword=pgAdmin
mondrian.jdbcDrivers=org.postgresql.Driver
Neoview
mondrian.foodmart.jdbcURL=jdbc:hpt4jdbc://localhost:18650/:schema=PENTAHO;serverDataSource=PENTAHO_DataSource
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=com.hp.t4jdbc.HPT4Driver
driver.classpath=/some/path/hpt4jdbc.jar
Netezza: mimics Postgres
mondrian.foodmart.jdbcURL=jdbc:netezza://127.0.1.10/foodmart
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=org.netezza.Driver
driver.classpath=/some/path/nzjdbc.jar
Sybase
mondrian.foodmart.jdbcURL=jdbc:jtds:sybase://xxx.xxx.xxx.xxx:port/dbName
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=net.sourceforge.jtds.jdbc.Driver
driver.classpath=/some/path/jtds-1.2.jar
Teradata
mondrian.foodmart.jdbcURL=jdbc:teradata://DatabaseServerName/DATABASE=FoodMart
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=com.ncr.teradata.TeraDriver
driver.classpath=/some/path/terajdbc/classes/terajdbc4.jar
Vertica
mondrian.foodmart.jdbcURL=jdbc:vertica://xxx.xxx.xxx.xxx:port/dbName
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=com.vertica.Driver
driver.classpath=/some/path/vertica.jar
Vectorwise
mondrian.foodmart.jdbcURL=jdbc:ingres://xxx.xxx.xxx.xxxport/dbName
mondrian.foodmart.jdbcUser=user
mondrian.foodmart.jdbcPassword=password
mondrian.jdbcDrivers=com.ingres.jdbc.IngresDriver
driver.classpath=/some/path/iijdbc.jar
|
mondrian.test.Iterations |
int |
1 |
Not documented.
|
mondrian.test.QueryFileDirectory |
string |
- |
Property defining
where the test XML files are.
|
mondrian.test.QueryFilePattern |
string |
- |
Property that defines
a pattern for which test XML files to run. Pattern has to
match a file name of the form:
querywhatever.xml in the directory.
Example:
mondrian.test.QueryFilePattern=queryTest_fec[A-Za-z0-9_]*.xml
|
mondrian.test.Class |
string |
- |
String property that determines which test class to run.
This is the name of the class. It must either implement
{@code junit.framework.Test} or have a method
{@code public [static] junit.framework.Test suite()}.
Example:
mondrian.test.Class=mondrian.test.FoodMartTestCase
@see #TestName
|
mondrian.test.connectString |
string |
- |
Property containing the connect string which regression tests should
use to connect to the database.
Format is specified in {@link Util#parseConnectString(String)}.
|
mondrian.test.ExpDependencies |
int |
0 |
Integer property that controls whether to test operators'
dependencies, and how much time to spend doing it.
If this property is positive, Mondrian's test framework allocates an
expression evaluator which evaluates each expression several times, and
makes sure that the results of the expression are independent of
dimensions which the expression claims to be independent of.
The default is 0.
|
mondrian.foodmart.jdbcPassword |
string |
- |
Property containing the JDBC password of a test database.
The default value is null, to cope with DBMSs that don't need this.
|
mondrian.foodmart.jdbcUser |
string |
- |
Property containing the JDBC user of a test database.
The default value is null, to cope with DBMSs that don't need this.
|
mondrian.test.Name |
string |
- |
String property that determines which tests are run.
This is a regular expression as defined by
{@link java.util.regex.Pattern}.
If this property is specified, only tests whose names match the pattern
in its entirety will be run.
@see #TestClass
|
mondrian.test.random.seed |
int |
1,234 |
Seed for random number generator used by some of the tests.
Any value besides 0 or -1 gives deterministic behavior.
The default value is 1234: most users should use this.
Setting the seed to a different value can increase coverage, and
therefore may uncover new bugs.
If you set the value to 0, the system will generate its own
pseudo-random seed.
If you set the value to -1, Mondrian uses the next seed from an
internal random-number generator. This is a little more deterministic
than setting the value to 0.
|
mondrian.test.TimeLimit |
int |
0 |
Property that returns the time limit for the test run in seconds.
If the test is running after that time, it is terminated.
|
mondrian.test.VUsers |
int |
1 |
Not documented.
|
mondrian.test.Warmup |
boolean |
false |
Property that indicates whether this is a "warmup test".
|
mondrian.test.WarnIfNoPatternForDialect |
string |
NONE |
Property that controls whether warning messages should be printed if a SQL
comparison test does not contain expected SQL statements for the specified
dialect. The tests are skipped if no expected SQL statements are
found for the current dialect.
Possible values are the following:
- "NONE": no warning (default)
- "ANY": any dialect
- "ACCESS"
- "DERBY"
- "LUCIDDB"
- "MYSQL"
- ... and any Dialect enum in SqlPattern.Dialect
Specific tests can overwrite the default setting. The priority is:
- Settings besides "ANY" in mondrian.properties file
- < Any setting in the test
- < "ANY"
|
XML/A |
mondrian.xmla.drillthroughTotalCount.enable |
boolean |
true |
If enabled, first row in the result of an XML/A drill-through request
will be filled with the total count of rows in underlying database.
|
mondrian.xmla.drillthroughMaxRows |
int |
1,000 |
Property that defines
limit on the number of rows returned by XML/A drill through request.
|
Limit properties
Properties mondrian.result.limit
, mondrian.rolap.iterationLimit
and mondrian.rolap.queryTimeout
enforce runtime limits on the
time or space required to execute a query. If any of these limits are exceeded,
mondrian throws an exception which extends
mondrian.olap.ResultLimitExceededException.
Connect strings
Connect string syntax
Mondrian connect strings are a connection of property/value pairs, of the
form 'property=value;property=value;...'.
Values can be enclosed in single-quotes, which allows them to contain spaces
and punctuation. See the the
OLE DB connect string syntax specification.
The supported properties are described below.
Connect string properties
Name |
Required? |
Description |
Provider |
Yes |
Must have the value "Mondrian". |
Jdbc |
Exactly one |
The URL of the JDBC database where the data is stored. You must
specify either DataSource or Jdbc . |
DataSource |
The name of a data source loaded via JNDI. The name must be a valid JNDI name, and the object referenced must implement the
javax.sql.DataSource interface.
You must specify either
DataSource or Jdbc . |
JdbcDrivers |
Yes |
Comma-separated list of JDBC driver classes, for example,
JdbcDrivers=sun.jdbc.odbc.JdbcOdbcDriver,oracle.jdbc.OracleDriver
|
JdbcUser |
No |
The name of the user to log on to the JDBC database. (If your JDBC
driver allows you to specify the user name in the JDBC URL, you don't
need to set this property.) |
JdbcPassword |
No |
The name of the password to log on to the JDBC database. (If your
JDBC driver allows you to specify the password in the JDBC URL, you
don't need to set this property.) |
Catalog |
Exactly one |
The URL of the catalog, an XML file which describes the schema: cubes, hierarchies, and so forth.
For example,
Catalog=file:demo/FoodMart.xml
Catalogs are described in the Schema Guide.
See also CatalogContent . |
CatalogContent |
An XML string representing the schema: cubes, hierarchies, and so forth.
For example,
CatalogContent=<Schema name="MySchema"><Cube name="Cube1"> ...
</Schema>
Catalogs are described in the Schema Guide.
See also Catalog . |
CatalogName |
No |
Not used. If, in future, Mondrian supports multiple catalogs, this property
will specify which catalog to use. See also Catalog . |
PoolNeeded |
No |
Tells Mondrian whether to add a layer of connection pooling.
If the value "true" is specified, or no value is specified, Mondrian
assumes that:
- connections created via the
Jdbc property are not pooled,
and therefore need to be pooled;
- connections created via the
DataSource are already pooled.
If the value "false" is specified, Mondrian does not apply
connection-pooling to any connection. |
Role |
No |
The name of the role to adopt
for access-control purposes. If not specified, the connection uses a role
which has access to every object in the schema.
This property can contain multiple role names separated by commas. If
so, queries in the connection execute with the sum of the privileges of
all of the rules; the effect is the same as running under a
union role, defined using the
<Union> element in the schema file.
If a role name contains a comma, escape the comma using an extra
comma. For example, a connection created with
Role='Pacific region manager,Europe,, Middle East and
Africa manager'
will execute with the combined privileges of the roles "Pacific
region manager", and "Europe, Middle East and Africa manager". |
jdbc.* |
No |
Any property whose name begins with "jdbc." will be added to the JDBC
connection properties, after removing this prefix. This allows you to specify connection
properties without a URL.
For example, given the properties
jdbc.Timeout=50; jdbc.CacheSize=1m
Mondrian will create a JDBC connection using the properties
{Timeout="50", CacheSize="1m"}. |
UseContentChecksum |
No |
Allows mondrian to work with dynamically changing schema. If this property
is set to true and schema content has changed (previous
checksum doesn't equal with current), schema would be reloaded.
The default is false .
Could be
used in combination with DynamicSchemaProcessor property. |
UseSchemaPool |
No |
Controls whether a new connection use a schema from the schema
cache. If true , the default, a connection shares a schema
definition (and hence also a cache of aggregate data retrieved by
previous queries) with other connections which have a textually
identical schema definition.
If false , the connection has a private schema definition
and cache. |
DynamicSchemaProcessor |
No |
The name of a class which is called at runtime in order to modify
the schema content. The class must implement the
mondrian.spi.DynamicSchemaProcessor interface. For example,
DynamicSchemaProcessor =
mondrian.i18n.LocalizingDynamicSchemaProcessor
uses the builtin schema processor class
mondrian.i18n.LocalizingDynamicSchemaProcessor to replace variables
in the schema file, according to resource files and the current locale
(see the Locale property). |
Locale |
No |
The requested Locale for the current session. The locale determines
the formatting of numbers and date/time values, and Mondrian's error
messages.
Example values are "en" (English), "en_US"
(United States English), "hu" (Hungarian). If Locale is not specified, then the name of system's default will be used, as per
java.util.Locale#getDefault(). |
JdbcConnectionUuid |
No |
A unique identifier for the connection. If this is set, Mondrian will look at this property and no other to determine whether two
data sources should be considered the same. You must ensure that connections will only share a JdbcConnectionUuid if they point to the same database. |
Connect string properties are also documented in the
RolapConnectionProperties class.
Cache management
Schema cache
To flush all schema definitions, use
the mondrian.olap.CacheControl.flushSchemaCache()
method:
import mondrian.olap.*;
Connection connection;
CacheControl cacheControl = connection.getCacheControl(null);
cacheControl.flushSchemaCache();
The cache is only used when creating new connections; existing connections
retain their schemas.
There are four connect string properties that control the use of the
Schema cache:
UseSchemaPool
,
UseContentChecksum
,
CatalogContent
and
DynamicSchemaProcessor
.
The UseSchemaPool
property controls whether or not the cache is used
regardless of the values of any of the other properties. If UseSchemaPool
is "false", then the cache is not used; each request for a new schema
object creates a new one (entailing the re-parsing of the schema definition
and re-scanning of the database for meta data and aggregate tables -
very slow, and, in addition, there is no reuse of the in-memory aggregate
cache).
Next, if UseContentChecksum
is "true", then a check sum (MD5) is created
from the schema definition content (not URL) and it is this check sum
that is used as the key to lookup previously cached versions of the
schema definition. If two schema definitions produce different check
sums, then one can safely assume that they are different schemas (of course,
it is possible that only a comment or some whitespace in the schema
definition changed in which case the two schemas would actually be the
same, but because their check sums are different, different schema
objects are used). If UseContentChecksum is "false", then no check sum
is created and used as the lookup key, rather, a combination of
the connection attributes
"catalogUrl",
"connectionKey",
"jdbcUser",
"dataSourceStr"
or
"catalogUrl",
"dataSource"
are used to create the key.
If the CatalogContent
is specified, then it is used as the schema
definition content. If, in fact, it is specified, then the value of
DynamicSchemaProcessor, if any, is ignored.
Finally, the DynamicSchemaProcessor
connection string property is the
class name of a class that implements the DynamicSchemaProcessor
interface. If set, an instance of the class is created for each
schema request and its "processSchema" method is called which
returns the schema definition content.
Memory management
Out Of Memory
Java OutOfMemoryError
errors have always been an issue with
applications. When the JVM throws an Error
as
opposed to an Exception
it is telling the application
that its world has ended and it has no recourse but to die.
Prior to Java5 there was not much one could do other
than buy 64-bit machines with lots of RAM and hope for the best.
For a multi-user, Mondrian environment with potentially very large
data-sets and clients that
can generate queries requesting arbitrarily large amounts of that
data, this can be an issue. This is especially the case when
Mondrian is being hosted on some corporate web-server; applications
that kill web-servers are not looked upon favorably by IT.
With Java5 (and Java6, etc.) there is alternative. An application
cay take advantage of
a new feature in Java5 allowing the application to be notified when
memory starts running low. This allows the application to take
preemptive action prior to an OutOfMemoryError
being
generated by the Java runtime.
Mondrian takes advantage of this new feature. Rather than
passing an OutOfMemoryError
to its client, it
will now stop processing the present query, free up data structures
associated with the present query and return a
MemoryLimitExceededException
to the client.
The MemoryLimitExceededException
is one of Mondrian's
ResultLimitExceededException
which are used to communicate
with clients that a limit has been exceeded, in this case, memory
usage.
By default, for Mondrian running under Java5, this feature is
enabled and the "safety limit" is set at 90 percent, when
memory usage gets to with 90 percent of the maximum possible, the
the processing of the current query is stopped and a
MemoryLimitExceededException
is return to the client.
See the Memory monitoring properties above on this page
for additional information.
Lastly, the gorilla in the closet. Java5 in its wisdom only allows
for one memory threshold notification level to be registered with the JVM.
What this means is if within the same JVM, some code registers
one level, say, at 80% (here I use percentages for ease of presentation
rather than number of
bytes which is what the Java5 API actually supports)
and some other code later on registers a level of
90%, then it is the 90% that the JVM knows about - it knows nothing
of the previously registered 80%. What this means is that the code
expecting to be notified when the memory level crosses 80%, won't be notified!
For many applications that don't share their JVM with
other applications, this is not a problem, but for Mondrian is it
potentially an issue. Mondrian can be running in a Webserver and
Webservers can have more than one independent applications.
Each such application can register a different memory threshold
notification level.
In general, application-containing applications such as
web-servers or application-servers are a problem with the current
Java5 memory threshold notification approach.
At the current time, I do not know a way around this problem.
Logging
Mondrian uses log4j for all information and debug logging. When running
within an application server, Mondrian's log4j configuration is determined by
the server's or web application's log4j configuration. Please see
log4j's documentation
for a additional details.
Configuring log4j within Mondrian's test environment
When running outside an application server, log4j determines the location
of the log4j.xml file via the log4j.configuration java system property. log4j
treats this string as a URL, so to have it detect the log4j file on the file
system, you must use the syntax "file:DIR/log4j.xml". Relative paths are
acceptible, so if you have your log4j.xml file in the root directory of
mondrian, "file:log4j.xml" will load the correct file. You may specify the
log4j.configuration property in mondrian.properties, because Mondrian's ant
build file explicitly sets the property as a JVM system property when running
JUnit tests.
MDX and SQL Statement Logging
The default log4j.xml file is configured so that a separate log file is
created for both MDX and SQL statement logging. In the code, the MDX and SQL
strings are logged at the debug level, so to disable them you can set the log
level to INFO or any other level above debug. Statement logging occurs within
the log4j categories "mondrian.mdx" and "mondrian.sql". These categories log
the statements and how long they took to execute. The SQL log also records the
number of results returned in the result set.
For example, to trace both MDX and SQL statements, create a file
log4j.properties
in the directory where you started mondrian
with the following contents:
# Set root logger level to DEBUG and its only appender to MONDRIAN.
log4j.rootLogger=WARN, MONDRIAN
# MONDRIAN is set to be a ConsoleAppender.
log4j.appender.MONDRIAN=org.apache.log4j.ConsoleAppender
# MONDRIAN uses PatternLayout.
log4j.appender.MONDRIAN.layout=org.apache.log4j.PatternLayout
log4j.appender.MONDRIAN.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
# Trace MDX and SQL statements
log4j.category.mondrian.mdx=DEBUG, MONDRIAN
log4j.category.mondrian.sql=DEBUG, MONDRIAN
Then mondrian with the argument
-Dlog4j.configuration=file:log4j.properties
on the Java command
line.
Consider setting the property
mondrian.rolap.generate.formatted.sql=true
in
mondrian.properties
to make the format more
readable.
Author: Julian Hyde; last modified April, 2011.
Version: $Id$
(log)
Copyright (C) 2006-2011 Pentaho