Skip Headers
Oracle® Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition
11g Release 1 (11.1.1)

Part Number E10541-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A NQSConfig.INI File Configuration Settings

This appendix lists the NQSConfig.INI file parameters for Oracle Business Intelligence and gives a brief description and any required syntax for each parameter. The Oracle BI 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 appendix assume that you are editing a Windows version of NQSConfig.INI. If you are editing this file on a UNIX system, then ensure that you use UNIX-appropriate file system paths and conventions.

This appendix includes the following sections:

A.1 About Parameters in the NQSConfig.INI File

Each instance of the Oracle BI Server has its own NQSConfig.INI file. When you update NQSConfig.INI parameters for a clustered deployment, ensure that you make the change in the NQSConfig.INI file for each instance of the Oracle BI Server.

Some parameters in NQSConfig.INI are centrally managed by Fusion Middleware Control and cannot be updated manually in NQSConfig.INI. Instead, use Fusion Middleware Control to change these parameters. Parameters that are centrally managed by Fusion Middleware Control are marked as such in this appendix, and are also identified by comments in the NQSConfig.INI file.

See Appendix C, "Mapping User Interface Labels with Configuration File Elements" for additional information.

Note:

If you attempt to manually update NQSConfig.INI parameters that are centrally managed by Fusion Middleware Control, then the manually updated values are ignored, because the value set in Fusion Middleware Control overrides the value in the file. If you must manually update these settings, then you must disable all configuration through Fusion Middleware Control (not recommended).

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

A.1.1 How to Update Parameters in NQSConfig.INI

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

To update parameters in NQSConfig.INI:

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

    ORACLE_INSTANCE/config/OracleBIServerComponent/coreapplication_obisn
    

    Make a backup copy of the file before editing.

  2. Locate and update the parameter you want to change.

  3. Save and close the file.

  4. Restart the Oracle BI Server. For more information, see Section 4.1, "About Starting and Stopping Oracle Business Intelligence."

  5. If you have multiple Oracle BI Server instances, then repeat these steps in each NQSConfig.INI file for all Oracle BI Server instances.

A.2 Repository Section Parameters

Note:

The default repository is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Repository tab of the Deployment page in Fusion Middleware Control controls the default repository. The logical name of the default repository is always "Star." See Section 10.2, "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" for more information.

Note that you can manually add additional repository entries in NQSConfig.INI without having these entries overridden by Fusion Middleware Control. However, hosting multiple repositories on a single Oracle BI Server is not recommended for production systems.

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

Syntax: logical_name = repository_name.rpd;

Optional syntax: logical_name = repository_name.rpd, DEFAULT;

In this syntax:

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

Example: Star = SampleAppLite.rpd, DEFAULT;

A.3 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, you should 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 executed 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 Business Intelligence, including information about how to use agents to seed the Oracle BI Server cache, see Chapter 7, "Managing Performance Tuning and Query Caching."

A.3.1 ENABLE

Note:

The ENABLE parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Cache enabled option on the Performance tab of the Capacity Management page in Fusion Middleware Control corresponds to the ENABLE parameter. See Section 7.5.1, "Using Fusion Middleware Control to Enable and Disable Query Caching" for more information.

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;

A.3.2 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, the paths specified should be 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 allowed 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 does not start with "/" (on UNIX) 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:

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obisn/cache

Note:

Multiple Oracle BI Servers across a cluster do not 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, they should 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.)

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 should be 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 are 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 a value that is less than 4 GB. Otherwise, the value might exceed the maximum allowable value for an unsigned 32-bit integer, because values over 4 GB cannot be processed on 32-bit systems. It is also a best practice to use values less than 4 GB on 64-bit systems.

Create multiple paths if you have values in excess of 4 GB.

A.3.3 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 is not cached.

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

Example: MAX_ROWS_PER_CACHE_ENTRY = 100000;

A.3.4 MAX_CACHE_ENTRY_SIZE

Note:

The MAX_CACHE_ENTRY_SIZE parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Maximum cache entry size option on the Performance tab of the Capacity Management page in Fusion Middleware Control corresponds to the MAX_CACHE_ENTRY_SIZE parameter. See Section 7.5.2, "Using Fusion Middleware Control to Set Query Cache Parameters" for more information.

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;

