How to ensure Cognos executes queries in parallel

[jayatu]

Hi,
I have a report that has multiple queries and I want the queries to be executed in parallel.

How can I ensure this in Cognos. Currently the execution is sequential.

Thanks
Jayatu

[sunosoft]

Check if below link helps you.

http://www-01.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.ug_cra.10.2.2.doc/c_queryexecution.html?lang=no

You should have Cognos admin access if you want to set these parameters.

[Francois51]

If you have access to a database monitoring tool, and that you're database allow it, you will easily see that you have a change in the way it's handled by the database after you activate concurrent queries. We use Solarwinds DBA which is easy to setup and has a trial period.
You should see a spike in the use of resources but it should take less time. 

[nsaxena]

Check if below link helps you.

http://www-01.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.ug_cra.10.2.2.doc/c_queryexecution.html?lang=no

You should have Cognos admin access if you want to set these parameters.

Hi ,

I have a report in which we have 6 crosstabs all from different database views/tables and source is not FM ,its direct sql connection in report for all of them.Report runs slow.
Is it because mode of running is sequential ,not parallel and if i enable concurrent query execution,(with steps as mentioned in below link for example :-
http://raulparracognos.blogspot.in/2014/01/steps-to-setup-concurrent-query.html

Will it help in faster running of report. And what will be the general impact or negative side of enabling concurrent query execution.

Many thanks in advance!

[Francois51]

From my experience :
It MAY help. I guess it depends of many things as the report (many queries), the database vendor, and the actual load on the DB.
Drawbacks :
- You have to activate it on each queries in report
- It will put a heavier load on the Database, which is a good thing, a DB working at 100% is not a bad thing. But since you will generate concurrent queries you will generate contention. So you have to monitor it r at least warn you're DBA.

So for me it's a trade-off between the gain of letting the DB work harder and the slowness you may cause.
We tried to use it here on a pdf report, with sections and based on a huge Framework model where almost the same queries are fired multiple times.
The report executed 3 times faster if I remember well.

[nsaxena]

I agree,

So on DB end , we must make sure to have sufficient primary and secondary log files so that when queries are running in parallel there must be no contention.

Also ,what about other reports,where query mode is still set as sequential(default property) .They will still run with same performance?

[Francois51]

I'm not sure what you mean by "make sure to have sufficient primary and secondary log files".
I was referring for example to latches on an Oracle Database when many queries are accessing the same segment of a table at the same time or CPU contention because you suddenly increase the number of concurrent actives sessions.

As long as you don't touch the queries behavior in the properties inside the report to switch to concurrent, other report should not be impacted...unless you put a heavy load on the DB at the same time with the report where you have concurrent queries, only testing will tell you.