Governor in Framework MGR
Governor in Framework MGR
Governor settings means we will set some restricted data of retrieval. we will set for report table limits data retrival limits query execution time governor setting is nothing but filter in fm using fm u can set properts Governors setting is used 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 will use the new settings. There are a number of governors that you can set. Governor settings in the model can be overridden by governor settings in Report Studio. 1.Report Table Limits You can control the number of tables that a user can retrieve in a query or report 2.Data Retrieval Limits You can control the number of rows that are returned in a query or report 3.Query Execution Time Limits You can limit the time that a query can take 4.Large Text Items Limit You can control the character length of BLOBS (binary large objects) that a user can retrieve in a
query or report 5.Allow Enhanced Model Portability at Run Time You can use a separate but structurally similar data source at run time. The database schema must be the same between the two data sources. 6.Allow Usage of Local Cache Select this governor to specify that all reports based on this model should use cached data. 7.Outer Joins You can control whether outer joins can be used in your query or report. 8.Cross-Product Joins You can control whether cross-product joins can be used in your query or report. 9.Use With Clause When Generating SQL You can choose to use the With clause with Cognos SQL if your data source supports the With clause. 10.Suppress Null Values for Dimensional Data Sources 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. Because null suppression is performed by the underlying data provider, in this case SAP BW, this reduces the amount of data transferred to the various Cognos 8 client products, thus improving performance and returning only relevant data in the report. Governer Settings------------------
-------------- We will use for Security purpose. Query Execution Time Limits--------------- we need to specify the Time in this option. Outer Joins-------------------You can control whether outer joins can be used in your query or report. Cross-Product Joins--------------------You can control weather cross-product joins can be used in your query or report. Allow Usage of Local Cache --------------------Select this governor to specify that all reports based on this model should use cached data. Large Text Items Limit----------------You can control the character length of BLOBS (binary large objects) that a user can retrieve in a query or report. Governor setting is basically used in Frame work Manager to improve the performance of the reports in the way like retrieving the number of tables or number of rows to be displayed.These setting are done before creating the packages to ensure the data or the information that is to be retrieved is restricted.As well you have different types of governor setting depending upon the data you want to retrieve.
What do you understand from governor settings in Framework manager and how to set it?
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. You can control the number of tables that a user can retrieve in a query or report. Maximum Number of Report Tables Query Execution Time Limit Large Text Item Limit Outer Joins Cross-Product Joins Shortcut Processing Allow Usage of Local Cache Allow Dynamic Generation of Dimension Information Steps 1. From the Project menu, click Edit Governors. 2. Specify the limits that you want to use when retrieving data. 3. Click OK.
In IBM Site they explain it very clearly. http://publib.boulder.ibm.com/infocenter/c8bi/v8r4m0/index.jsp?topic=/com.ibm.swg.im.cognos.ug_f m.8.4.0.doc/ug_fm_id19029SetGovernors.html
Set Governors
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. The governor settings that take precedence are the ones that apply to the model that is currently open (whether it is a parent model or a child model). 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.
Maximum Number of Report Tables
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.
Maximum Number of Retrieved Rows
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
Query Execution Time Limit
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.
Large Text Item Limit
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.
Outer Joins
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 create a new model query subject based on other objects
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.
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.
Shortcut Processing
You can control how shortcuts are processed by IBM 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.
SQL Join Syntax
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 CQEConfig.xml file to determine the syntax. If there is no entry in the CQEConfig.xml file, then the Implicit setting is used. 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.
Grouping of Measure Attributes(query items)
The Server determined setting uses the CQEConfig.xml file to determine the setting. If there is no entry in the CQEConfig.xml file, then the Disabled setting is used. The Disabled setting prevents aggregation of the measure for the attributes. This is the default behavior. For example,
select Product.Product_line_code as Product_line_code, Order_method.Order_method_code as Order_method_code, //measure attribute
The Enabled setting allows aggregation of the measure for the attributes. Note: This is the default behavior for IBM Cognos 8 versions prior to 8.3.
select Product.Product_line_code as Product_line_code, Order_method.Order_method_code as Order_method_code, //measure attribute XSUM(Sales.Quantity for Order_method.Order_method_code, Product.Product_line_code) as Quantity //aggregated measure from ...
You can control the use of the minimum aggregate in SQL generated for attributes of a level (member caption). The Server determined setting uses the CQEConfig.xml file to determine the setting. If there is no entry in the CQEConfig.xml file, then the Minimum setting is used. The Minimum setting generates the minimum aggregate for the attribute. This setting ensures data integrity if there is a possibility of duplicate records. For example,
select XMIN(Product.Product_line for Product.Product_line_code) as Product_line, //level attribute Product.Product_line_code as Product_line_code from (...) Product
The Group By setting adds the attributes of the level in the group by clause. with no aggregation for the attribute. The distinct clause indicates a group by on all items in the projection list. The Group By setting is recommended if the data has no duplicate records. It can enhance the use of materialized views and may result in improved performance. For example,
select distinct Product.Product_line as Product_line, //level attribute Product.Product_line_code as Product_line_code from (...) Product
You can control the use of the minimum aggregate in SQL generated for attributes of a determinant with the group by property enabled. The Server determined setting uses the CQEConfig.xml file to determine the setting. If there is no entry in the CQEConfig.xml file, then the Minimum setting is used.
The Minimum setting generates the minimum aggregate for the attribute. This setting ensures data integrity if there is a possibility of duplicate records. For example,
select PRODUCT_LINE.PRODUCT_LINE_CODE as Product_line_code, XMIN(PRODUCT_LINE.PRODUCT_LINE_EN for PRODUCT_LINE.PRODUCT_LINE_CODE) as Product_line //attribute from great_outdoors_sales..GOSALES.PRODUCT_LINE PRODUCT_LINE group by PRODUCT_LINE.PRODUCT_LINE_CODE //key
The Group By setting adds the attributes of the determinants in the group by clause with no aggregation for the attribute. This setting is recommended if the data has no duplicate records. It can enhance the use of materialized views and may result in improved performance. For example,
select PRODUCT_LINE.PRODUCT_LINE_CODE as Product_line_code, PRODUCT_LINE.PRODUCT_LINE_EN as Product_line //attribute from great_outdoors_sales..GOSALES.PRODUCT_LINE PRODUCT_LINE group by PRODUCT_LINE.PRODUCT_LINE_CODE //key PRODUCT_LINE.PRODUCT_LINE_EN //attribute
This governor specifies whether generated SQL uses parameter markers or literal values. The behavior can be set using the model governor or studio query hint. If not set in the model or the studio, it is obtained from the server configuration file. Dynamic SQL applications have the ability to prepare statements which include markers in the text which denote that the value will be provided later. This is most efficient when the same query is used many times with different values. The technique reduces the number of times a database has to hard parse an SQL statement and it increases the re-use of cached statements. However, when queries navigate larger amounts of data with more complex statements, they have a lower chance of matching other queries. In this case, the use of literal values instead of markers may result in improved performance.
Allow Enhanced Model Portability at Run Time
This governor is selected upon initial upgrade of an IBM Cognos ReportNet 1.x model. It prevents rigid enforcement of data types so that an IBM 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, IBM 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.
Allow Dynamic Generation of Dimension Information
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.
Use With Clause When Generating SQL
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 IBM 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 IBM 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 IBM 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.
Steps
1. From the Project menu, click Edit Governors. 2. Specify the limits that you want to use when retrieving data. 3. Click OK.
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.
Steps
1. In the Project Viewer, click the data source you want to change. 2. In the Properties pane, in the Query Processing list box, click either Limited Local or Database Only.
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.
Deciding Whether to Use Query Reuse in Your Environment
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 IBM 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.