1) I have requirement where i have to join with some tables and views.
For a Job atmost we're using 5 join stages and 10 sort stages( since the pre-requirement for join stage is to sort the data).
Since i have 5 join stages with two inputs, for each input one sort stage so total will be 10 sort stages.And we're joining on different keys and same keys again also, based on the business requirement.
I want to know whether such kind of design will be reliable or not.
If not, then please tell me how many number of join and lookup stage i've to use per job.
2) In some cases i'm joing multiple sources(more than two) with one Join stage, will this design affect the job peformance or not?
3) I heard that we shouldn't use multiple Join stages on same keys in one job, since this affects the job performance..
Am i right ?
Please help me out..
Any help will be greatly appreciated..
Regards
Number of Join in a Job
Moderators: chulett, rschirm, roy
Number of Join in a Job
RK Raju
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
1) Yes, for some value of "reliable" and if you have sufficient resources on the server.
2) Yes - any load will "affect performance" (whatever "performance" means)
3) Who told you that?
2) Yes - any load will "affect performance" (whatever "performance" means)
3) Who told you that?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The best scenario for scenario 3 (need more than one Join stage) is to use more than one Join stage. Provided your system has the resources, there is no limit on the number you can have. But that's a major proviso.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.