Continuous Surrogate key generation for multiple runs

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
swathi.yanala
Participant
Posts: 9
Joined: Mon Nov 12, 2007 11:38 pm
Location: Hyderabad

Continuous Surrogate key generation for multiple runs

Post by swathi.yanala »

Hi

Is there a possibility in DataStage PX to generate a surrogate key which is continuous for multiple runs also.

For Example: If in 1 run, the surrogate key generator generates 1 through 10 keys, then in next run the key count should start from 11 and continue the count from there on.


Thanks in Advance
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Yes. All you have to do is to record where you left off, and add that to a key generated from 0 or 1 in the next run.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
balajisr
Charter Member
Charter Member
Posts: 785
Joined: Thu Jul 28, 2005 8:58 am

Post by balajisr »

Yes. You need to set "Start Value" as 11.

Get the maximum value from the previous run,increment it by 1 and set this value as a job parameter to this job. Use this job parameter as "Start Value".
gnan_gun
Participant
Posts: 30
Joined: Thu Aug 02, 2007 5:31 am
Location: Mumbai, India

Post by gnan_gun »

In Datastage u can, But u have to pass maximum value of last run to startvalue by manually. By Using the Oracle Sequences you can achieve this with out passing any params by manually. Just create a sequence in oracle and use it where u required.
Ex: Insert in to table(empid,ename, sal) values (oracle_sequence.nextval, orchestrate.ename, orchestrate.sal)
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

U did not ask the question. U is the name of one of our posters.

This is one of the reasons we ask posters to adhere to a professional standard of written English on DSXchange. DSXchange is not a mobile telephone; SMS may have its place, but DSXchange is not that place.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
crouse
Charter Member
Charter Member
Posts: 204
Joined: Sun Oct 05, 2003 12:59 pm
Contact:

Post by crouse »

Be careful using database sequences in PX jobs... sooner or later they WILL be the slowest link in your job(s), and could slow the job(s) down significantly.
Craig Rouse
Griffin Resouces, Inc
www.griffinresources.com
srividya
Participant
Posts: 62
Joined: Thu Aug 25, 2005 2:31 am
Location: Ashburn,VA

Post by srividya »

Yes ... using the database sequences definitely slowed our jobs significantly... The more data we tried processing, the worse the performance got ... We have to go for a re-design :? ....

This is what we are doing(trying to :oops:) ......We have created a UNIX script which returns the maximum of the sequence from the table. We are returning this Value as output of this script.

In the sequencer job we are calling this before the required job and pass the output to the job

Now i am working on whether i can pass the pouput directly in the sequencer or whether i will need to assign this to a variable in UNIX script only ....

Will keep you posted once i get something ....
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Could I suggest using a DataStage job (a server job is most efficient) rather than a UNIX script for extracting the next value from the target table? Using the server job's user status area makes it easier for the job sequence to retrieve the value, which it can do with an unqualified reference to the activity variable $UserStatus.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply