You can manage the query environment by setting query limits (governors) in the repository for particular application roles.
You can limit queries by the number of rows received, by maximum run time, and by restricting to particular time periods. You can also allow or disallow direct database requests or the Populate privilege.
You should always set query limits for particular application roles rather than for individual users.
This section contains the following topics:
Learn how to access the Query Limits tab of the User/Application Role Permissions dialog.
Note:
If you are in offline mode, no application roles appear in the list unless you have first modified them in online mode, see About Applying Data Access Security in Offline Mode.
You can control runaway queries by limiting queries to a specific number of rows.
Any query limits you set should exceed the Presentation Server settings for Maximum Number of Rows Processed when Rendering a Table View and Maximum Number of Rows to Download by at least 500 to avoid error messages. If you choose to impose data source rows limits on certain users or Application Roles using the repository Max Rows query limits setting, then those users may receive Max Row Limit Exceeded messages.
See Using Fusion Middleware Control to Set Configuration Options for Data in Tables and Pivot Tables and Using Fusion Middleware Control to Set the Maximum Number of Rows Processed to Render a Table in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
The options for Status Max Rows are:
Enable: This limits the number of rows to the value specified. If the number of rows exceeds the Max Rows value, the query is terminated.
Disable: Disables any limits set in the Max Rows field.
Warn: Does not enforce limits, but logs queries that exceed the set limit in the Query log.
Ignore: Limits are inherited from the parent application role. If there is no row limit to inherit, no limit is enforced.
Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.
You can forbid queries during certain time periods, or you can specify the maximum time a query can run on a database.
If you do not select a particular time period, access rights remain unchanged. If you allow or disallow access explicitly in one or more application roles, users are granted the least restrictive access for the defined time periods. For example, if a user is a member of an application role that is explicitly allowed access all day on Mondays, but that user also belongs to another application role that is disallowed access during all hours of every day, then the user has access on Mondays only.
Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.
To specify the maximum time a query can run on a database, in the Max Time (Minutes) column, enter the maximum number of minutes you want queries to run on each database object. Then, in the Status Max Time field, select one of the following options for each database:
Enable: This limits the time to the value specified.
Disable: Disables any limits set in the Max Time field.
Warn: Does not enforce limits, but logs queries that exceed the set time limit in the Query log.
Ignore: Limits are inherited from the parent application role. If there is no time limit to inherit, no limit is enforced.
To restrict access to a database during particular time periods, in the Restrict column, click the Ellipsis button. Then, in the Restrictions dialog, perform the following steps:
To select a time period, click the start time and drag to the end time.
To explicitly grant access, click Allow.
To explicitly deny access, click Disallow.
Click OK.
Click OK, then click OK again to return to the Identity Manager.
Use this task to allow or disallow the ability to execute direct database requests for a particular application role.
For the selected role, this privilege overrides the Allow direct database requests by default
property for the database object in the Physical layer.
The options for the Execute Direct Database Requests field are:
Explicitly grants the ability to execute direct database requests for this database.
Explicitly denies the ability to execute direct database requests for this database.
Limits are inherited from the parent application role. If there is no limit to inherit, then direct database requests are allowed or disallowed based on the Allow direct database requests by default
property for the database object.
Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.
When a criteria block is cached, the Populate stored procedure writes the Cache/Saved Result Set value to the database.
You can grant or deny this Populate privilege to particular application roles.
For the selected application role, this privilege overrides the Allow populate queries by default
property for the database object in the Physical layer.
Any Oracle Marketing Segmentation user who writes a cache entry or saves a result set must be a member of an application role that has been assigned the POPULATE
privilege for the target database.
The options for the Populate Privilege field are:
Explicitly grants the Populate privilege for this database. For all Marketing data warehouses, select Allow.
Explicitly denies the Populate privilege for this database.
Limits are inherited from the parent application role. If there is no limit to inherit, then the Populate privilege is allowed or disallowed based on the Allow populate queries by default
property for the database object.
Follow the steps in Accessing the Query Limits Functionality in the Administration Tool to access the Query Limits tab.