To introduce the second kind of flashback, let me first present you a seemingly trivial scenario: Open one session against your Oracle Database, take a table of your choice and make an update of one row of it without commit. Then open a second session and select the rows of that table.
Please notice two things: 1. The query does not wait for the first session to commit. 2. The query shows a consistent result set with the old value of the row that you updated in the first session. This is called read consistency and is delivered by Oracle Databases since version 6 without the need for the select to lock rows in the table. We make that possible by retaining the old value of the updated row (called before image) in undo segments. Since the 9i version, we make additional usage of these before images; in 9i you can do a flashback query like this:
select * from t as of timestamp systimestamp – interval ’15‘ minute;
That select shows the content of table t as it was before 15 minutes – provided that the before images to reconstruct this content are still present in the undo segments. 10g takes that approach one step further by making it possible to do a „table point in time recovery“ with the old values of the table reconstructed from the before images. The command goes
alter table t enable row movement;
flashback table t to timestamp systimestamp – interval ’15‘ minute;
You can also provide a comma separated list of tables in that statement to flashback all the tables that belong together. This can be extremely useful and works very fast and easy compared to the old cumbersome and time consuming methods to achieve the same result!
If you just want to investigate who made exactly what kind of logical mistake, you can achieve that with Flashback Transaction Query – also a 10g New Feature and explained here.
Pickleball spielen 