Flashback Technologies Features

Flashback supports recovery at all levels including the row, transaction, table, and the entire database.
Flashback provides an ever growing set of features to view and rewind data back and forth in time,
namely:

● Flashback Database: restore the entire database to a specific point-in-time, using

Oracle-optimized flashback logs, rather than via backups and forward recovery.
● Flashback Table: easily recover tables to a specific point-in-time, useful when a logical
corruption is limited to one or a set of tables instead of the entire database.
● Flashback Drop: recover an accidentally dropped table. It restores the dropped table, and all
of its indexes, constraints, and triggers, from the Recycle Bin (a logical container of all dropped
objects).
● Flashback Transaction: undo the effects of a single transaction, and optionally, all of its
dependent transactions. via a single PL/SQL operation or by using an Enterprise Manager
wizard.
● Flashback Transaction Query: see all the changes made by a specific transaction, useful
when an erroneous transaction changed data in multiple rows or tables.
● Flashback Query: query any data at some point-in-time in the past. This powerful feature can
be used to view and logically reconstruct corrupted data that may have been deleted or
changed inadvertently.
● Flashback Versions Query: retrieve different versions of a row across a specified time interval
instead of a single point-in-time.
● Total Recall: efficiently manage and query long-term historical data. Total Recall automatically
tracks every single change made to the data stored inside the database and maintains a
secure, efficient and easily accessible archive of historical data.

The Flashback features offer the capability to query historical data, perform change analysis, and perform
self-service repair to recover from logical corruptions while the database is online. With Oracle Flashback
Technology, you can indeed undo the past.

FLASHBACK DATABASE
Purpose
Use the FLASHBACK DATABASE command to rewind the database to a target time, SCN, or log
sequence number.

This command works by undoing changes made by Oracle Database to the data files that exist
when you run the command. Flashback can fix logical failures, but not physical failures. Thus, you
cannot use the command to recover from disk failures or the accidental deletion of data files.

FLASHBACK DATABASE is usually much faster than a RESTORE operation followed by point-in-time
recovery, because the time needed to perform FLASHBACK DATABASE depends on the number of
changes made to the database since the desired flashback time. On the other hand, the time
needed to do a traditional point-in-time recovery from restored backups depends on the size of the
database.

Flashback Database also has several uses in a Data Guard environment.

Prerequisites

You can run this command from the RMAN prompt or from within a RUN command.

RMAN must be connected as TARGET to a database, which must be Oracle Database 10g or later.
The target database must be mounted with a current control file, that is, the control file cannot be a
backup or re-created. The database must run in ARCHIVELOG mode.

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

The fast recovery area must be configured to enable flashback logging. Flashback logs are stored as
Oracle-managed files in the fast recovery area and cannot be created if no fast recovery area is
configured. You must have enabled the flashback logging before the target time for flashback using
the SQL statement ALTER DATABASE ... FLASHBACK ON. Query V$DATABASE.FLASHBACK_ON to
see whether flashback logging has been enabled.

The database must contain no online tablespaces for which flashback functionality was disabled with
the SQL statement ALTER TABLESPACE ... FLASHBACK OFF.

Usage Notes
A Flashback Database operation applies to the whole database. You cannot flash back individual
tablespaces. A Flashback Database operation is similar to a database point-in-time recovery
(DBPITR) performed with RECOVER, but RMAN uses flashback logs to undo changes to a point
before the target time or SCN. RMAN automatically restores from backup any archived redo log files
that are needed and recovers the database to make it consistent. RMAN never flashes back data for
temporary tablespaces.

The earliest SCN that can be used for a Flashback Database operation depends on the setting of
the DB_FLASHBACK_RETENTION_TARGET initialization parameter, and on the actual retention of
flashback logs permitted by available disk. View the current database SCN in
V$DATABASE.CURRENT_SCN.

Oracle Flashback
Oracle flashback allows you to move database back in time. You can use flashback
technology to move entire database or a particular table inside database.

● Flashback Table Before Drop

● Flashback Table
● Flashback Database
● Enable Flashback
● Create Sample User
● Flashback Database to SCN or Timestamp

Note: only for flashback database activity, you must enable flashback
database. For all other flashback activities, you do not need to enable flashback
database
Flashback Table Before Drop

You can flashback a dropped table from recyclebin using flashback table command
SHOW RECYCLEBIN;

FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE

DROP;

or

FLASHBACK TABLE SCOTT.FLASH_EMP TO BEFORE DROP;

You can even rename table while flashing it back from recyclebin

FLASHBACK TABLE SCOTT.FLASH_EMP TO BEFORE DROP RENAME TO