A.3.5 MAX_CACHE_ENTRIES

Note:

The MAX_CACHE_ENTRIES parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Maximum cache entries option on the Performance tab of the Capacity Management page in Fusion Middleware Control corresponds to the MAX_CACHE_ENTRIES parameter. See Section 7.5.2, "Using Fusion Middleware Control to Set Query Cache Parameters" for more information.

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;

A.3.6 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 executed query, then the new query is not 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 executed query (in this example, by aggregating data from the first result set stored in the cache). That is, Oracle Business Intelligence 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 is not 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 are not affected by this parameter. If a query result is satisfied by the cache—that is, the query gets a cache hit—then this query is not 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;

A.3.7 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 did not 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 is not 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. See also the parameter "MAX_SUBEXPR_SEARCH_DEPTH" for related information.

A.3.7.1 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 did not 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 did not 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 is 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 are not 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 are not 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 Section A.3.2, "DATA_STORAGE_PATHS" and Section A.3.3, "MAX_ROWS_PER_CACHE_ENTRY" for more information.

  • Query is canceled. 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 Section 8.4.1, "Configuring Query Logging" for more information.

A.3.8 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.

A.3.9 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;

A.3.10 GLOBAL_CACHE_STORAGE_PATH

Note:

The GLOBAL_CACHE_STORAGE_PATH parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Global cache path and Global cache size options on the Performance tab of the Capacity Management page in Fusion Middleware Control correspond to the GLOBAL_CACHE_STORAGE_PATH parameter. See Section 7.5.4, "Using Fusion Middleware Control to Set Global Cache Parameters" for more information.

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;

A.3.11 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;

A.3.12 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;

A.3.13 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;

A.4 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.

A.4.1 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 Business Intelligence, 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 Oracle BI Catalog Manager and language extensions, see Chapter 15, "Localizing Oracle Business Intelligence."

A.4.2 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 is defined in the Physical layer in the Oracle BI 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 Oracle BI 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 should 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 Table A-1.

Table A-1 Critical SORT_ORDER_LOCALE Parameters

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.

Note: The LOCALE and SORT_ORDER_LOCALE parameters accept platform-independent names only. See the list provided in Section A.4.1, "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 does not match the SORT_ORDER_LOCALE setting in the Features tab of the Database dialog in the Oracle BI repository, then result sets might not be correct. If the settings do not 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 does not 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 does not affect the correctness of the result set.

Example: SORT_ORDER_LOCALE = "english-usa";

A.4.2.1 SORT_ORDER_LOCALE on UNIX 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 Chapter 15, "Setting Locale Parameters on the Oracle BI Server" for more information.

A.4.3 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";

A.4.4 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 Presentation Services, see Section B.1, "Making 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 allows 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 is not case-sensitive, then the DISTINCT result is two rows.

CASE_SENSITIVE_CHARACTER_COMPARISON should be set to correspond with how the back-end database deals with case. For example, if the back-end database is case-insensitive, then the Oracle BI Server should be configured to be case-insensitive. If the Oracle BI Server and the back-end database are not 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 has not 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 does not 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, it should be set to match the case sensitivity of the dominant back-end database of the repository.

Example: CASE_SENSITIVE_CHARACTER_COMPARISON = ON;

A.4.5 NULL_VALUES_SORT_FIRST

Specifies if NULL values sort before other values (ON) or after (OFF). ON and OFF are the only valid values. The value of NULL_VALUES_SORT_FIRST should conform 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;

A.4.6 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";

A.4.7 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";

A.4.8 TIME_DISPLAY_FORMAT

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";

A.4.9 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 UNIX) 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:

ORACLE_INSTANCE/tmp/OracleBIServerComponent/coreapplication_obisn/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 should reside on high-performance storage devices. If you specify multiple directories, then they should 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.

A.4.10 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 NT 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 NT system buffers, as each I/O still goes through the system buffers. 128 KB is also a reasonable value on UNIX systems.

Example: VIRTUAL_TABLE_PAGE_SIZE = 128 KB;

