We do this in our BCV5 product to allow people to make consistent copies from running production objects, and we have seen that it does not matter if the index is COPY YES or COPY NO.Īs far as I can tell, the only real difference is in a RECOVER scenario where you can avoid the index rebuild if you have an image copy. It's also the reason why we can use index log records in order to bring a dirty VSAM copy of an index into a consistent state. This is similar to a tablespace with NOT LOGGED, which will go into recover pending upon rollback. If Db2 didn't have any log records for the index, it would have to put it in rebuild pending whenever you do a rollback (assuming the transaction affected the index in any way). The reason for this is that Db2 needs those log records if you decide to rollback a transaction. In other words, even for COPY NO indexes, Db2 will log every change to every page in the index, whether it's a key insertion, deletion, RID update, page split, and so on. But my point is, COPY YES or COPY NO makes no difference when you look at the data change records for that index, and those probably account for 99.9% of the index log records. Well, I guess it is possible that there is the occasional log record that gets written when the index goes into informational copy pending, or some other status information.
In Reply to David Simpson: It generates extra log records that are not necessary if you are not doing index recovery.ĭb2 does not generate extra log records for COPY YES indexes.
0 kommentar(er)
