DSXchange

We do exactly this. We have parameter values in 6 types of files. So if you have a parameter jpTargetUser then it can get set in these files. Assuming the job name is JobA and the instance id is Instance1. 1. JobA.Instance1_#jpTargetUser#.prm 2. JobA.Instance1.prm 3. JobA_#jpTargetUser#.prm 4. JobA....

That document is on my tips page. Great doc.

We ran reports looking for variations from day to day in our numbers like print any job name where it was more than one standard deviation from the average.

This allowed us to track abnormal variations.

I give one away similar to Ray's on my tips page.

Vincent logic has starts with the same name DsJobReportDb. It is not in the current EtlStats.zip. I just checked. It is simple. Just aggregate on job, stage, link and sum(row_count). You cannot ignore partitions. You need to aggregate them up to the link level.

The partition level can be aggregated up to the link level. In effect the partitions are ignored. There should be a job created be Vincent which does this for PX jobs. This job should be included with EtlStats. If not then let me know. Server jobs only have one partition so this was never an issue. ...

Depends on your source database and stage chosen. In SQL Server you could do a (NOLOCK) with User Defined. Some stage types have this in the options. Even though you may need a no lock as well as the option.

Usually 255 means the job needs to be reset.

Why not aggregate it?

Merry Christmas and Happy New Year, Digitheads.

Not too functional, he has no head.

It is fairly easy to validate the parameter name before adding it to the list with:

dsjob -lparams

So you could build your parameter list one parameter at a time.

That should work.

I agree with Ray, I have no idea what is not working.

They ride horses through the woods looking for lost souls.

I think he means a user not associated with a person or generic user like etluser.

Do the same for all the other headless users and projects.