Page 1 of 1

Can debug option in 8.7 replace peek stage

Posted: Thu Oct 16, 2014 8:30 pm
by pillip
Hi,

We have the debugger in DataStage 8.7. Can it be a replacement for peek stage which we generally use.




Thanks,
Prasanna

Posted: Thu Oct 16, 2014 9:34 pm
by ray.wurlod
Yes, it can. But it's overkill, and jobs in the debugger run (necessarily) far more slowly than not in the debugger.

You can also set the "compile in Trace mode" option in job properties. This effectively puts a Peek stage on every link in the job. This works whether or not the job is running in the debugger.

Posted: Mon Oct 20, 2014 3:31 am
by pillip
Thank you Ray.

I have a scenario where the job is aborting at the target oracle connector stage while inserting into a table. The error which it is giving is

ORA-00060: deadlock detected while waiting for resource.

The OCI function OCIStmtExecute returned status -1. Error code: 24381, Error message: ORA-24381: error(s) in array DML

Now, I can put a peek stage and reject the erroneous record from the target stage.

But I do not want to change the job and do that.
Is there a way we can find this out using the datastage debugger.
I tried using the debugger, but unable to get this. Can you let me know how to achieve this.

Posted: Mon Oct 20, 2014 4:17 am
by priyadarshikunal
Did you just check the oracle trace file? should tell you the exact reason for the failure.

Posted: Mon Oct 20, 2014 5:13 am
by pillip
Can you let me know the oracle trace file path?



Thank you.

Posted: Mon Oct 20, 2014 7:31 am
by chulett
In the alert log from what I recall. Talk to your DBA. As noted, the "deadlock trace file" will have all of the gory details behind the issue. Are you aware of the kind of things that can cause a deadlock? Is this error repeatable or does it depend on the time of day the job is run or what other processes are running at the time? Wondering if it is a "self deadlock" or not.

And these kind of things can be hard to debug as the debugger can change how the job runs under the covers and thus resolve (as in not cause) the issue.

Posted: Mon Oct 20, 2014 10:40 am
by pillip
Found the issue by putting a peek stage as output to oracle connector stage and rejecting the records to peek stage.

But I had to change the job and put peek stage. Thought if I put the breakpoint before the oracle connector stage and debug at abort would give me the record which is actually causing the issue.

Had to put a peek stage finally :-(. It would be great if the debugger would show such records at the breakpoint in case of aborts like this. But this is not the case it seems.

Posted: Mon Oct 20, 2014 10:57 am
by chulett
So, resolved?