Re: Logical log size

Hi Carlson, first of all, rows that will not be changed during an update operation will not be logged, that is, if you set a field's value to the same value it contained before, this will not be marked as an update and therfore will not be logged in the logical logs. If you change the value of an indexed column, if have no idea of the costs in the logical log files ( you might check it yourself by using "onlog -l -n #" ). For non-indexed columns the adminsitrative overhead of an ordinary update will be about 36 Bytes plus the modified bytes times 2 ( at least 4 Bytes ) per row. My guess in your case : Number of rows modified * ( 36 + ( 2 smallints = 4 * 2 = 8 ) ). Number of rows modified * 44 Bytes. Uhps, I forgot the BEGIN WORK and COMMIT WORK. I think they will cost about 20 + 20 = 40Bytes. I think it's better if you have a detailled look into the logical log files as mentioned above. Bye Stefan Weideneder Carlson@WHSmith wrote: > > I looked all around and couldn't find any info, so, here goes . . . > > How much logical log space is used on an update? I will be updating two > columns (smallint) of each record on various tables in my system, along > the lines of . . . > > update table_name > set upd_a = new_value_a, > upd_b = new_value_b > where upd_a = old_value_a > and upd_b = old_value_b > > The two ideas I have now would be to : > 1. select subset of table > begin work > update subset of table > commit work > repeat until no more subsets. > > or > 2. select all rows from table > begin work > update > commit work > select rows from next table.> > > The problem I have is one of granularity. I'd like to be able to update > an entire table on a transaction, but I'd like to plan ahead to see if > it is even possible. Is there any way to determine how much logical log > space a two-column update would take?? > > TIA > > John Carlson > Informix DBA > WH Smith, Inc. > > Last seen: Trying to get all projects caught up after the Conference.