Bookmark and Share
RSS

Recent Posts

Db2 12 Avoids CPU and I/O During PIT Recovery

October 10, 2017

Traditionally when a point-in-time (PIT) recovery is needed, all the tables that have a referential relationship will be recovered simultaneously to the same PIT. The problem is there's no way to determine whether one or more parent tables or related child tables have changed. Besides substantially lengthening the recovery time, this can consume a lot of CPU resources, which of course drives up recovery costs.

The good news is that Db2 12 introduces an option to skip PIT recovery for non-updated page sets, which are objects that aren't updated after the PIT recovery point. In other words, RECOVER doesn't run the RESTORE phase, and there's no need for the LOGAPPLY phase. This is the new default behavior for the RECOVER utility when recovering to a previous PIT. The reasoning behind this is that the data in those objects at the target and current PIT is identical, so there's no need to incur the cost of recovering them.

If need be, this default behavior can be overridden by specifying SCOPE(ALL)--rather than the default of SCOPE(UPDATED)--on the RECOVER utility. One reason to use SCOPE(ALL) is if you're experiencing an I/O error due to disk corruption. SCOPE(ALL) will rebuild the object.

The IBM Knowledge Center has more about the RECOVER utility.

Posted October 10, 2017 | Permalink

comments powered by Disqus