8/3/2019 Cognos Work Description

1/3

COGNOS WORK DESCRIPTION

Involved in installing, configuring and Administering Cognos components on Windows and UNIX environment.

Involved in Complex Dashboard type Report Creation using Report Studio.

Create a semantic layer using Framework Manager.

Involved in Cube generation for analysis purpose using Framework manager and Cognos Transformer.

Played the role of Team Member, Module lead and Cognos Administrator.

Performance tuning and Quality Control.

Review of the work and Troubleshooting.

Deploying reports and cubes in client environment.

Acquired strong soft skills required for IT industry

Review of the work and Troubleshooting.

Providing the status update and coordination between offshore and onsite teams.

1. It's not DBA's job to tune Cognos reports. It's best suited for Cognos admin.

If the DBA doesn't have Cognos reporting skill, then it's just waste of time.

Because, the problem may be in the report and you'll be just spending time trying to fix outside the report.

2. Cognos reports' sql that you get from Cognos queries are not much help.

It only gives you idea of query sent to database.

Cognos report server may be the culprit taking hours after it gets data from database.

The report may have local calculations, aggregations, joins, etc... that you cannot do nothing from outside.

Unless of course, if you decide to create summary tables for each report's calculation, then it'll be helpful.

I have some reports that take hours to run but the individual queries from report only take a minute to run.

3. If the report is already at it's best, then DBA can do something.

Create indexes in the key fields that report queries are joined.

ETL summary tables and use report to just get the summarized data.

I don't think sorting will help much as it depends upon how the report displays data.

4. Hate to say this, but the app team members who created report may not have designed the report in the

best possible way. I have seen report writers who have worked for over 5 years and doing very bad report

design.

So, take a look at the report itself:

a. Can the report be redesigned? Does it have too many calculations that can be coded in a different

8/3/2019 Cognos Work Description

2/3

expression?

b. Does the report has one huge query that can be divided into multiple sub-queries and joined/unioned

later?

c. Does the report has graph that's taking time to generate at presentation layer?

d. Is it possible to add extra prompts to narrow the data set?

e. Create parent/child reports so the report only runs detail data for a particular parent data.

Hope you got some direction as the solution depends upon what you can find about the questions above.

Strictly from DBA's side, there is not a whole lot to tune Cognos reports except adding indexes and making

sure the database doesn't get hammered by other applications.

2. the issue may be in the FM model where the joins are defined.

If the model is not optimum, then you'll get crazy sql statements that perform bad.

Looks like it's time to review not only reports but FM model as well.

But you can start by doing what you can do in the database first.

3. About Index Scan - index scans are not always bad, sometimes index scan outperforms index seeks if

majority of the index pages are satisfied by the query. If the satisfied rows are small then you are missing

useful index. Analyze the execution plan to find out the missing index and create it.

Sorting - Create a covered index on the sorting column.

As an additional step check the index fragmentation, statistics are outdated, locking and blocking issues,

recompilation etc .

4. In your situation, check the execution plan and find out where the report is taking time.

If it's taking time in querying database, index, data integrity etc... in the server helps.

There is not a whole lot of things to do just in the database if the report is taking time processing calculations

in the reporting layer.

Summary tables is a different approach and you can still do the indexing/sorting whatever before this.

Summary tables are pre-calculated tables so that report doesn't need to do any calculations int reportingserver.

This allows Cognos report to just query the summarized data and display.

When we did this for a report, the run time from 90 minutes went down to 18 seconds. But this is not

possible for each report or you'll end up creating a table for each report which is a nightmare to maintain.

Another thing to think about is: Are all report running slow or just few of them?

5. Summary tables are aggregate tables.

You have to look at the report to see what calculations is it doing.

For example, if the report is summarizing total sales for a year by month and by salesman, these

calculations take a long time in report server.

If you create a new table in the database that pre-calculates the sales summary by month and by salesman,

the report then needs to be pointed to the new table and it just displays pre-calculated fields instead of

calculating them on the fly in Cognos.

It involves following steps:

1. Assess report calculations/aggregations.

2. Create the calculations in a new table.

3. Modify FM model to include the new table.

4. Modify the report to remove the Cognos calculations and point to new the table for displaying data.

8/3/2019 Cognos Work Description

3/3

Yes, it's a lot of work especially if the table only satisfies one report.

Assess the reports and may be one table can satisfy more number of reports.