DB_FLASHBACK_RETENTION_TARGET initialization parameter setting. As it is always preserved, it must be dropped explicitly. The disk space usage and the performance overhead of logging for GRP is lower than normal flashback database logging because the database stores the before image of the first time modified block in flashback logs. Any subsequent modifications to the same block do not cause the contents to be logged.Requirements:
1. The database must be running in ARCHIVELOG mode.
2. The fast recovery area must be configured. See my blog at http://anandbitra.blogspot.com/2011/04/fast-recovery-area.html
3. If the flashback logging is not enabled, the database must be mounted to create the first GRP or if all previously created GRPs have been dropped.
Create GRP
SQL> create restore point before_app_upgrade guarantee flashback database;
Drop GRP
SQL> drop restore point before_app_upgrade;
List Restore Points
SQL> select name,scn,time,database_incarnation#,guarantee_flashback_database,storage_size from v$restore_point;
Considerations:
Dropping a tablespace or shrining a datafile can prevent flashback the affected datafiles to GRP. However, the shrunken file can be taken offline to flashback the rest of the database and then the shrunken datafile can be restored and recovered later.
