Getting Clear on FLASHBACK

During the teaching of the DBA I workshop this week, I've had something greatly clarified - by the observing instructors there - thanks Tony Woodell and Larry Baumann. It has to do with Flashback technology, and what the underlying supporting data is for making each of them happen. It's good to know this, because it helps to keep straight what each flashback command (well, they're not all "commands", either) is doing for you.

Flashback technology  What it uses
--------------------  ------------
Flashback Database    Flash Recovery Area
Flashback Table       Undo
Flashback Drop        Recycle Bin
Flashback Query       Undo
Flashback Version     Undo
Flashback Transaction Undo

It's also good to keep clear that the first three *change* data in the database. The last 3 are simply add-on clauses, or different way to *select* - the flashback is just done on the fly, so you can reach back in time and retrieve the data you're after, for the time you specify. The recycle bin is a great thing, but keep in mind that it isn't really an area of storage that you set up in any way. As tables are dropped, they are renamed, and thus hidden, in a way. As long as they are not PURGEd (either by manually issuing the PURGE clause at drop time, or automatically when there is space pressure) then the table is still considered to be in the recycle bin. And, mind you, there is no way to guarantee how long a table sticks around in the recycle bin, so don't depend on it in your design. The class is over - it went very well, and now we have a lot of good feedback to work back into it before it gets out the door.