"version control" for Oracle database?

Question

Hi,
My work involves loading data from csv files into database tables. The data structure is different in the csv files than that in the tables, so the loading is not straight forward and I often make mistakes along the way. I would like to know what the best practice is for undoing mistakes and rolling back to meaningful point back in time. To make this more concrete, consider the following scenario.
10:00AM I start loading some data into the database. I create two external tables for my csv files.
10:30AM I create a PL/SQL script to insert the data from the external tables to the target tables.
10:35AM I run the PL/SQL script and commit the change.
11:00AM I notice a bug in my script: some of the data is loaded incorrectly, and some are not loaded.
11:15AM I fix the bug, try to run it again but it fails this time because of unique constraints.
At this point, I want my database to go back in time to 10:00AM, so I can start over. How can I do this?
12:00PM Suppose I manage to start over and successfully loaded the two csv files. I still have more files to load. Before I proceed, I want to somehow "tag" the database so that I can go back to this state later (say two weeks from now, and the rollback segment isn't large enough to go back two weeks).
Currently I use data pump export/import to undo mistakes on my development server. Due to the size of the database, it is not as efficient as I would like. I am from a Java developer background. The scenario sounds a lot like source version control to me. Is there such a thing in database land? What's the best practice for doing rapid try-error-rollback cycles?

Answer 1

Is the data in the external tables sorted by some attribute? Consider keeping a small metadata table indicating the last successful key of the attribute that was committed. Then, after the commit, set a Savepoint (use the attribute key value for the savepoint name) and continue execution. If you find an error before your next commit, you can rollback to that savepoint and not lose all of the updates prior to it, but remember that a subsequent commit erases all savepoints you have set. Flashback of the table(s) is also a good idea. You can get the current db commit no. by executing 'Select current_scn from v$database' (you may need privs to read this table from the dba), and then executing 'Flashback table <table_name> to scn <scn_no>'. You can also use a Timestamp in place of scn_no with the Flashback command.