cube optimization

1. Shorten processing Time in Transformer: a. Use multiple queries to reduce the size of each source file and shorten processing time in Transformer. b. Specify how the cube is processed, either by reducing the number of categories in the cube or by optimizing queryingc. Use incremental updates so that you only add new data during the cube updates. 2. Shorten access time in PowerPlay: a. Reduce the number of categories b. Maximize data consolidation by using the auto-partition feature and by adding a sort step before records are written to the cube, which decreases cube size and shortens access time in PowerPlay. c. Enable auto-partitioning for large cubes, which can significantly shorten access time in PowerPlay. PowerCube Optimization Methods are: Categories, Data Passes, Direct Create and Auto-Partition. Categories: Minimizes the number of categories in a cube. Transformer adds only categories that are referenced in the source data or specifically designated to be included. Categories optimization requires an extra data pass for each cube to find the categories needed for that cube.Note: This is the default optimization setting for models created in Transformer versions prior to 6.0. Data Passes: Optimizes the number of passes through the temporary working files during the creation of a cube. Transformer assumes that all categories will be required in the resulting cube, and does not pass through the source data to determine which categories are required. Although included, unreferenced categories will not be visible in PowerPlay. Direct Create:Direct Create works by reading from the database and then writing to the cube immediately. It will result in a quicker cube build however the cube will be much larger in size because there are no consolidated records. Auto-Partition: Enables the Auto-Partition tab, where you can set the parameters for Transformer to devise a partitioning scheme.

We are facing an issue in implementing Data level security using Cognos transformer 8.3. The details are as described below. Really appreciate if anyone of you could help us in resolving the same. As-Is scenario: Our client has around 20 cubes developed in Cognos Version 7.1. These cubes are rendered to users in PowerPlay client with no security features inbuilt. The transactions are analyzed across Material, Customer and Time in these cubes. The data sources to the model files are CSV's which gets created daily from respective fact and dimension tables. Business requirement: We are now upgrading these cubes to Cognos version 8.3 (Transformer) and render the cubes created through Cognos Connection portal with data level security. The model file will is migrated to 8.3 from 7.1. The requirement is that the data (Facts/Dimensions) in these cubes need to be restricted based on user groups (currently we have 4 user groups). To be more specific, any user in a group should see only materials, customers and transaction related to his/her group in the cube (Left Panel of Insertable Object section) and not others. Also, a person in "Super User" group should be able to see the complete data across all user groups. This should be done with out any changes to the existing cube hierarchy to the user. Approach considered and Issues faced: Approach 1 - Add an additional field on top of each drill down paths for all dimensions (Material & Customer), which could be used to restrict the data as per the user requirement above. Have a customized view in the model for each dimension folder and restrict the data in each drill down based on the values of field added after generating the categories. Also, to ensure that users are not impacted by an additional level added in the hierarchy of cube model, we have suppressed the newly added field in the model file itself. Issue - For all the user groups, it is working fine except for Super Users who want to see the complete data. In case of a Super User, all fields in the drill down paths of dimensions are being repeated multiple times due to the new suppressed field added on top of them. (We were not able to suppress/unsupress levels in a dimension level based on user groups) Approach 2 - Create separate cubes from a single model (Cube groups) based on the field to be restricted.

Issue - As the number of cubes are around 20, we would end up having 80 (20*4) physical cubes. This leads to increased maintenance and decrease in flexibility of cubes. As this is a very common business requirement, we presume that we are missing on some options in Cognos that can be utilized. If there are any additional approaches we can look into OR if the approaches mentioned above could be corrected/modified please let us know as we need to get back to the client ASAP.

Cognos Performance
updated Apr 5, 2011 11:04 pm | 14,460 views

Most of us will have to analyse and tune the performance of Cognos on a regular basis. This article is intended to describe tools and method to analyse and improve the performance of Cognos. Update: After writing this article, I now added more information on the Cognos Advanced Settings
Contents [Hide TOC]

1 2 3 4 5 6 7

