9582.69043 gigabytes of physical read total bytes and increasing!

Question

In EM
Database Instance: PROD > Top Activity > I got following
physical read total bytes     62763565056     10289335500800     4183122176
cell physical IO interconnect bytes     62763565056     10289335500800     4183122176
physical read bytes     62763565056     10289335500800     4183122176
And the session is running following update procedure:
declare
FM_BBBB MT.BBBB_CODE%TYPE;
l_start NUMBER;
cursor code_upd is select /*+ parallel(FM_KWT_POP_BBBB_MISMATCH, 10) */ DDD_CID, DDD_BBBB, CCCC_BBBB from MT_MISMATCH;
begin
-- Time regular updates.
l_start := DBMS_UTILITY.get_time;
FOR rec IN code_upd LOOP
update /*+ parallel(MT, 10) nologging */ MT
set BBBB_code = rec.CCCC_BBBB
where source= 0
and cid_no = rec.DDD_CID
and BBBB_code = rec.DDD_BBBB;
commit;
END LOOP;
DBMS_OUTPUT.put_line('Bulk Updates : ' || (DBMS_UTILITY.get_time - l_start));
end;
There are 9.5 million records in MT but source=0 have only 3 million records and 376K records in MT_MISMATCH, What I don't understand why this is taking so much of time and so many bytes read? Both Tables are analyzed before running this procedure.
Can someone shed some light on this? Is there any better way of doing the same job?

Answer 1

Nabeel Khan wrote:
In EM
Database Instance: PROD > Top Activity > I got following
physical read total bytes     62763565056     10289335500800     4183122176
cell physical IO interconnect bytes     62763565056     10289335500800     4183122176
physical read bytes     62763565056     10289335500800     4183122176
And the session is running following update procedure:
declare
FM_BBBB MT.BBBB_CODE%TYPE;
l_start NUMBER;
cursor code_upd is select /*+ parallel(FM_KWT_POP_BBBB_MISMATCH, 10) */ DDD_CID, DDD_BBBB, CCCC_BBBB from MT_MISMATCH;
begin
-- Time regular updates.
l_start := DBMS_UTILITY.get_time;
FOR rec IN code_upd LOOP
update /*+ parallel(MT, 10) nologging */ MT
set BBBB_code = rec.CCCC_BBBB
where source= 0
and cid_no = rec.DDD_CID
and BBBB_code = rec.DDD_BBBB;
commit;
END LOOP;
DBMS_OUTPUT.put_line('Bulk Updates : ' || (DBMS_UTILITY.get_time - l_start));
end;
There are 9.5 million records in MT but source=0 have only 3 million records and 376K records in MT_MISMATCH, What I don't understand why this is taking so much of time and so many bytes read? Both Tables are analyzed before running this procedure.
Can someone shed some light on this? Is there any better way of doing the same job?Lots of badness going on here.
1) looping / procedural code where none is needed.
2) commit within the loop, one of the worst evils of all in Oracle. Please read this
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2680799800346456179
I'd look into rewriting this as a single SQL (maybe merge) statement. Or at worst .. a bulk process utilizing collections and FORALL's.