On Dec 5, 11:26 am, Serge Rielau <srie...@ca.ibm.com> wrote:
> mike_dba wrote:
> > I have been testing compression for update operations. Can anyone
> > tell me why I require more log for an update of a compressed table
> > than I do for the same table that is not compressed ?
>
> > I tried an update for the same number of rows for two copies of a
> > table, one compressed and one not. The compressed UOW exceeds my log
> > allocation while the non-compressed does not.
>
> Huh? That's odd. The log records remain compressed. Simply speaking you
> should see a similar compression ration for the logs as for the table.
>
> Cheers
> Serge
>
> --
> Serge Rielau
> DB2 Solutions Development
> IBM Toronto Lab

I was thinking that maybe the updated column had some immense
compression on it (the table went from 22 Gb to 9 Gb). And the update
changed the dictionary and maybe there was no entry for the new value
in the dictionary so this caused some trickle down effect and caused
additional logging. But the fact that it fit into my logs for non-
compressed data is puzzling.

I am updating a 10 byte column in a 559 byte wide row. There are 72
million rows to update. The log started at 8 Gb and was increased to
12 Gb and still wouldn't fit.