Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle oledb bug?

Re: Oracle oledb bug?

From: <>
Date: 21 Feb 2006 13:19:29 -0800
Message-ID: <>

> First of all just the idea you want to do this in a front end tool is
> of course horrible. DDL is a server task, shouldn't be done in a front
> end, and this code has nothing to do with proper administration. It is
> just a plain utter nightmare, especially as you also expose the system
> password which is still set to the default everyone knows

Yes, I knew I was going to regret not posting the disclaimer that this was just a simple program to replicate our problem and not the actual production code which is causing the issue...oh wait, I did do that

The actual scenario is as follows:

1.) Large csv files are uploaded through an application to a server directory.
2.) Background service on server bulk loads the csv file using SQLLDR into a staging table.
3.) Background service then makes a call to a package that runs business rules on the bulk data to clean and/or reject it and then loads it into the proper tables. This is where the problem lies. We've found that during this load, when the database is fresh (no data so no stats) and there is a large amount of data, the proper indexes aren't used in the queries loading child/dependent tables (even with hints) and the loads take forever. They are used if we gather stats after the parent table loads. Everything was fine here until someone created a composite index on one of these parent tables.

So there you have it, we are not using the actual system user for the background service account, just a created user that has been granted proper minimal rights to run the package. I guess my workaround for now is to submit the call to the package as an oracle job.

> That said, you should know, on your way to hell, that there are at
> least a 1000 different causes for ora-3113 and those causes can only
> be diagnosed by means of searching on Metalink, and/or submitting a
> service request on this site.

Hence "ambiguous". I've checked the alert log and trace files and found nothing. I've searched metalink and found nothing. I plan on submitting a TAR, just wanted to know if someone here could offer something more helpful than "You n00b, your example program is teh sux0r!!!!1!111"...not sure what I was thinking Received on Tue Feb 21 2006 - 15:19:29 CST

Original text of this message