NEW_EMP;

Note: Recyclebin must be enabled to use flashback table before drop

Flashback Table
You can flashback table to a particular SCN or time in the past. Before you can
flashback table, you must enable row movement

ALTER TABLE hr.employees ENABLE ROW MOVEMENT;

Now you are ready to flashback table to SCN or timestamp

FLASHBACK TABLE EMP TO SCN <scn_no>;

FLASHBACK TABLE HR.EMPLOYEES TO TIMESTAMP

TO_TIMESTAMP(‘2016-05-12 18:30:00’, ‘YYYY-MM-DD HH24:MI:SS’);

Note: for flashback table, enabling FLASHBACK DATABASE is not required at

all

Flashback Database

We can move an entire database back in time to a particular SCN or a timestamp.

Flashback Database must be already enabled on the database to user this feature.

Enable Flashback Database

Make sure DB_RECOVERY_FILE_DEST parameter is set. This is the location where
Oracle will store flashback logs

SQL> alter system set db_recovery_file_dest='/u02/flash_logs'

SCOPE=spfile;

Set DB_RECOVERY_FILE_DEST parameter as per requirement

SQL> alter system set db_recovery_file_dest_size=50G

SCOPE=spfile;

Set the DB_FLASHBACK_RETENTION_TARGET parameter which specifies the upper

limit (in minutes) on how far back in time the database can be flashed back

SQL> alter system set db_flashback_retention_target=2880;

Enable flashback database which requires database bounce

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database flashback on;
SQL> alter database open;

SQL> select flashback_on from v$database;

Create Sample User

Let us capture the database SCN number before we create a user

SQL> SELECT current_scn, SYSTIMESTAMP FROM v$database;
Current SCN: 2703232

Create a user FLASH_USR and try to connect the database with same user
SQL> create user flash_usr identified by flash_usr;
SQL> grant connect, resource to flash_usr;

SQL> conn flash_usr/flash_usr;

Flashback Database to SCN or Timestamp

Assume that the user has been created by mistake and you want to flashback database
to the SCN just before the user creation. Shutdown DB and startup mount
SQL> shut immediate;

SQL> startup mount;

Flashback database to SCN before user creation and open database with resetlogs
SQL> Flashback database to scn 2703232;

SQL> Alter database open resetlogs;

You can flashback database to particular timestamp too

FLASHBACK DATABASE TO TIMESTAMP

TO_TIMESTAMP(‘2016-05-12 18:30:00’, ‘YYYY-MM-DD HH24:MI:SS’);

How to quickly restore to a clean database using Oracle’s
restore point ?

Restore point:
Restore point is nothing but a name associated with a timestamp or an SCN of the
database. One can create either a normal restore point or a guaranteed restore point.
The difference between the two is that guaranteed restore point allows you to flashback
to the restore point regardless of the DB_FLASHBACK_RETENTION_TARGET
initialization parameter i.e. it is always available (assuming you have enough space in
the flash recovery area).

Guaranteed Restore point:

Prerequisites: Creating a guaranteed restore point requires the following prerequisites:

● The user must have the SYSDBA system privileges
● Must have created a flash recovery area
● The database must be in ARCHIVELOG mode

Create a guaranteed restore point:

After you have created or migrated a fresh database, first thing to do is to create a
guaranteed restore point so you can flashback to it each time before you start a new
workload. The steps are as under:
1. $> su – oracle
2. $> sqlplus / as sysdba;
3. Find out if ARCHIVELOG is enabled
SQL> select log_mode from v$database;
If step 3 shows that ARCHIVELOG is not enabled then continue else skip to step
8 below.
4. SQL> shutdown immediate;
5. SQL> startup mount;
6. SQL> alter database archivelog;
 7. SQL> alter database open;
8. SQL> create restore point CLEAN_DB guarantee flashback database;
where CLEAN_DB is the name given to the guaranteed restore point.

Viewing the guaranteed restore point

SQL> select * from v$restore_point;

Verify the information about the newly created restore point. Also, note down the SCN#
for reference and we will refer to it as "reference SCN#"

Flashback to the guaranteed restore point

Now, in order to restore your database to the guaranteed restore point, follow the steps
below:
1. $> su – oracle
2. $> sqlplus / as sysdba;
3. SQL> select current_scn from v$database;
4. SQL> shutdown immediate;
5. SQL> startup mount;
6. SQL> select * from v$restore_point;
7. SQL> flashback database to restore point CLEAN_DB;
8. SQL> alter database open resetlogs;
9. SQL> select current_scn from v$database;

Compare the SCN# from step 9 above to the reference SCN#.