Insert + Update code in 11g taking WAY longer than 9 ?

Question

Hi guys
Hoping to get a few suggestions as to what might be causing a problem I'm having.
I've got a routine in a form that was previously running against a version 9 database, and is now running against an 11g database.
The routine has a series of cursor loops which results in a number of inserts and updates on the database.
I have in this routine a call to a procedure which inserts a record into a logging table, with the time it is called. With this I can gauge how long the routine is taking.
On the version 9 database, the log of inserts is as follows :
After x rows, time taken (mins, secs)
1000 rows - 1.04
4000 rows - 4.38
9000 rows - 9.43
13000 rows - 14.01
18000 rows - 15.58
So, as a very approximate value, 1000 rows a minute consistantly through to the end at 18000.
The version 11 database is an import of the version 9 database. so has all the same constraints, indexes, triggers etc.
The code disables foreign key constraints before executing, it doesnt drop the indexes.
On the version 11 database, the log of inserts is as follows :
1000 rows - 0.30
4000 rows - 3.58
9000 rows - 19.58
13000 rows - 41.46
18000 rows - 80.45
So rather than staying at a rough 1000 rows per 1 minute time, as more rows are inserted, the time to complete is going up and up and up.
This would point at indexing maybe? But since there is only 1 index on the tables being inserted into, which is the same on the 9 and 11 database, this ought not to be the case.
Can anyone suggest why the version 11 database is taking so much longer, and why the time to process is increasing rather than staying constant throughout.
I'm at a loss at what to look for now.
Thanks a lot
Scott

Answer 1

Scott Hillier wrote:
The code has to gather data from several tables, perform some fairly complex logic on it, building up record structures before inserting into a number of tables and updating several others. None of which can be done with a simple merge statement.
It has to be done using cursors, both implicit and explicit to retrieve the data first."Has to" is a bit presumptive. SQL has got very powerful constructs and features that can (pretty much) do anything you require. It may be complex SQL but it will process all the rows of data in one go rather than doing continuous context switching.
Here's a basic example of the time difference between running stuff as a single SQL and context switching...
[code]
SQL> ed
Wrote file afiedt.buf
  1  declare
  2    v_sysdate DATE;
  3  begin
  4    v_sysdate := SYSDATE;
  5    INSERT INTO mytable SELECT rownum FROM DUAL CONNECT BY ROWNUM <= 1000000;
  6    DBMS_OUTPUT.PUT_LINE('Single Transaction: Time Taken: '||ROUND(((SYSDATE-v_sysdate)*(24*60*60)),0));
  7    EXECUTE IMMEDIATE 'TRUNCATE TABLE mytable';
  8    v_sysdate := SYSDATE;
  9    FOR i IN 1..1000000
10    LOOP
11      INSERT INTO mytable (x) VALUES (i);
12    END LOOP;
13    DBMS_OUTPUT.PUT_LINE('Multi Transaction: Time Taken: '||ROUND(((SYSDATE-v_sysdate)*(24*60*60)),0));
14    EXECUTE IMMEDIATE 'TRUNCATE TABLE mytable';
15* end;
SQL> /
Single Transaction: Time Taken: 1
Multi Transaction: Time Taken: 37
PL/SQL procedure successfully completed.
SQL>
[/code]One hell of a difference, and it can get worse depending on how many switches are done in a loop.
Theres no commit until the end.That's good.
So, feel free to suggest how I go about gathering data to build up the various records without using cursors.Without knowing your structures, data, requirements etc. how can we tell, apart from to say that maximising SQL and minimising PL/SQL will improve performance.
Even if you do - it still wouldnt explain why tuned code which runs in 18 minutes on one box is running at 90 minutes on another.It could be a configuration factor of the database, but equally it could be a number of other factors.
Unless you provide comparative explain plans for queries etc. then how can we tell.