DSXchange

Check whether you have admin priviledge on the base tables.

If not, create one table yourself and run against it.

OK, so what's different about this one problematic server? I'd mostly be curious about the exact Oracle version and the roles/grants the connecting user has there v. elsewhere.

Sainath.Srinivasan wrote:Check whether you have admin priviledge on the base tables.

If not, create one table yourself and run against it. ...

Thanks for the reply
As per the suggestion I have created the new table with only two columns and ran the job,but still the job is aborting with error message as :
I am not able to understand even if we have set the quota time as unlimited why it is throwing the SIGSEGV error message ??

AmeyJoshi14 wrote:I am not able to understand even if we have set the quota time as unlimited why it is throwing the SIGSEGV error message ??

Mostly because it's not a 'quota time' related problem.

Did you ask your DBA to set a trace? What happened to the trace result ?

Try creating an SQL*Loader control file and attempt to load.

When you said the same job works fine in other environment, do you mean "with the same user and test data" ?

chulett wrote:OK, so what's different about this one problematic server? I'd mostly be curious about the exact Oracle version and the roles/grants the connecting user has there v. elsewhere. ...

It's really strange the new server has same configuration as well as same version(Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 ) with respect to other servers where in load and truncate options are working fine...
Actually if we use the upsert mode then the records are inserted into the table(ran on the single node as per IBM's recommendation),but sqlldr is not working ..

The connecting user has dba privileges as well .... through sql plus the same user can insert/truncate the tables...Also in the upsert mode the same user is inserrting the data.....tried to use delete mode as well and it is also working fine...

I am really thankfully for all the help

Obviously, though, something is different about it. The bitch is going to be finding it. Don't recall if this has already been asked, but can you run the equivalent sqlldr session from the command line on that box with that user? It won't truly be equivalent as the stage uses pipes as the input source of the data (which could be contributing to your issue) but at least it would tell us that there's no fundamental issue with sqlldr on that server.

Remember that only 'load' uses sqlldr, the other options do 'normal' OCI transactional insert/update/delete operations. Have you tried isolating specific load options to see if they are triggering the segmentation violation? For example, manually truncate the table and load without the truncate option? Or use the OPTION clause to try a conventional load via sqlldr (DIRECT=FALSE) rather than a direct path load (DIRECT=TRUE)? What about other options you may be using - index maintenace, for example? Does it matter if there are indexes on the target or not? Just some examples off the top of my head, but hopefully dectective work of that nature could help isolate what aspect, if any, of the load you are doing is causing the issue.

Don't know if this will help but I thought about this issue when I came upon this problem.

JR30348 SIGSEGV error occurs when parallel job uses a stage that is not wave aware and performance data is enabled

Where is the TMPDIR pointing to? Is it a NFS file system?.

I believe the sqlldr will try to create pipes in this directory and if it is non-NFS then it would throw an error.

Any news about this issue?

I have the same symptomps on our server, CTL file is 0 bytes when pointing to another Oracle DB it is working. Upsert en delete is working fine.

The only difference is that I get a SIGBUS error:
ORA_<TABLENAME>,1: Operator terminated abnormally: received signal SIGBUS

not good for my temper

SIGBUS is issue with the network or session. This is different from SIGSEGV.

Does this happen all the time or only at random intervals ?

Try checking the connection using tools outside datastage when this happens.

Better open a new thread.

Sainath.Srinivasan wrote:SIGBUS is issue with the network or session. This is different from SIGSEGV.

Does this happen all the time or only at random intervals ?

Try checking the connection using tools outside datast ...

Thanks for the quick reply.
It happens Always when pointing to one ORACLE DB / Never when using another one.
Altough my Unix is a bit rusty I will try and check it out outside of datastage. Keep you updated.