Configuration File Settings

F Configuration File Settings

This appendix lists key configuration files for Oracle Analytics and provides details about parameters in the NQSConfig.INI file.

Topics:

Configuration Files

Configuration files control the behavior of the system.

The following table lists key configuration files for Oracle Analytics and their locations. See What Are Diagnostic Log Configuration Files and Where Are They Located?.

BI Component	Configuration File	File Location
Oracle BI Server	NQSConfig.INI logconfig.xml	For example: `BI_DOMAIN/config/fmwconfig/biconfig/OBIS`
Oracle BI Presentation Services	instanceconfig.xml credentialstore.xml marketingwebexpressions.xml userpref_currencies.xml	For example: `BI_DOMAIN/config/fmwconfig/biconfig/OBIPS` Don't add elements to the `instanceconfig.xml` file unless you're overriding the stated default values. Override only those settings that are necessary for configuring the system to meet the needs of your organization.
Cluster Controller	bi-cluster-config.xml ccslogconfig.xml	For example: `BI_DOMAIN/config/fmwconfig/biconfig/OBICCS`
Oracle BI Scheduler	schedulerconfig.xml	For example: `BI_DOMAIN/config/fmwconfig/biconfig/OBISCH`
JavaHost	config.xml logging-config.xml	For example: `BI_DOMAIN/config/fmwconfig/biconfig/OBIJH`
Presentation Services Plug-in	bridgeconfig.properties	For example: `BI_DOMAIN/config/fmwconfig/biconfig`
Oracle BI Environment	bi-environment.xml odbc.ini obis.properties	For example: `BI_DOMAIN/config/fmwconfig/bienv/core` `bi-environment.xml` contains environment configuration settings (separate from process command-specific parameters), for example: Data directory (SDD) - path to a singleton directory (for high availability purposes). By default, SDD = $DOMAIN_HOME/bidata. It's required that the SDD is mounted to the same point for all machines in a scaled-out system. Mixed mode (where some components use the SDD, and some don't), isn't allowed. See Key Directories. Runtime compatibility flag. Hardware acceleration flag. Port ranges. SSL External/Internal Certificate Authorities (CA) and certificate paths. Although the internal certificates DNs are not verified (and thus don't display hostname), it may be required to change these during cloning operations. `odbc.ini` contains the single source of truth for ODBC connection endpoints: Where the endpoint is internal (for example, BIEE cluster controller or Essbase), then the drivers (or clients of the drivers) must use the endpoint API to recover the appropriate endpoint. Where the endpoint is external to the system, then this file might change if the domain is copied or moved. OPSS and BIPLATFORM DSNs are provided in odbc.ini. The credentials for BIPLATFORM DSN is in the OPSS Credential Store. `obis.properties` contains BI Server-specific environment and configuration settings that are substituted with specified values, and is located in: `BI_DOMAIN/config/fmwconfig/bienv/OBIS`

NQSConfig.INI File Configuration Settings

This section lists the NQSConfig.INI file parameters for Oracle Analytics Server and gives a brief description and any required syntax for each parameter. The Oracle Analytics Server software uses an initialization file called NQSConfig.INI to set parameters upon startup. This initialization file includes parameters to customize behavior based on the requirements of each individual installation. The parameters are generally listed in the order in which they appear in the configuration file.

Note:

The examples in this section assume that you're editing a Windows version of NQSConfig.INI. If you're editing this file on a LINUX system, then ensure that you use LINUX-appropriate file system paths and conventions.

This topic includes the following sections:

About Parameters in the NQSConfig.INI File

Oracle Analytics Server has one NQSConfig.INI file.

Note the following rules and guidelines for NQSConfig.INI file entries:

Oracle Analytics Server reads the NQSConfig.INI file each time it starts.
Each parameter entry in NQSConfig.INI must be within the section to which the parameter belongs (Repository, Cache, General, and so on).
Each entry must be terminated with a semicolon ( ; ).
You can add comments anywhere in the NQSConfig.INI file. Comments must begin with either of the following:

#

//

Any text following these comment characters up to the end of the line is ignored when Oracle Analytics Server reads the file.
For parameters that require a setting in bytes, you can specify the value in either bytes, KB, MB, or GB. If you omit the size qualifier, then the value is interpreted as the number of bytes. If you include the size qualifier, then ensure that you include a space before the qualifier. The following are examples of valid values:
```
MAX_QUERY_PLAN_CACHE_ENTRY_SIZE = 1 MB;
MAX_QUERY_PLAN_CACHE_ENTRY_SIZE = 1024 KB;
MAX_QUERY_PLAN_CACHE_ENTRY_SIZE = 1048576;
```
Any syntax errors prevent the Oracle Analytics Server from starting. The errors are logged to the obis1-diagnostic.log file, which is located in BI_DOMAIN/servers/obis1/logs

There might also be a summary message in the system log that relates to the error.

If you get an error, then correct the problem and start the Oracle Analytics Server again. Repeat this process until the server starts with no errors.

How to Update Parameters in NQSConfig.INI

The following procedure explains how to update parameters in NQSConfig.INI.

To update parameters in NQSConfig.INI:

Open the NQSConfig.INI file in a text editor. You can find this file at:

BI_DOMAIN/config/fmwconfig/biconfig/OBIS

Make a backup copy of the file before editing.
Locate and update the parameter you want to change.
Save and close the file.
Restart the Oracle BI Server.

See About Managing Processes.

Repository Section Parameters

The Repository section contains one entry for every repository that's loaded when the server starts.

Note:

Hosting multiple repositories on a single Oracle BI Server isn't recommended for production systems.

Syntax: logical_name = repository_name.rpd;

Optional syntax: logical_name = repository_name.rpd, DEFAULT;

In this syntax:

logical_name: A logical name for the repository. Client tools use this name to configure the ODBC data sources that connect to the repository. To use a reserved keyword for the name, such as OCI7 or OCI8, enclose it in single quotation marks.
repository_name.rpd: The file name of the repository. The file name must have the .rpd file extension, and the file must reside in the repository subdirectory.

The demonstration repository SampleAppLite.rpd is installed when selected at install time with Oracle Analytics Server.

When DEFAULT is specified for a repository, connections that don't specify a logical repository name in the DSN connect to the default repository.

Example: Star = SampleAppLite.rpd, DEFAULT;

Multitenancy Section Parameters

The parameters in the Multitenancy Section provide support for a configuration that includes multiple tenants. The parameters in this section are reserved for future use.

MT_ROOT_DIRECTORY

This parameter is reserved for future use.

Example: MT_ROOT_DIRECTORY= "";

MT_ENTRIES

This parameter is reserved for future use.

Example: MT_ENTRIES= ;

Query Result Cache Section Parameters

The parameters in the Query Result Cache Section provide configuration information for Oracle BI Server caching.

The query cache is enabled by default. After deciding on a strategy for flushing outdated entries, configure the cache storage parameters in Fusion Middleware Control and in the NQSConfig.INI file.

Note that query caching is primarily a runtime performance improvement capability. As the system is used over a period of time, performance tends to improve due to cache hits on previously run queries. The most effective and pervasive way to optimize query performance is to use the Aggregate Persistence wizard and aggregate navigation.

This section describes only the parameters that control query caching. For information about how to use caching in Oracle Analytics Server, including information about how to use agents to seed the Oracle BI Server cache, see Manage Performance Tuning and Query Caching.

ENABLE

Note:

The ENABLE parameter can be managed by Fusion Middleware Control or by manually editing NQSConfig.INI.

The Cache enabled option on the Performance tab of the Configuration page in Fusion Middleware Control corresponds to the ENABLE parameter. See Use Fusion Middleware Control to Enable and Disable Query Caching.

Specifies whether the cache system is enabled. When set to NO, caching is disabled. When set to YES, caching is enabled. The query cache is enabled by default.

Example: ENABLE = YES;

DATA_STORAGE_PATHS

Specifies one or more paths for where the cached query results data is stored and are accessed when a cache hit occurs and the maximum capacity in bytes, kilobytes, megabytes, or gigabytes.

The maximum capacity for each path is 4 GB. For optimal performance, specify the paths on high-performance storage systems.

