Home/ Questions/Q 41273
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T15:09:18+00:00

I have two insert statements, almost exactly the same, which run in two different

  • 0

I have two insert statements, almost exactly the same, which run in two different schemas on the same Oracle instance. What the insert statement looks like doesn’t matter – I’m looking for a troubleshooting strategy here.

Both schemas have 99% the same structure. A few columns have slightly different names, other than that they’re the same. The insert statements are almost exactly the same. The explain plan on one gives a cost of 6, the explain plan on the other gives a cost of 7. The tables involved in both sets of insert statements have exactly the same indexes. Statistics have been gathered for both schemas.

One insert statement inserts 12,000 records in 5 seconds.

The other insert statement inserts 25,000 records in 4 minutes 19 seconds.

The number of records being insert is correct. It’s the vast disparity in execution times that confuses me. Given that nothing stands out in the explain plan, how would you go about determining what’s causing this disparity in runtimes?

(I am using Oracle 10.2.0.4 on a Windows box).

Edit: The problem ended up being an inefficient query plan, involving a cartesian merge which didn’t need to be done. Judicious use of index hints and a hash join hint solved the problem. It now takes 10 seconds. Sql Trace / TKProf gave me the direction, as I it showed me how many seconds each step in the plan took, and how many rows were being generated. Thus TKPROF showed me:-

Rows     Row Source Operation -------  ---------------------------------------------------   23690  NESTED LOOPS OUTER (cr=3310466 pr=17 pw=0 time=174881374 us)   23690   NESTED LOOPS  (cr=3310464 pr=17 pw=0 time=174478629 us) 2160900    MERGE JOIN CARTESIAN (cr=102 pr=0 pw=0 time=6491451 us)    1470     TABLE ACCESS BY INDEX ROWID TBL1 (cr=57 pr=0 pw=0 time=23978 us)    8820      INDEX RANGE SCAN XIF5TBL1 (cr=16 pr=0 pw=0 time=8859 us)(object id 272041) 2160900     BUFFER SORT (cr=45 pr=0 pw=0 time=4334777 us)    1470      TABLE ACCESS BY INDEX ROWID TBL1 (cr=45 pr=0 pw=0 time=2956 us)    8820       INDEX RANGE SCAN XIF5TBL1 (cr=10 pr=0 pw=0 time=8830 us)(object id 272041)   23690    MAT_VIEW ACCESS BY INDEX ROWID TBL2 (cr=3310362 pr=17 pw=0 time=235116546 us)   96565     INDEX RANGE SCAN XPK_TBL2 (cr=3219374 pr=3 pw=0 time=217869652 us)(object id 272084)       0   TABLE ACCESS BY INDEX ROWID TBL3 (cr=2 pr=0 pw=0 time=293390 us)       0    INDEX RANGE SCAN XIF1TBL3 (cr=2 pr=0 pw=0 time=180345 us)(object id 271983)

Notice the rows where the operations are MERGE JOIN CARTESIAN and BUFFER SORT. Things that keyed me into looking at this were the number of rows generated (over 2 million!), and the amount of time spent on each operation (compare to other operations).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

    • 0