From the look of the plan you are calculating the results of the view for each row in small table. Operation 4 in the plan seems to suggest that there is some sort of ordering inside the view which is preventing the view from being merged which may help your plan.

Could you post the definition of the view?

To prevent the view from being executed for each row you could do something like:

Your PL/SQL technique is not equivalent to the original UPDATE statement. The UPDATE will update every row in SMALL_TABLE, setting FCR7 to the calculated value or to NULL if there is no match in the view. Your PL/SQL will not update any rows where there is no match.

The problem seems to be that you are running the slow subquery one time for each row in the small table. I if you do the math 74 rows x 7 mins, you end up at about 9 hours. Remove som time due to caching effect and you´ld probably end up somewhere in the range you mention.

I suggest you rewrite the query to something where you incorporate the ids from the small table, maybe by using subquery factoring:

with slow_view_data as

(SELECT

FCR7*100 new_value, D.MONAT, D.DL

FROM SLOW_VIEW D

WHERE (D.DL, D.MONAT) in (select DL, MONAT from SMALL_TABLE st)

)

UPDATE

SMALL_TABLE T

SET FCR7=

(SELECT

new_value

FROM SLOW_VIEW_data D

WHERE D.MONAT = T.MONAT

AND D.DL = T.DL

)

;

I haven´t tested this code, just showing you the outline here. The subquery, slow_view_data will be run only once an can be used as a regular table in the following statement. Let me know if it works or anything is unclear, and I´ll set up a tested example.