archivelog needed for a GRP before running flashback database..

archivelog files needed for a guaranteed restore point before running flashback database?

SELECT DISTINCT al.thread#, al.sequence#, al.resetlogs_change#, al.resetlogs_time     FROM v$archived_log al,          (select grsp.rspfscn               from_scn,                  grsp.rspscn                to_scn,                  dbinc.resetlogs_change#    resetlogs_change#,                  dbinc.resetlogs_time       resetlogs_time             from x$kccrsp grsp,  v$database_incarnation dbinc            where grsp.rspincarn = dbinc.incarnation#              and bitand(grsp.rspflags, 2) != 0              and bitand(grsp.rspflags, 1) = 1 -- guaranteed              and grsp.rspfscn <= grsp.rspscn -- filter clean grp              and grsp.rspfscn != 0          ) grsp       WHERE al.next_change#   >= grsp.from_scn           AND al.first_change#    <= (grsp.to_scn + 1)           AND al.resetlogs_change# = grsp.resetlogs_change#           AND al.resetlogs_time       = grsp.resetlogs_time           AND al.archived = 'YES'; Sample Output: SQL> !date Sun Jun 28 13:31:20 UTC 2020    THREAD#  SEQUENCE# RESETLOGS_CHANGE# RESETLOGS ---------- ---------- ----------------- ---------          1         32           1920977 24-JUN-20          1         30           1920977 24-JUN-20          1         31           1920977 24-JUN-20          1         29           1920977 24-JUN-20          1         34           1920977 24-JUN-20          1         33           1920977 24-JUN-20 6 rows selected.

Normal Restore Points and Guaranteed Restore Points

Normal Restore Points and Guaranteed Restore Points

Normal Restore Points

Creating a normal restore point assigns a restore point name to an SCN or specific point in time. Thus, a restore point functions as a bookmark or alias for this SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The control file stores the name of the restore point and the SCN.

If you use flashback features or point-in-time recovery, then you can use the name of the restore point instead of a time or SCN. The following commands support this use of restore points:

The RECOVER DATABASE and FLASHBACK DATABASE commands in RMAN

The FLASHBACK TABLE statement in SQL

Creating a normal restore point eliminates manually recording an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query.

Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant effect on database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.

Guaranteed Restore Points

Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped. In general, you can use a guaranteed restore point as an alias for an SCN with any command that works with a normal restore point. Except as noted, the information about where and how to use normal restore points applies to guaranteed restore points as well.

A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN, even if the generation of flashback logs is disabled. If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only.

Caution:
If flashback logging is disabled, then you cannot FLASHBACK DATABASE directly to SCNs between the guaranteed restore points and the current time. You can, however, flashback to the guaranteed restore point first and then recover to SCN's between the guaranteed restore point and current time.
If the recovery area has enough disk space to store the needed logs, then you can use a guaranteed restore point to rewind a whole database to a known good state days or weeks ago. As with Flashback Database, even the effects of NOLOGGING operations like direct load inserts can be reversed with guaranteed restore points.

Note:
Limitations that apply to Flashback Database also apply to guaranteed restore points. For example, shrinking a datafile or dropping a tablespace can prevent flashing back the affected datafiles to the guaranteed restore point. See "Limitations of Flashback Database" for details. In addition, when there are guaranteed restore points in the database, the database compatibility parameter cannot be set to a higher database version. An attempt to do so results in an error. This restriction exists because flashback database is currently unable to reverse the effects of increasing the database version with the compatibility initialization parameter.

Limitations of Flashback Database

Because Flashback Database works by undoing changes to the datafiles that exist at the moment when you run the command, it has the following limitations:

Flashback Database can only undo changes to a datafile made by Oracle Database. It cannot be used to repair media failures, or to recover from accidental deletion of datafiles.

You cannot use Flashback Database to undo a shrink datafile operation. However, you can take the shrunken file offline, flash back the rest of the database, and then later restore and recover the shrunken datafile.

You cannot use Flashback Database alone to retrieve a dropped datafile. If you flash back a database to a time when a dropped datafile existed in the database, only the datafile entry is added to the control file. You can only recover the dropped datafile by using RMAN to fully restore and recover the datafile.

If the database control file is restored from backup or re-created, all accumulated flashback log information is discarded. You cannot use FLASHBACK DATABASE to return to a point in time before the restore or re-creation of a control file.

When using Flashback Database with a target time at which a NOLOGGING operation was in progress, block corruption is likely in the database objects and datafiles affected by the NOLOGGING operation. For example, if you perform a direct-path INSERT operation in NOLOGGING mode, and that operation runs from 9:00 to 9:15 on April 3, 2005, and you later use Flashback Database to return to the target time 09:07 on that date, the objects and datafiles updated by the direct-path INSERT may be left with block corruption after the Flashback Database operation completes.

If possible, avoid using Flashback Database with a target time or SCN that coincides with a NOLOGGING operation. Also, perform a full or incremental backup of the affected datafiles immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.