Tools Cognos server settings Cognos service settings Cognos Framework Manager settings Cognos Report Studio settings Client settings Sources

[edit] Tools
Cognos 8 includes a sample audit model in Framework Manager. The default location is c8_location/webcontent/samples/Models/Audit/Audit.cpf. There also is an extension pack for the Audit packages and there are more detailed reports available. There also are tools installed on the server, that can provide you with more detailed information:

c8_location/bin/logconsole.exe gives you the possibility to log more details of different services c8_location/bin/logviewV2.exe is a tool that is able to transform the cogserver.log files that are created when logging on the filesystem is enabled (by default in the ../logs/ directory)

And of course you can use the default OS monitoring (like Windows task manager) or a open source variant like Nagios to see in what is happening on the server(s).

[edit] Cognos server settings

Because the Cognos core is not changing every day, you can enable (IIS/Apache) caching. This can speed up the performance, because all images, javascripts etc. will be only retrieved after they're expired (for example: after a week). Scheduled reports that are too large, are rejected by a SMTP service. Cognos only sees that it cannot be send, and will try it again, every hour (!). This causes a lot of reads on the Content Store (if they're too large, they're a least 10MB), and causes a lot of disk I/O, because the JobService (of EventManagerService) created a temp file before sending the e-mail again. Cognos can create large temp files for intermediate results. On high loads, this can cause the disk to flood. Temp files of 2Gb have been seen, so monitor the temp directory and make sure there is enough space to write to.

[edit] Cognos service settings

Some service aren't used on a day-to-day bases (or aren't used at all). High loglevels have a negative influence on the performance. Full logging will nearly break a machine and is never advised on a production environment.

For every service the loglevel should be Basic or less: This will log all the errors, but has the least effect on performance. Some services don't need logging to be enabled at all. In a distributed environment you can apply routing rules to guide users to different machines. You can assign different machines to different machine groups or assign a package to a package group. For example: interactive reporting on a given package will be routed to three machines, all other reporting will be done on two other machines. On the first three machines you can disable jobservice, eventmanagerservice, batchreportservice, metadataservice etc. By default, IBM Cognos 8 executes queries in a report sequentially. Depending on the server environment it might be possible to improve report run performance by enabling parallel query execution. This setting can be adjusted in the advanced server properties for the report service and the

batch report service. When concurrent query execution is enabled, the report server determines which queries in the report can be run in parallel. There are a few parameters that can be adjusted to manage concurrency in Cognos 8: o RSVP.CONCURRENTQUERY.NUMHELPERSPERPROCESS - number of helpers per report service (and batch report service) process. By default the parameter value is 0 (concurrency disabled). o RSVP.CONCURRENTQUERY.MAXNUMHELPERSPERREPORT - maximum number of helpers per report. By default it is set to 1. Has no effect when the above parameter is set to 0. o RSVP.CONCURRENTQUERY.ENABLEDFORINTERACTIVEOUTPUT enables concurrent query execution when the report service is producing interactive output (disabled by default).

[edit] Cognos Framework Manager settings

Using (not-materialized) views in your packages makes it impossible for Cognos to retrieve metadata, because a view is dynamic. Using a view can be a good practice, but keep this in mind. Joins over different views can influence performance. On oracle, views very rarely cause a metadata problem in Framework Manager. Even with extremely complex views (20 or more pages of sql), Framework manager is able to resolve data types correctly. This may not be the case (as mentioned above) in other databases and may be driver dependent. For complex queries, views significantly improve report performance by pushing all of the data processing to the database. Even with Database only processing, the sql generated from the framework is, typically, not as performant as well tuned sql. The database, generally, processes the data, joins, and aggregations more efficiently. Generally, views, used as a performance optimization (not a default), can be a very effective strategy for improving framework performance.

[edit] Cognos Report Studio settings

If your database is strong enough and you want to let your queries be executed on the database, check these settings for your query o Processing: Database only o Rollup Processing: Database o Execution Optimization: All Rows o Use Local Cache: No o Use for Parameter Info: Yes or No (depends on your design) o Execution Method: Concurrent (if available, see services) Disable Selection Based Interactivity (less HTML will be generated)

