By monitoring and adjusting the behavior of queries in your project, you can improve the performance of your model.
You can do the following:
Use governors to reduce system resource requirements and improve performance. You set governors before you create packages to ensure the metadata in the package contains the specified limits. All packages that are subsequently published use the new settings.
In a new project the governors do not have values defined in the model. You must open the Governors window and change the settings if necessary. When you save the values in the Governors window by clicking OK, the values for the governors are set. You can also set governors in Report Studio. The governor settings in Report Studio override the governor settings in the model.
You can control the number of tables that a user can retrieve in a query or report. When a table is retrieved, it is counted each time it appears in the query or report. The limit is not the number of unique tables. If the query or report exceeds the limit set for the number of tables, an error message appears and the query or report is shown with no data.
A setting of zero (0) means no limit is set.
You can set data retrieval limits by controlling the number of rows that are returned in a query or report. Rows are counted as they are retrieved.
When you run a report and the data retrieval limit is exceeded, an error message appears and the query or report is shown with no data.
You can also use this governor to set limits to the data retrieved in a query subject test or the report design mode.
A setting of zero (0) means no limit is set.
If you externalize a query subject , this setting is ignored when you publish
the model.
You can limit the time that a query can take. An error message appears when the preset number of seconds is reached.
A setting of zero (0) means no limit is set.
You can control the character length of BLOBS (binary large objects) that a user can retrieve in a query or report. When the character length of the BLOB exceeds the set limit, an error message appears, and the query or report is shown with no data.
A setting of zero (0) means no limit is set.
You can control whether outer joins can be used in your query or report. An outer join retrieves all rows in one table, even if there is no matching row in another table. This type of join can produce very large, resource-intensive queries and reports.
Governors are set to deny outer joins by default. For example, outer joins are not automatically generated when you test a query item in Framework Manager.
SQL is generated automatically when you
run a report
test a query item or relationship in Framework Manager
If you keep the setting as Deny, you are notified only if you create a relationship in the Diagram tab that includes outer joins. You are not notified if you create a relationship in a data source query subject that includes outer joins.
If you set the governor to Allow, dimension to fact relationships are changed from inner joins to outer joins.
The outer joins governor does not apply in these circumstances:
SQL that is generated by other means. If
you set this governor to Deny, it does not
apply to the permanent SQL found in a data source query subject,
whether the SQL was generated on import , manually entered, or based on existing
objects
.
Framework Manager needs to generate an outer join to create a stitched query. A stitched query is a query that locally combines the results of two or more sub-queries by using a locally processed outer join.
Note: This governor is not applicable for SAP BW data sources.
You can control whether cross-product joins can be used in your query or report. A cross-product join retrieves data from tables without joins. This type of join can take a long time to retrieve data.
The default value for this governor is Deny. Select Allow to allow cross-product joins.
You can control how shortcuts are processed by Cognos 8.
When you open a model from a previous release, the Shortcut Processing governor is set to Automatic. Automatic is a shortcut that exists in the same folder as its target and behaves as an alias, or independent instance. However, a shortcut existing elsewhere in the model behaves as a reference to the original. When you create a new model, the Shortcut Processing governor is always set to Explicit.
If you set the governor to Explicit, the shortcut behavior is taken from the Treat As property. If the Shortcut Processing governor is set to Automatic, we recommend that you verify the model and, when repairing, change the governor to Explicit. This changes all shortcuts to the correct value from the Treat As property based on the rules followed by the Automatic setting.
The Shortcut Processing governor takes priority over the Treat As property. For example, if the governor is set to Automatic, the behavior of the shortcut is determined by the location of the shortcut relative to its target regardless of the setting of the Treat As property is.
You can control how SQL is generated for inner joins in a model by selecting one of the following settings:
The Server determined setting uses the UseSQL99JoinSyntax entry in the CQEConfig.xml file to determine the syntax. If there is not a UseSQL99JoinSyntax entry in the CQEConfig.xml file, then the Implicit setting is used. Server determined is the default value for this governor.
The Implicit setting uses the where clause.
For example,
SELECT publishers.name, publishers.id, books.title FROM publishers, books WHERE publishers.id = books.publisher_id ORDER BY publishers.name, books.title;
The Explicit setting uses the from clause with the keywords inner join in an on predicate.
For example,
SELECT publishers.name, publishers.id, books.title FROM publishers INNER JOIN books ON publishers.id = books.publisher_id ORDER BY publishers.name, books.title;
You can set the join type on the query property in Report Studio to override the value of this governor.
Regardless of the setting you use for this governor, the Explicit setting is used for left outer joins, right outer joins, and full outer joins.
This governor has no impact on typed-in SQL.
This governor is selected upon initial upgrade of a Cognos ReportNet 1.x model. It prevents rigid enforcement of data types so that a Cognos 8 model can function as a ReportNet 1.x model until you update the data types in the metadata. After you have verified that the model has been upgraded successfully, clear this governor.
Other than for initial upgrade, there are limited uses for this governor. For example, you have created a model for use with a data source and you want to run it against a different data source. The new data source must be structurally similar to the original data source, and the database schema must be the same between the two data sources. If you select this governor, Cognos 8 retrieves metadata from the data source and caches it instead of using the metadata already cached in the model. When you have completed modifying and testing the model against the new data source, clear this governor.
If you do not use this governor, you must ensure that the following metadata is the same in the original and new data sources:
collation sequence name
collation level
character set
nullability
precision
scale
column length
data type
Select this governor to specify that all reports based on this model will use cached data. For a new model, this governor is enabled by default.
This setting affects all reports that use the model. Use Report Studio if you want a report to use a different setting than the model. For more information, see Improving Performance by Reusing Cached Data When Running a Report.
This governor is selected only upon initial upgrade of a ReportNet 1.x model. This governor allows consistent behavior with ReportNet 1.x by deriving a form of dimension information from the relationships, key information, and index information in the data source.
You can choose to use the With clause with Cognos SQL if your data source supports the With clause.
The With clause is turned on for models created in Cognos 8. For upgraded models, it is turned off unless it was explicitly turned on in the ReportNet model prior to upgrading.
This governor is supported for SAP BW data sources only. It does not work with relational or OLAP data sources.
Some queries can be very large because null values are not filtered out. Null suppression removes a row or column for which all of the values in the row or column are null (empty). Null suppression is performed by SAP BW. This reduces the amount of data transferred to the Cognos 8 client products and improves performance.
The default value for this governor is to suppress null values. If you clear this governor, null values are not suppressed for any report or analysis in Cognos 8.
There is a property called Suppress in Report Studio that overrides this governor. If the Suppress property is set to None, null values are included in the result set even if the governor is set to suppress null values.
From the Project menu, click Edit Governors.
Specify the limits that you want to use when retrieving data.
Click OK.
The Rollup Processing property for data sources determines whether aggregate rollups above the lowest level are computed locally or in the database. The default is set to local if local query processing is enabled, and is otherwise set to database.
Note: This property is not applicable for SAP BW data sources.
The possible options for this property are
unspecified
The aggregation rollup is not specified.
local
All aggregation rollups are computed locally (in the report server) using a running aggregate (for example, RSUM). Running aggregates spread the cost of this computation as the data is retrieved. Use this option if the local computer has more idle resources than the database computer, or if you find through experiment that it is the fastest method.
database
Aggregation rollups are computed by the underlying database software if possible. Otherwise, they are computed locally (provided local query processing is enabled). Running aggregates are used, but the cost is incurred by the database server instead of the report server. Use this option if the database computer has more idle resources than the local computer, or if you find through experiment that it is the fastest method.
extended
All aggregation rollups are computed by the database server using an extended aggregate (for example, XSUM). Extended aggregates incur the entire cost of this computation up front. Typically, this is the fastest method, but only where the database is set up to take advantage of materialized views. For databases where OLAP functionality is supported, this is translated into the appropriate OLAP aggregate functions.
In the Project Viewer, click the data source you want to change.
In the Properties pane, in the Rollup Processing list box, select the type of rollup processing that you want.
The query processing property for data sources determines whether SQL processing is performed by the database server or if it is processed locally. For relational metadata, you can improve performance by selecting the right type of query processing.
There are two types of query processing:
limited local
The database server does as much of the SQL processing and execution as possible. However, some reports or report sections use local SQL processing.
database only
The database server does all the SQL processing and execution. An error appears if any reports or report sections require local SQL processing.
Although the database server can usually run the SQL and run reports much faster, local processing is sometimes necessary. For example, choose limited local processing if you want to create cross database joins, or if you want your users to use unsupported SQL99 functions.
Some complex queries require limited local processing, such as a query that must generate an At clause to avoid double-counting. In this case, the query automatically uses limited local processing even if the package was published with database only processing.
For information about optimizing SAP BW performance, see Optimizing SAP BW Performance.
In the Project Viewer, click the data source you want to change.
In the Properties pane, in the Query Processing list box, click either Limited Local or Database Only.
When you run a report, the query request is sent to the database and the result set is returned. After the initial report execution, you may decide to make changes to the report. Often, the report can be created without querying the database again. To take advantage of this, turn the query reuse feature on.
When query reuse is turned on and you run a report for the first time, the query is stored in the cache on the report server. Also, some data source resources may not be available until the transaction using them is released. The current default time-out is 60 minutes. If certain database activities involve modifying database objects, you must wait for the time-out period to be completed, or you can disable query reuse for reports.
The first time the report is run and the cache is created, the response time may be slightly negatively impacted. The performance improvement is realized by the report consumer on each subsequent report execution, when the response time is improved by as much as 80%. This performance improvement occurs because the report does not have to re-query the database. In addition to this, reduced queries to the database yields improved overall system performance, which positively impacts all users.
Query reuse can be set on the model or on individual reports. To specify that all reports using a particular model should use cached data, enable the Allow Usage of Local Cache governor on the model in Framework Manager and republish the model. By default, this setting affects all reports that use this model, including analyses that are run as reports in Cognos Viewer.
If you want a report to use a different setting than the model, you can do this in Report Studio. In the Properties pane, change the Use Local Cache property. Set the property to No if you want to always execute the query. Set the property to Yes if you want to use cached results. If you want the report to use the same setting as the model, change the setting to Default.
Changing the Use Local Cache property for one report does not affect other reports.
Query Studio reuses cached data under various conditions. If query reuse is turned on in the model and the action can be satisfied by a subset of the cached data set, the report uses the cached data. For example, changes to the report such as adding a filter or removing a column, may change the report data, but the request can still be satisfied from a subset of the cached data.
If query reuse is turned off and the action can be satisfied from the cached data set without modifications, the report still uses the cached data. For example, changing the report format uses the previous data set even if query reuse is turned off. This is known as cursor reuse. Cursor reuse is used when the cached data can satisfy the request without modifications.
Reports that were created in Query Studio always use the same setting as that specified in the model. If the model has query reuse turned on, the report attempts to use the cached data.
Before deciding whether or not to turn query reuse on, consider the following:
If most report consumers run reports interactively but run them only once, you may not experience a high level of performance improvement by caching data.
Note: Regardless of the query reuse settings, reports that run in batch mode do not cache data.
The size of the cache may impact Cognos 8 scalability. For example, if a report has a large result set, the cache will also be large. This should be taken into account when sizing and configuring your server environment.
A collection of vendor-specific functions is called a function set. When you create a project that contains relational metadata, the expression editor lists the function sets for all available vendors. However, you can restrict the function sets so that they list only the vendors that you want to use in your project. You customize the function set by identifying the specific vendor for each data source defined in the project.
You can use functions that you defined in your relational data source in Framework Manager. If you imported the user-defined functions, they are listed in Framework Manager for easy selection. If you did not import them, you can type the name of the function into an expression. If the function must be qualified, you must import them into Framework Manager.
Sometimes the vendor-specific functions were created on schemas with broad access permissions. You cannot use these functions in Cognos 8 on a schema with restricted access permissions if both the schemas are on the same database instance.
If an unrecognized function is typed into a report, it is assumed that the function is native. For more information, see Native SQL.
Note: When you create a project that contains SAP BW metadata, Framework Manager automatically lists only the functions that apply to SAP BW data.
From the Project menu, click Project Function List.
Select the Set function list based on the data source type check box.
Tip: To disable this filter, select the Include all function sets check box.
In the Function set page, click the appropriate data source row.
Select the function set you want to use with this data source.
Repeat steps 2 to 4 until finished.
Click OK.
For information about how to specify which function sets are included in individual packages, see Optimizing SAP BW Performance.
With Framework Manager, you can query any combination of data source types, but not all data sources support functions the same way. The quality of service indicator provides you and your users with a visual clue about the behavior of individual functions when used in conjunction with the data sources in the model.
Each function specified in your data source may have a different quality of service, depending on the type of data source in use. For each query feature that does not have the same quality of service across packages, you can override the level of service and add text to describe the specific situation in that model. Your users can see the quality of service indicators and the context specific description, and use this information when determining which functions to use in reports.
The quality of service for a function is specified at the data
source level and can be set for an individual function or for all
functions in a package. The quality of service indicators are:
not available (X)
This function is not available for any data sources in the package
limited availability (!!)
The function is not available for some data sources in the package
poor performance (!)
The function is available for all data sources in the package but may have poor performance in some data sources
unconstrained (no symbol)
The function is available for all data sources
If there is more than one type of data source in the model, the quality of service values are aggregated according to the following rules:
If the quality of service is defined as Unconstrained, Poor Performance, or Limited Availability in one data source and defined as Not Available in another data source, the quality of service for that function becomes Limited Availability.
In all other cases, the lowest common dominator is used. For example, if the quality of service is Unconstrained in one data source and Poor Performance in another data source, the quality of service for that function becomes Poor Performance. If the quality of service is Poor Performance in one data source and Limited Availability in another data source, the quality of service is reported as Limited Availability.
Framework Manager determines the quality of service for functions based upon the data source type. Taking into consideration the context of the model, you can override the quality of service that is determined by the product. Overriding the quality of service provides guidance to your users. It does not change the level of support for that function in your data source.
When a package is made by combining sub-packages, quality of service overrides in the parent package take precedence. If there is no parent override, the quality of service for the child packages are aggregated as described above.
Ultimately, the goal is to provide your users with enough information to satisfy their business requirements, but not enough to confuse them. If your users are unable to make decisions regarding which functions to use based on the quality of service indicators, you should consider publishing separate packages for different groups of users. If your users require access to functions whose quality of service is less than Unconstrained, you should document the restrictions of those functions when you set the quality of service.
The quality of service indicators has no direct impact on query performance. Service indicators are intended to give you some control over which functions are available for use. You can then prevent your users from using functions that could result in long running queries or queries that fail.
It is important to note that if you use functions that are not available in your data source, Framework Manager tries to compensate by using local processing on the report server. This may have an impact on query performance because the work is done on your report server instead of on your data source server.
In some situations, local processing may require more data to be retrieved from the data source server, which has an impact on both the data source server and the network. For example, OLAP functions are not available in a relational data source. If you attempt to use OLAP functions with a relational data source, Framework Manager uses the dimensional information in the data source to generate a local cube and run the OLAP functions against the cube. This requires retrieval of dimensional information from the data source server and extra processing on the report server.
From the Project menu, select Project Function List.
Click Define Quality of Service.
Expand the tree nodes to view the quality of service for each function.
To override the quality of service, click the arrow beside each function and select the quality of service indicator from the list.
After changing the quality of service, you can add detailed information about the function in the text box on the right.
This information becomes available to your users and can assist them in determining whether to use this function in their reports.
Tip: Click Remove override to set the quality of service back to the default.
Click OK.
You can modify the properties of a data source that was created using the Metadata Wizard in Framework Manager. The data source properties help you control and optimize the way queries are run against the database.
You cannot modify the properties of a data source that was created using the portal. These data sources can only be modified in the portal. For more information, see the Administration and Security Guide.
Data Source Property | Description |
Name | Descriptive name of the data source connection provided by the user at the time of creation |
Query Processing | Determines whether SQL processing is performed by the database server or processed locally |
Rollup Processing | Determines whether aggregate rollups are computed locally or in the database |
Content Manager Data Source | Specifies the name of the data source as it is identified in the Content Manager. If using an XML data source, this property may be parameterized. |
Catalog | Represents different information for different databases. For example, if the database is SQL Server, the element contains the name of the database; if the database is Oracle, it is not used. |
Cube | Specifies the name of the cube |
Schema | Represents different information for different databases. For example, for SQL Server or Oracle, the element contains the name of the owner. |
Type | Specifies the type for the parent object. |
Query Type | Specifies the type of query model that this data source understands. For example, SQL sources are relational and MDS sources are multidimensional. |
Query Interface | This element contains two letters, identifying the provider type. It is maintained by the application. |
Function Set ID | Defines the function set that applies to a data source. Used in the initial population of the function sets of a security view when a package is created. |
Parameter Maps | References a parameterMap that represents a DB2OLAP alias table map. |