woods
woods

Reputation: 243

Why is my COGNOS report taking 11-12 hours to run?

I have a daily scheduled COGNOS report created by someone else a few months ago. This developer left the company over a month ago. From what I'm told this report ran fine. Then a week before the developer left the company, it began to take longer and longer to run. Now its taking 11-12 hours. There is no documentation for the report that would indicate any possible changes made by the developer that would cause this. And as a very recent new hire; I am, so far, unaware of any db changes that may have caused the issue to begin. I was hoping that someone more experienced could point me in the right direction.

Do I need to investigate changes to the db? Could this be a cache issue? Maybe a permissions problem or just an issue with the created schedule?

Let me know what additional info would be helpful.

Upvotes: 1

Views: 1021

Answers (2)

user10465430
user10465430

Reputation: 21

Which type of datasource has been used for this report? Multidimensional or relational? Which mode has been used - classic or dynamic? Is this report sending out information to different users via email? Maybe bursting and master detail has been used which is often a performance killer.

Upvotes: 0

VAI Jason
VAI Jason

Reputation: 544

  1. Check to see if slow performance is connected to a specific data item

Start with a simplified version of the report

For example if you have a report with 10 columns

Reduce the report down to 3 columns and compare the performance.

Then add back one data items/column and re-examine If you notice a difference linked to a specific data item, examine the changes in the SQL statement. Look for outer joins or maybe complex expressions with functions which can impact performance

  1. Look for a logic trap

Maybe you are witnessing a logic trap Like a data chasm where you are getting the cartesian product for results because the request is a many to many relationship

  1. Check the data source system

It could be the time of day the process is running is now in conflict with another competing process that is taking priority/all of the resources To help test this, try to run the analysis during a non-peak time

  1. Cursor Isolation/lock escalation Check your settings to see what your cursor isolation level is Be careful, don't just change this value casually as it will impact access to the data source. If you have a test system, try uncommitted read (aka dirty read) to avoid locking issues. If another user is maintaining or updating data/operation tables, this could impact the SQL response time

Upvotes: 0

Related Questions