Is Splitter degrades performance?

Question

Hi,
I am using Oracle Warehouse Builder 10G R1.
Even the origin of the question is from OWB, its mainly regarding database performace.
Here my scenario is as follows.
There is a mapping , internally OWB creates a package.
First Way
In that mapping there are two sources A and B .
I used a Join operator and used Full outer join. From there I am doing lookup into tables and finally data is inserted int Table C.
In the package it is creating a cursor for Join operator.
I mean,
Cursor JOin_A_B
as selct * from Table_A, Table_B where A.column_A (+) = B.Column_B
... so on.
Second Way
I used a Join operator and used Full outer join. Instead of direclyt doing lookup into tables as in the first way, I used a splitter operator where it divides the data from Join to two groups.
The groups are as follows
1st group --> the records which satisfy the condition as Column_B is null
2nd group --> the records which satisfy the condition as Column_A is null
3rd group --> the remaining records (which are matched in both A and B)
So for this owb is generating the code in such a way that, it is creating one cursor for each group.
Son in the "First Way" it is only defining one cursor .
And in the "Second Way" it is creating 3 cursors.
Here each source is in GBs. Almost more that 2 Crore records are there in each source.
I am not much aware of database perfomance issues.
Could any one please explain which is the best way considering performance issues.
One more thing I would like to add here, in the first case (First Way), even it is not required I have to do lookup into tables and get the keys.
But in the "Second Way" according to the group wise data, I use lookup tables.
Thank you,
Regards,
Gowtham Sen.

Answer 1

Hi Gowtham,
Let me clearly understand the design of the maps.
First way
From the outgrp of joiner, you are picking up A.Col_A and B.Col_B, and doing a lookup in a tbl (say LKP_TBL). Here 3 cases could be possible --
a. A.Col_A is null -->> In this case lookup will return no rec (coz operators like = doesn't work with variables having null value)
b. B.Col_B is null -->> In this case lookup will return no rec (same reason as above)
c. both A.Col_A & B.Col_B is not null --->> in this case the lookup will retrun some value
I assume that you have defined the lookup such a way that it will return 'no row' on no match. So effectively the target table would be updated by records returned in case c ONLY.
Second Way
The outgroup of the joiner goes to the Splitter. Now here is my doubt. Whenever you are pulling records from outgrp1 or ourtgrp2 to use in the lookup, they will never return any row (since eith A.Col_A or B.Col_B would be null.). Only records returned from the 'Remaining Row' grouped when used in the lookup, would return values from the lookup, right?
Then probably, you are having 3 instances of the same target table. They are being updated from each of the 3 outgroups of the splitter with some target load order defined. But you see, in this case, really you dont need to use a Splitter, since there will never be a record-set after the lookup corresponding to outgrp1 & outgrp2.
I know I haven't answered your specific question about the database performance related to 3 cursors or 1 cursor!! But before I started creating such a scenario to test the execution path and overall performance, the design of the 'Second Way' seemed not appropiate to me.
Could you please confirm whether I am in right track in visualising both the designs?
Cheers,
Swagata