Each path listed must be an existing, writable path name, with double quotation marks ( " ) surrounding the path name. Specify mapped directories only. UNC path names and network mapped drives are enabled only if the service runs under a qualified user account.

You can specify either fully qualified paths, or relative paths. When you specify a path that doesn't start with "/" (on Linux) or "<drive>:" (on Windows), the Oracle BI Server assumes that the path is relative to the local writable directory. For example, if you specify the path "cache," then at runtime, the Oracle BI Server uses the following:

BI_DOMAIN/servers/obisn/cache

Note:

Multiple Oracle BI Servers across a cluster don't share cached data. Therefore, the DATA_STORAGE_PATHS entry must be unique for each clustered server. To ensure this unique entry, enter a relative path so that the cache is stored in the local writable directory for each Oracle BI Server, or enter different fully qualified paths for each server.

Specify multiple directories with a comma-delimited list. When you specify multiple directories, ensure that they reside on different physical drives. If you have multiple cache directory paths that all resolve to the same physical disk, then both available and used space might be double-counted. When you specify multiple directories, ensure that the directory names aren't subsets of each other. For example, use names such as cache1 and cache2 rather than cache and cache2.

Syntax: DATA_STORAGE_PATHS = "path_1" sz[, "path_2" sz{, "path_n" sz}];

Example: DATA_STORAGE_PATHS = "cache" 256 MB;

Note:

Specifying multiple directories for each drive does not improve performance, because file input and output (I/O) occurs through the same I/O controller. In general, specify only one directory for each disk drive. Specifying multiple directories on different drives might improve the overall I/O throughput of the Oracle BI Server internally by distributing I/O across multiple devices.

The disk space requirement for the cached data depends on the number of queries that produce cached entries, and the size of the result sets for those queries. The query result set size is calculated as row size (or the sum of the maximum lengths of all columns in the result set) times the result set cardinality (that is, the number of rows in the result set). The expected maximum is the guideline for the space needed.

This calculation gives the high-end estimate, not the average size of all records in the cached result set. Therefore, if the size of a result set is dominated by variable length character strings, and if the length of those strings is distributed normally, you would expect the average record size to be about half the maximum record size.

Note:

It is a best practice to use values less than 4 GB on your 64-bit system. Create multiple paths if you've values in excess of 4 GB.

MAX_ROWS_PER_CACHE_ENTRY

Specifies the maximum number of rows in a query result set to qualify for storage in the query cache.

Limiting the number of rows is a useful way to avoid consuming the cache space with runaway queries that return large numbers of rows. If the number of rows a query returns is greater than the value specified in the MAX_ROWS_PER_CACHE_ENTRY parameter, then the query isn't cached.

When set to 0, there's no limit to the number of rows per cache entry.

Example: MAX_ROWS_PER_CACHE_ENTRY = 100000;

MAX_CACHE_ENTRY_SIZE

The MAX_CACHE_ENTRY_SIZE parameter can be managed by either Fusion Middleware Control or by editing NQSConfig.INI.

Note:

The Maximum cache entry size option on the Performance tab of the Configuration page in Fusion Middleware Control corresponds to the MAX_CACHE_ENTRY_SIZE parameter. See Use Fusion Middleware Control to Set Query Cache Parameters.

Specifies the maximum size for a cache entry. Potential entries that exceed this size are not cached. The default size is 20 MB.

Specify GB for gigabytes, KB for kilobytes, MB for megabytes, and no units for bytes.

Example: MAX_CACHE_ENTRY_SIZE = 20 MB;

MAX_CACHE_ENTRIES

The Maximum cache entries option on the Performance tab of the Configuration page in Fusion Middleware Control corresponds to the MAX_CACHE_ENTRIES parameter.

Note:

The MAX_CACHE_ENTRIES parameter can be managed by either Fusion Middleware Control or by editing NQSConfig.INI.

See Use Fusion Middleware Control to Set Query Cache Parameters.

Specifies the maximum number of cache entries allowed in the query cache to help manage cache storage. The actual limit of cache entries might vary slightly depending on the number of concurrent queries. The default value is 1000.

Example: MAX_CACHE_ENTRIES = 1000;

POPULATE_AGGREGATE_ROLLUP_HITS

Specifies whether to aggregate data from an earlier cached query result set and create a new entry in the query cache for rollup cache hits. The default value is NO.

Typically, if a query gets a cache hit from a previously run query, then the new query isn't added to the cache. A user might have a cached result set that contains information at a particular level of detail (for example, sales revenue by ZIP code). A second query might ask for this same information, but at a higher level of detail (for example, sales revenue by state). The POPULATE_AGGREGATE_ROLLUP_HITS parameter overrides this default when the cache hit occurs by rolling up an aggregate from a previously run query (in this example, by aggregating data from the first result set stored in the cache). That is, Oracle Analytics Server sales revenue for all ZIP codes in a particular state can be added to obtain the sales revenue by state. This is referred to as a rollup cache hit.

Normally, a new cache entry isn't created for queries that result in cache hits. You can override this behavior specifically for cache rollup hits by setting POPULATE_AGGREGATE_ROLLUP_HITS to YES. Nonrollup cache hits aren't affected by this parameter. If a query result is satisfied by the cache—that is, the query gets a cache hit—then this query isn't added to the cache. When this parameter is set to YES, then when a query gets an aggregate rollup hit, then the result is put into the cache. Setting this parameter to YES might result in better performance, but results in more entries being added to the cache.

Example: POPULATE_AGGREGATE_ROLLUP_HITS = NO;

USE_ADVANCED_HIT_DETECTION

When caching is enabled, each query is evaluated to determine whether it qualifies for a cache hit.

A cache hit means that the server was able to use cache to answer the query and didn't go to the database at all. The Oracle BI Server can use query cache to answer queries at the same or later level of aggregation.

The parameter USE_ADVANCED_HIT_DETECTION enables an expanded search of the cache for hits. The expanded search has a performance impact, which isn't easily quantified because of variable customer requirements. Customers that rely heavily on query caching and are experiencing misses might want to test the trade-off between better query matching and overall performance for high user loads. Refer to the parameter MAX_SUBEXPR_SEARCH_DEPTH for related information.

Example: USE_ADVANCED_HIT_DETECTION = NO;

Reasons Why a Query Is Not Added to the Cache

Customers who rely on query result caching in the Oracle BI Server to meet their performance KPIs can use caching parameters to help determine why a cache hit didn't occur.

Logging facilities can help diagnose common reasons for getting a cache miss, where the logical SQL query that was supposed to seed the cache didn't get inserted into the cache. The following describes some situations when this might occur.

Noncacheable SQL element. If a SQL request contains CURRENT_TIMESTAMP, CURRENT_TIME, RAND, POPULATE, or a parameter marker, then it's not added to the cache.
Noncacheable table. Physical tables in the Oracle BI Server repository can be marked "noncacheable." If a query references any noncacheable table, then the query results aren't added to the cache.
Cache hit. In general, if the query gets a cache hit on a previously cached query, then the results of the current query aren't added to the cache.

The exception is query hits that are aggregate rollup hits. These are added to the cache if the NQSConfig.INI parameter POPULATE_AGGREGATE_ROLLUP_HITS has been set to YES.
Result set is too big.

This situation occurs when you exceed the size set in DATA_STORAGE_PATHS, or if you have rows in excess of the number set in MAX_ROWS_PER_CACHE_ENTRY. See DATA_STORAGE_PATHS and MAX_ROWS_PER_CACHE_ENTRY.
Query is cancelled. This can happen by explicit cancellation from Oracle BI Presentation Services or the Administration Tool, or implicitly through timeout.
Oracle BI Server is clustered. Queries that fall into the 'cache seeding' family are propagated throughout the cluster. Other queries continue to be stored locally. Therefore, even though a query might be put into the cache on Oracle BI Server node 1, it might not be on Oracle BI Server node 2.

Level 4 of query logging is the best tool to diagnose whether the Oracle BI Server compiler intended to add the entry into the query result cache. See Configure Query Logging.

MAX_SUBEXPR_SEARCH_DEPTH

Lets you configure how deep the hit detector looks for an inexact match in an expression of a query. The default is 5.

For example, at level 5, a query on the expression SIN(COS(TAN(ABS(ROUND(TRUNC(profit)))))) misses on profit, which is at level 7. Changing the search depth to 7 opens up profit for a potential hit.

Example: MAX_SUBEXPR_SEARCH_DEPTH = 7;

DISABLE_SUBREQUEST_CACHING

When set to YES, disables caching at the subrequest (subquery) level.

The default value is NO.

Caching subrequests improves performance and the cache hit ratio, especially for queries that combine real-time and historical data. In some cases, however, you might disable subrequest caching, such as when other methods of query optimization provide better performance.

Example: DISABLE_SUBREQUEST_CACHING = NO;

CACHE_FILE_BUFFER_SIZE

Specifies the amount of memory used to temporarily store the cache file when writing to the disk.

The default value is 128 KB.

Example: CACHE_FILE_BUFFER_SIZE = 128;

GLOBAL_CACHE_STORAGE_PATH

The GLOBAL_CACHE_STORAGE_PATH parameter can be managed by Fusion Middleware Control or by editing NQSConfig.INI.

Note:

The Global cache path and Global cache size options on the Performance tab of the Configuration page in Fusion Middleware Control correspond to the GLOBAL_CACHE_STORAGE_PATH parameter. See Use Fusion Middleware Control to Set Global Cache Parameters.

In a clustered environment, Oracle BI Servers can be configured to access a shared cache that is referred to as the global cache. The global cache resides on a shared file system storage device and stores seeding and purging events and the result sets that are associated with the seeding events.

This parameter specifies the physical location for storing cache entries shared across clustering. This path must point to a network share. All clustering nodes share the same location.

You can specify the size in KB, MB, or GB, or enter a number with no suffix to specify bytes.

Syntax: GLOBAL_CACHE_STORAGE_PATH = "directory name" SIZE;

Example: GLOBAL_CACHE_STORAGE_PATH = "C:\cache" 250 MB;

MAX_GLOBAL_CACHE_ENTRIES

The maximum number of cache entries stored in the location that is specified by GLOBAL_CACHE_STORAGE_PATH.

Example: MAX_GLOBAL_CACHE_ENTRIES = 1000;

CACHE_POLL_SECONDS

The interval in seconds that each node polls from the shared location that is specified in GLOBAL_CACHE_STORAGE_PATH.

Example: CACHE_POLL_SECONDS = 300;

CLUSTER_AWARE_CACHE_LOGGING

Turns on logging for the cluster caching feature.

Used only for troubleshooting. The default is NO.

Example: CLUSTER_AWARE_CACHE_LOGGING = NO;

General Section Parameters

The General section contains general server default parameters, including localization and internationalization, temporary space and memory allocation, and other default parameters used to determine how data is returned from the Oracle BI Server to a client.

Note:

The settings for the parameters LOCALE, SORT_ORDER_LOCALE, SORT_TYPE and CASE_SENSITIVE_CHARACTER_COMPARISON, described in the following topics, are interrelated. They help determine how the Oracle BI Server sorts data.

LOCALE

Specifies the locale in which data is returned from the server. This parameter also determines the localized names of days and months.

To successfully run Oracle Analytics Server, ensure that you configure the appropriate locales on the operating system for the language in which you run the applications. In some cases, you might install additional content on the system to support the locale. The Oracle BI Server sets the C-runtime locale during the server startup. Some locale- and language-related settings are interrelated and help determine how the Oracle BI Server sorts data. Ensure that the settings for the following parameters work together:

LOCALE
SORT_ORDER_LOCALE
SORT_TYPE
CASE_SENSITIVE_CHARACTER_COMPARISON

Valid platform-independent values for LOCALE and SORT_ORDER_LOCALE are:

Arabic
Chinese
Chinese-traditional
Croatian
Czech
Danish
Dutch
English-USA
Finnish
French
German
Greek
Hebrew
Hungarian
Italian
Japanese
Korean
Norwegian
Polish
Portuguese
Portuguese-Brazilian
Romanian
Russian
Slovak
Spanish
Swedish
Thai
Turkish

For information about Catalog Manager and language extensions, see Localize Oracle Analytics Server.

SORT_ORDER_LOCALE

Used to help determine whether the Oracle BI Server can function-ship (push down) an ORDER BY clause to a relational database.

ORDER BY clauses are used in sorting.

Every database that's defined in the Physical layer in the Administration Tool has a features table associated with it. If you want to override the default value in the Features table for a particular type of relational database, then you must do so for all occurrences of it in the Physical layer.

In the Administration Tool, the Features table in the Features tab of the Database dialog specifies the features and functions that the relational database supports. The settings for SORT_ORDER_LOCALE in the Features table and in the NQSConfig.INI file match only if the database and the Oracle BI Server sort data in the same way.

For the relational database and the Oracle BI Server to sort data the same way, they must be in agreement on the parameters that are shown in the following table.

Functional Category	Specific Parameters
Base language	`LOCALE`
Base language	`SORT_ORDER_LOCALE` The default value for `SORT_ORDER_LOCALE` in both the Features table and in the NQSConfig.INI file is `english-usa`. If the Oracle BI Server and the database sort data differently, then the Features table entry `SORT_ORDER_LOCALE` for the database must be set to a different value than `english-usa`. Otherwise, the different data sort methods clash. The `LOCALE` and `SORT_ORDER_LOCALE` parameters accept platform-independent names only. See the list provided in LOCALE for details.
Case	`CASE_SENSITIVE_CHARACTER_COMPARISON`
Binary versus linguistic comparison	`SORT_TYPE`

If the SORT_ORDER_LOCALE setting in the actual data source doesn't match the SORT_ORDER_LOCALE setting in the Features tab of the Database dialog in the metadata repository, then result sets might not be correct. If the settings don't match, then incorrect answers can result when using multi-database joins, or errors can result when using the Union, Intersect, and Except operators, which all rely on consistent sorting between the back-end data source and the Oracle BI Server.

If the SORT_ORDER_LOCALE setting in NQSConfig.INI doesn't match the SORT_ORDER_LOCALE setting in the Features tab of the Database dialog in the Oracle BI repository, then query performance might be negatively impacted. However, this situation doesn't affect the correctness of the result set.

 SORT_ORDER_LOCALE = "english-usa";

SORT_ORDER_LOCALE on Linux Operating Systems

The Oracle BI Server sets the C-runtime locale during server startup.

A value for the setting is specified using the SORT_ORDER_LOCALE entry in the NQSConfig.INI file. See Set Locale Parameters on the Oracle BI Server.

SORT_TYPE

Specifies the type of sort to perform.

The default value is BINARY. Binary sorts are faster than nonbinary sorts.

Valid values are BINARY and DEFAULT. If you specify DEFAULT, then a nonbinary sort is performed; this yields better sort results for data that contains accented characters.

Example: SORT_TYPE = "BINARY";

CASE_SENSITIVE_CHARACTER_COMPARISON

Specifies whether the Oracle BI Server differentiates between uppercase and lowercase characters when performing comparison operations.

Valid values are ON and OFF. When set to OFF, case is ignored. When set to ON, case is considered for comparisons. This parameter is set to ON by default. For binary sorts, case sensitivity for the server and for the relational database should be set the same way.

For information about how this parameter relates to the case setting in Oracle BI Server, see Make Advanced Configuration Changes for Presentation Services.

This setting only applies to the internal comparisons of the Oracle BI Server for caching and aggregation. Case sensitivity is a function of database operations and is set at the database level. The CASE_SENSITIVE_CHARACTER_COMPARISON parameter enables the Oracle BI Server to match the functions of the back-end database. The following operators are affected:

Order By
Group By
Distinct
Join
comparisons (<, >, =, <=, >=, <>)

For example, consider the following three terms:

ACME
DELTA
acme

An ORDER BY with CASE_SENSITIVE_CHARACTER_COMPARISON set to ON results in rows in the order shown in the preceding example. An ORDER BY with a case-insensitive setting results in ACME and acme appearing next to one another in the list.

If the term is case-sensitive and you perform a duplicate remove (DISTINCT), then the result is three rows. If the term isn't case-sensitive, then the DISTINCT result is two rows.

Set CASE_SENSITIVE_CHARACTER_COMPARISON to correspond with how the back-end database deals with case. For example, if the back-end database is case-insensitive, then configure the Oracle BI Server to be case-insensitive. If the Oracle BI Server and the back-end database aren't similarly case-sensitive, then some subtle problems can result.

For an example of CASE_SENSITIVE_CHARACTER_COMPARISON applied to aggregation, a case-sensitive database has the following tuples (or rows):

Region  Units
 WEST     1
 west     1
 West     1

With CASE_SENSITIVE_CHARACTER_COMPARISON set to ON, the data is returned to the client the with the same results shown in the preceding table.

With CASE_SENSITIVE_CHARACTER_COMPARISON set to OFF, the data is again returned to the client the with the same results shown in the preceding table. There is no change because the Oracle BI Server hasn't done any character comparisons.

However, if SUM_SUPPORTED is set to OFF in the features table, the Oracle BI Server is forced to do a character comparison. The results of the query in this case are as follows:

Region  Units
 WEST     3

The reason for these results is that the Oracle BI Server has case-sensitive character comparison turned off, so it now treats the three tuples as the same value and aggregates them. In this case WEST = West = west. However, if you filter on the Region column, you would still see the regions WEST, West, and west; CASE_SENSITIVE_CHARACTER_COMPARISON doesn't affect filtering on a back-end database. The logic shown in the aggregation example applies to caching as well.

Because CASE_SENSITIVE_CHARACTER_COMPARISON is set in the NQSConfig.INI file, the parameter applies to all back-end databases in a repository. Therefore, set the parameter to match the case sensitivity of the dominant back-end database of the repository.

Example: CASE_SENSITIVE_CHARACTER_COMPARISON = ON;

NULL_VALUES_SORT_FIRST

Specifies if NULL values sort before other values (ON) or after (OFF).

ON and OFF are the only valid values. Ensure that the value of NULL_VALUES_SORT_FIRST conforms to the underlying database. If there are multiple underlying databases that sort NULL values differently, then set the value to correspond to the database that is used the most in queries.

Example: NULL_VALUES_SORT_FIRST = OFF;

DATE_TIME_DISPLAY_FORMAT

Specifies the format for how date/time stamps are input to and output from the Oracle BI Server. The default value is yyyy/mm/dd hh:mi:ss.

Example: DATE_TIME_DISPLAY_FORMAT = "yyyy/mm/dd hh:mi:ss";

How are the Date and Time Display Formats Used?

The property values specified by DATE_TIME_DISPLAY_FORMAT, DATE_DISPLAY_FORMAT, and TIME_DISPLAY_FORMAT determine the default format that the BI Server uses when converting TIMESTAMP, DATE, and TIME expressions to and from character data types such as VARCHAR and CHAR.

DATE_TIME_DISPLAY_FORMAT, DATE_DISPLAY_FORMAT, and TIME_DISPLAY_FORMAT determine how date or time conversion expressions such as CAST(<chardata> as TIMESTAMP), CAST(<chardata> as DATE), CAST(<datetimeexpr> AS VARCHAR(20)), and CAST(<dateexpr> AS CHAR(10)) work when CAST_SUPPORTED isn't enabled in the database.

When the CAST_SUPPORTED feature is enabled in the database, the date and time formats are determined by the database rather than the DATE_TIME_DISPLAY_FORMAT, DATE_DISPLAY_FORMAT, and TIME_DISPLAY_FORMAT properties.

These properties don't affect the format of the timestamps written to the obis1-diagnostic.log or the nqquery.log. The format of the timestamps written in the log files is fixed according to Oracle Fusion Middleware standards and can't be changed since many tools like Fusion Middleware Control need to be able to parse the log files. These tools rely on the fact that the timestamps in the log files have a fixed format.

See DATE_DISPLAY_FORMAT and TIME_DISPLAY_FORMAT.

DATE_DISPLAY_FORMAT

Specifies the format for how dates are input to and output from the Oracle BI Server. The default value is yyyy/mm/dd.

Note:

Specify the year as either 2-digit (yy) or 4-digit (yyyy). Separators can be any character except y, m, or d.

Example: DATE_DISPLAY_FORMAT = "yyyy/mm/dd";

See How are the Date and Time Display Formats Used?.

TIME_DISPLAY_FORMAT

You can configure the way times are displayed or entered.

Specifies the format for how times are input to and output from the Oracle BI Server. The default value is hh:mi:ss.

Example: TIME_DISPLAY_FORMAT = "hh:mi:ss";

See How are the Date and Time Display Formats Used?.

WORK_DIRECTORY_PATHS

Specifies one or more directories for temporary space.

Each directory listed must be an existing, writable path name, with double quotation marks ( " ) surrounding the path name. Specify mapped directories only.

You can specify either fully qualified paths, or relative paths. When you specify a path that does not start with "/" (on Linux) or "<drive>:" (on Windows), the Oracle BI Server assumes that the path is relative to the local writable directory. For example, if you specify the path "temp," then at runtime, the Oracle BI Server uses the following:

BI_DOMAIN/servers/obisn/tmp/obis_temp

Specify multiple directories with a comma-delimited list. Valid values are any relative path, or fully qualified path to an existing, writable directory. UNC path names and network mapped drives are allowed only if the service runs under a qualified user account.

For optimum performance, temporary directories must reside on high-performance storage devices. If you specify multiple directories, then ensure that they reside on different physical drives.

Syntax: WORK_DIRECTORY_PATHS = "path_1" [, "path_2"{, "path_n"}];

Example 1: WORK_DIRECTORY_PATHS = "temp" ;

Example 2: WORK_DIRECTORY_PATHS = "D:\temp", "F:\temp";

Note:

Specifying multiple directories for each drive does not improve performance because file I/O occurs through the same I/O controller. In general, specify only one directory for each disk drive. Specifying multiple directories on different drives improves the overall I/O throughput of the Oracle BI Server because internally, the processing files are allocated using a round-robin algorithm that balances the I/O load across the given disk drives.

WORK_FILE_COMPRESSION_LEVEL

Use this parameter for Oracle BI Server internal temporary file tuning.

This parameter uses the compression library to compress the temporary working files.

For example, WORK_FILE_COMPRESSION_LEVEL = 2;

ENABLE_COLUMNAR_STORAGE_FOR_WORK_FILE

Use this parameter for Oracle BI Server internal temporarily file tuning.

This parameter applies to the temporary file created for the aggregation operator.

For example, ENABLE_COLUMNAR_STORAGE_FOR_WORK_FILE = YES;

WORK_DIRECTORY_SIZE_GLOBAL_LIMIT

Use this parameter for Oracle BI Server internal temporarily file tuning.

This parameter specifies the directory size limit and works along with MAX_WORK_FILE_SIZE_PERCENT to ensure that the temporary file does not exceed a specified percentage of the global work directory size limit.

For example, WORK_DIRECTORY_SIZE_GLOBAL_LIMIT = 100 GB;

MAX_WORK_FILE_SIZE_PERCENT

Use this parameter for Oracle BI Server internal temporarily file tuning.

You can also set in the Console, see Performance and Compatibility Options in Configure Advanced System Settings in the Console.

This parameter works with WORK_DIRECTORY_SIZE_GLOBAL_LIMIT to determine the maximum size that the temporarily file can grow to.

For example, set MAX_WORK_FILE_SIZE_PERCENT = 5;

VIRTUAL_TABLE_PAGE_SIZE

Several operations, such as sort, join, union, and database fetch, can require memory resources beyond those available to the Oracle BI Server.

To manage this condition, the server uses a virtual table management mechanism that provides a buffering scheme for processing these operations. When the amount of data exceeds the VIRTUAL_TABLE_PAGE_SIZE, the remaining data is buffered in a temporary file and placed in the virtual table as processing continues. This mechanism supports dynamic memory sizes and ensures that any row can be obtained dynamically for processing queries.

VIRTUAL_TABLE_PAGE_SIZE specifies the size of a memory page for Oracle BI Server internal processing. A larger value reduces I/O but increases memory usage, especially in a multiuser environment.

When VIRTUAL_TABLE_PAGE_SIZE is increased, I/O operations are reduced. Complex queries might use 20 to 30 virtual tables, while simple queries might not even require virtual tables. The default size of 128 KB is a reasonable size when one considers that the size for virtual paging in Windows is 64 KB. This parameter can be tuned depending on the number of concurrent users and the average query complexity. In general, setting the size larger than 256 KB does not yield a corresponding increase in throughput due to the 64 KB size limit of Windows system buffers, as each I/O still goes through the system buffers. 128 KB is also a reasonable value on Linux systems.

Example: VIRTUAL_TABLE_PAGE_SIZE = 128 KB;

USE_LONG_MONTH_NAMES

Specifies whether month names are returned as full names, such as JANUARY and FEBRUARY, or as three-letter abbreviations, such as JAN and FEB.

Valid values are YES and NO. Specify YES to have month names returned as full names, or NO to have months names returned as three-letter abbreviations. The default value is NO.

Example: USE_LONG_MONTH_NAMES = NO;

MEMORY_COMPACT_PERIOD_IN_SECONDS

Specifies the number of seconds that the Oracle BI Server waits between calls to its internal memory compaction routine.

The Oracle BI Server has a memory manager that does not return free memory to the system until the memory compaction routine is called in a background thread. Setting this parameter to a smaller value causes the Oracle BI Server to return unused memory to the system sooner at the expense of some additional CPU overhead. The default is 3600 seconds.

Example: MEMORY_COMPACT_PERIOD_IN_SECONDS = 3600;

USE_LONG_DAY_NAMES

Specifies whether day names are returned as full names, such as MONDAY and TUESDAY, or as three-letter abbreviations, such as MON and TUE.

Valid values are YES and NO. Specify YES to have day names returned as full names, or NO to have day names returned as three-letter abbreviations. The default value is NO.

Example: USE_LONG_DAY_NAMES = NO;

USE_UPPERCASE_MONTH_NAMES

Specifies whether month names are returned in mixed case, or in uppercase.

Valid values are YES and NO. Specify YES to have month names returned in uppercase, or NO to have month names returned in mixed case. The default value is NO.

Example: USE_UPPERCASE_MONTH_NAMES = NO;

USE_UPPERCASE_DAY_NAMES

Specifies whether day names are returned in mixed case, or in uppercase.

Valid values are YES and NO. Specify YES to have day names returned in uppercase, or NO to have day names returned in mixed case. The default value is NO.

Example: USE_UPPERCASE_DAY_NAMES = NO;

UPPERCASE_USERNAME_FOR_INITBLOCK

You can use the special syntax :USER in initialization blocks to pass through user names.

When this parameter is set to YES, then user names passed through initialization blocks using :USER are changed to all uppercase. Otherwise, case is maintained in the user names.

Example: UPPERCASE_USERNAME_FOR_INITBLOCK = NO;

Security Section Parameters

The security parameters specify default values for the Oracle BI Server security features.

See Security Guide for Oracle Business Intelligence Enterprise Edition.

DEFAULT_PRIVILEGES

Specifies the default metadata repository object privilege granted to the AuthenticatedUser application role, which is the default application role associated with any new repository object.

In effect, this setting specifies the default level of object security in the Presentation layer of the repository for new objects that don't have other explicit security settings.

Note that the AuthenticatedUser application role means "any authenticated user." This role is internal to the metadata repository.

Valid values are NONE and READ. The default value is READ. Note that NONE corresponds to the No Access setting in the Permissions dialog in the Administration Tool.

Example: DEFAULT_PRIVILEGES = READ;

PROJECT_INACCESSIBLE_COLUMN_AS_NULL

Controls how security-sensitive columns are displayed to unauthorized users. If this parameter is set to YES, then a NULL expression replaces the original column expression in the query and secured columns are hidden from unauthorized users in analyses.

If this parameter is set to NO, then when a user attempts to run a report that contains a secured column the user isn't authorized to see, an unresolved column error occurs.

The default value is YES.

Example: PROJECT_INACCESSIBLE_COLUMN_AS_NULL = YES;

IGNORE_LDAP_PWD_EXPIRY_WARNING

Determines whether users can log in even when the LDAP server issues a password expiration warning.

Valid values are YES and NO. Uncomment this parameter and specify YES to enable users to log in when the LDAP server issues a password expiration warning, or specify NO to reject user logins when the warning is issued. The default value is NO.

After user passwords have actually expired in the LDAP server, users can't log in, regardless of the value of this parameter.

Example: IGNORE_LDAP_PWD_EXPIRY_WARNING = NO;

MAX_AUTHENTICATION_TIME

Specifies the number of seconds that the Oracle BI Server is allocated to run initialization blocks before the user's login attempt times out. If a timeout happens, then the Oracle BI Server user is prompted to log in again.

This setting applies to the accumulated run time for all the initialization blocks. Suppose this value is set to ten minutes (600 seconds) and there are ten initialization blocks that the Oracle BI Server needs to run. If after running the fifth initialization block the ten minute login maximum is exceeded, then the Oracle BI Server does not run the remaining five initialization blocks and rejects the login attempt.

Example: MAX_AUTHENTICATION_TIME = 600;

INIT_BLOCK_LOG_TIME_THRESHOLD

Specifies a threshold in seconds for initialization block execution, which if exceeded, the Oracle BI Server logs the time of execution. This might provide a warning of possible initialization block design problems.

Example: INIT_BLOCK_LOG_TIME_THRESHOLD = 60;

NUM_INIT_BLOCK_THREADS_PER_USER

Specifies the number of initialization block threads that the Oracle BI Server allocates for each user.

The default is one thread.

Example: NUM_INIT_BLOCK_THREADS_PER_USER = 1;

SSL

This parameter, along with the remaining parameters in this section, relate to Secure Sockets Layer (SSL) communication between Oracle Analytics Server components.

The default setting for SSL is NO.

SSL_CERTIFICATE_FILE

Specifies the directory path to the certificate file.

For components acting as SSL servers, such as Oracle BI Server and Oracle BI Scheduler, this is the Server Certificate file name. For client components, such as Oracle Analytics Server ODBC Client Data Source, this is the Client Certificate file name.

Example (Server): SSL_CERTIFICATE_FILE = "servercert.pem";

Example (Client): SSL_CERTIFICATE_FILE = "client-cert.pem";

SSL_PRIVATE_KEY_FILE

Specifies the private key file.

For server components, this is the Server Private Key file name. For client components, this is the Client Private Key file name.

Example (Server): SSL_PRIVATE_KEY_FILE = "serverkey.pem";

Example (Client): SSL_PRIVATE_KEY_FILE = "client-key.pem";

SSL_PK_PASSPHRASE_FILE

Specifies the private key passphrase file name.

Example: SSL_PK_PASSPHRASE_FILE = serverpwd.txt;

SSL_PK_PASSPHRASE_PROGRAM

Specifies the private key passphrase program executable file name.

Example: SSL_PK_PASSPHRASE_PROGRAM = sitepwd.exe;

SSL_VERIFY_PEER

This parameter has been deprecated.

The SSL_VERIFY_CLIENTS and SSL_VERIFY_SERVERS parameters replace comparable functionality previously controlled by the SSL_VERIFY_PEER parameter.

SSL_VERIFY_SERVERS

Specifies whether to verify server certificates when acting as a client (that is, when the Oracle BI Server is calling the BI Security Service).

The default value is YES.

Example: SSL_VERIFY_SERVERS = YES;

SSL_VERIFY_CLIENTS

Specifies whether to verify client certificates when acting as a server (that is, when the Oracle BI Server is receiving calls from clients such as Presentation Services).

The default value is NO.

Example: SSL_VERIFY_CLIENTS = NO;

SSL_CA_CERTIFICATE_DIR

Specifies the path of the trusted CA Certificate that is used to verify the server or client certificate when Verify Peer is set to YES.

Takes effect only when client authentication is required.

Example: SSL_CA_CERTIFICATE_DIR = "CACertDir";

SSL_CA_CERTIFICATE_FILE

Specifies the name of the trusted CA Certificate that is used to verify the server or client certificate when Verify Peer is set to YES.

Takes effect only when client authentication is required.

Example: SSL_CA_CERTIFICATE_FILE = "CACertFile";

SSL_TRUSTED_PEER_DNS

Specifies individual named clients that are allowed to connect by Distinguished Name (DN).

The DN identifies the entity that holds the private key that matches the public key of the certificate.

Example: SSL_TRUSTED_PEER_DNS = "";

SSL_INTERNAL_CA_CERTIFICATE_FILE

Specifies the internal CA certificate file name.

Example: SSL_INTERNAL_CA_CERTIFICATE_FILE = "InternalCACertFile";

SSL_INTERNAL_TRUSTED_PEER_DNS

Specifies the internal trusted peer DNS name.

Example: SSL_INTERNAL_TRUSTED_PEER_DNS = "";

SSL_WEBSERVER_CA_CERTIFICATE_FILE

Specifies the web server CA certificate file name.

Example: SSL_WEBSERVER_CA_CERTIFICATE_FILE = "WebServerCACertFile";

SSL_WEBSERVER_TRUSTED_PEER_DNS

Specifies the web server trusted peer DNS name.

Example: SSL_WEBSERVER_TRUSTED_PEER_DNS = "";

SSL_CERT_VERIFICATION_DEPTH

The depth of the certificate chain. A depth of one means a certificate has to be signed by a trusted CA.

A depth of two means the certificate was signed by a CA that was further verified by a CA. The default value is 9.

Example: SSL_CERT_VERIFICATION_DEPTH = 9;

SSL_CIPHER_LIST

A list of permitted cipher suites that the server uses.

The default is empty string, which is equivalent to "ALL."

You must set this parameter only when you want to use a cipher suite other than the default choice.

Example: SSL_CIPHER_LIST = "EXP-RC2-CBC-MD5";

Server Section Parameters

The parameters in the Server section define defaults and limits for the Oracle BI Server.

READ_ONLY_MODE

Permits or forbids changing Oracle BI repository files when using the Administration Tool.

Note:

The READ_ONLY_MODE parameter can be set in Fusion Middleware Control or by editing NQSConfig.INI.

The Disallow RPD Updates option on the Performance tab of the Configuration page in Fusion Middleware Control corresponds to the READ_ONLY_MODE parameter. See Use Fusion Middleware Control to Disallow RPD Updates.

The default is NO, meaning that repositories can be edited.

When this parameter is set to YES, it prevents the Administration Tool from making any changes to repository files. When the Administration Tool opens the repository, a message informs the user that the repository is read-only. If this parameter is set to NO, then the Administration Tool can make changes to the repository.

Even when READ_ONLY_MODE is set to NO, there are still situations when Administration Tool opens repositories in read-only mode. For example, a repository might open as read-only if an offline Oracle BI Server held a lock on the repository at the time the Oracle BI Server started.

In addition, the Administration Tool also opens in read-only mode when Oracle Analytics Server has been clustered, and the Administration Tool is connected in online mode to a secondary node. This occurs because the primary node holds a lock on the repository. To avoid this situation when running in a clustered environment, ensure that the Oracle BI Server ODBC DSN that is used by the Administration Tool has been configured to point to the cluster controller rather than to a particular Oracle BI Server.

MAX_SESSION_LIMIT

Specifies the maximum number of concurrent connections that are allowed by the server.

When this number is exceeded, the server refuses the connection request.

The limit is 65,535 connections.

Example: MAX_SESSION_LIMIT = 2000;

About the MAX_SESSION_LIMIT and SERVER_THREAD_RANGE Parameters

The size of the connection pool determines the number of available Oracle BI Server connections and the number of available threads for processing physical queries. A logical query might generate multiple physical queries, each of which could go to different connections.

The Oracle BI Server creates server threads up to the specified maximum using the parameter SERVER_THREAD_RANGE. All the threads that are available at any time are used to process queries from one or more sessions as needed.

Typically, the number of sessions that is specified by MAX_SESSION_LIMIT is larger than the number of available threads that is specified by SERVER_THREAD_RANGE.

In summary:

MAX_SESSION_LIMIT specifies the number of sessions that can be connected to the Oracle BI Server, even if inactive. The sessions and the corresponding queries are queued to the threads for processing as they become available.
The size of the connection pool specifies the number of threads and connections that process physical queries.
SERVER_THREAD_RANGE specifies the number of threads that process the logical queries, or in other words, the number of queries that can be active in the Oracle BI Server at any time.

MAX_REQUEST_PER_SESSION_LIMIT

Specifies the maximum number of logical requests per session. This is how many open requests there are, per session, at the same time.

The limit is 65,535 logical requests per session.

Note:

Usually, individual users have only one open request for each session at the same time. Application programs and Oracle BI Presentation Services, however, typically have multiple requests open at the same time. In general, the default value of 5000 is sufficient for most environments, but tune this parameter based on the application environment and the client tools in use.

Example: MAX_REQUEST_PER_SESSION_LIMIT = 5000;

SERVER_THREAD_RANGE

Thread allocation configuration information is recorded for each server request.

For each Oracle BI Server request, SERVER_THREAD_RANGE specifies configuration information for thread allocation. The lower number in the range specifies the number of threads that is initially allocated, and the larger number in the range specifies the maximum number of threads to be allocated. The thread pool grows and shrinks in 5-thread increments until the upper or lower bound is reached. If there are fewer threads than sessions, then sessions share the available number of threads on a first come-first served basis.

Although setting both values to the same number maximizes the benefits of thread pooling, there is a cost associated with doing so. If you set the lower boundary and the upper boundary to the same number, then that number of threads is always allocated, which consumes stack space.

Example: SERVER_THREAD_RANGE = 10-200;

See About the MAX_SESSION_LIMIT and SERVER_THREAD_RANGE Parameters for related information.

SERVER_THREAD_STACK_SIZE

Specifies the memory stack size that is allocated for each server thread.

A value of 0 sets the stack size as 1 MB per server thread (64-bit systems).

The default value is 0. If you change this value, then ensure that the value that you provide is appropriate for the memory resources that are available on the system.

Example: SERVER_THREAD_STACK_SIZE = 0;

DB_GATEWAY_THREAD_RANGE

Specifies the minimum and maximum number of threads in the Oracle Analytics Server Database Gateway thread pool, according to SERVER_THREAD_RANGE.

The default value is 40-200.

Example: DB_GATEWAY_THREAD_RANGE = 40-200;

DB_GATEWAY_THREAD_STACK_SIZE

Specifies the memory stack size that is allocated for each Oracle Analytics Server Database Gateway thread. A value of 0 sets the stack size as 1 MB per server thread (64-bit systems).

The default value is 0. If you change this value, then ensure that the value that you provide is appropriate for the memory resources that are available on the system.

Example: DB_GATEWAY_THREAD_STACK_SIZE = 0;

HTTP_CLIENT_THREAD_RANGE

Specifies the minimum and maximum number of threads in the thread pool that the Oracle BI Server uses for reading and writing data using the HTTP client wrapper.

The default value is 0-100.

Example: HTTP_CLIENT_THREAD_RANGE = 0-100;

HTTP_CLIENT_THREAD_STACK_SIZE

Specifies the memory stack size that is allocated for each thread that is specified in HTTP_CLIENT_THREAD_RANGE. A value of 0 sets the stack size as 1 MB per thread (64-bit systems).

The default value is 0. If you change this value, then ensure that the value that you provide is appropriate for the memory resources that are available on the system.

Example: HTTP_CLIENT_THREAD_STACK_SIZE = 0;

MAX_EXPANDED_SUBQUERY_PREDICATES

Controls the maximum number of values that can be populated by a subquery when it is expanded. The default is 8,192 values. The Oracle BI Server generates an error if this limit is exceeded.

The Oracle BI Server syntax supports various kinds of subqueries, including IN and COMPARISON subqueries. In some cases, the Oracle BI Server must run the subquery and convert it into values (for example, when the database features IN_SUPPORTED/IN_SUBQUERY_SUPPORTED and COMPARISON_SUBQUERY are turned off in the database features table). When the Oracle BI Server converts subqueries into value lists, MAX_EXPANDED_SUBQUERY_PREDICATES is used to monitor the maximum number of values from the result set of the subquery.

Note that there is also a database feature setting called MAX_ENTRIES_PER_IN_LIST. This value is set according to how many literals can be supported by the given data source. If this limit is exceeded, then the Oracle BI Server breaks the IN list into smaller ones and ORs them together. However, if the original IN list is too long, it might exceed the SQL statement length limit for that data source, resulting in a database error or failure. The MAX_EXPANDED_SUBQUERY_PREDICATES parameter provides a second limit to ensure that this situation does not occur.

Example: MAX_EXPANDED_SUBQUERY_PREDICATES = 8192;

Note:

If you see the error [nQSError: 42029] Subquery contains too many values for the IN predicate, you must increase the value of MAX_EXPANDED_SUBQUERY_PREDICATES (default value is 8192). Then retry your query.

MAX_QUERY_PLAN_CACHE_ENTRIES

Controls the number of cached logical query plans. The query plan cache is an internal performance feature that increases the speed of the query compilation process by caching plans for the most recently used queries.

The default value of this parameter is 1024. Don't raise this value without consulting Oracle Support Services.

Example: MAX_QUERY_PLAN_CACHE_ENTRIES = 1024;

MAX_QUERY_PLAN_CACHE_ENTRY_SIZE

Specifies the heap memory usage limit that is allocated for the single logical plan cache entry. The total plan cache memory usage per Oracle BI Server can be calculated by multiplying MAX_QUERY_PLAN_CACHE_ENTRY_SIZE times MAX_QUERY_PLAN_CACHE_ENTRY_SIZE.

The default value of 0 indicates the default limit of 1MB (64-bit platform). If you change this value, then ensure that the value that you provide is appropriate for the memory resources that are available on the system.

Example: MAX_QUERY_PLAN_CACHE_ENTRY_SIZE = 0;

MAX_DRILLDOWN_INFO_CACHE_ENTRIES

Controls the number of cached Action Link drilldown information entries per repository. This increases the speed of computing Action Link information by caching the Action Link information for the most recently used queries.

The default value of this parameter is 1024. Don't raise this value without consulting Oracle Support Services.

Example: MAX_DRILLDOWN_INFO_CACHE_ENTRIES = 1024;

MAX_DRILLDOWN_QUERY_CACHE_ENTRIES

Controls the number of cached Action Link query entries per repository. This increases the speed of drilling down by caching the Action Link drilldown results for the most recently used queries.

The default value of this parameter is 1024. Don't raise this value without consulting Oracle Support Services.

Example: MAX_DRILLDOWN_QUERY_CACHE_ENTRIES = 1024;

INIT_BLOCK_CACHE_ENTRIES

Controls the number of initialization block result sets that are cached with row-wise initialization.

The cache key is the fully instantiated initialization block SQL.

The default value is 20. Because this parameter affects internal operations for localized versions of Oracle Analytics Server, it's recommended that you don't change this value unless instructed to do so.

Example: INIT_BLOCK_CACHE_ENTRIES = 20;

CLIENT_MGMT_THREADS_MAX

Specifies the number of management threads to allocate for managing Oracle BI Server client/server communications. Each client process consumes a management thread.

The client/server communication method for Oracle BI Server is TCP/IP.

Because the default value of 5 is typically sufficient for server communications with clients, don't change the value of this parameter.

Example: CLIENT_MGMT_THREADS_MAX = 5;

DEFAULT_JOBQUEUE_SIZE_PER_THREAD

Specifies the number of jobs that are in the queue per thread.

The default is 100 jobs. When set to 0, there is no limit to the number of jobs in the queue per thread.

Example: DEFAULT_JOBQUEUE_SIZE_PER_THREAD = 100;

MAX_COLUMNS_IN_SELECT

Specifies the maximum number of columns in a SELECT statement, including all subtotaling expressions generated by Presentation Services. This limit applies to all SELECT statements including derived or leaf select blocks.

Setting this value to 0 does not represent unlimited. The limit that you set in this parameter applies to all users, including administrators, and all subject areas.

Example: MAX_COLUMNS_IN_SELECT = 50;

MAX_LOGICAL_DIMENSION_TABLES

A single presentation column might references multiple logical tables when the corresponding logical column is derived from multiple logical tables.

Also, multiple presentation tables might reference the same logical table. For example, suppose a query requests multiple logical tables such as EmployeeCity, EmployeeRegion, and EmployeeCountry. In this example, the table count is three even though all tables reference the same dimension.

Hidden dimension attributes are include in the total number of logical dimension tables.

Setting this value to 0 does not represent unlimited. The limit that you set in this parameter applies to all users, including administrators, and all subject areas.

Example: MAX_LOGICAL_DIMENSION_TABLES = 30;

MAX_LOGICAL_FACT_TABLES

Specifies the maximum number of logical fact tables that display in a single leaf logical request.

This parameter also applies to implicit fact measures added by the Oracle BI Server. Suppose this parameter is set to 0 and the query requests two dimensions which invokes the implicit fact measure. The query fails because the logical fact table limit was exceeded.

Hidden fact attributes are include in the total number of logical fact tables.

Note that setting this value to 0 does not represent unlimited. The limit that you set in this parameter applies to all users, including administrators, and all subject areas.

Example: MAX_LOGICAL_FACT_TABLES = 5;

MAX_LOGICAL_MEASURES

Specifies the maximum number of unique logical measure columns, that is the unique dimension aggregations defined in the logical layer in a single logical request.

Some measures might be referenced multiple times in a single query, but are counted once. Measures that are based on the same physical attribute and aggregation rules but with different level-based setup are counted as different measures. For example, EmployeeCountry.Revenue is derived from Sales.Revenue with its level set to COUNTRY on the Product-Region dimension, but it is counted as a measure different from Sales.Revenue.

Hidden fact attributes are included in the total number of logical measures.

Note that setting this value to 0 does not represent unlimited. The limit that you set in this parameter applies to all users, including administrators, and all subject areas.

Example: MAX_LOGICAL_MEASURES = 15;

MAX_SET_OPERATION_BLOCKS

Specifies the maximum number of union, intersect, or minus blocks that display in an incoming SQL query. A query with a set operator contains at least two query blocks.

Every query must have at least one query block. If you specify 0 in this parameter, then the Oracle BI Server doesn't run a query. If you specify 1 in this parameter, then only queries that don't use set operators, and therefore contain only one query block, are included in the query.

The limit that you set in this parameter applies to all users, including administrators, and all subject areas.

Example: MAX_SET_OPERATION_BLOCKS = 15;

DEFAULT_DB_MAX_EXEC_TIME

Determines the maximum time that a database query runs.

If the execution time of a database query exceeds the number of seconds set for this parameter, the error message [nQSError: 60009] The user request exceeded the maximum query governing execution time. is displayed, and the query is terminated. If query execution time is less than the number of seconds set for this parameter, then the query completes and no error message is displayed.

Example: DEFAULT_DB_MAX_EXEC_TIME = 60;

QUERY_LIMIT_WARNING_INSTEAD_OF_ERROR

Determines if an error message displays when the logical query limits are exceeded.

If this parameter is set to OFF and the logical query limits are exceeded, then the Oracle Analytics Server displays an error message and terminates the remainder of the query. If this parameter is set to ON and the logical query limits are exceeded, then the query completes and no error message displays, but a warning message indicating that the threshold was exceeded is logged in the obis1-diagnostic.log file.

Example: QUERY LIMIT_WARNING_INSTEAD_OF_ERROR = OFF;

RPC_SERVICE_OR_PORT

Specifies the IP address and port number on which the Oracle BI Server listens.

Note:

The RPC_SERVICE_OR_PORT parameter can be set by editing NQSConfig.INI.

Setting the port range overrides the RPC_SERVICE_OR_PORT parameter.

You can specify an IP address and port number in the form ip_address:port, or you can specify a port number only.

When you specify an IP address and port number, the Oracle BI Server binds to the specified IP address.

When you specify a port number only, the IP address is set by default to 0.0.0.0, which causes the Oracle BI Server to listen on all IP addresses on that computer.

When you specify an IP address only, the port value defaults to 9703.

When using the Oracle Analytics Server ODBC wizard to configure ODBC data sources for the Oracle BI Server, ensure that the port number that is specified in the Port field on the Enter Logon Information screen matches the port number that is specified here. If you change the port number in the configuration file, then ensure that you reconfigure any affected ODBC data sources to use the new port number.

Example1: RPC_SERVICE_OR_PORT = 9703;

Example2: RPC_SERVICE_OR_PORT = 127.0.0.1:9703;

LISTEN_ADDRESS

This parameter is reserved for a future update.

LISTEN_PORT

This parameter is reserved for a future update.

ENABLE_DB_HINTS

Enables optional hints to be passed along with a SQL statement to an Oracle Database.

The default value is YES.

Example: ENABLE_DB_HINTS = YES;

PREVENT_DIVIDE_BY_ZERO

Controls the behavior for when a division by zero occurs.

When set to YES, then a NULL value is returned. When set to NO, then the query is terminated and an appropriate error is returned to the user.

Example: PREVENT_DIVIDE_BY_ZERO = YES;

CLUSTER_PARTICIPANT

Specifies whether the Oracle BI Server that is using this configuration file is a member of an Oracle BI Server cluster.

Note:

The CLUSTER_PARTICIPANT parameter can be set by editing NQSConfig.INI.

All Oracle Analytics Server deployments are designed to run the Cluster Controller, even if they are single-node deployments. Because of this design, always set CLUSTER_PARTICIPANT to YES.

Valid values are YES and NO. The default value is YES.

When CLUSTER_PARTICIPANT is set to YES, this server must have a valid, configured ClusterConfig.xml file in the following location:

BI_DOMAIN/config/fmwconfig/biconfig/core

For more information, see the information about the ClusterConfig.xml file in Deploy for High Availability.

Example: CLUSTER_PARTICIPANT = YES;

DISCONNECTED

This parameter has been deprecated and is no longer used.

VARIABLE_VALUE_LIMIT

Variables can be truncated to a specific length.

Specifies the maximum length of returned session variable values when client tools call the NQSGetSessionValues() function.

Example: VARIABLE_VALUE LIMIT= 10;

For example, suppose VARIABLE_VALUE_LIMIT is set to 10 and the NQSGetSessionValues() function is called on a variable whose value is "1234567890ABCDE." The value is truncated to "1234567890".

EVALUATE_SUPPORT_LEVEL

Specifies whether the database functions EVALUATE, EVALUATE_ANALYTIC, EVALUATE_AGGR, and EVALUATE_PREDICATE can be issued by users.

You can also set in the Console, see Performance and Compatibility Options in Configure Advanced System Settings in the Console.

See Evaluate Functions in Managing Metadata Repositories for Oracle Analytics Server for more information.

By default, this parameter is set to 0, which means that all support for the EVALUATE family of functions is disabled. Set this parameter to 1 to enable users with the oracle.bi.server.manageRepositories permission to issue EVALUATE functions. Set this parameter to 2 to enable all users to issue EVALUATE functions.

Note the following:

The EVALUATE_SUPPORT_LEVEL parameter controls the use of the EVALUATE family of database functions within analyses. Oracle recommends leaving EVALUATE_SUPPORT_LEVEL set to its default value of 0 to prevent the use of these functions within analyses. Setting EVALUATE_SUPPORT_LEVEL to a value of 1 or 2 enables users to insert arbitrary SQL expressions into an analysis using the Analysis editor, which potentially compromises data access security.
The EVALUATE_SUPPORT_LEVEL parameter does not control use of the EVALUATE family of database functions within the metadata repository.

Example: EVALUATE_SUPPORT_LEVEL = 1;

FMW_SECURITY_SERVICE_URL

Specifies the location where Oracle WebLogic Server is running so that the Oracle BI Server can locate the Oracle Fusion Middleware security service.

Example: FMW_SECURITY_SERVICE_URL = "http://localhost:9704";

FMW_SECURITY_SERVICE_MAX_NUMBER_OF_CONNECTIONS

Limits the number of connections from the Oracle BI Server to the Oracle Fusion Middleware security service to avoid overloading the Oracle WebLogic Server with too many connections. Don't change.

Example: FMW_SECURITY_SERVICE_MAX_NUMBER_OF_CONNECTIONS = 2000;

FMW_SECURITY_SERVICE_MAX_NUMBER_OF_RETRIES

Specifies the maximum number of times to attempt to connect to the Oracle Fusion Middleware security service.

Example: FMW_SECURITY_SERVICE_MAX_NUMBER_OF_RETRIES = 0;

ENABLE_NUMERIC_DATA_TYPE

Specifies whether to import decimal/numeric data from Oracle Database and TimesTen as DOUBLE (the default) or NUMERIC, which provides greater precision.

Set this parameter to YES to enable numeric support for Oracle Database and TimesTen data sources. Data imported into the metadata repository from Oracle Database and TimesTen has decimal/numeric dataset to NUMERIC, and decimal/numeric SQL code that's entered by users is treated as NUMERIC. The data type of physical columns imported prior to changing this setting remains the same.

To leverage this configuration for queries run by the Oracle BI Server, enable the NUMERIC_SUPPORTED database feature in the Physical layer database object. See SQL Features Supported by a Data Source in Managing Metadata Repositories for Oracle Analytics Server .

Note that decimal/numeric data from other database types is still mapped as DOUBLE, even when this parameter is set to YES. Also, a column in Oracle Database or TimesTen that is declared as DOUBLE instead of NUMBER is still imported as DOUBLE in Oracle Analytics Server, regardless of how this parameter is set.

Note the following:

Numeric data types can be cast to other Number data types, and vice versa.
Numeric data type support isn't available through the Oracle BI Server JDBC driver.
There might be a performance overhead of enabling the numeric data type because of the higher number of bits for numeric data.

Example: ENABLE_NUMERIC_DATA_TYPE = NO;

ENDECA_SERVLET_URL

This parameter is reserved for a future update.

Example: ENDECA_SERVLET_URL = "http://localhost:9500/EndecaIntegration/EndecaServlet"

High Availability Parameters

The parameters in the High Availability section define defaults and limits use in a highly available configuration.

HA_DB_PING_PERIOD_MILLISECS

Specifies the number of milliseconds between two consecutive polls of every TimesTen database performed by the BI Server to ensure high availability.

Through this polling, the Oracle BI Server determines which TimesTen schemas are inactive, so that the Oracle BI Server can select which TimesTen aggregate tables to use for a query.

Example: HA_DB_PING_PERIOD_MILLISECS = 60000;

Dynamic Library Section Parameters

This section contains one entry for each dynamic link library (DLL) or set of shared objects that is used to make connections to the Oracle BI Server, for both Windows and Linux systems.

Syntax: logical_name = dynamic_library;

In this syntax:

logical_name: A logical name for the dynamic link library. These logical names also appear in the Connection Pool dialog.
dynamic_library: The name of the associated dynamic library. These libraries are located in:

ORACLE_HOME/bi/bifoundation/server/bin

Note:

Don't make any changes to this section unless instructed to do so by Oracle Support Services.

The following are the dynamic link libraries that are shipped with this update:

ODBC200 = nqsdbgatewayodbc;
ODBC350 = nqsdbgatewayodbc35;
OCI8 = nqsdbgatewayoci8;
OCI8i = nqsdbgatewayoci8i;
OCI10g = nqsdbgatewayoci10g;
DB2CLI = nqsdbgatewaydb2cli;
DB2CLI35 = nqsdbgatewaydb2cli35;
NQSXML = nqsdbgatewayxml;
XMLA = nqsdbgatewayxmla;
ESSBASE = nqsdbgatewayessbasecapi;
OracleADF = nqsdbgatewayoracleadf;
OracleADF_HTTP = nqsdbgatewayoracleadf;
OracleCEP_HTTP = nqsdbgatewayoraclecep;
HyperionADM = nqsdbgatewayadm;
OracleWS = nqsdbgatewayoraclews;
hadoop = nqsdbgatewayhadoop;
timesten = nqsdbgatewaytimesten;
timesten35 = nqsdbgatewaytimesten35;
JAVADS = nqsdbgatewayjava
CSV = nqsdbgatewaycsv

Usage Tracking Section Parameters

The usage tracking parameters define default values for the collection of usage tracking statistics on each logical query submitted to the Oracle BI Server.

The following table shows the names and descriptions of columns that are added to the usage tracking table and to the standalone usage tracking repository.

Name	Data Type	Description	Notes
SAW_DASHBOARD_PG	Varchar(150)	Page within Oracle BI Presentation Services dashboard	Null if not a dashboard request.
PRESENTATION_NAME	Varchar(128)	Name of the Presentation Catalog in Oracle BI Presentation Services	NA
ERROR_TEXT	Varchar(250)	Error flag and reason text for queries that don't generate a cache entry, from back-end databases	Only applicable if `SUCCESS_FLG` is nonzero. Concatenates multiple messages; the application must parse the column contents.
RUNAS_USER_NAME	Varchar(128)	Impersonated User (the Proxy User that ran the query)	Null if the request isn't run as an impersonated user.

For more information about usage tracking, see Set Direct Insertion Parameters.

ENABLE

Enables or disables the collection of usage tracking statistics.

Note:

For new (non-upgraded) installations, the ENABLE parameter in the [USAGE_TRACKING] section can be changed by manually editing NQSConfig.INI

See Set Direct Insertion Parameters.

Valid values are YES and NO. The default value is NO. When set to NO, statistics are not accumulated. When set to YES, statistics are accumulated for each logical query.

Example: ENABLE = NO ;

DIRECT_INSERT

Specifies whether statistics are inserted directly into a database table or written to a local file.

Note:

For new (non-upgraded) installations, the DIRECT_INSERT parameter can be changed by editing NQSConfig.INI.

See Set Direct Insertion Parameters.

When DIRECT_INSERT is set to NO, data is written to a flat file.
When DIRECT_INSERT is set to YES, data is inserted into a table.

Note:

This parameter is operative only if the usage tracking parameter ENABLE is set to YES.

Because direct insertion into a database table is recommended, the default value is YES.

Certain other parameters become valid, depending whether DIRECT_INSERT is set to YES or to NO. These parameters are summarized in the table below and described in the following sections.

DIRECT_INSERT Setting	Parameters Used	Parameter Setting
NO	STORAGE_DIRECTORY	"`full_directory_path`"
NO	CHECKPOINT_INTERVAL_MINUTES	5
NO	FILE_ROLLOVER_INTERVAL_MINUTES	30
NO	CODE_PAGE	"ANSI"
YES	PHYSICAL_TABLE_NAME	"`Database`"."`Catalog`"."`Schema`"."`Table`" or "`Database`"."`Schema`"."`Table`"
YES	CONNECTION_POOL	"`Database`"."`Connection_Pool`"
YES	BUFFER_SIZE	10 MB
YES	BUFFER_TIME_LIMIT_SECONDS	5
YES	NUM_INSERT_THREADS	5
YES	MAX_INSERTS_PER_TRANSACTION	1
YES	JOBQUEUE_SIZE_PER_INSERT_THREADPOOL_THREAD	100
YES	THROW_INSERT_WHEN_JOBQUEUE_FULL	NO

STORAGE_DIRECTORY

Specifies the full path to the directory that is used to store usage tracking log files.

The directory listed must be a valid fully qualified, writable directory path name, with double quotation marks ( " ) surrounding the path name. Specify mapped directories only.

Valid values are any fully qualified path name to an existing, writable directory.

The parameter STORAGE_DIRECTORY is valid only if the parameter DIRECT_INSERT is set to NO.

Example: STORAGE_DIRECTORY = "C:\Temp\UsageTracking";

CHECKPOINT_INTERVAL_MINUTES

Specifies how often the usage tracking data is flushed to disk.

Setting this interval to a larger number increases the amount of data that might be lost if the server shuts down abnormally. Setting this interval lower incurs additional overhead.

The default is 5 minutes.

Note:

When the interval is set to 0, the Oracle BI Server attempts to write usage tracking data to disk with minimal time between attempts. This can negatively affect server performance and is strongly discouraged.

Example: CHECKPOINT_INTERVAL_MINUTES = 5;

FILE_ROLLOVER_INTERVAL_MINUTES

Specifies the time, in minutes, before the current usage tracking log file is closed and a new file is created. For example, if this entry is set to 60 minutes, then 24 usage tracking log files are created each day.

The default is 30 minutes.

When the checkpoint interval equals or exceeds the rollover interval, only the rollover occurs explicitly; the checkpoint occurs implicitly only when the old usage tracking log file is closed.

Note:

When the checkpoint interval is set to 0, the Oracle BI Presentation Services attempts to close current usage tracking log files and open new log files with minimal time between attempts. This can negatively affect server performance and result in a large number of usage tracking log files in the storage directory. Setting this interval to 0 is strongly discouraged.

Example: FILE_ROLLOVER_INTERVAL_MINUTES = 240;

CODE_PAGE

For multilingual repositories, this specifies the type of output code page to use when writing statistics to disk.

Valid values include any valid code page number (such as 1252), and other globally recognized output code page types.

The default value is ANSI. The type depends upon the database loader being used. For example, to support multilingual repositories for database loaders that are used by Oracle Database and DB2, specify UTF8. Enclose the value in double quotation marks. USC-2 is currently not supported.

Example: CODE_PAGE = "ANSI";

PHYSICAL_TABLE_NAME

Specifies the table in which to insert records that correspond to the query statistics. The table name is the fully qualified name as it appears in the Physical layer of the Administration Tool.

Note:

For new (non-upgraded) installations, the PHYSICAL_TABLE_NAME parameter can be updated by editing NQSConfig.INI.

See Set Direct Insertion Parameters.

The general structure of this parameter depends on the type of database being used:

For SQL Server, use the following general structure:

PHYSICAL_TABLE_NAME = "Database"."Catalog"."Schema"."Table";

Example:

PHYSICAL_TABLE_NAME = "OracleBI Usage"."Catalog"."dbo"."S_NQ_ACCT";

In the preceding example, the structure is as follows:
- "Oracle BI Usage" represents the database component
- "Catalog" represents the catalog component
- "dbo" represents the schema component
- "S_NQ_ACCT" represents the table name
For Oracle Database, use the following general structure:

PHYSICAL_TABLE_NAME = "Database"."Schema"."Table";

Examples:

PHYSICAL_TABLE_NAME = "OracleBI Usage"."DEV_BIPLATFORM"."S_NQ_ACCT";

In the preceding example, the structure is as follows:
- "Oracle BI Usage" represents the database component
- "DEV_BIPLATFORM" represents the schema component
- "S_NQ_ACCT" represents the table name

CONNECTION_POOL

Specifies the connection pool to use for inserting records into the usage tracking table.

This is the fully qualified name as it appears in the Physical layer of the Administration Tool.

Example: CONNECTION_POOL = "OracleBI Usage"."Connection Pool";

Note:

For new (non-upgraded) installations, the CONNECTION_POOL parameter can be changed by editing NQSConfig.INI.

See Set Direct Insertion Parameters.

INIT_BLOCK_TABLE_NAME

Specifies the table in which to insert records that correspond to the initialization block statistics.

The table name is the fully qualified name as it appears in the Physical layer of the Administration Tool. The default table, S_NQ_INITBLOCK, is defined in the RCU schema.

Example: INIT_BLOCK_TABLE_NAME = Database"."Catalog"."Schema"."Table";

INIT_BLOCK_CONNECTION_POOL

Specifies the connection pool to use for inserting records into the initialization block usage tracking table.

The connection pool name is the fully qualified name as it appears in the Physical layer of the Administration Tool.

Example: INIT_BLOCK_CONNECTION_POOL = Database"."Connection_Pool";

BUFFER_SIZE

Specifies the amount of memory that is used to temporarily store insert statements.

The buffer enables the insert statements to be issued to the usage tracking table independently of the query that produced the statistics to be inserted. When the buffer fills up, then the statistics of subsequent queries are discarded until the insert threads service the buffer entries.

You can specify the size in KB or MB, or enter a number with no suffix to specify bytes.

Example: BUFFER_SIZE = 10 MB;

BUFFER_TIME_LIMIT_SECONDS

Specifies the maximum amount of time that an insert statement remains in the buffer before it is issued to the usage tracking table. This time limit ensures that the Oracle BI Presentation Services issues the insert statements quickly even during periods of extended quiescence.

Example: BUFFER_TIME_LIMIT_SECONDS = 5;

NUM_INSERT_THREADS

Specifies the number of threads that remove insert statements from the buffer and issue them to the usage tracking table. The number of threads must not exceed the total number of threads that are assigned to the connection pool.

Example: NUM_INSERT_THREADS = 5;

MAX_INSERTS_PER_TRANSACTION

Specifies the number of records to group as a single transaction when inserting into the usage tracking table, using the bulk insert API of the database where this is supported.

Increasing the number might slightly increase performance, but also increases the possibility of inserts being rejected due to deadlocks in the database.

Example: MAX_INSERTS_PER_TRANSACTION = 1;

JOBQUEUE_SIZE_PER_INSERT_THREADPOOL_THREAD

Specifies the maximum number of insert jobs that may be put into the job queue of a thread.

Example: JOBQUEUE_SIZE_PER_INSERT_THREADPOOL_THREAD = 100;

THROW_INSERT_WHEN_JOBQUEUE_FULL

You can configure the system to wait until there is space in the thread job queue to complete or run a job.

Specifies that the thread running the job stops and waits until the thread job queue is no longer full (when set to NO) or reject the new insert job (when set to YES).

Example: THROW_INSERT_WHEN_JOBQUEUE_FULL = NO;

SUMMARY_STATISTICS_LOGGING

You can enable or disable the logging statistics

Note:

For new (non-upgraded) installations, the SUMMARY_STATISTICS_LOGGING parameter can be changed by editing NQSConfig.INI.

See Turning On Summary Advisor Logging in Managing Metadata Repositories for Oracle Analytics Server .

Enables or disables the collection of Summary Advisor logging statistics, as follows:

Set this parameter to YES to enable Summary Advisor logging.
Set this parameter to LOG_OUTER_JOINT_QUERIES_ONLY to enable Summary Advisor logging only for logical queries that contain outer joins. Consider using this option when the minor performance impact of enabling full Summary Advisor logging is a concern.
Set this parameter to NO (the default) to disable Summary Advisor logging.

The Oracle BI Summary Advisor feature is only available when you're running Oracle Analytics Server on the Oracle Exalytics Machine. See Using Oracle BI Summary Advisor to Identify Query Candidates for Aggregation in Managing Metadata Repositories for Oracle Analytics Server .

Example: SUMMARY_STATISTICS_LOGGING = YES;

SUMMARY_ADVISOR_TABLE_NAME

You can specify the table where logging statistic records are stored.

Note:

For new (non-upgraded) installations, the SUMMARY_ADVISOR_TABLE_NAME parameter can be changed by manually editing NQSConfig.INI.

See Turning On Summary Advisor Logging in Managing Metadata Repositories for Oracle Analytics Server .

Specifies the table in which to insert records that correspond to the Oracle BI Summary Advisor logging statistics. The table name is the fully qualified name as it appears in the Physical layer of the Administration Tool.

Example: SUMMARY_ADVISOR_TABLE_NAME = "Orcl"."DEV_BIPLATFORM".

"S_NQ_SUMMARY_ADVISOR"

Query Optimization Flags Section Parameters

Parameters in the Query Optimization Flags section can override the behavior of Oracle BI Server.

STRONG_DATETIME_TYPE_CHECKING

Use this parameter to relax strong type checking to prevent some date/time data type incompatibilities in queries from being rejected.

You can also set in the Console, see Performance and Compatibility Options in Configure Advanced System Settings in the Console.

For example, a query of the form "date/time op string-literal" technically contains a date/time data type incompatibility and would normally be rejected by the Oracle BI Server.

Valid values are ON and OFF. The default value is ON, which means that strong type checking is enabled and queries containing date/time data type incompatibilities are rejected. This is the recommended setting.

To relax the strong type checking, set the value to NO. Note that invalid queries or queries with severe date/time incompatibilities are still rejected. Note also that the query could still fail, for example, if the relational database implements a similar strong type checking.

Example: STRONG_DATETIME_TYPE_CHECKING = ON;

Query Optimizer Thread Pool Parameters

The Query Optimizer Thread Pool handles the complex queries where the query execution plan (rqTree) is too deep to put into one thread, which causes the stack to overflow.

The Query Optimizer Thread Pool uses parameters that enable you to divide the execution plan, letting each thread in that pool handle a part of the plan.

QUERY_OPTIMIZER_THREAD_RANGE

Use this parameter to specify the minimum and maximum number of threads in the Query Optimizer Thread Pool.

Example: QUERY_OPTIMIZER_THREAD_RANGE = 0 - 100;

QUERY_OPTIMIZER_STACK_SIZE

Use this parameter to specify the stack size of the Query Optimizer Thread.

When you use the default value (0), the stack size is 256KB (in 32-bit mode), and 1MB (in 64-bit mode).

Example: QUERY_OPTIMIZER_STACK_SIZE = 0;

QUERY_OPTIMIZER_MAX_THREAD_PER_QUERY

Use this parameter to specify the maximum number of Query Optimizer threads used per query.

The default value is 5.

Example: QUERY_OPTIMIZER_MAX_THREAD_PER_QUERY = 5;

Aggregate Persistence Section Parameters

Oracle Business Intelligence provides an aggregate persistence feature that automates the creation and loading of the aggregate tables and their corresponding Oracle Business Intelligence metadata mappings.

The parameters in this section relate to configuring and using the aggregate persistence feature.

AGGREGATE_PREFIX

Specifies the Domain Server Name for aggregate persistence.

The prefix must be between 1 and 8 characters long and must not have any special characters ('_' is allowed).

Example: AGGREGATE_PREFIX = "SA_";

AGGREGATE_THREAD_POOL_SIZE

Specifies the number of threads to be started for aggregate persistence.

Within each phase, relational loads are run in separate threads to improve the load performance. The default value is 5.

Example: AGGREGATE_THREAD_POOL_SIZE = 5;

AGGREGATE_AW_NAME

Specifies the name of the Analytic Workspace object that is created in the target Oracle Database.

The aggregate AW cubes and dimensions are created under this container.

Example: AGGREGATE_AW_NAME = "OBI_AW";

PREAGGREGATE_AW_CUBE

Specifies whether the system-generated AW cube for aggregate persistence must be fully solved.

The default value is YES. Note that a YES value significantly increases storage space usage.

Example: PREAGGREGATE_AW_CUBE = YES;

SUPPORT_ANALYTICAL_WORKSPACE_TARGETS

Specifies whether to turn on support for persisting aggregates in Oracle Analytic Workspaces.

The default is NO.

Example: SUPPORT_ANALYTICAL_WORKSPACE_TARGETS = NO;

JavaHost Section Parameters

The parameters in this section provide information about the computers on which the JavaHost process is running.

JAVAHOST_HOSTNAME_OR_IP_ADDRESSES

This parameter provides information about JavaHost connectivity. The default port value is 9810.

Note:

The JAVAHOST_HOSTNAME_OR_IP_ADDRESS parameter can be updated by editing NQSConfig.INI.

Syntax: JAVAHOST_HOSTNAME_OR_IP_ADDRESS = "host_name1:port1",host_name2:port2;

Example: JAVAHOST_HOSTNAME_OR_IP_ADDRESS = "MYHOST:9810";

JAVAHOST_HOSTNAME_OR_IP_ADDRESSES_OVERRIDE

Specifies whether to override the JavaHost host name or IP address for connecting to data sources for Hyperion Financial Management when Oracle Analytics Server is installed on a non-Windows platform.

Hyperion Financial Management provides a client driver for only the Windows platform. You must have a JavaHost process for Oracle Analytics Server running on a Windows computer to access Hyperion Financial Management even if the main instance of Oracle Analytics Server is running on a non-Windows platform. In this case, the JAVAHOST_HOSTNAME_OR_IP_ADDRESSES_OVERRIDE parameter must be configured to indicate the JavaHost instance running on the Windows computer where the Hyperion Financial Management client is installed.

Syntax: JAVAHOST_HOSTNAME_OR_IP_ADDRESS_OVERRIDE = "host_name1:port1",host_name2:port2;

Example: JAVAHOST_HOSTNAME_OR_IP_ADDRESS_OVERRIDE = "MYHOST:9810";

Datamart Automation Section Parameters

The parameters in this section are reserved for a future update.

ESSBASE_SERVER

This parameter is reserved for a future update.

DMA_DATABASE

This parameter is reserved for a future update.