DSXchange

We have a job that runs for around 40 minutes and then aborts with no reason given in Director. Looking at the log in the &PH& directory, this is the error I see. Whare can I go to find out what is causing it?


./DSD_BP.O/DSD_Update.BDataStage Job 1426 Phantom 28495
Abnormal termination of DataStage.
Fault type is 11. Layer type is BASIC run machine.
Fault occurred in BASIC program DSD.Update at address 124

Since you've looked at the &PH& entry, your next step is to identify the transformer stage that blew up tragically. Was the job running any kind of after-stage routine or after-job routine when it died? A lot of the time, these subroutines can have issues such as calls to other subroutines that don't exist or aren't compiled and therefore cause abnormal terminations.

The other thing to look at is what your job is doing. If it's building a default 32-bit hash file and exceeds 2.2 gigabytes then this message happens. Can you give us a little more design information?

There are no pre/post job or Trn routines. The job has an OCI8 primary linkinto a trn with an OCI8 lookup and a hash file lookup. It has output links for INSERT into an OCI8 table and a reject text file if either lookup is not found. Ther is some calculations and checks in the trn, but nothing out of the ordinary.

I hate it when things blow up tragically. Nice blow ups are so much better ways to die.

I think what Ken is saying is there are failures which DataStage can easily trap. This jobs will end under DataStage control. There are other times when a job fails by violating something that the OS does not allow therefore the OS will terminate that process before DataStage can trap it. It terminates or dies more abruptly or tragically.

Geez Ken, it sounds like your best friend died. Blame Dennis because he always gives me a hard time about how I phrase things. You can take the boy out of Oklahoma but not the Okie out of the boy. Good thing your apostrophes are correct. You don't want those police too.

I also noticed that there is a 'core' file in the project directory. Is there and easy way to read this file?

The job processed 3.3 milion records, reading all from hash and OCI lookups. The database is actually an Oracle 9i database and we usually use OCI9 stages, but the developer grabbed the wrong stage. IS that an issue?

Could be an issue, one customer of mine uses OCI8 with 8i client to talk to 9i databases, but OCI8 with 9i client talking to 9i, not sure.

One last thing to look at is if you have row buffering turned on. Search the forum, but this is a finicky feature and you may wish to try turning it off after you swap out the stages.

Hi,

We have been using OCI8 with 9i client talking to 9i and it works fine.


Ketfos

I have tried ORAOCI 8 with 9i client . It doesn't work. I checked with forum on this and got the reply for ORAOCI 8 we should use 8 i client even if database is 9i.
Try doing that. I should work.

Thanks
Mukund

We use a Oracle 8 client with a Oracle 9 database. Works flawlessly.

As have I...

We had this issue and it was resolved by replacing the OCI stage with ODBC stage try using that

smohamme wrote:

We had a similar issue and was related to a 32-bit Oracle client on the ETL box talking to a 64-bit Oracle server. Apparently there is a memory leak when a 32-bit client talks to a 64-bit server and fails with an abnormal termination error and fails while processing around 15.7 million records.

Update on this is that we have applied an Oracle Patch to the 32-bit client and it fixed the abnormal termination issues.

Please advise the patch identification. Others are seeing this too.

ray.wurlod wrote:Please advise the patch identification. Others are seeing this too.

The details of the patch that allowed us to fix the "Abnormal Termination..." are as follows:

Oracle Bug number is 2298968 and detail information is as follows:

********************( BUGTAG NOTES - See <Note:66631.1> )******************
BugTag: Support notes on <Bug:2298968> - DDR info <BugDesc:2298968>
Affects: RDBMS (81-92)
NB: *Serious* FIXED
Abstract: Client side memory leak for 32<->64 bit SELECTs
Fixed-Releases: 8175 9014 9201
Tags: EXP INTEROP LEAK/MEM R8173
Details:
Client side memory leak for 32<->64 bit SELECTs.
This client side bug can have a severe effect on EXPORT.
A 32bit EXP process may grow dramatically if exporting
a 64 bit database. ("exp" is 32 bit by default for most
64bit releases of Oracle).

The client (on etl box) and server (on database box) version of oracle are both 8.1.7.4, only the client is 32-bit and server is 64-bit.