Re: Not using Physical Log, why?

Original Post: Hi , I already identify this situation on v11.10 xC1 and since then I not found any answer. I just forgot about this and today the situation "popup" and again I not found the reason.... v11.70 UC1DE - OpenSuse 11.2 This is a very simple test environment. - Database with log - 1 table with +- 520.000 records , rowsize 1320, 1 PK - update executed over 1 field ( NCHAR(100) ), single transaction (begin work) , changing 100.000 records - No physical log is used - Only logical log is filled If the transaction is rolled back, then the physical log is used.. appear to be filled by the recover from logical log, and monitoring with onstat -D , I can see the pages writes on the physical log and thedbspace used by table grow up with exactly same values... Looking the Logical Log content (onlog -n # -l ) they used HUPDAT record, what have the before/after image. I already looking into the manual about this situation and not found. Can someone explain why the engine choose this way ? Regards Cesar Response: Ok, so the point of physical logging pages is so that during logical recovery, the database can either complete or undo the transactions that happened after or were open at the time of the checkpoint used for recovery. I suspect that in the case of fix length record updates, since the logical log, as you pointed out, contains both the before and after image of the column, the code does not require a pre-image of the page to ensure the transaction can be either completed or rolled back. I suspect this is only the case in fix row length updates, as varchar modifications are more complex and would possibly require other page modifications that to be completed or undone would need the before image of the page. As for why the physical log is used during the rollback, my suspicion would be that we are physically logging everything in that code, as an extra precaution. My guess the reason behind all this is to try and reduce the amount of physical logging required, which should improve performance. Jacques Renaut IBM Informix Advanced Support APD Team