updates causing loads of redo?

[ssmith]

We have an issue where the log switches every 4 minutes on a 'test' database, i.e. not doing much, just a few tests. I have checked the log miner and discovered that an unsupported procedure was doing 41,000+ updates every 4 minutes:
SQL> @logmnr_results

OPERATION SEG_OWNER SEG_NAME COUNT(*)
---------------------------------------- -------------------- UNSUPPORTED LIMARES ALLOCATION_HOLD_MAP 41024
UNSUPPORTED SYS SEQ$ 2
On checking the procedure ALLOCATION_HOLD_MAP it updates all 864 columns table to null every 5 seconds. Apparently this needs to be done this way, so we can ensure the data is refreshed for new data! Anyway, I am assuming that these 41000+ entries in the log file are related to these updates (updating 864 columns in the table, every 5 seconds within approx. 4 minutes. Here is the equation (60/5*4=45, 48*864=41,472).
My question is, why is this update have 41000+ entries in the log file? Does each column updated represent one entry? Rgds. Sheryl

[PAVB]

Mnnnhhh... 864 columns table? do you mean 864 rows table perhaps?
Well... a redo image is needed for each update, isn't it? That's the way redo works.

[ssmith]

No, its one update sql statement that updates 864 columns to NULL for 1 row, e.g.

UPDATE LIMARES.ALLOCATION_HOLD_MAP
SET
T_1_0000 =NULL,
T_1_0005 =NULL,
T_1_0010 =NULL, etc etc.(864 columns later.....)
WHERE RES_ID= :B1
commit;
This is why I am asking the question, I thought it would just have 1 entry in the redo log as it is 1 transation.
Rgds. Sheryl