we have flashback at various levels -

flashback query/versions query - UNDO based
flashback transaction query/flashback transaction - UNDO and a bit of REDO based
flashback data archive - UNDO based to generate archive into table
flashback undrop table - recycle bin based, works object by named object
flashbck table - UNDO based

those work on individual named objects, data only. they are object by object capabilities. The next leap is

flashback database - fast recovery area based, used pre-checkpoint images of blocks and redo to put the database back the way it was (or before) and then roll it forward. Replaces all blocks on disk that were modified since the flashback time with a pre-checkpoint image of the block from the fast recovery area. Works on the ENTIRE database (or none of the database, it is all or nothing).


There is nothing even close in between these two areas. We have flashback that works object by object - object by individual object. We have flashback that works at the entire database level.

There is nothing in the middle that could even come close to putting a schema back the way it was at a former point in time.

The individual object by object technologies cannot do it since they would put entire objects back the way they were (and we need a very selective update to the data dictionary here - not the ENTIRE dictionary) and they do not cover things like code.

The flashback database technology could never be tweaked to do it - that works on basic recovery principles - you have a set of blocks that need to be rolled forward, recovered. There is no way to do that selectively - to just roll back the changes made on behalf of a schema.


so, I frankly do not see it happening at a schema level, there is a lot involved - the code needs to be put back, the data (that part is "easy" - we can do that in a trivial sense already), the grants - both internal and external (things this schema GRANTED and things granted TO this schema - or revoked), the synonyms, the views and so on and so on...


In the future - looking at pluggable database - we will likely have a flashback pluggable database at some point (not in the first release) which would be a valid solution going forward.