So the bottom line is if you think you will be using any flashback options be careful and get prepared about their limitations(mentioned in my previous post linked above), for this case flashback disabled tablespace was the drawback and workaround was to offline it(of course if this is acceptable).

ps: If you want to clean up the mess;

shutdown immediate;
startup
drop user flash cascade;
drop tablespace flashtbs including contents and datafiles;
-- this one is not needed because of the second flashback database
-- drop tablespace flashtbs2 including contents and datafiles;

Like this:

LikeLoading...

Related

Hi nice information. I have a question with nologging and flashback database. We have database running in no logging mode and force logging is off. Now if I create a restore point (guarantee) and do a restore with the flashback database option, do I see any corruption in the data blocks or not. One more thing is that it has some tables created in nologging mode and bulk of insert was happened. It also have standby database running, so after opening it with resetlogs standby gets corrupted or not.

This are the steps I am gone a perform in primary.

— Differ the standby database from primary

— db running in force_logging=off
— We do shutdown immediate
— startup mount
— create restore point
— Not using flashback logging because we just want to put it at restore point creation time only
— alter database open;
— Something goes wrong within 24 hours of retention period
— shutdown immediate
— startup mount
— flashback database to restore point