Note in the job, the ipc links are coming out of the transformer, for some reason I am not able to show that here.
Now, the requirement is if any error occurs while loading records, there should be a rollback of all records inserted until then. The Tx Size has been set to 0 in both DRS stage. In one scenario, am getting 10 records, the 10th is an record which is has error in it. But I see that 9 records are loaded in the DB even though the job aborts at the 10th record.
I tried the same without the IPC stages and the rollback occurs as expected. Seems with the IPC, the rollback is not occuring. Any advice?
Have you tried the native stage for Oracle? The ORAOCI plugin stage?
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
chulett wrote:Actually, the DRS stage set to 'Oracle' does use the native OCI interface under the covers from what I recall.
Totally agree . But still, doesn't the DRS stage have a similar overhead like the ODBC stage as compared to the native OCI interface? I was promoting the OCI stage as opposed to DRS in order to avoid the overhead costs.
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
Get rid of the IPC stage. Go to the job properties , performance tab, uncheck 'project defaults', check Enable row buffer and choose Inter process. Run you job. See if you still have the rollback problem.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
Not sure if there is a difference in using DRS with Oracle specified as the "database type" and actually using the Oracle OCI stage?
Of course using DRS Stage with ODBC as the "database type" would be less performant.
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.
chulett wrote:Actually, the DRS stage set to 'Oracle' does use the native OCI interface under the covers from what I recall.
Totally agree . But still, doesn't the DRS stage have a similar overhead like the ODBC stage as compared to the native OCI interface? I was promoting the OCI stage as opposed to DRS in order to avoid the overhead costs.
I don't believe so, but then I've never put any time or effort into investigating the DRS stage. I just slavishly stick with the OCI ones.
-craig
"You can never have too many knives" -- Logan Nine Fingers
narasimha wrote:Not sure if there is a difference in using DRS with Oracle specified as the "database type" and actually using the Oracle OCI stage?
Of course using DRS Stage with ODBC as the "database type" would be less performant.
I still think DRS = ODBC stage, except that the database type can be dynamic (assigned through a job parameter) in the DRS stage?
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
I_Server_Whale wrote:I still think DRS = ODBC stage, except that the database type can be dynamic (assigned through a job parameter) in the DRS stage?
If you specify the "Database type" as Oracle it uses the Native Interface and does not use the ODBC.
There is no involvement of ODBC in this case. IMHO
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.