load method giving fatal error

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
bi_fujitsu
Premium Member
Premium Member
Posts: 46
Joined: Tue Mar 20, 2007 3:30 am
Location: India

load method giving fatal error

Post by bi_fujitsu »

Hi

I am trying to load records from a dataset into an oracle table using load method. But when i run the job it fails giving the following error

ORA_PS_AZERITY_INVENTORY_ITEM_CDC,1: The system(sqlldr ETLLOADER@CORACDEVL66 CONTROL=ora.5451.353168.1.ctl LOG=ora.5451.353168.1.log BAD=ora.5451.353168.1.log.bad SILENT=header PARFILE=ora.5451.353168.1.par) failed; see the log file for the Oracle specific message.

I could not make out what this error is. Can anybody help me out on this.
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

Check your "ora.5451.353168.1.log" log file to see the detailed error message.
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

you need to look in the .bad file for more log messages.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
ivannavi
Premium Member
Premium Member
Posts: 120
Joined: Mon Mar 07, 2005 9:49 am
Location: Croatia

Post by ivannavi »

To see the files mentioned above go to the scratch directory. On my site it's location is "/asc/Ascential/DataStage/Scratch". It contains more than 40000 files. Maybe your destination table has a field named TIMESTAMP or some other word that is a keyword to sqlldr.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

The location of your scratch disk is unlikely to help anyone other than your co-workers on the same server.

Location of scratch disk is specified by the configuration file selected when the job is run - it can differ day to day.

Also, you need to check all the scratch disks for the node from which the error was reported - in the original post this was node #1, which is the second node mentioned in the configuration file.
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