All

I am using SQL SQLDBM and sending the query to DB2. The query takes very long.
The SQL trace gives me the FOC 2616, which is the reason for not aggregating at DBMS-side. This query always ran very fast.

What is meant by 'Aggregation disabled by user'?

Regards
Ron

This message has been edited. Last edited by: FP Mod Chuck,

Ron

You will need to post your code so we can debug.

quote:

This query always ran very fast

Find out what changed.
Turn on SQL Trace to see what your code is generating.
Turn on &ECHO to look at any substitutions.
Did you upgrade DBMS?

All

what I don't like at Focal Point, is that I am not able to post screenshots. Yeah, there is some Image URL, but don't know how it works.
If I can mail my screenshots to somebody personally, let me know.

Situation is as follows. We have two reporting servers, one is an UAT (User Acceptance Test) environment, the other is production. But both servers point to the same DB2 production database.
The table involved contains 100 million rows.
I run the query from InfoAssist and I am using exactly the same business view.
However, in UAT, after 20 minutes I still haven't any response. In Production I get my response after 3 seconds.

In UTA the SQL trace says:
FOC2590 - Aggregation not done for the following reason:
FOC2616 - Aggregation disabled by user

In production the SQL trace says:
FOC2689 - Aggregation done

The 'funny' thing is. I compared some more business views on UAT and PROD. And guess what. Every SQL trace in UAT gives for every business view the same FOC2616.
In other words, it seems like the cause in the environment. We did not upgrade de UAT server. We did not upgrade the RDBMS.

Disabled by user?? I am disabling nothing

This message has been edited. Last edited by: Ronibi,

Can you create a test.mas for a DB2 table. Don't join it to anything else and run a report off of this test.mas file. See if the FOC2616 still happens. Then edit the master file and remove the BV. See if a simple report still gives you an error. If a very simple master still generates an error find out if you still have this problem when testing with Admin user id. Difference in behavior could be user profile settings. The next step is to compare configurations. edasprof.prf is a good place to check. See if the UAT and PROD have the same settings. Maybe there's something in your profile that triggers the optimization problem.

Also, check to see if TRACE is turned on in the UAT. That might also slow things down.

Thnx for helping me out.
Edasprof on UAT had the next addition: ENGINE DB2 SET OPTIMIZATION NOAGGR
That caused the problem. I don't know how it got in, but removing it solves everything.
Because now aggregation is done by the RDBMS

Thnx again for advising and helping me solving it.

Case closed

regards
Ron