Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 380

Sometimes however it is not possible to correct a problem, and a point in time recovery is needed. This can
become a time-consuming process as it involves a restore of the last level 0 backup followed by potential other
incremental backup restore operations until finally you can apply media recovery. Flashback database, another new
10g feature can help in such situations since it merely “rewinds” the database instead. It requires the database to be in
flashback mode. When flashback is enabled the database writes information into an additional set of log files, called
flashback logs. Writing into flashback logs might have negative performance implications and should be tested first!
Flashback database does not only rely on the flashback logs, the archived redo logs are equally required to perform
the operation.
Flashback database is great prior to performing software releases as it allows you to get the database back to
where it was before the release, saving you from having to apply rollback scripts which are usually poorly tested
at best. Instead of having to memorize when the release started it is best to set a guaranteed restore point before
starting to simplify the rollback operation. The guaranteed restore point prevents a situation whereby the information
required to perform the flashback database call has been overwritten in a way similar to the infamous ORA-
1555(snapshot too old) error. Create the guaranteed restore point before the release, as shown here. Remember that
the restore point has to be set in the CDB root.

SYS@CDB$ROOT> create restore point pre_release guarantee flashback database;

Then proceed and deploy the release. If required you can perform a flashback database operation which is very
straightforward, but it affects all PDBs in the CDB. If this is not possible or desirable refer to the PDB Point In Time
Recovery later in this chapter.

SQL> shutdown abort
[...]
SQL> startup mount
[...]
SQL> flashback database to restore point 'pre-release';

Flashback complete.

SQL> alter database open resetlogs;

Database opened.

■ not every operation can be undone using flashback database, some tasks like dropping a data file or certain
nologging operations cannot be undone and require a full point-in-time-recovery. In other words: test the flashback
operation during a release in a non-production environment and read up on the feature's limitations in the documentation.
In data Guard configurations flashback database has additional consequences.

Note

The final topic worth mentioning is similar to the flashback database feature just discussed. Rather than allowing
Oracle to perform the rewind operation you could rely on the storage subsystem to perform this task for you. Your
storage administrator can create snapshots on the array level before important operations, allowing the array to
reset the database as it was before the release or batch-run. Whichever technique works best for you depends on the
relationship of storage administrators and DBAs. If the DBAs like to be in control of the process to the greatest extent,
then it makes a lot of sense to rely on Oracle's restore points and the flashback database feature.