Friday, November 25, 2011

Flashback Technology in Oracle 10g & 11g

First Written Date: March 13, 2008                          Last Updated: March 23, 2008
Human errors are inevitable.  Every one makes some mistake at some time. The largest cause of
database outage is human error, in addition to hardware failure, block corruption, and complete
database loss.
We have seen in the past that when a table was mistakenly deleted or dropped,  we restored the
data or complete table from another source.  And we saw immediately that the integrity of the
database was lost.
Flashback Technology, first introduced in Oracle 9i,  is a set of Oracle Database features that allow
you to view past states of database objects or to return database objects to a previous state
without using point-in-time media recovery. This new technology reduces recovery time from hours
to minutes.
With flashback features, you can do the following:
·    Perform queries that return past data
·    Perform queries that return meta data that shows a detailed history of changes to the database
·    Recover tables or rows to a previous point in time
·    Automatically track and archive transactional data changes
·    Roll back a transaction and its dependent transactions while the database remains online
·    Rewind the database to a previous point in time
The flashback features are:
1.   Flashback Query                       (Introduced in 9i)
2.   Flashback Version Query          (Introduced in 9i)
3.   Flashback Transaction Query   (Introduced in 9i)
4.   Flashback Table                       (Introduced in 9i)
5.   Flashback Drop                        (Introduced in 9i)
6.   Flashback Database                (Introduced in 10g)
7.   Flashback Data Archive           (Introduced in 11g)
The first 5 flashback features do not need any resource to be set up within the database, and they
require is properly sized “UNDO” tablespace and UNDO Retention Time.
Let us move on to study each feature.
1.   Flashback Query
Flashback Query  was first introduced in 9i and has been enhanced in Oracle Database 10g
Release 1 and later where it provides the ability to query data in the past for more than 5 days if
the UNDO_RETENTION is set for greater than 5 days. Oracle will maintain the undo for that
period of time as long as the Undo Tablespace data files are allocated enough disk space.
The prerequisites are:
1.   Ensure that the database is using an undo tablespace.
2.   Set AUTO to UNDO_MANAGEMENT initialization parameter.
2.   Set the UNDO_RETENTION initialization parameter to a value that causes undo to be kept for a
length of time that allows success of your longest query back in time or to recover from human
errors.
3.   To guarantee that unexpired undo will not be overwritten, set the      RETENTION GUARANTEE
clause for the undo tablespace.
The unique feature of Flashback Query allows you to see the data as it was in the past, then
choose exactly how to process the information.
You might perform an analysis and then undo the changes, or capture changed data for further
processing. The Flashback Query mechanism is flexible enough to be used in many situations. You
can:
·         query data as it existed in the past.
·         compare current data with past data. You can compare individual rows or do more complex
comparisons such as finding the intersection or union.
·         recover deleted or changed data

I will demonstrate this new feature with an example:
Oracle database release 10.2.0.3
16:22:10 -SQL> select name, FLASHBACK_ON from v$database;
NAME                           FLASHBACK_ON
-------------------------- ------------------
GTS                       NO
1 row selected.
16:26:38 -SQL> drop table T1 purge
16:26:38   2  /
Table dropped.
16:26:38 -SQL> create table T1 (id int, rdate date)
16:26:38   2  /
Table created.
16:26:38 -SQL> insert into T1 values (1, sysdate)
16:26:38   2  /
1 row created.
16:26:38 -SQL> insert into T1 values (2, sysdate)
16:26:38   2  /
1 row created.
16:26:38 -SQL> insert into T1 values (3, sysdate)
16:26:38   2  /
1 row created.
16:26:38 -SQL> commit;
Commit complete.
16:26:38 -SQL> select * from T1
16:26:38   2  /
     ID RDATE
---------- -------------------
      1 2008-03-14 16:26:38
      2 2008-03-14 16:26:38
      3 2008-03-14 16:26:38
3 rows selected.
16:27:30 -SQL> delete t1 where id =1 ;
1 row deleted.
16:27:43 -SQL> commit;
Commit complete.
16:27:46 -SQL> select * from t1;
     ID RDATE
---------- -------------------
      2 2008-03-14 16:26:38
      3 2008-03-14 16:26:38
