Now that we've executed the first test of our new batch process, we need to "reset" the data back to how it appeared before running the test. We'll shut down and remount the database, then use the ''flashback database" command to "reset" the database to our specified restore point:
SQL> shutdown immediate;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 159383552 bytes
Fixed Size 1259696 bytes
Variable Size 62916432 bytes
Database Buffers 92274688 bytes
Redo Buffers 2932736 bytes
SQL> flashback database to restore point before_test;
We've now "reset" the database back to the restore point. We need to re-open the database, but because we're essentially doing a point-in-time recovery, we need to use the "resetlogs" command to recreate the redo logs and create a new instantiation of the database:
SQL> alter database open resetlogs;
We can verify that we once again see 200 rows in the "testuser.test" table, that our "testuser.logging" table is empty, and that we're ready to test another iteration of our batch processing algorithm:
SQL> select count(*) from testuser.test;
SQL> select count(*) from testuser.logging;
Once we've completed our several iterations of testing, we're ready to remove the guaranteed restore point and free up whatever space the database used to manage the restore point. We accomplish this with the following:
SQL> drop restore point before_test;
Restore point dropped.
Restore points provide a means for a DBA to label a particular point-in-time in the timeline of the database with a user-defined name, without digging into the details of SCNs or timestamps. The guaranteed restore point takes this a step further, providing the ability to guarantee a flashback database is possible until the DBA decides it is no longer needed, along with the ability to perform a flashback database without enabling flashback logging (with a reduced level of functionality). In conclusion, restore points make an invaluable addition to the DBA's arsenal of tools, useful any time a point-in-time recovery is needed.
NOTE: All code tested and known to be working on Oracle 10.2.0.2, running on 32-bit SLES9 (linux).
blog comments powered by Disqus