Flashback Technology Provides A Set of Features To View and Rewind Data Back and Forth in Time
Flashback Technology Provides A Set of Features To View and Rewind Data Back and Forth in Time
Flashback technology provides a set of features to view and rewind data back and forth in time.
The flashback features offer the capability to query past versions of schema objects, query
historical data, perform change analysis, and perform self-service repair to recover from logical
Flashback technology provides a SQL interface to quickly analyze and repair human errors.
Flashback provides fine-grained analysis and repair for localized damage such as deleting the
wrong customer order. Flashback technology also enables correction of more widespread
damage, yet does it quickly to avoid long downtime. Flashback technology is unique to the
Oracle Database and supports recovery at all levels including row, transaction, table, tablespace,
and database.
Oracle Flashback Versions Query is an extension to SQL that can be used to retrieve the versions
of rows in a given table that existed in a specific time interval. Oracle Flashback Versions Query
returns a row for each version of the row that existed in the specified time interval. For any
given table, a new row version is created each time the COMMIT statement is executed.
Oracle Flashback Table enables users to recover a table to a previous point in time. It provides a
fast, online solution for recovering a table or set of tables that has been erroneously modified by
a user or application. In most cases, Flashback Table alleviates the need for administrators to
perform more complicated point-in-time recovery operations. Even after a flashback, the data in
the original table is not lost; it can later be reverted back to the original state.
With 9i this feature was marketed as “Oracle found the time machine” :) But with 9i to flashback
was not so easy, needed DBA privileges etc. After 10g with SELECT statements we are not able
to get only a picture but a movie of our data in time. Ok lets work on an example, seeing is
delete flashback_test ;
commit ;
exec dbms_lock.sleep(15);
VERSIONS_STARTTIME VERSIONS_ENDTIME
VERSIONS_XID VERSIONS_OPERATION C1
-------------------------------------------------
------------------------------------------------- ----------------
------------------ ----------
08/10/2007 08:18:29 08/10/2007 08:18:44
08002200A6040000 U 2
08/10/2007 08:18:44 08/10/2007 08:18:59
03002300C7040000 U 4
08/10/2007 08:18:59
06002900AC040000 D 4
08/10/2007 08:18:29
1
UNDO_SQL
----------------------------------------------------------------------------
insert into "HR"."FLASHBACK_TEST"("C1","C2") values ('4',TO_DATE('08/10/2007',
'
UNDO_SQL
-----------------------------------------------------------------------------
update "HR"."FLASHBACK_TEST" set "C1" = '2' where ROWID =
'AAAONoAAEAAAAGWAAA';
The maximum of there versions e can get are dependent on UNDO_RETENTION parameter of the
PL/SQL as needed. In this example we are looking for the sum of the salaries on the employees
in time;
set serveroutput on
DECLARE
l_scn NUMBER;
l_timestamp TIMESTAMP;
BEGIN
l_scn := TIMESTAMP_TO_SCN(SYSTIMESTAMP - 1/48);
dbms_output.put_line('l_scn '||l_scn);
l_timestamp := SCN_TO_TIMESTAMP(l_scn);
dbms_output.put_line('l_timestamp '||l_timestamp);
END;
/
SQL>
l_scn 1531264
l_timestamp 04/01/2007 08:01:29,000000
SUM(SALARY)
-----------
691400
SUM(SALARY)
-----------
691400
Another related subject is PURGE command and RECYCLEBIN with 10g, after 10g when you drop
a table by default it is stored in recyclebin like windows. And you can restore the table with
SQL>
Table dropped
Table created
Table dropped
Done
PURGE RECYCLEBIN;
PURGE DBA_RECYCLEBIN;
* When you flashback a table the triggers and indexes are not returned with their original
names. This can be fixed by running an extra alter index or alter trigger statement.
* Not only you may want to flashback a table that is dropped, like Versions query a whole table
can be flashbacked in time;
* If there are tables with same names in Recyclebin they can be restores with different names;
Now emp and dept have one row each. In terms of row versions, each table has one
version of one row. Suppose that an erroneous transaction deletes empno 111 from
table emp:
Next, a transaction reinserts empno 111 into the emp table with a new employee
name:
The database administrator detects the application error and must diagnose the
problem. The database administrator issues the following query to retrieve versions of
the rows in the emp table that correspond to empno 111. The query uses Oracle
Flashback Version Query pseudocolumns:
SELECT versions_xid XID, versions_startscn START_SCN,
versions_endscn END_SCN, versions_operation OPERATION,
empname, salary FROM hr.emp
VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
where empno = 111;
The results table rows are in descending chronological order. The third row corresponds
to the version of the row in the table emp that was inserted in the table when the table
was created. The second row corresponds to the row in emp that the erroneous
transaction deleted. The first row corresponds to the version of the row in emp that
was reinserted with a new employee name.
4 rows selected
To see the details of the erroneous transaction and all subsequent transactions, the
database administrator performs the following query:
6 rows selected
Using ORA_ROWSCN
ORA_ROWSCN is a pseudocolumn of any table that is not fixed or external. It
represents the SCN of the most recent change to a given row; that is, the latest
COMMIT operation for the row. For example:
The latest COMMIT operation for the row took place at approximately SCN 202553. To
convert an SCN to the corresponding TIMESTAMP value, use the function
SCN_TO_TIMESTAMP.
);
Table created.
Flashback complete.
ID NAME
---------- ------------------------------
1 Ben Rockwood
2 Tamarah Rockwood
3 Nova Rockwood
4 Hunter Rockwood