A.4.11 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;

A.4.12 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;

A.4.13 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;

A.5 Security Section Parameters

The security parameters specify default values for the Oracle BI Server security features. For more information about security, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

A.5.1 DEFAULT_PRIVILEGES

Specifies the default Oracle BI 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 do not have other explicit security settings.

Note that the AuthenticatedUser application role means "any authenticated user." This role is internal to the Oracle BI 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;

A.5.2 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 is not authorized to see, an unresolved column error occurs.

The default value is YES.

Example: PROJECT_INACCESSIBLE_COLUMN_AS_NULL = YES;

A.5.3 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 allow 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 cannot log in, regardless of the value of this parameter.

Example: IGNORE_LDAP_PWD_EXPIRY_WARNING = NO;

A.5.4 SSL

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

The default setting for SSL is NO.

Note:

Most of the SSL parameters in this section are centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended). The centrally managed SSL parameters include:

  • SSL

  • SSL_CERTIFICATE_FILE

  • SSL_PRIVATE_KEY_FILE

  • SSL_VERIFY_PEER

  • SSL_CA_CERTIFICATE_FILE

See "SSL Configuration in Oracle Business Intelligence" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition for complete information about how to configure SSL between Oracle Business Intelligence components.

A.5.5 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 Business Intelligence ODBC Client Data Source, this is the Client Certificate file name.

This parameter is centrally managed.

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

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

A.5.6 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.

This parameter is centrally managed.

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

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

A.5.7 SSL_VERIFY_PEER

Specifies whether the server requires client authentication or not. When set to YES, the Oracle Business Intelligence component verifies that the other component in the connection has a valid certificate (that is, mutual authentication). The default value of NO permits a connection to any peer.

This parameter is centrally managed.

Example: SSL_VERIFY_PEER = NO;

A.5.8 SSL_CA_CERTIFICATE_FILE

Specifies the name and path of the trusted CA Certificate used to verify the server or client certificate when Verify Peer is set to YES. Takes effect only when client authentication is required.

This parameter is centrally managed.

Example: SSL_CA_CERTIFICATE_FILE = "CACertFile";

A.5.9 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.

This parameter is not centrally managed.

Example: SSL_TRUSTED_PEER_DNS = "";

A.5.10 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.

This parameter is not centrally managed.

Example: SSL_CERT_VERIFICATION_DEPTH = 9;

A.5.11 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.

This parameter is not centrally managed.

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

A.6 Server Section Parameters

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

A.6.1 READ_ONLY_MODE

Note:

The READ_ONLY_MODE parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Disallow RPD Updates option on the Performance tab of the Capacity Management page in Fusion Middleware Control corresponds to the READ_ONLY_MODE parameter. See Section 7.3.1, "Using Fusion Middleware Control to Disallow RPD Updates" for more information.

Permits or forbids changing Oracle BI repository files when the Administration Tool is in either online or offline mode. 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.

Note that even when READ_ONLY_MODE is set to NO, there are still situations when Administration Tool opens repositories in read-only mode. For example, if you open a repository in offline mode, but the Oracle BI Server or another Administration Tool client holds a lock on the repository, then the repository opens in read-only mode. In online mode, a repository might open as read-only if an offline Administration Tool 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 Business Intelligence has been clustered, and the Administration Tool is connected in online mode to a slave node. This occurs because the master 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.

A.6.2 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;

A.6.2.1 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.

A.6.3 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 500 should be sufficient for most environments, but this parameter should be tuned based on the application environment and the client tools in use.

Example: MAX_REQUEST_PER_SESSION_LIMIT = 500;

A.6.4 SERVER_THREAD_RANGE

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 Section A.6.2.1, "About the MAX_SESSION_LIMIT and SERVER_THREAD_RANGE Parameters" for related information.

A.6.5 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 256 KB for each server thread for 32-bit platforms, or 1 MB for 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;

A.6.6 DB_GATEWAY_THREAD_RANGE

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

The default value is 40-200.

Example: DB_GATEWAY_THREAD_RANGE = 40-200;

