Updating a large table

Question

Hello,
We need to update 2 columns on a very large table (20000000 records). Every row in the table is to be updated and the client wants to be able to update the records by year. Below the procedure that has been developed
DECLARE
l_year VARCHAR2 (4) := '2008';
CURSOR c_1 (l_year1 VARCHAR2)
IS
SELECT ROWID l_rowid, (SELECT tmp.new_code_x
FROM new_mapping_code_x tmp
WHERE tmp.old_code_x = l.code_x) code_x,
(SELECT tmp.new_code_x
FROM new_mapping_code_x tmp
WHERE tmp.old_code_x = l.code_x_ori) code_x_ori
FROM tableX l
WHERE TO_CHAR (created_date, 'YYYY') = l_year1;
TYPE typec1 IS TABLE OF c_1%ROWTYPE
INDEX BY PLS_INTEGER;
l_c1 typec1;
BEGIN
DBMS_OUTPUT.put_line ( 'Update start - '
|| TO_CHAR (SYSDATE, 'DD/MM/YYYY HH24:MI:SS')
OPEN c_1 (l_year);
LOOP
FETCH c_1
BULK COLLECT INTO l_c1 LIMIT 100000;
EXIT WHEN l_c1.COUNT = 0;
FOR indx IN 1 .. l_c1.COUNT
LOOP
UPDATE tableX
SET code_x = NVL (l_c1 (indx).code_x, code_x),
code_x_ori =
NVL (l_c1 (indx).code_x_ori, code_x_ori)
WHERE ROWID = l_c1 (indx).l_rowid;
END LOOP;
COMMIT;
END LOOP;
CLOSE c_1;
DBMS_OUTPUT.put_line ( 'Update end - '
|| TO_CHAR (SYSDATE, 'DD/MM/YYYY HH24:MI:SS')
END;
We do not want to do a single update by year as we fear the update might fail with for example rollback segment error.
It seems to me the above developed is not the most efficient one. Any comments on the above or anyone having a better solution?
Thanks

Answer 1

Everything wrong with the sample code and approach used. This is not how one uses Oracle. This is not how one designs performant and scalable code.
Transactions must be consistent and logical. A commit in the middle of "+doing something+" is wrong. Period. (and no, the reasons for committing often and frequently in something like SQL-Server do not and never have applied to Oracle)
Also, as I/O is the slowest and most expensive operation that one can perform in a database, it simply makes sense to reduce I/O as far as possible. This means not doing this:
WHERE TO_CHAR (created_date, 'YYYY') = l_year1;Why? Because an index on created_date is now rendered utterly useless... and in this specific case will result in a full table scan.
It means using the columns in their native data types. If the column is a date then use it as a date! E.g.
where created_date between :startDate and :endDateThe proper approach to this problem is to determine what is the most effective logical transaction that can be done, given the available resources (redo/undo/etc).
This could very likely be daily - dealing and updating with a single day's data at a time. So then one will write a procedure that updates a single day as a single transaction.
One can also create a process log table - and have this procedure update this table with the day being updated, the time started, the time completed, and the number of rows updated.
One now has a discrete business process that can be run. This allows one to run 10 or 30 or more of these processes at the same time using DBMS_JOB - thus doing the updates for a month using parallel processing.
The process log table can be used to manage the entire update. It will also provide basic execution time details allowing one to estimate the average time for updating a day and the total time it will take for all the data in the large table to be updated.
This is a structured approach. An approach that ensures the integrity of the data (all rows for a single day is treated as a single transaction). One that also provides management data that gives a clear picture of the state of the data in the large table.
I'm a firm believer that is something is worth doing, it is worth doing well. Using a hacked approach of blindly updating data and committing ad-hoc without any management and process controls... That is simply doing something very badly. Why? It may be interesting running into a brick wall the first time around. However, subsequent encounters with the wall should be avoided.