The Aggrigator...dum dum dum :)

kcbland · Post by **kcbland** » Mon Dec 29, 2003 6:40 pm

Search for mutex, it's a common issue.

Hint:

did you enable row buffer in your job?

ray.wurlod · Post by **ray.wurlod** » Mon Dec 29, 2003 10:51 pm

You shouldn't need TRIM on the numerics. This may help. An even more efficient way to handle this is to perform any arithmetic - for example add zero to the number. DataStage always returns the shortest possible string from an arithmetic calculation. And it's definitely quicker, if the item is already numeric.

JDionne · Post by **JDionne** » Tue Dec 30, 2003 7:53 am

ray.wurlod wrote:You shouldn't need TRIM on the numerics. This may help. An even more efficient way to handle this is to perform any arithmetic - for example add zero to the number. DataStage always returns the shortest possible string from an arithmetic calculation. And it's definitely quicker, if the item is already numeric.

The numeric fields that I did the trim(upcase)) to were id fields...Like Port ID. id rather not do any funny stuff to that. im gona search for multex again see if i can find my last post.
Jim

JDionne · Post by **JDionne** » Tue Dec 30, 2003 8:13 am

I have looked at the forum about mutex and all the post that I see want me to increase the time out limit. Well that didnt do anything for me...Im gona go and back out some of my trims and see what I get.
Jim

kcbland · Post by **kcbland** » Tue Dec 30, 2003 9:15 am

viewtopic.php?t=84161&highlight=mutex

viewtopic.php?t=85065&highlight=mutex

JDionne · Post by **JDionne** » Tue Dec 30, 2003 9:21 am

kcbland wrote:viewtopic.php?t=84161&highlight=mutex

viewtopic.php?t=85065&highlight=mutex

ya i read both of those posts...and i have already had row buffers enabled and i had set my time out to 60 seconds. that should have been plenty of time. when i set it to 0 it automaticaly resets it to 1
Jim

roy · Post by **roy** » Tue Dec 30, 2003 10:22 am

Hi,
I don't remember if it was said here or not, was much to read,
did you concider sorting the data (oh yea Ken, I believe, said it )
before aggregating it?
this should speed your aggregator stage and might eliminate the mutex issue since the work for the agg stage would be much easier on the system resources.
(Don't forget to mention the sorted column number in the input section of your agg stage and the ascending/descending sort you made)

IHTH

JDionne · Post by **JDionne** » Tue Dec 30, 2003 10:31 am

roy wrote:Hi,
I don't remember if it was said here or not, was much to read,
did you concider sorting the data (oh yea Ken, I believe, said it )
before aggregating it?
this should speed your aggregator stage and might eliminate the mutex issue since the work for the agg stage would be much easier on the system resources.
(Don't forget to mention the sorted column number in the input section of your agg stage and the ascending/descending sort you made)

IHTH

I have actualy been a very bad forum poster...the type that I hate actualy. The multex error is happening in a job before the aggrigator job. You see i am haveing a problem in the aggrigator in that it is producing more rows of data than the same function in SQL server sql code would produce. So i went back to the job that creates the load file for my aggrigator and did a Trim(upcase)) to all of the fields except my metrics. At this point the job that creates the load file for the aggrigator is failing with the multex error. Im guessing I should have broken it out into another post. What is worse is this very job had done this in the past and i did something to get past it and I CANT REMEMBER!!!! its just about to drive me crazy.
Jim

roy · Post by **roy** » Wed Dec 31, 2003 12:53 am

Hi,
Well unfortunatly the only solution I can give you is to rewrite it from scratch and do everything by the book.
sometimes thru time some jobs, that were edited numerous times get some litle thing we wrote that messes the job and we can't find our bug.
so I would recomend a rewrite from scratch, painfull yess, but might get you going with no bugs.

Good Luck

JDionne · Post by **JDionne** » Wed Dec 31, 2003 9:11 am

roy wrote:Hi,
Well unfortunatly the only solution I can give you is to rewrite it from scratch and do everything by the book.
sometimes thru time some jobs, that were edited numerous times get some litle thing we wrote that messes the job and we can't find our bug.
so I would recomend a rewrite from scratch, painfull yess, but might get you going with no bugs.

Good Luck

After i rebuilt the partitioner and colector section of the job it ran without any trouble. Thank god I didnt have to rebuild the transforms. Now on to my aggrigation problem

Jim

inter5566 · Post by **inter5566** » Mon Jan 05, 2004 12:45 pm

Jim,

Out of curiosity, what form and options of trim are you using?

Steve

JDionne · Post by **JDionne** » Mon Jan 05, 2004 1:42 pm

inter5566 wrote:Jim,

Out of curiosity, what form and options of trim are you using?

Steve

just using trim()
no options
Jim

inter5566 · Post by **inter5566** » Mon Jan 05, 2004 2:36 pm

Jim,
Trim by itself without options defaults to option r I believe. This may be giving you problems since the r option removes leading, trailing, and multiple occurances of space and tab(unless another character is specified) within the field.

example:

trim(" this text ")= "this text"

I have run into problems mainly concerning trailing blanks, therefore I use trimb(filedname) most of the time.

hth,
Steve