Based on your question and other discussion comments, I didn't see any clue for network and blocking issues.
Here, I'd like to give following approaches to try which can help in your situation:
Approach#1:
Suspecting performance issue because of indexes in STG_TRANSIT table. In the sutuation of big STG_TRANSIT table
and there are indexes available, what if you might drop them and rebuild them after populating tables during off hours.
Approach#2:
Create temporary table -
create table temp_STG_TRANSIT
as
select * from
(
SELECT TRIM(r.R_ID), 1, TRIM(r.R_CODE), TRIM(r.R_MISC4), trim(rc.DESCR)
FROM sradmin.RACEWAY@sr25 r
LEFT JOIN sradmin.RWAYCODE@sr25 rc ON r.R_CODE = rc.R_CODE
)
Where Rownum <= 10000;
Perform bulk insert -
insert /* APPEND */ into STG_TRANSIT select a.* from temp_STG_TRANSIT as a;
Approach#3:
Trying with DRIVING_SITE hint which forces query execution to be done at a different site than the initiating instance, following query pattern can help in your context:
INSERT INTO STG_TRANSIT(TRANSIT_ID, SHIP, TRANSIT_TYPE, COMPARTMENT_ID, DESCRIPTION)
SELECT /*+ DRIVING_SITE(X) */ *
FROM
(
SELECT TRIM(r.R_ID), 1, TRIM(r.R_CODE), TRIM(r.R_MISC4), trim(rc.DESCR)
FROM sradmin.RACEWAY@sr25 r
LEFT JOIN sradmin.RWAYCODE@sr25 rc ON r.R_CODE = rc.R_CODE
) X
Refer link for the details of DRIVING_SITE hint.
So the disaster has been averted. The issue is an apparent "bug" - because I have no other word for it - with Oracle when you attempt to use a pfile that exists in the %ORACLE_HOME%\database
directory.
Oracle 11gR2 will apparently not correctly load any pfile
that exists in the same directory as the spfile
, even if you supply the full path and filename.
Instead, I had to create the pfile
from the spfile
and supply a completely different path, once I did that, and then edited that file and supplied it to the startup
command, I was able to get the instance mounted and change the configuration and successfully open the database.
Best Answer
First of all,
NOT IN
is not the same asNOT EXISTS
.Let's find customers without purchasebill (
customerid = 2
). FIrst with a naiveNOT IN
:Now with
NOT EXISTS
:NOT IN
did not provide the result we expected. It's because the wayNOT IN
works. If any row of the subquery returnsNULL
,NOT IN
will returnFALSE
, so no result in this case.Now your queries:
The problem with the
NOT EXISTS
query is that you havecustomer c
both in the outer query and the subquery. The subquery usescustomer c
from its inside, not thecustomer c
from the outer query. Because of this, the subquery always returns data, soNOT EXISTS
will always evaluate toFALSE
, hence no result.The
NOT IN
version works, because the inner query is not a correlated subquery, it does not usecustomer c
from the outside, but the inside. The inner query returns customers who made purchases, withoutNULL
s, because the join topurchasebill p
eliminates them. With noNULL
s to worry anymore,NOT IN
works as naively expected.If you want to make
NOT EXISTS
work, removecustomer c
from the subquery, so it becomes a correlated subquery: