It makes sense to RECOVER and redo legitimate changes only if the number of changes you wish to undo is relatively high and the cost of undoing incorrect changes is higher than recovering the entire table. For example, if a table has million rows and 70 percent of the rows were deleted by mistake while at the same time 5 percent of the rows had legitimate changes, then it makes more sense to recover the entire table and then reapply the 50000 changes that were lost with recovery. The tool should allow you to identify exactly the log point that should be used to recover the table before the table was incorrectly changed. You can then generate REDO SQL for all the legitimate changes that were made since the selected point of recovery. The REDO SQL should exclude the unit of work that made the incorrect changes that you wish to undo. Also important is flexible handling of triggers, if the same triggers are implemented on both sides triggered changes must normally not be forwarded.