Please Help resolve the issue

Question

Hello everybody
I have a very serious issue on our production system.I have a script that has been running for more than 72 hours and i really need your help in optimizing the script.
DB server : Oracle 10g release 10.2.0.3
CREATE TABLE TBL_MENU_LEAF_NODES
AS
select distinct root_data_col_id, lft, rgt, old_collection_id
from tbl_object_data t1, tbl_keys t2, tbl_data_collections t3
where t1.data_id = t2.data_id
and t1.data_collection_id = t3.data_collection_id
and not exists ( select 1 from tbl_keys x1
where x1.collection_key_id = t3.old_collection_id);
-- This select qry returns about 1 million records
--Pl/sql bock starts here
DECLARE
CURSOR cur IS
select root_data_col_id, lft, rgt, old_collection_id
from tbl_menu_leaf_nodes;
BEGIN
FOR rec IN cur
LOOP
UPDATE tbl_keys SET rgt = rgt+2 WHERE root_data_col_id = rec.root_data_col_id AND rgt >= rec.rgt;
INSERT INTO TBL_KEYS ( root_data_col_id, lft, rgt, collection_key_id )
SELECT rec.root_data_col_id, rec.rgt, rec.rgt+1, rec.old_collection_id FROM dual;
Commit;
END LOOP;
END;
The problem is with the update statement..It is at a very snail pace,because the cursor has to just loop through million records and the updates on the table would be the same.
even though we are freqeuntly commiting the data,the UNDO table space is growing huge.
Pl help out.
Thanks
sreeni
Pl help me to optimize the code..

Answer 1

I'm sorry to answer your question by asking another question. I'm just curious what it supposed to do?
(I overlooked the part with distinct ids and to fix my post, removed the nonsense about the order of rows)
Just few statements about the transaction size, undo and other load in the system. You need to commit no less or more often than your business logic requires/permits. Even if you do commit often, this does not shrink the undo you have it as much as currently running statements or read-only transactions require to maintain read consistency. Otherwise they will fail with "snapshot too old" error. By introducing artificially often commits you make things run even slower.
The update and insert do generate undo data. But neither would require the amount of undo you described. It will be overridden according to the undo retention time. It might be however required for other transactions. Vice verse if there are other DMLs against tbl_keys or tbl_menu_leaf_nodes at the same or around the same time, then their respective undo might be required for the statements in the block including cursor statement.
But back to the topic. Three things I would suggest to do.
1. Fetch the results of the cursor into an array and use the array as a driving source of information.
2. Then do bulk update and then bulk insert (or simply insert as select).
3. Reduce mentioned interference to significantly reduce the amount of work Oracle has to do. If this is a huge update process start it in off peak hours.
Vlad Sadilovskiy
Oracle Database Tools
http://www.fourthelephant.com
Message was edited by:
Vlad S.