Long running task

I have a proc that is running since more than half an hour.

How can i expedite the procedure.

The proc is stuck at this update:

               WHEN 'USD'
                  (SELECT PX_MID_PRC
                     FROM UCUR_CCY_EXCH_RATE_VU
                    WHERE     AS_OF_DT = A.RELEASE_DATE
                          AND CCY_FROM_CD = A.BASE_PRICE_CCY
                          AND CCY_TO_CD = 'USD')
          * (SELECT NVL (MULT_FACTOR_VAL, 1)
               FROM MD_CCY_MULT_FACTOR
              WHERE CCY_CD = A.BASE_PRICE_CCY),
       BASE_PRICE_CCY = 'USD',
       CLOSE_PRICE =
          * (SELECT NVL (MULT_FACTOR_VAL, 1)
               FROM CCY_MULT_FACTOR

There is a Row-X (SX) mode DML lock on table IVRSN and table partition IVRSN

Explain plan shows full table scan of IVRSN with cost of 6,00,000
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Christoffer SwanströmPartnerCommented:
How many rows are there in total and how many are you updating? If you are updating only a small fraction of rows (as defined by as_of_dt = :B1) then adding an index on as_of_dt could help by avoiding the full table scan.

Another option to speed up the table access would be to partition the table no as_of_dt.

A third approach worth trying would be to do a CREATE TABLE ... AS SELECT instead of UPDATE. You would essentially:
-CREATE TABLE  IVRSN_TMP AS SELECT xxx FROM IVRSN (subsitute xxx with all the columns from IVRSN, except replace BASE_PRICE with your calculation above)
-DROP (or rename) original IVRSN table

The logic is that UPDATEs are generally very slow (even more so when you have indexes that need to be updated) and recreating the table might actually be faster than updating it.

Of course you would also need to recreate any indexes you had on the original table.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DavidSenior Oracle Database AdministratorCommented:
Anything of interest in your alert.log, suggesting REDO log issues?  My two cents would be to curtail the data set -- so that the logic could be traced with a minimal number of records.
gram77Author Commented:
The table ivrsn dosent have any indexes on it. It holds 32 GiGs of data, 17 million records.
and partitioned on as_of_dt while search is on release_dt

why is update generally slower then insert?
gram77Author Commented:
sorry, partitioned on release_dt while search is on as_of_dt
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.