Performance of mapping with FILTER

Question

LS,
How to tackle performance of OWB 10g-generated mappings in Oracle10g?
Database: 10.1.0.2.0
OWB repos: 10.1.0.1
OWB client: 10.1.0.2
Situatie:
A StorageArea (1) with data of more than 1 day, each row has a column filled with a date, to which this row ‘belongs’. All tables have a pk of a dwkey, and a uk composed of the date-column extended by a logical key (one or more columns).
A StorageArea (2) with the same kind of tables, only modified / enriched / unified etc. All tables have a pk of a dwkey, and a uk composed of a logical key (one or more columns) extended by the date-column.
The mappings responsible for putting the data in SA(1) do analyze the table (90%), but not the indexes. So I manually do that by dbms_stats.gather_index_stats after all mappings to SA (1) are done.
I gather the statistics, because the mappings to SA (2) all have a FILTER containing “date-column = <Get_Current_Date>”. Any other (outer)joins made by the mappings, are all based on the uk’s in SA (1). So, I expect a good performance of Oracle10g, because it will (eventually) use the indexes of the uk’s.
BUT THEY DO NOT !!!!
The mappings responsible for putting the data in SA(2) do analyze the table (90%), but not the indexes. So I manually do that by dbms_stats.gather_index_stats after all mappings to SA (2) are done.
So, when starting a mapping towards SA (2), each side (sources and target) is up-to-date on their statistics in table and indexes.
First I thought this is something of Oracle10g, but it’s the OWB generated source.
The filter in the source will look something like:
“WHERE date-column = package.function-call”
Now the indexes will NOT be used. Instead, in the merge-statement source and target tables are scanned FULLy.
They will be used if one would ask:
“WHERE date-column = sysdate”
or if one would ask:
“WHERE date-column = TRUNC(sysdate)”
But even “TRUNC(sysdate)-30” is too much and will lead to FULL scans.
I changed my mapping by defining a constant “current_date”, which is filled in the mapping specification by the package.function-call. Now the filter in the source looks like:
“WHERE date-column = mappingname.constantname”.
When asked for the execution-plan on the select-statement, it STILL denies the indexes.
- What can I do to put on the turbo and to make sure the customer (and I) are very pleased they choosed Oracle and its tooling?
Mind you, the difference between no index (costs 7900) and uk-indexes (costs 6) are VERY BIG, according to the explain plan.
It takes 8 minutes to merge 270.000 rows. This can’t be serious, the Oracle10g solution to very big databases and datawarehousing in special!!
Regards,
André Klück

Answer 1

Hi Andre,
What happens if you start using hints to "force" the index usage?
One thing I would try is at database level, take the OWB generated code as is (no hints, or just the defaults ones for parallel).
Run this in SQL Plus, and record the performance and the plan. Then force it to use the index, using hints and compare.
If that helps, revert to OWB and apply the hint in there (or do it all from there of course). Run with hints.
I'm curious to see if you get it to run on the indexes by forcing it...
Furthermore, 270.000 rows in 8 minutes. Was that bad or good? Reason I'm asking is whether you have hardware capacity to go faster? Any I/O issues that prevent you from going faster?
In general it will be hard to solve this on the forum, so just try the SQL statement and hint it, if you get a good plan try to get that out of OWB.
If it still does not work let me know...
Jean-Pierre