2 rows selected.
The table has only 2 rows.
Now let me flashback query to retrieve the deleted row.
16:29:05 -SQL> select * from T1
16:29:07   2   AS OF TIMESTAMP
16:29:10   3    TO_TIMESTAMP('14-MAR-08 16:27:00', 'DD-MON-
YY Hh24:MI:SS');
     ID RDATE
---------- -------------------
      1 2008-03-14 16:26:38
      2 2008-03-14 16:26:38
      3 2008-03-14 16:26:38
3 rows selected.
As you can see you can query from a table as it was existed in the past. This feature does
not    need to set up FLASHBACK area.
    
2.   Flashback Version Query
Flashback version query would details about the row changes history.
Again, this feature does not need any special setup in the database.
  17:42:24 -SQL> select flashback_on , name from v$database
  17:42:24   2  /
  FLASHBACK_ON       NAME
  ------------------        ----------------
  NO                            GTS
  1 row selected.
  17:42:24  -SQL> create table ps_emp
  17:42:24   2     (empid int, name varchar2(30), salary  number(10,2), rdate date);
  Table created.
  17:42:24  -SQL> exec dbms_lock.sleep(60);  --- Introduce a delay between two transactions
                           PL/SQL procedure successfully
  completed.
  17:43:24  -SQL> insert into ps_emp values (1001, 'Tamil',  3000.00, sysdate)
  17:43:24   2  /
  1 row created.
  17:43:24  -SQL> commit
  17:43:24   2  /
  Commit complete.
  17:43:24  -SQL> exec dbms_lock.sleep(50);
                            PL/SQL procedure successfully
  completed.
  --- Update the same row
  17:44:15  -SQL> update ps_emp set salary=3200, rdate=sysdate where empid=1001
  17:44:15   2  /
  1 row updated.
  17:44:15  -SQL> commit
  17:44:15   2  /
  Commit complete.
  17:44:15  -SQL> exec dbms_lock.sleep(60);
                            PL/SQL procedure successfully
   completed.
  17:45:15  -SQL>
  17:45:15  -SQL> delete ps_emp where empid = 1001
  17:45:15   2  /
  1 row deleted.
  17:45:15  -SQL> commit
  17:45:15   2  /
                      Commit complete.
  17:45:15  -SQL> exec dbms_lock.sleep(50);
                           PL/SQL procedure successfully
   completed.
  17:46:05  -SQL> insert into ps_emp values (1001, 'Tamil',  3400.00, sysdate)
  17:46:05   2  /
                    1 row created.
  17:46:05  -SQL> commit
  17:46:05   2  /
                       Commit complete.
  17:46:05  -SQL> exec dbms_lock.sleep(60);
  PL/SQL procedure successfully completed.
  17:47:05  -SQL> update ps_emp set salary=4000 ,  rdate=sysdate where empid=1001
  17:47:05   2  /
                          1 row updated.
  17:47:05  -SQL> commit
  17:47:05   2  /
                         Commit complete.
  18:04:22 -SQL> select versions_startscn,
  18:04:22   2     to_char(versions_starttime, 'YYYY-MM-DD HH24:MI:SS') st_time,
  18:04:22   3                  versions_xid,     versions_operation, empid, salary
  18:04:22   4        from ps_emp
  18:04:22   5        versions between  timestamp
  18:04:22   6                 to_timestamp('2008-03-15 17:43:24', 'YYYY-MM-DD HH24:MI:SS') and
  18:04:22   7                 to_timestamp('2008-03-15 17:48:00', 'YYYY-MM-DD HH24:MI:SS')
  18:04:22   8      where empid = 1001
  18:04:22   9      order by versions_starttime
  18:04:22  10     /
VERSIONS_STARTSCN ST_TIME             VERSIONS_XID     V    EMPID     SALARY
-----------------          -------------------               --    --------------              - ---------- ----------
635387 2008-03-15 17:43:23         000500150000006E    I       1001       3000     --- Insert
635406 2008-03-15 17:44:14         0002001800000070     U       1001       3200     --- Update
635458 2008-03-15 17:45:15         000A0013000005E9     D       1001       3200     --- Delete
635475 2008-03-15 17:46:03         000A0023000005E9     I        1001       3400     --- Insert
635497 2008-03-15 17:47:03         000A001B000005EC     U        1001       4000     --- Update
The flashback query helps you to identify all the changes occurred in the past, and if there was any
error, you correct the data.  Once the information in the undo segments is lost, then you can’t see
the row changes history.
3.   Flashback Transaction Query
Use Flashback Transaction Query to obtain transaction information, including SQL code that you
can use to undo each change  that the transaction made. Flashback Transaction Query queries the
static data dictionary view FLASHBACK_TRANSACTION_QUERY.
To get the “UNDO” SQL statement, you need to know Transaction
ID (XID) value from the Flashback Version Query.
Assume that you mistakenly deleted the row of emplid 1001 at    2008-03-15 17:45:15, and you
want to revert the change.  You  can easily get the UNDO SQL by querying the table    
FLASHBACK_TRANSACTION_QUERY by filtering the column XID.
18:16:34 -SQL> select xid, start_scn , commit_scn COMMIT,
              2   operation OP, logon_user , undo_sql
              3  FROM flashback_transaction_query
             4* where xid = HEXTORAW('000A0013000005E9')
--- Refer previous example
18:16:52 -SQL> /
XID               START_SCN     COMMIT     OP           LOGON_USER    UNDO_SQL
----------------     ----------      ----------  -------    ------------  ----------------------------------
000A0013000005E9  635406  635458     DELETE     TAMIL    insert into  "TAMIL"."PS_EMP"("EMPID","  NAME",
                                                                                "SALARY","RDATE") values ('1001','Tamil',
                                                                                '3200',
                                                                                TO_DATE('2008-03-15 17:44:15',
                                                                                'YYYY-MM-DD HH24:MI:SS'));
000A0013000005E9     635406     635458 BEGIN        TAMIL
Look at the Operation column. The original operation was a    “delete” statement. And the UNDO
SQL shows “Insert” operation.    This is a simple and straight forward way to get the UNDO SQL.
You don’t need to use LOG Miner to get the UNDO SQL Statement.    More over, you do not need to
set up Flashback Recovery Area to    correct one or more bad rows on a table or group of tables.
4.   Flashback Table
Flashback Table provides the ability to simply revert a table to   previous point in time.  Flashback
Table employs the same   mechanisms as Flashback Query – with information stored in the Undo
segment.  In addition to undo segment, this feature requires you to   enable “row movement” for
the table.
The example given below demonstrates this Flashback Table feature:
10:14:38 TAMIL@GTS-SQL> --- parent table
10:14:38 TAMIL@GTS-SQL> create table ps_dept
10:14:38   2    (deptno number(2),
10:14:38   3     deptname varchar2(30)
10:14:38   4    );
Table created.
10:14:38 -SQL>
10:14:38 -SQL> alter table ps_dept add constraint
10:14:38   2  ps_dept_pk primary key(deptno)
10:14:38   3  using index;
Table altered.
10:14:38 -SQL>
10:14:38 -SQL> --- child table
10:14:38 -SQL> create table ps_emp
10:14:38   2         (empid int,
10:14:38   3          name varchar2(30),
10:14:38   4          salary number(10,2),
10:14:38   5          cdate date,
10:14:38   6          deptno number(2) references ps_dept
10:14:38   7      );
Table created.
10:14:38 -SQL>
10:14:38 -SQL> alter table ps_emp add constraint
10:14:38   2  ps_emp_pk primary key (empid)
10:14:38   3  using index;
Table altered.
10:14:38 -SQL>
10:14:38 -SQL> --- enable row movement
10:14:38 -SQL>
10:14:38 -SQL> alter table ps_dept enable row movement;
Table altered.
10:14:38 -SQL> alter table ps_emp enable row movement;
Table altered.
10:14:38 -SQL>
10:14:38 -SQL> --- insert rows
10:14:38 -SQL>
10:14:38 -SQL> insert into ps_dept values
10:14:38   2   (10, 'Marketing');
1 row created.

10:14:38 -SQL> insert into ps_dept values
10:14:38   2   (20, 'Sales');
1 row created.
10:14:38 -SQL>
10:14:38 -SQL> insert into ps_emp values
10:14:38   2   (1001,'TAMIL',3000, sysdate, 10);
1 row created.
10:14:38 -SQL>
10:14:38 -SQL> insert into ps_emp values
10:14:38   2   (1002,'RAJIV',3000, sysdate, 20);
1 row created.
10:14:38 -SQL>
10:14:38 -SQL> commit;
Commit complete.
10:14:38 -SQL>
10:14:38 -SQL> col name for a8
10:14:38 -SQL> set lines 88
10:14:38 -SQL>
10:14:38 -SQL> select * from ps_dept;
DEPTNO DEPTNAME
---------- ------------------------------
   10 Marketing
   20 Sales
2 rows selected.
10:14:38 -SQL> select * from ps_emp;
EMPID    NAME         SALARY CDATE                         DEPTNO
---------- --------    ----------   -------------------              ----------
 1001      TAMIL          3000   2008-03-16 10:14:38    10
 1002      RAJIV          3000   2008-03-16 10:14:38     20   --- Original Table
2 rows selected.
10:15:38 -SQL> delete ps_emp where empid=1001 ;
1 row deleted.
10:16:03 -SQL> commit;
Commit complete.

10:16:07 -SQL> select * from ps_emp;
EMPID NAME         SALARY CDATE                   DEPTNO
---------- --------       ---------- ------------------- -------    ---
 1002 RAJIV          3000 2008-03-16 10:14:38         20    -- After delete
1 row selected.
10:17:24 -SQL> flashback table ps_emp to timestamp
10:17:37   2      to_timestamp('2008-03-16 10:15:00', 'YYYY-MM-DD    HH24:MI:SS') ;
Flashback complete.
10:17:53 -SQL> select * from ps_emp;
EMPID NAME         SALARY CDATE                   DEPTNO
---------- --------       ---------- ------------------- -------   ---
 1001 TAMIL          3000 2008-03-16 10:14:38         10
 1002 RAJIV          3000 2008-03-16 10:14:38         20    --- Got back the original table
2 rows selected.
11:04:02 -SQL> select object_type, object_name, status from
                              dba_objects where owner='TAMIL';
OBJECT_TYPE    OBJECT_NAME                    STATUS
--------------        ------------------------------     -------
INDEX                PS_DEPT_PK                       VALID
TABLE                PS_DEPT                             VALID
TABLE                PS_EMP                              VALID
INDEX                PS_EMP_PK                        VALID
TABLE                SYS_TEMP_FBT                   VALID    --- A temp Table created for Flashback Table.
5 rows selected.
During the flashback table operation, Oracle created a temporary   table as seen above.
The real problem comes when working with 3rd party applications where we typically see
thousands of tables.  And enabling row movement for all tables is a huge task.

5.   Flashback Drop
Flashback drop lets you to undrop database objects.  When you drop a table, Oracle renames the
table to a system identifiable string (normally starting with BIN$), but the segment remains in the
tablespace.  There are some restrictions:
a.   Dropped objects should NOT be initially created in SYSTEM tablespace.
b.   The tablespace where you drop the object must be LMT.
c.   There is no fixed time that the dropped object will remain in the tablespace.
Here is a simple demo:

SQL> create table PS_TAMIL_TEST (id int);
Table created.
SQL> insert into PS_TAMIL_TEST values (10);
1 row created.
SQL>  insert into PS_TAMIL_TEST values (11);
1 row created.
SQL> commit;
Commit complete.
SQL> drop table PS_TAMIL_TEST;
Table dropped.
SQL> show recyclebin
ORIGINAL NAME    RECYCLEBIN NAME                      OBJECT TYPE  DROP TIME
---------------- ------------------------------                       ------------ -------------------
PS_TAMIL_TEST    BIN$SJW9WpXASWXgRAAaS/Un/Q==$0 TABLE    2008-03-16:18:51:11
SQL> flashback table PS_TAMIL_TEST to before drop;
Flashback complete.
SQL> select * from ps_tamil_test;
   ID
----------
   10
   11             --- Undropped the table

When a user complaints that he mistakenly dropped a table, you do not need to restore the entire
database and start recovery operation. First check the table is available in the RECYCLEBIN. If it’s,
then flashback the table. If the table was created and dropped multiple times, then you may see
multiple lines from the RECYCLEBIN.

SQL> drop table ps_tamil_test;   -- First drop
Table dropped.
SQL> create table ps_tamil_test (id int, name varchar2(20));
Table created.
SQL> insert into ps_tamil_test values (10,'TAMIL');
1 row created.
SQL> commit;
Commit complete.
SQL> drop table ps_tamil_test;    --- 2nd drop
Table dropped.
SQL> select object_name, original_name, droptime, dropscn
2  from user_recyclebin order by droptime;
OBJECT_NAME    ORIGINAL_NAME   DROPTIME                  DROPSCN
---------------                 ------    ---------            -------------------          ----------
BIN$SJW9WpXCSWXgRAAaS/Un/Q==$0 PS_TAMIL_TEST   2008-03-16:19:04:54     673328
BIN$SJW9WpXDSWXgRAAaS/Un/Q==$0 PS_TAMIL_TEST   2008-03-16:19:05:45     673369
You see there 2 tables in the RECYCLEBIN with the same TABLE    name.
Now flashback the 2nd table.
SQL> flashback table "BIN$SJW9WpXDSWXgRAAaS/Un/Q==$0" to before  drop;
Flashback complete.
SQL> select * from ps_tamil_test;
   ID NAME
---------- ------------------------------
   10 TAMIL                                     --- Table undropped.

As a DBA, you do not need to setup any thing extra in the database for flashback drop.  I consider
this is one of the best features of Flashback Technology.
6.   Flashback Database
Flashback Database introduced in 10g is the most revolutionary feature.  Flashback Database
allows the ability to simply rewind the entire database to a previous point in time without affecting
the  integrity of the data.
In order to flashback the database you must have SYSDBA privilege and the flash recovery area
must have been configured in advance, and the database must be running  in archivelog mode.
The following example demonstrates point in time recovery using FLASHBACK DATABASE.
Step 1  Login as sys and set up recovery area.
SYS@GTS-SQL> alter system set db_recovery_file_dest_size=1G scope=spfile;
System altered.
SYS@GTS-SQL> alter system
                            set db_recovery_file_dest =  '/opt/app/GTS/oraarch01' scope=spfile;   
System altered.
SYS@GTS-SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@GTS-SQL> startup mount;
ORACLE instance started.
Total System Global Area  641728512 bytes
Fixed Size                            2145856 bytes
Variable Size                    427737536 bytes
Database Buffers              209715200 bytes
Redo Buffers                         2129920 bytes
Database mounted.
Step 2.  Turn on FLASHBACK
SYS@GTS-SQL> alter database flashback on ;
Database altered.
SYS@GTS-SQL> alter database open ;
Database altered.

SYS@GTS-SQL> select name, flashback_on from v$database ;
NAME                    FLASHBACK_ON
---------------------- ------------------
GTS                       YES                         ---     Ensured that flashback is turned on

Step 3.   LOGIN as TAMIL and create a table.
19:36:49 TAMIL@GTS-SQL> create table TAMIL_FLASH
                                                  as select * from dba_objects;
Table created.
19:37:10 TAMIL@GTS-SQL> select count(*) from TAMIL_FLASH ;
COUNT(*)
----------
40375
Step 4.  Login as Sys and verify flashback database status
SYS@GTS-SQL> select * from v$flashback_database_stat;
BEGIN_TIME  END_TIME    FLASHBACK_DATA    DB_DATA  REDO_DATA    ESTIMATED_FLASHBACK_SIZE
-----------     ----------      ---    --------   ----------      ----------            ----------    --------------
2008-03-16 19:33:51 2008-03-16 19:40:11         860160    4980736    4803584                        0
Step 5.  Login as Tamil and introduce a fault
TAMIL@GTS-SQL> truncate table TAMIL_FLASH ;
Table truncated.
Step 6.  Login as Sys and flashback the database to previous  point in time
SYS@GTS-SQL> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@GTS-SQL> startup mount;
ORACLE instance started.
Total System Global Area  641728512 bytes
Fixed Size                             2145856 bytes
Variable Size                    427737536 bytes
Database Buffers              209715200 bytes
Redo Buffers                         2129920 bytes
Database mounted.
SYS@GTS-SQL> flashback database to timestamp
                                 to_timestamp('2008-03-16 19:40:11','YYYY-MM-DD HH24:MI:SS');
Flashback complete.
Note: If you know the SCN, then You can flashback the database  to previous SCN also.
SYS@GTS-SQL> alter database open read only;
Database altered.
Step 7.  Login as  TAMIL and verify the rows exist from the  truncated table.
TAMIL@GTS-SQL> select count(*) from TAMIL_FLASH ;
COUNT(*)
----------
40375           --------- all the rows are recovered.

Step 8. Login as SYS and finally open the database with  RESETLOGS option.
SYS@GTS-SQL> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@GTS-SQL> startup mount;
ORACLE instance started.
Total System Global Area  641728512 bytes
Fixed Size                            2145856 bytes
Variable Size                    427737536 bytes
Database Buffers              209715200 bytes
Redo Buffers                         2129920 bytes
Database mounted.
SYS@GTS-SQL> alter database open resetlogs;
Database altered.
Since, the database has been rewound to previous point in time,  you must open the database
with RESETLOGS option.
Flashback database is really a good feature in development and test environments where you
frequently restore the database to previous point in time.
Some important points to remember are:
·           You cannot rewind the database to a time more than  DB_FLASHBACK_RETENTION_TARGET
value.
·           The database must be running with ARCHIVELOG mode.
·           You need to estimate the size for the FRA, and allocate Disk storage.


7.   Flashback Data Archive
The Flashback Data Archive in Oracle 11g tracks every single change made to the data stored
inside the database and maintains a secure and easily accessible archive of historical data. The
captured historical data can be retained for as long as the business wants it.

Oracle Release 11g
Step 1 Login as Sys and create a tablespace
create tablespace TBS1 datafile
'C:\OPT\APP\ORACLE\ORADATA\GTS\TBS1.DBF'
extent management local autoallocate;
Step 2 Create FLASHBACK ARCHIVE
Create a default Flashback Data Archive named fla1 that uses
up to 1 G of tablespace tbs1, whose data will be retained for
one year:
CREATE FLASHBACK ARCHIVE DEFAULT fla1 TABLESPACE tbs1
  QUOTA 1G RETENTION 1 YEAR;
Step 3 Login as TAMIL and create table
20:57:04 SQL> create table sale_comm
20:57:04   2   (empid        number(3),
20:57:04   3    name         varchar2(20),
20:57:04   4    commission number(5,2),
20:57:04   5    idate        date)
20:57:04   6  tablespace TBS1
20:57:04   7  flashback archive FLA1;
Table created.
20:57:04 SQL> insert into sale_comm values
20:57:04   2   (101, 'TAMIL', 200.00 , sysdate);
1 row created.
20:57:04 SQL> commit;
Commit complete.
20:57:04 SQL> exec dbms_lock.sleep(100);
PL/SQL procedure successfully completed.
20:58:44 SQL> update sale_comm set commission = 300
20:58:44   2  where  empid = 101;
1 row updated.
20:58:44 SQL> commit;
Commit complete.

21:00:19 SQL> select * from sale_comm;
  EMPID NAME    COMMISSION IDATE
---------- ------------- ----------       --------------------
    101 TAMIL           300           17-MAR-2008 20:57:04
1 row selected.
21:00:26 SQL> select * from sale_comm
21:00:34   2  as of timestamp
21:00:40   3  to_timestamp('17-MAR-2008 20:58:00','DD-MON-YYYY Hh24:mi:ss');
  EMPID NAME                 COMMISSION IDATE
---------- -------------------- ---------- ----------------   ----
    101 TAMIL                       200 17-MAR-2008 20:57:04
1 row selected.
21:04:47 SQL> select * from sale_comm
        2  as of timestamp
        3* (systimestamp - interval '7' MINUTE)
21:04:57 SQL> /
  EMPID NAME                 COMMISSION IDATE
---------- -------------------- ---------- --------------------
    101 TAMIL                       200 17-MAR-2008 20:57:04
1 row selected.

Summary




#
Feature
Prerequisites /
Additional Setup
Comments
1
Flashback Query
None. Properly sized
UNOD tablespace and
retention time
Query data as in the past and
offers to reconstruct
lost/changed data
2
Flashback Version
Query
Same as above
Provides a mechanism to view
changes made at row level.
3
Flashback
Transaction Query
Same as above
Provides UNDO SQL at the
transaction level to correct user
errors.
4
Flashback Table
ENABLE ROW
MOVEMENT
Provides the ability to recover a
table, a set of tables to a
previuos point in time.
5
Flashback Drop
None
Only objects stored in
non-system tablespace can be
undropped and the tablespace
must be LMT.
6
Flasback Database
Flashback Recovery
Area
Rewinds the database w/o
affecting the integrity of data.
More Suitable for dev and test
environments.
7
Flashback Data
Archive
Tablespace ;
Retention Time
Provides the ability to view
historical data changes.





1 comment: