Creating a table with volatile columns at first to reduce log size

Question

I am not sure about this, but I think I read it before, and I would like to know if that is true or false:

When creating tables, it is better to put volatile columns first and then the static columns. I mean, to put the columns that will be updatable, and the not updatable at the end. This is good to reduce the size of the transaction log because each time a row is modified, the log will write the old row, and the columns of the new row till the last updated.

Row

ID-PK, code, name , message
1    , 10 , "John Doe", "A funny message"

Update to

1    , 10 , "John Doe", "The message was changed."

In this case, the log will write completely the new row. However, if we change the order of the columns:

Row

ID-PK, message , code, name<br/>
1    , "A funny message"         , 10 , "John Doe"

Update to

1    , "The message was changed.", 10 , "John Doe"

The transaction log will only write the till the last modified column (1, "The message was changed.") and this could improve the performance while writting and shipping logs to another machine like when using HADR.

I would like to know if this is true, and where can I found information about this.

Answer 1

When full data change capture is not enabled, DB2 LUW log records begin with the first byte where data changes and continue to the last byte where data changes. IBM offers the following recommendation in a section of their online documentation titled "Ordering columns to minimize update logging"

Columns which are updated frequently should be grouped together, and defined towards or at the end of the table definition. This results in better performance, fewer bytes logged, and fewer log pages written, as well as a smaller active log space requirement for transactions performing a large number of updates.