Best way to back out data changes after a release

Question

Hi,
I'm trying to decide on the best way to backup some production data in case a release fails and we need to roll back the changes. This would be for data updates only, not schema changes. We have extremely limited access to production, and another team handles all the RMAN backups. The people who actually implement our releases are also pretty prone to mistakes.
I have thought of two options. The tables we want to backup are about 9 MB total in size (it's about 10 codes tables).
1. Create a bu table for each of the tables before the release. So for JENNSTABLE, we would create a JENNSTABLE_BU using CTAS. If we need to revert, we can drop JENNSTABLE and rename the JENNSTABLE_BU accordingly. The bu table would remain in production until the next release, where it would be reused again. This would be really easy to script and therefore avoid any mistakes by the production support team who implements our instructions. We would also be able to determine what values changed by querying the bu table at any time (currently old values are not retained anywhere).
2. Use datapump to export the 10 tables, then truncate the tables and import the previously created files to restore the original data. I'm hesitant to use this method because I've never used datapump before, and as we don't have access to the servers, creating file system files makes me a little nervous. If I used a bu table, I can logon to the database and at least tell if it exists.
Are there any preferred methods for doing this (besides restoring a table w/ RMAN)? Is there a best practice? Any advice is appreciated!
-Jenn
Oracle 10g
UNIX Solaris

Answer 1

Hi sb92075,
That's a good suggestion. FLASHBACK_ON is set to no on my database, but if I understand correctly, I can still do a FLASHBACK TABLE and the undo data would be used. Is that correct?
My concerns w/ using Flashback are ..
1) The client might decide to rollback the changes a week after they've been executed. The undo data might not be available and the flashback would fail.
2) If any of the following processes are part of the release, the flashback wouldn't work:
"The following DDL operations change the structure of a table, so that you cannot subsequently use the TO SCN or TO TIMESTAMP clause to flash the table back to a time preceding the operation: upgrading, moving, or truncating a table; adding a constraint to a table, adding a table to a cluster; modifying or dropping a column; adding, dropping, merging, splitting, coalescing, or truncating a partition or subpartition (with the exception of adding a range partition)."
Can you address those two issues? Thanks so much for taking the time to respond! This forum has helped me immensely with my work.
-Jenn