SIGSEGV error occured during loading the data
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
-
- Participant
- Posts: 334
- Joined: Fri Dec 01, 2006 5:17 am
- Location: Texas
Thanks for the replySainath.Srinivasan wrote:Check whether you have admin priviledge on the base tables.
If not, create one table yourself and run against it. ...
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 :
Code: Select all
ora_tgt,0: Operator terminated abnormally: received signal SIGSEGV
where
ora_tgt is target table.
http://findingjobsindatastage.blogspot.com/
Theory is when you know all and nothing works. Practice is when all works and nobody knows why. In this case we have put together theory and practice: nothing works. and nobody knows why! (Albert Einstein)
Theory is when you know all and nothing works. Practice is when all works and nobody knows why. In this case we have put together theory and practice: nothing works. and nobody knows why! (Albert Einstein)
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
-
- Participant
- Posts: 334
- Joined: Fri Dec 01, 2006 5:17 am
- Location: Texas
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...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. ...
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
http://findingjobsindatastage.blogspot.com/
Theory is when you know all and nothing works. Practice is when all works and nobody knows why. In this case we have put together theory and practice: nothing works. and nobody knows why! (Albert Einstein)
Theory is when you know all and nothing works. Practice is when all works and nobody knows why. In this case we have put together theory and practice: nothing works. and nobody knows why! (Albert Einstein)
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.
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Premium Member
- Posts: 278
- Joined: Wed Oct 03, 2007 8:45 am
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
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
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Thanks for the quick reply.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 ...
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.