In Report Studio, if you don't use detailed chart information, you can minimize the number of Hotspots in a chart to 0 (zero). This reduces the HTML that is been generated, especially with complex charts In Report Studio, menu Data > Drill Behavior > uncheck Allow this report to be package-based drill-through source In Report Studio, menu Data > Drill Behavior > uncheck Accept dynamic filters when this report is a drill-through target Validation Level is by default set to Warning. In the menu Tools > Validate Options > Validation level, this can be set to Information. This might give extra tips on joins, metadata or other "less than perfect" issues.

[edit] Client settings

A virusscanner can have a negative effect on the performance, because every http connection and every download is being scanned. See if you can add your intranet/extranet to a trusted site/trusted zone, so scanning is disabled.

Hi All, We are facing an issue in implementing Data level security using Cognos transformer 8.3. The details are as described below. Really appreciate if anyone of you could help us in resolving the same. As-Is scenario: Our client has around 20 cubes developed in Cognos Version 7.1. These cubes are rendered to users in PowerPlay client with no security features inbuilt. The transactions are analyzed across Material, Customer and Time in these cubes. The data sources to the model files are CSV's which gets created daily from respective fact and dimension tables. Business requirement: We are now upgrading these cubes to Cognos version 8.3 (Transformer) and render the cubes created through Cognos Connection portal with data level security. The model file will is migrated to 8.3 from 7.1. The requirement is that the data (Facts/Dimensions) in these cubes need to be restricted based on user groups (currently we have 4 user groups). To be more specific, any user in a group should see only materials, customers and transaction related to his/her group in the cube (Left Panel of Insertable Object section) and not others. Also, a person in "Super User" group should be able to see the complete data across all user groups. This should be done with out any changes to the existing cube hierarchy to the user. Approach considered and Issues faced: Approach 1 - Add an additional field on top of each drill down paths for all dimensions (Material & Customer), which could be used to restrict the data as per the user requirement above. Have a customized view in the model for each dimension folder and restrict the data in each drill down based on the values of field added after generating the categories. Also, to ensure that users are not impacted by an additional level added in the hierarchy of cube model, we have suppressed

the newly added field in the model file itself. Issue - For all the user groups, it is working fine except for Super Users who want to see the complete data. In case of a Super User, all fields in the drill down paths of dimensions are being repeated multiple times due to the new suppressed field added on top of them. (We were not able to suppress/unsupress levels in a dimension level based on user groups) Approach 2 - Create separate cubes from a single model (Cube groups) based on the field to be restricted. Issue - As the number of cubes are around 20, we would end up having 80 (20*4) physical cubes. This leads to increased maintenance and decrease in flexibility of cubes. As this is a very common business requirement, we presume that we are missing on some options in Cognos that can be utilized. If there are any additional approaches we can look into OR if the approaches mentioned above could be corrected/modified please let us know as we need to get back to the client ASAP. Even Exclude works for security along with Apex it all depends on what security we need . I had a similar requirement for implementing data level security in Cubes.The requirement was such that the particular Client should only see his data i.e all region for which the client has access to when he logs in. To implement this first we created a hierarchy in the dimension on Client and Geography so that client specific geography appears.Now for restricting the Access to the client,as we can not use Macros properties in the Transformer we had to use Custom Views.We got different groups created for different client and as per that client group created different Custom Views in Transformer and mapped the group with Custom view.In the custom view we used Exclude property to restrict the client access. For e.g. we have 2 clients Client1 and Client2,so in the client look up we get two values as Client1 and Client2 now we can get two different groups created for Client1 and Client2 and will map this group with their respectively Custom view in the transformer.Now for Custom view of Client1 we will exclude the Client2 and similarly for Client2 View we would exclude Client1. We can also restricts the metrics/facts for particular client,for that we just need to uncheck the fact in the custom view section for the particular client ,so only the fact to which we give access would be accessible to the user