A.6.7 DB_GATEWAY_THREAD_STACK_SIZE

Specifies the memory stack size that is allocated for each Oracle Business Intelligence Database Gateway thread. A value of 0 sets the stack size as 256 KB per server thread for 32-bit platforms, or 1 MB for 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;

A.6.8 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;

A.6.9 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 256 KB per thread for 32-bit platforms, or 1 MB for 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;

A.6.10 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 execute the subquery and convert it into values (for example, when the database features IN_SUPPORTED/IN_SUBQUERY_SUPPRTED 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;

A.6.11 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. Do not raise this value without consulting Oracle Support Services.

Example: MAX_QUERY_PLAN_CACHE_ENTRIES = 1024;

A.6.12 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 256KB on 32-bit platforms, or 1MB on 64-bit platforms. 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;

A.6.13 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. Do not raise this value without consulting Oracle Support Services.

Example: MAX_DRILLDOWN_INFO_CACHE_ENTRIES = 1024;

A.6.14 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. Do not raise this value without consulting Oracle Support Services.

Example: MAX_DRILLDOWN_QUERY_CACHE_ENTRIES = 1024;

A.6.15 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 Business Intelligence, it is recommended that you do not change this value unless instructed to do so.

Example: INIT_BLOCK_CACHE_ENTRIES = 20;

A.6.16 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, do not change the value of this parameter.

Example: CLIENT_MGMT_THREADS_MAX = 5;

A.6.17 RPC_SERVICE_OR_PORT

Note:

The RPC_SERVICE_OR_PORT parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Port Range From and Port Range To options on the Scalability tab of the Capacity Management page in Fusion Middleware Control override the RPC_SERVICE_OR_PORT parameter. See Section 5.5, "Using Fusion Middleware Control to Scale System Components" for more information.

Specifies the IP address and port number on which the Oracle BI Server listens. 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 Business Intelligence ODBC wizard to configure ODBC data sources for the Oracle BI Server, the port number specified in the Port field on the Enter Logon Information screen should match the port number 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;

A.6.18 LISTEN_ADDRESS

This parameter is reserved for a future release.

A.6.19 LISTEN_PORT

This parameter is reserved for a future release.

A.6.20 ENABLE_DB_HINTS

Enables optional hints to be passed along with a SQL statement to an Oracle Database. Database hints are discussed in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.

The default value is YES.

Example: ENABLE_DB_HINTS = YES;

A.6.21 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;

A.6.22 CLUSTER_PARTICIPANT

Note:

The CLUSTER_PARTICIPANT parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

For each Oracle BI Server instance listed on the Scalability tab of the Capacity Management page in Fusion Middleware Control, CLUSTER_PARTICIPANT is set to YES for that server. See Section 5.5, "Using Fusion Middleware Control to Scale System Components" for more information.

All Oracle Business Intelligence deployments are designed to run the Cluster Controller, even if they are single-node deployments. Because of this, CLUSTER_PARTICIPANT should always be set to YES.

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

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

In a clustered environment, you typically designate a repository publishing directory to propagate changes made to the repository in online mode. See "REPOSITORY_PUBLISHING_DIRECTORY" and "REQUIRE_PUBLISHING_DIRECTORY" for more information about the repository publishing directory.

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

ORACLE_INSTANCE/config/OracleBIApplication/coreapplication

For more information, see the information about the ClusterConfig.xml file in Chapter 6, "Deploying Oracle Business Intelligence for High Availability."

Example: CLUSTER_PARTICIPANT = YES;

A.6.23 REPOSITORY_PUBLISHING_DIRECTORY

Note:

The REPOSITORY_PUBLISHING_DIRECTORY parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The RPD Publishing Directory option on the Repository tab of the Deployment page in Fusion Middleware Control corresponds to the REPOSITORY_PUBLISHING_DIRECTORY parameter. Note that this parameter only appears in NQSConfig.INI if the RPD Publishing Directory option has been set in Fusion Middleware Control. See Section 10.2, "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" for more information.

When the parameter CLUSTER_PARTICIPANT is set to YES, REPOSITORY_PUBLISHING_DIRECTORY specifies the location of the repository publishing directory shared by all Oracle BI Servers participating in the cluster. There is no default value for this parameter.

When a repository is updated in online mode, it is published to this location. All clustered servers examine this location upon startup for any repository changes. This must be a valid location visible to all servers in the cluster, even if you anticipate that no repositories are updated in online mode.

The directory should reside on a shared file system. The directory must be a valid fully qualified directory path name, with double quotation marks ( " ) surrounding the path name. UNC path names and network mapped drives are allowed only if the service runs under a qualified user account. Do not specify a relative path name, or the Repository subdirectory (located in the Oracle Business Intelligence software installation directory) as the location of the repository publishing directory.

The Oracle BI Server designated as the master server for online repository changes (the one for which the MasterServer parameter is set to true in the ClusterConfig.xml file) must have read and write access to this directory. The Oracle BI Servers in the cluster (the other servers defined in the ClusterConfig.xml file) must also have read and write access to this directory. All entries must reference the same actual directory, although different names can be specified to accommodate differences in drive mappings.

Examples:

REPOSITORY_PUBLISHING_DIRECTORY = "z:\OracleBI\Publish";

REPOSITORY_PUBLISHING_DIRECTORY = "\\ClusterSrv\Publish";

A.6.24 REQUIRE_PUBLISHING_DIRECTORY

Note:

The REQUIRE_PUBLISHING_DIRECTORY parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The Share Repository option on the Repository tab of the Deployment page in Fusion Middleware Control corresponds to the REQUIRE_PUBLISHING_DIRECTORY parameter. See Section 10.2, "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" for more information.

When the parameter CLUSTER_PARTICIPANT is set to YES, REQUIRE_PUBLISHING_DIRECTORY specifies that the repository publishing directory (from the parameter REPOSITORY_PUBLISHING_DIRECTORY) must be available for this Oracle BI Server to start and join the cluster.

This parameter is commented out by default.

When set to YES, if the publishing directory is not available at startup or if an error is encountered while the server is reading any of the files in the directory, an error message is logged in the nqserver.log file and the server shuts down.

To allow the Oracle BI Server to start and join the cluster even if the publishing directory is not available, set this value to NO. When set to NO, the server joins the cluster and a warning message is logged in the nqserver.log file. Any online repository updates are not reflected in the server's Repository directory (located in the Oracle Business Intelligence software installation directory). This could result in request failures, wrong answers, and other problems. However, this could be useful in situations where online repository editing is done infrequently and the goal is to keep the cluster operational even if some servers have stale repositories.

Example: REQUIRE_PUBLISHING_DIRECTORY = YES;

A.6.25 DISCONNECTED

This parameter has been deprecated and is no longer used.

A.6.26 AUTOMATIC_RESTART

Specifies whether the Oracle BI Server should be automatically restarted after a failure. Automatic restart applies only to an Oracle BI Server platform; it does not apply to a clustered Oracle BI Server environment. The default value is YES.

Example: AUTOMATIC_RESTART = YES;

A.6.27 VARIABLE_VALUE_LIMIT

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".

A.6.28 EVALUATE_SUPPORT_LEVEL

Specifies whether the database functions EVALUATE, EVALUATE_ANALYTIC, EVALUATE_AGGR, and EVALUATE_PREDICATE can be issued by users. See "Database Functions" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information about the EVALUATE* functions.

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.

Example: EVALUATE_SUPPORT_LEVEL = 1;

A.6.29 FMW_SECURITY_SERVICE_URL

Note:

The FMW_SECURITY_SERVICE_URL parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

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";

A.6.30 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. Do not change.

Example: FMW_SECURITY_SERVICE_MAX_NUMBER_OF_CONNECTIONS = 2000;

A.6.31 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;

A.6.32 FMW_UPDATE_ROLE_AND_USER_REF_GUIDS

Users are identified by their global unique identifiers (GUIDs), not by their names. Because of this identification, if you migrate from test to production or change from one identity store to another, then user-based data access security that you configure in the Oracle BI repository might no longer work.

To avoid this situation, you can temporarily set this parameter to YES to refresh the GUIDs for users in the repository with the GUIDs for users in the identity store. The default value for this parameter is NO.

You do not normally refresh GUIDs in the identity store between test and production environments, because the GUIDs should be identical in both environments. You should refresh GUIDs only if they differ between test and production environments.

Ensure that you set this parameter back to NO after refreshing the GUIDs to avoid compromising the security of the system.

See "Managing Security Using the Default Security Configuration" in Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition for complete information about the process of refreshing GUIDs. Note that a similar parameter is also needed to refresh GUIDs for Presentation Services.

Example: FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = NO;

A.6.33 MONITOR_PORT

Note:

The MONITOR_PORT parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

Specifies the port that the BI Server listens on when the Cluster Controller must connect to it.

Example: MONITOR_PORT = 9701;

A.6.34 ORACLEHARDWAREACCELERATION

Note:

The ORACLEHARDWAREACCELERATION parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

This setting is for internal use only. Do not modify it.

Example: ORACLEHARDWAREACCELERATION = NO;

A.7 High Availability Parameters

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

A.7.1 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 BI Server determines which TimesTen schemas are inactive, so that the BI Server can select which TimesTen aggregate tables to use for a query.

Example: HA_DB_PING_PERIOD_MILLISECS = 60000;

A.8 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 UNIX systems.

Syntax: logical_name = dynamic_library;

In this syntax:

Caution:

Do not 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 release:

A.9 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.

Table A-2 shows the names and descriptions of columns that are added to the usage tracking table and to the standalone usage tracking repository.

Table A-2 Names and Descriptions of Columns Added to Usage Tracking Table

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 do not 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 executed the query)

Null if the request is not run as an impersonated user.


For more information about usage tracking, see Chapter 9, "Managing Usage Tracking."

A.9.1 ENABLE

Note:

For new (non-upgraded) installations, the ENABLE parameter in the [USAGE_TRACKING] section is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The UsageTrackingEnabled attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the ENABLED parameter. See "Managing Usage Tracking" for more information.

Enables or disables the collection of usage tracking statistics.

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 ;

A.9.2 DIRECT_INSERT

Note:

For new (non-upgraded) installations, the DIRECT_INSERT parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The UsageTrackingDirectInsert attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the DIRECT_INSERT parameter. See "Managing Usage Tracking" for more information.

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

  • 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 Table A-3 and described in the following sections.

Table A-3 Valid Parameters for DIRECT_INSERT Settings

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


A.9.3 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. When usage tracking is enabled, but no storage directory is specified, the files are written to the following location:

ORACLE_INSTANCE\diagnostics\logs\OracleBIServerComponent\coreapplication_obisn

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

A.9.4 CHECKPOINT_INTERVAL_MINUTES

Specifies how often the usage tracking data is flushed to disk. Setting this interval ti 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;

A.9.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 Server 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;

A.9.6 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";

A.9.7 PHYSICAL_TABLE_NAME

Note:

For new (non-upgraded) installations, the PHYSICAL_TABLE_NAME parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The UsageTrackingPhysicalTableName attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the PHYSICAL_TABLE_NAME parameter. See "Managing Usage Tracking" for more information.

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.

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

A.9.8 CONNECTION_POOL

Note:

For new (non-upgraded) installations, the CONNECTION_POOL parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The UsageTrackingConnectionPool attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the CONNECTION_POOL parameter. See "Managing Usage Tracking" for more information.

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";

A.9.9 BUFFER_SIZE

Specifies the amount of memory that is used to temporarily store insert statements. The buffer allows 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;

A.9.10 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 Server issues the insert statements quickly even during periods of extended quiescence.

Example: BUFFER_TIME_LIMIT_SECONDS = 5;

A.9.11 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 should not exceed the total number of threads that are assigned to the connection pool.

Example: NUM_INSERT_THREADS = 5;

A.9.12 MAX_INSERTS_PER_TRANSACTION

Specifies the number of records to group as a single transaction when inserting into the usage tracking table. 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;

A.9.13 SUMMARY_STATISTICS_LOGGING

Note:

For new (non-upgraded) installations, the SUMMARY_STATISTICS_LOGGING parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The SummaryStatisticsLogging attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the SUMMARY_STATISTICS_LOGGING parameter. See "Turning On Summary Advisor Logging" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.

Enables or disables the collection of Oracle BI 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 are running Oracle Business Intelligence on the Oracle Exalytics Machine.

See "Using Oracle BI Summary Advisor to Identify Query Candidates for Aggregation" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information about the Summary Advisor feature.

Example: SUMMARY_STATISTICS_LOGGING = YES;

A.9.14 SUMMARY_ADVISOR_TABLE_NAME

Note:

For new (non-upgraded) installations, the SUMMARY_ADVISOR_TABLE_NAME parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless the UsageTrackingCentrallyManaged attribute of the BIDomain.BIInstance.ServerConfiguration MBean has been set to false.

The SummaryAdvisorTableName attribute of the BIDomain.BIInstance.ServerConfiguration MBean corresponds to the SUMMARY_ADVISOR_TABLE_NAME parameter. See "Turning On Summary Advisor Logging" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.

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"

A.10 Query Optimization Flags Section Parameters

There is one parameter in the Query Optimization Flags section. It is a special parameter to override the behavior of the Oracle BI Server in certain situations.

A.10.1 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. 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;

A.11 MDX Member Name Cache Section Parameters

The parameters in this section are for a cache subsystem that maps between a unique name and the captions of members of all SAP/BW cubes in the repository.

A.11.1 ENABLE

This parameter indicates if the feature is enabled or not.

The default value is NO because this only applies to SAP/BW cubes.

A.11.2 DATA_STORAGE_PATH

The path to the location where the cache is persisted. This applies only to a single location.

The number at the end of the entry indicates the storage capacity. When the feature is enabled, the string <full directory path> must be replaced with a valid path.

Example: DATA_STORAGE_PATH = "C:\OracleBI\server\Data\Temp\Cache" 500 MB;

A.11.3 MAX_SIZE_PER_USER

The maximum disk space that is allowed for each user for cache entries.

Example: MAX_SIZE_PER_USER = 100 MB;

A.11.4 MAX_MEMBER_PER_LEVEL

The maximum number of members in a level that can be persisted to disk.

Example: MAX_MEMBER_PER_LEVEL = 1000;

A.11.5 MAX_CACHE_SIZE

The maximum size for each individual cache entry size.

Example: MAX_CACHE_SIZE = 100 MB;

A.12 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.

A.12.1 AGGREGATE_PREFIX

Specifies the Domain Server Name for aggregate persistence. The prefix must be between 1 and 8 characters long and should not have any special characters ('_' is allowed).

Example: AGGREGATE_PREFIX = "SA_";

A.12.2 AGGREGATE_THREAD_POOL_SIZE

Specifies the number of threads to be started for aggregate persistence. Within each phase, relational loads are executed in separate threads to improve the load performance. The default value is 5.

Example: AGGREGATE_THREAD_POOL_SIZE = 5;

A.12.3 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";

A.12.4 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;

A.13 JavaHost Section Parameters

There is only one parameter in this section. It provides information about the computers where the JavaHost process is running.

A.13.1 JAVAHOST_HOSTNAME_OR_IP_ADDRESSES

Note:

The JAVAHOST_HOSTNAME_OR_IP_ADDRESS parameter is centrally managed by Fusion Middleware Control and cannot be changed by manually editing NQSConfig.INI, unless all configuration through Fusion Middleware Control has been disabled (not recommended).

The host information and Port Range From and Port Range To options on the Scalability tab of the Capacity Management page in Fusion Middleware Control override the JAVAHOST_HOSTNAME_OR_IP_ADDRESS parameter. See Section 5.5, "Using Fusion Middleware Control to Scale System Components" for more information.

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

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

Example: JAVAHOST_HOSTNAME_OR_IP_ADDRESS = "MYHOST:9810";

A.14 Datamart Automation Section Parameters

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

A.14.1 ESSBASE_STUDIO_URL

This parameter is reserved for a future release.

A.14.2 ESSBASE_SERVER

This parameter is reserved for a future release.

A.14.3 DMA_DATABASE

This parameter is reserved for a future release.