Gotcha. I looked at every column in the inserts and didn't notice that the table names were different.

Regardless, sorting will not make a difference, unless you care which of those (1 2 3) records gets inserted into which table. An insert statement is completely atomic.

INSERT INTO T1...
INSERT INTO T2...
INSERT INTO T1...

is, for all intensive purposes, as fast as:

INSERT INTO T1...
INSERT INTO T1...
INSERT INTO T2...

The minor differences you *might* see because of the cacheing of the index blocks or whatever is going to be completely overshadowed by both the speed of the driving query and the fact that you are doing separate inserts. You need to optimize the query in the cursor. If possible, you should not be doing inserts inside a cursor. It is much faster to do them as a bulk operation. However, in this case, it would probably be rather difficult to do that, so.....

The other handyd-dandy trick you can do with Oracle is the BULK COLLECT functionality. Here is a link for ya:

[url]http://oradoc.photo.net/ora81/DOC/server.815/a67842/04_colls.htm#23723[/url]

You do a BULK COLLECT around the cursor SELECT to bulk-load a TABLE array. You then use FORALL around the INSERTS to do a bulk insert. There are, as always, some restrictions here. You won't be able to hit the table to look for rows inside the loop, because I don't think the rows are inserted until the end. BUT...

If you order the rows, and then use some local vars to tell when the ID changes, you can handle that functionality without hitting the table. Whenever the key changes, insert into the details table. If the key is the same, insert into the exceptions table. Using the FORALL, Oracle should hold off until the end and do a bulk-insert for you. This should shave some serious time off.

Again, start by using the hints I gave you in the first reply to try to optimize the driving query. This will be the biggest bang for the buck. Then you can worry about doing the BULK stuff.

Hope this helps,

- Chris