Contents:

Introduction

Configuring Database to Oracle Flashback

Create Flashback Archive

AlterFlashback Archive

Drop Flashback Archive

Enabling Flashback to Database

Flashback Query

Flashback Version Query

Flashback Transaction Query

Flashback Table

Flashback Database

Flashback Drop

Flashback Data Archive  

Introduction:Oracle9i introduced the DBMS_FLASHBACK package to allow queries to reference older versions of the database. Oracle 10g has taken this technology a step further making it simpler to use and much more flexible. Oracle Flashback Technology is a group of Oracle Database features that let you to view past states of database objects or to return database objects to a previous state without using point-in-time media recovery. With flashback features, you can do the following:

Perform queries that return past data Perform queries that return metadata 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

Oracle Flashback features use the Automatic Undo Management system to obtain metadata and historical data for transactions. They rely on undo data, which are records of the effects of individual transactions. For example, if a user executes an UPDATE statement to change a salary from 15000 to 18000, then Oracle Database stores the value 15000 in the undo data. Undo data is persistent and survives a database shutdown. By using flashback features, you can use undo data to query past data or recover from logical damage.

 

Configuring Your Database for Oracle Flashback Technology:Before you can use flashback features in your application, you must perform the configuration tasks described in the following topics:

Configuring Your Database for Automatic Undo Management

To configure your database for Automatic Undo Management , you must do the following:

1. Create an undo tablespace with enough space to keep the required data for flashback operations. The more often users update the data, the more space is required. The database administrator usually calculates the space requirement.

2. Enable automatic undo management, as explained below. Set the following database initialization parameters for the database,

UNDO_MANAGEMENT

UNDO_TABLESPACE

UNDO_RETENTION

The below picture show the parameters that should mentioned in parameter file, For a fixed-size undo tablespace, Oracle Database automatically tunes the system to give the undo tablespace the best possible undo retention. For an automatically extensible undo tablespace, Oracle Database retains undo data longer than the longest query duration as well as the low threshold of undo retention specified by the UNDO_RETENTION parameter.

3. Setting UNDO_RETENTION does not guarantee that unexpired undo data is not discarded. If the system needs more space, Oracle Database can overwrite unexpired undo with more recently generated undo data. Specify the RETENTION GUARANTEE clause for the undo tablespace to ensure that unexpired undo data is not discarded.

Configuring Your Database for Oracle Flashback Transaction Query

To configure your database for the Oracle Flashback Transaction Query feature, you must do the following:

a.Ensure that Oracle Database is running with version 10.0 or higher compatibility.

b.Enable supplemental logging by using,

SQL>ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Configuring Your Database for Flashback Transaction

a.To configure your database for the Flashback Transaction feature, With the database mounted state but not open, enable ARCHIVELOG:

SQL>ALTER DATABASE ARCHIVELOG;

b. Switch at least one archive log.

SQL>ALTER SYSTEM ARCHIVE LOG CURRENT;

Granting Necessary Privileges

You must grant privileges to users, roles, or applications that must use the following flashback features.

a.For Oracle Flashback Query and Oracle Flashback Version Query

To allow access to specific objects during queries, grant FLASHBACK and SELECT privileges on those objects or to allow queries on all tables, grant the FLASHBACK ANY TABLE privilege. For Oracle Flashback Transaction Query Grant the SELECT ANY TRANSACTION privilege.

b. To allow execution of undo SQL code retrieved by a Oracle Flashback Transaction Query, grant SELECT, UPDATE, DELETE, and INSERT privileges for specific tables.

c. For DBMS_FLASHBACK Package

To allow access to the features in the DBMS_FLASHBACK package, grant the EXECUTE privilege on DBMS_FLASHBACK.

d. For Flashback Data Archive

To allow a specific user to enable Flashback Data Archive on tables, using a specific Flashback Data Archive, grant the FLASHBACK ARCHIVE object privilege on that Flashback Data Archive to that user. To grant the FLASHBACK ARCHIVE object privilege, you must either be logged on as SYSDBA or have FLASHBACK ARCHIVE ADMINISTER system privilege.

To allow execution of the following statements, grant the FLASHBACK ARCHIVE ADMINISTER system privilege.

Create Flashback Archive:Create a Flashback Data Archive named fla1 that uses tablespace tbs2, whose data will be retained for two years:

SQL>CREATE FLASHBACK ARCHIVE fla1 TABLESPACE tbs2 RETENTION 2 YEAR;

Alter Flashback Archive:

To Make Flashback Data Archive fla1 the default Flashback Data Archive:

SQL>ALTER FLASHBACK ARCHIVE fla1 SET DEFAULT;

To Flashback Data Archive fla1, add up to 5 G of tablespace tbs3:

SQL>ALTER FLASHBACK ARCHIVE fla1 ADD TABLESPACE tbs3 QUOTA 5G;

To Flashback Data Archive fla1, add as much of tablespace tbs4 as needed:

SQL>ALTER FLASHBACK ARCHIVE fla1 ADD TABLESPACE tbs4;

Change the maximum space that Flashback Data Archive fla1 can use in tablespace tbs3 to 20 G:

 SQL>ALTER FLASHBACK ARCHIVE fla1 MODIFY TABLESPACE tbs3 QUOTA 20G;

Allow Flashback Data Archive fla1 to use as much of tablespace tbs1 as needed:

SQL>ALTER FLASHBACK ARCHIVE fla1 MODIFY TABLESPACE tbs1;

Change the retention time for Flashback Data Archive fla1 to two years:

SQL>ALTER FLASHBACK ARCHIVE fla1 MODIFY RETENTION 2 YEAR;

Remove tablespace tbs2 from Flashback Data Archive fla1:

SQL>ALTER FLASHBACK ARCHIVE fla1 REMOVE TABLESPACE tbs2;

Purge all historical data from Flashback Data Archive fla1:

SQL>ALTER FLASHBACK ARCHIVE fla1 PURGE ALL;

Purge all historical data older than one day from Flashback Data Archive fla1:

SQL>ALTER FLASHBACK ARCHIVE fla1 PURGE BEFORE TIMESTAMP (SYSTIMESTAMP-INTERVAL ‘1’ DAY);

Purge all historical data older than SCN 728969 from Flashback Data Archive fla1:

SQL>ALTER FLASHBACK ARCHIVE fla1 PURGE BEFORE SCN 728969;

Drop Flashback Archive:

Remove Flashback Data Archive fla1 and all its historical data, but not its tablespaces:

SQL>DROP FLASHBACK ARCHIVE fla1;

Uses of Oracle Flashback Query:1. Recovering lost data or undoing incorrect, committed changes.

2. Comparing current data with the corresponding data at some time in the past.

3. Checking the state of transactional data at a particular time.

4. Simplifying application design by removing the need to store some kinds of temporal data.

5. Oracle Flashback Query lets you retrieve past data directly from the database.

6. Applying packaged applications, such as report generation tools, to past data.

7. Providing self-service error correction for an application, thereby enabling users to undo and correct their errors.

 

Enabling Flashback to the database:1. Database has to be in archivelog mode.

 

2. Flash Recovery Area has to be configured. To configure follow the below steps,

SQL> Show parameter db_recovery_file_dest

If Currently flashback is disabled. To enable follow the steps,

A. Set db_recovery_file_dest_size initialization parameter.

SQL> Alter system set db_recovery_file_dest_size=2g;

B. After db_recovery_file_dest_size parameter has been set, create a directory for flashback logs to store.

$ mkdir -p /u01/db1/admin/arch

C. Now set db_recovery_file_dest initialization parameter.

SQL> Alter system set db_recovery_file_dest=’/u01/db1/admin/arch ‘; (or)

SQL> Alter system set db_recovery_file_dest=’/ u01/db1/admin/arch ‘ sid= ‘bsprod01’;

SQL> Show parameter db_recovery

3. Create an Undo Tablespace with enough space to keep data for flashback operations. More often users update the database more space is required.

SQL> Create undo tablespace undotbs datafile ‘/u01/db1/oradata/undotbs01.dbf’ size 300m;

4. By default automatic Undo Management is enabled, if not enable it by using below steps,

SQL> Alter system set undo_management=auto scope=spfile;

5. Shut Down your database

SQL> Shut immediate;

6. Startup your database in MOUNT mode

SQL> Startup mount;

7. Change the Flashback mode of the database

SQL> Select flashback_on from v$database;

SQL>Alter database flashback ON;

SQL> Select flashback_on from v$database;

8.Next open the database,

SQL> alter database open;

FLASHBACK mode of the database has been enabled.

 

Flashback Query:Using Oracle flashback query, you can retrieve the committed data as it was at a past point in time. As most of other flashback technologies, this feature retrieves data from the undo tablespace. It is possible to get undo data based on a specific time or scn number. Using the select as of statement with both OF TIMESTAMP and OF SCN clauses, you can use this feature easily. It can even be performed by any application developer without any DBA intervention. Developers can use the dbms_flashback package to perform flashback query directly from their applications, but the execute privilege should be granted on the dbms_flashback package. We can do this by following,

Create a table and insert the values into the table and query it as follows:

SQL> Create table emp_oracle( no number(10),name varchar2(10));

SQL> Insert into emp_oracle values(&no,’&name’);

SQL> Select * from emp_oracle;

 In order to return back to this state of the table anytime, get the current scn number and timestamp:

SQL> Select to_char(sysdate,’dd-mm-yyyy hh24:mi:ss’) ddate , dbms_flashback.get_system_change_number() scn from dual;

 Now run the delete command to clear the table and commit the transaction:

SQL> Delete from emp_oracle;

SQL> commit;

SQL> Select * from emp_oracle;

 As we know that the timestamp at which the table was correct by previous command, we can use flashback query and retrieves the before state of deleted rows from the undo tablespace as follows by using the scn value or timestamp as follows,

SQL> Select count(*) from emp_oracle as of timestamp to_timestamp(’07-02-2010 15:14:21′,’dd-mm-yyyy hh24:mi:ss’);

 In case if you know the scn number ,you can use the OF SCN clause to view the data of the table at the specified scn as follows:

SQL> Select * from emp_oracle as of scn 460135;

 To view the data of the table as it was 15 minutes ago, use the following query:

SQL> Select count(*) from tbl_seg_tbs as of timestamp (systimestamp -interval ’15’ minute);

It is possible to convert scn to timestamp and timestamp to scn using scn_to_timestamp and timestamp_to_scn functions:

SQL>Select scn_to_timestamp(4004040) from dual;

SQL> Select timestamp_to_scn(’07-02-2010 15:14:21′) from dual;

SQL> Select scn_to_timestamp(460141) ddate, timestamp_to_scn(to_timestamp(’07-02-2010 15:14:21′,’dd-mm-yyyy hh24:mi:ss’)) scn from dual;

 Viewing/Retrieving the Dropped PL/SQL Object codes using Flashback Query You can retrieve any dropped PL/SQL object using flashback query. The source of these objects is stored in an internal table sys.source$. It means that when you create a trigger, the line that contains its source is added to that table. The same works for dropping the procedure. Please note that recreating the objects relies on the dependencies being valid; thus, any tables/views referenced in the procedure must be present or recreated before recreating the procedure.

Create a simple trigger and get the current scn valueof the database:

SQL> Create trigger trg_logon after logon on database begin insert into tbl_logons values(sysdate, user);

SQL> Select current_scn from v$database;

Now drop the trigger.

SQL> Drop trigger trg_logon;

Using the scn value that has been noted before dropping the trigger, query the dba_source view as follows:

SQL> Select text from dba_source as of scn 528857 where name=’trg_logon’;

Using the about result text code, you can create or replace the trigger again.

Flashback Version Query:Use Oracle Flashback Version Query to retrieve the different versions of specific rows that existed during a given time interval. A row version is created whenever a COMMIT statement is executed. Specify Oracle Flashback Version Query using the VERSIONS BETWEEN clause of the SELECT statement. The syntax is:

VERSIONS BETWEEN TIMESTAMP [lower bound] AND [upper bound];

or

VERSIONS BETWEEN SCN [lower bound] AND [lower bound].

The lower and upper boundaries can either be specific timestamps/SCNs or the keywords MINVALUE and MAXVALUE. These keywords instruct Oracle to retrieve all available data versions. The age of the data available is determined by the undo_retention parameter.

Oracle Flashback Version Query returns a table with a row for each version of the row that existed at any time during the specified time interval. Each row in the table includes pseudo columns of metadata about the row version This information can reveal when and how a particular change occurred to your database.

Procedure:

Create a table and insert the values into the tbale,

SQL> Create table company( emp_id number(5), emp_name varchar2(10),sal number(10));

SQL> Insert into company values(&emp_id,’&emp_name’,&sal);

SQL> Select * from company;

Now made some updates in the table,

SQL> Update company set sal=15000 where emp_id=3;

SQL> Commit;

SQL> Update company set sal=23000 where emp_name=bbb;

SQL> Commit;

SQL> Update company set emp_name= ppp where emp_id=5;

SQL> commit;

SQL> SELECT LOCALTIMESTAMP FROM dual;

SQL> Delete from company;

 

Now there is no data in the table company, we can now run some flashback version queries against it. This will enable us to view the data as it evolved between commits. Flashback version query is invoked using the new VERSIONS BETWEEN extension to the FROM clause

SQL>Select * from company VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE ORDER BY emp_id;

Flashback version query includes several pseudo-columns to describe each version of our data, which we can now use to determine the actual operations and change times. The metadata is exposed via a number of pseudo-columns that we can use with our flashback version queries. These pseudo-columns are as follows:

VERSIONS_STARTTIME                       start timestamp of version

VERSIONS_STARTSCN                          start SCN of version

VERSIONS_ENDTIME                           end timestamp of version

VERSIONS_ENDSCN                             end SCN of version

VERSIONS_XID                                      transaction ID of version

VERSIONS_OPERATION                     DML operation of version

Use the following command for flashback version query,

SQL>Select VERSIONS_STARTTIME,VERSIONS_ENDTIME,VERSIONS_XID, VERSIONS_OPERATION

FROM company VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE ORDER BY VERSIONS_ENDTIME;

(or)

SQL>Select VERSIONS_STARTSCN, VERSIONS_STARTTIME, VERSIONS_ENDSCN, VERSIONS_ENDTIME, VERSIONS_XID, VERSIONS_OPERATION,

LAST_NAME, SALARY from company VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP(‘2008-12-18 14:00:00’, ‘YYYY-MM-DD HH24:MI:SS’) AND

TO_TIMESTAMP(‘2008-12-18 17:00:00’, ‘YYYY-MM-DD HH24:MI:SS’);

Flashback Transaction Query:Flashback transaction query can be used to get extra information about the transactions listed by flashback version queries. Oracle Flashback Transaction Query is to retrieve metadata and historical data for a given transaction or for all transactions in a given time interval. Oracle Flashback Transaction Query queries the static data dictionary view FLASHBACK_TRANSACTION_QUERY , whose columns are described in Oracle Database Reference.

The column UNDO_SQL shows the SQL code that is the logical opposite of the DML operation performed by the transaction. You can usually use this code to reverse the logical steps taken during the transaction. This statement queries the FLASHBACK_TRANSACTION_QUERY view for transaction information, including the transaction ID, the operation, the operation start and end SCNs, the user responsible for the operation, and the SQL code that shows the logical opposite of the operation:

SQL> Desc flashback_transaction_query;

SQL>Select  xid, operation, start_scn, commit_scn, logon_user, undo_sql FROM flashback_transaction_query where WHERE table_owner =abc and table_name = ‘company’

ORDER BY emp_id;

The VERSIONS_XID column values from a flashback version query can be used to query the FLASHBACK_TRANSACTION_QUERY view.

SQL> Select  xid, operation, start_scn,commit_scn, logon_user, undo_sql from flashback_transaction_query WHERE xid = HEXTORAW(‘0600030021000000’);

The values in the OPERATION column show us this, reading from the top-down. The reversal of this sequence can be viewed by reading the UNDO_SQL column from the bottom-up. For recovery purposes this can be quite useful. Note that the user responsible for the change is also available.

 

Flashback Table:The FLASHBACK TABLE statement is to restore an earlier state of a table in the event of human or application error. The time in the past to which the table can be flashed back is dependent on the amount of undo data in the system. You cannot roll back a FLASHBACK TABLE statement. However, you can issue another FLASHBACK TABLE statement and specify a time just prior to the current time. Therefore, it is advisable to record the current SCN before issuing a FLASHBACK TABLE clause.

Prerequisites:

To flash back a table to an earlier SCN or timestamp, you must have either the FLASHBACK object privilege on the table or the FLASHBACK ANY TABLE system privilege. In addition, you must have the SELECT, INSERT, DELETE, and ALTER object privileges on the table.

Row movement must be enabled for all tables in the Flashback list unless you are flashing back the table TO BEFORE DROP. That operation is called a flashback drop operation, and it uses dropped data in the recyclebin rather than undo data.

SQL>Alter table <tablename>  enable row movement;

To flash back a table to a restore point, you must have the SELECT ANY DICTIONARY or FLASHBACK ANY TABLE system privilege or the SELECT_CATALOG_ROLE role.

To flash back a table to before a DROP TABLE operation, you need only the privileges necessary to drop the table.

 

Procedure:

Create a table and insert the values into the tbale,

SQL> Create table company( emp_id number(5), emp_name varchar2(10),sal number(10));

SQL> Insert into company values(&emp_id,’&emp_name’,&sal);

SQL> Select * from company;

SQL> Alter table company ENABLE ROW MOVEMENT;

SQL> Select current_scn from v$database;

SQL> Select DBMS_FLASHBACK.get_system_change_number from dual;

Now made some updates in the table,

SQL> Update company set sal=15000 where emp_id=3;

SQL> Commit;

SQL>Select current_scn, SYSTIMESTAMP from v$database;

SQL> Select LOCALTIMESTAMP from dual;

SQL> Delete from company;

Now you can restore the deleted or dropped table to its original state by using the following type,

1.TO SCN Clause:

Specify the system change number (SCN) corresponding to the point in time to which you want to return the table. The expr must evaluate to a number representing a valid SCN.

SQL> Flashback Table Company TO SCN 715315;

2.TO TIMESTAMP Clause:

Specify a timestamp value corresponding to the point in time to which you want to return the table. The expr must evaluate to a valid timestamp in the past. The table will be flashed back to a time within approximately 3 seconds of the specified timestamp.

SQL>Flashback Table Company TO TIMESTAMP TO_TIMESTAMP(‘2015-03- 03 10:00:00’, ‘YYYY-MM-DD HH:MI:SS’);

3.TO RESTORE POINT Clause:

Specify a restore point to which you want to flash back the table. The restore point must already have been created.

SQL>Create restore point zero;

SQL> Insert into company values(&emp_id,’&emp_name’,&sal);

SQL>Commit;

SQL>Create restore point one;

SQL> Update company set sal=15000 where emp_id=5;

SQL>Commit;

SQL>Create restore point two;

SQL> Update company set sal=15000 where emp_id=8;

SQL>Commit;

SQL> Select * from company;

SQL>Select  scn, time, name FROM gv$restore_point;

Now you can restore your table to any of the restore piont using below commands,

SQL>Select scn, time, name FROM gv$restore_point;

SQL>FLASHBACK TABLE Company TO RESTORE POINT two;

(or)

SQL>FLASHBACK TABLE Company TO RESTORE POINT zero;

4.TO BEFORE DROP Clause:

Use this clause to retrieve from the recycle bin a table that has been dropped, along with all possible dependent objects.

SQL>Drop table company;

SQL>Show Recyclebin;

SQL>FLASHBACK TABLE Company TO BEFORE DROP;

SQL>Select * FROM Company;

5.RENAME TO Clause:

Use this clause to specify a new name for the table being retrieved from the recycle bin.

SQL>Drop table company;

SQL>Show Recyclebin;

SQL>FLASHBACK TABLE Company TO BEFORE DROP RENAME TO company_old;

6. Enabling and Disabling Triggers to flashback Table:

Triggers can be Enable while performing the flashback to the table by using,

SQL>FLASHBACK TABLE Company TO TIMESTAMP TO_TIMESTAMP(‘2015-11-03 14:00:00’) ENABLE TRIGGERS;

Triggers can be Disable while performing the flashback to the table by using,

SQL>FLASHBACK TABLE Company TO TIMESTAMP TO_TIMESTAMP(‘2015-11-03 14:00:00’) DISABLE TRIGGERS;

 

Flashback Database:The FLASHBACK DATABASE command is a fast alternative to performing an incomplete recovery. In order to flashback the database you must have SYSDBA privilege and the flash recovery area must have been prepared in advance..If the database is in NOARCHIVELOG it must be switched to ARCHIVELOG mode. The FLASHBACK_ON column of theV$DATABASE view shows the current status of flashback database

SQL> Select FLASHBACK_ON from v$database;

With flashback enabled the database can be switched back to a previous point in time or SCN without the need for a manual incomplete recovery.

FLASHBACK DATABASE to a Specific SCN:

You can bring back the database to specific SCN value where the database is in consistence state by using flashback as ,

SQL> Shutdown immediate;

SQL> Startup mount;

SQL> Flashback database to SCN 411010;

SQL> Alter database open resetlogs;

FLASHBACK DATABASE to a Specific TIMESTAMP:

You can bring back the database to specific TIMESTAMP by using flashback database as,

SQL> Shutdown immediate;

SQL> Startup mount;

SQL> Flashback database to  timestamp TO_TIMESTAMP(‘2015- 11-03 14:00:00’);

SQL>  Alter database open resetlogs ;

Some other variations of the flashback database command include.

SQL> Flashback database to TIMESTAMP <timestamp>;

SQL> Flashback database to BEFORE TIMESTAMP <timestamp>;

SQL> Flashback database to  SCN <scn number>;

SQL>Flashback database to BEFORE SCN <scn number>;

FLASHBACK DATABASE to a Restore Point:

In addition to using SCNs and timestamps, we can create guaranteed restore points.

SQL>CREATE RESTORE POINT <before_changes restore point name>;

Existing restore points can be displayed using the V$RESTORE_POINT view. To flashback to this restore point, we would issue the following command.

SQL>FLASHBACK DATABASE TO RESTORE POINT <before_changes restore point name>;

You mount the database, flash back the database to the restore point and then open the database with the RESETLOGS option:

SQL> Shutdown immediate

SQL> Startup mount

SQL> Flashback database to restore point ‘<restore point name>’;

SQL> Alter database open resetlogs;

The window of time that is available for flashback is determined by the DB_FLASHBACK_RETENTION_TARGET parameter. The maximum flashback can be determined by querying the V$FLASHBACK_DATABASE_LOG view. It is only possible to flashback to a point in time after flashback was enabled on the database and since the last RESETLOGS command.

Disabling Flashback Database

Full any previous point in time flashback can be disabled with the database open. Any unused Flashback logs will be automatically removed at this point and a message detailing the file deletion written to the alert log. The Flashback Disabling can be done by using below commands,

$ sqlplus ‘/ as sysdba’

SQL> ALTER DATABASE FLASHBACK OFF;

 

 Flashback Drop(Oracle Recycle Bin):Recycle Bin:

The recycle bin is actually a data dictionary table containing information about dropped objects. Dropped tables and any associated objects such as indexes, constraints, nested tables, and the likes are not removed and still occupy space. They continue to count against user space quotas, until specifically purged from the recycle bin or the unlikely situation where they must be purged by the database because of tablespace space constraints. A user can have his own recycle bin, if he has granted by the SYSDBA privilege. The only objects that the user has access to in the recycle bin are those that the user owns. A user can view his objects in the recycle bin using the statement

SQL>Select * from Recycle Bin;

SQL> select object_name, original_name, operation, type, droptime from user_recyclebin;

SQL> Show RECYCLEBIN;

When you drop a tablespace including its contents, the objects in the tablespace are not placed in the recycle bin and the database purges any entries in the recycle bin for objects located in the tablespace. When a dropped table is moved to the recycle bin, the table and its associated objects are given system-generated names. This is necessary to avoid name conflicts that may arise if multiple tables have the same name.

The renaming convention is as follows:

BIN$unique_id$version

Where:  unique_id = a 26-character globally unique identifier for this object, which makes the recycle bin name unique across all databases

version =a version number assigned by the database

Enabling and Disabling the Recycle Bin:

We can enable and disable the recycle bin with the recyclebin initialization parameter. When the recycle bin is enabled, dropped tables and their dependent objects are placed in the recycle bin. When the recycle bin is disabled, dropped tables and their dependent objects are not placed in the recycle bin.

To Enable the recycle bin for the database issue the below statement,

SQL> Alter system set recyclebin= ON;

To enable it in the session level, use:

SQL>Alter session set recyclebin = ON;

To Disable the recycle bin for the database issue the below statement,

SQL> Alter system set recyclebin= OFF;

To disable it in the session level, use:

SQL> Alter session set recyclebin = OFF;

 

Oracle Database provides two views for obtaining information about objects in the recycle bin:

View                                                Description

USER_RECYCLEBIN                  This view can be used by users to see their own dropped objects in the recycle bin.

DBA_RECYCLEBIN                     This view gives administrators visibility to all dropped objects in the recycle bin.

You can query objects that are in the recycle bin, just as you can query other objects. However, you must specify the name of the object as it is identified in the recycle bin.

SQL> Show recyclebin;

SQL>Select * from “BIN$yrMKlZaVMhfgNAgAIMenRA==$0”;

Purging Objects in the Recycle Bin

The purging will delete the data objects permanently from the database. You can do this by following queries,

SQL> Purge Table company;

or

SQL>Show recycle bin;

SQL> Purge Table BIN$jsleilx392mk2=293$0;

Users can purge the recycle bin of their own objects, and release space for objects, by using the following statement:

SQL>PURGE RECYCLEBIN;

 

Several purge options options for Recycle Bin are:

PURGE TABLE tablename;                                                Specific table.

PURGE INDEX indexname;                                               Specific index.

PURGE TABLESPACE ts_name;                                      All tables in a specific tablespace.

PURGE TABLESPACE ts_name USER username;       All tables in a specific tablespace for a specific user.

PURGE RECYCLEBIN;                                                       The current users entire recycle bin.

PURGE DBA_RECYCLEBIN;                                            The whole recycle bin.

 

The restrictions relating to the recycle bin:

Only available for non-system, locally managed tablespaces. There is no fixed size for the recycle bin. The time an object remains in the recycle bin can vary. The objects in the recycle bin are restricted to query operations only (no DDL or DML).

Flashback query operations must reference the recycle bin name. Tables and all dependent objects are placed into, recovered and purged from the recycle bin at

the same time. Tables with Fine Grained Access policies are not protected by the recycle bin. Partitioned index-organized tables are not protected by the recycle bin. The recycle bin does not preserve referential integrity.

FLASHBACK Table To BEFORE DROP:

The recycle bin is a logical collection of previously dropped objects, with access tied to the DROP privilege. This feature does not use flashback logs or undo, so it is independent of the other flashback technologies. As a result, a previously dropped table can be recovered from the recycle bin.

SQL>Drop table company;

SQL> Show RECYCLEBIN;

You can view the table data from the recyclebin name of the table as follows,

SQL> select * from BIN$jsleilx392mk2=293$0;

You can retrieve the original table data by using the statement

SQL> Flashback table company to BEFORE DROP;

 You can rename an dropped object to a new name by using the below statements,

SQL> Drop table company;

SQL> Show RECYCLEBIN;

SQL> Flashback table company TO Before Drop Rename TO my_comapany;

Flashback Data Archive (Oracle Total Recall):A Flashback Data Archive provides the ability to track and store transactional changes to a table over its lifetime. A Flashback Data Archive is useful for compliance with record stage policies and audit reports. A Flashback Data Archive consists of one or more tablespaces or parts thereof. You can have multiple Flashback Data Archives. If you are logged on as SYSDBA, you can specify a default Flashback Data Archive for the system. A Flashback Data Archive is configured with retention time. Data archived in the Flashback Data Archive is retained for the retention time.

By default the Flashback Data Archive is disabled . You can enable it by accepting the below conditions,

You have the FLASHBACK ARCHIVE object privilege on the Flashback Data Archive to use for that table.

The table is neither nested, clustered, temporary, remote, or external. The table contains neither LONG nor nested columns. The table does not use any of these Flashback Data Archive reserved words as column names:

startscn, endscn, rid, xid,  op, operation.

Create a Flashback Data Archive named fla1 that uses tablespace tbs2, whose data will be retained for two years:

SQL>Create flashback archive fla1 TABLESPACE tbs2 RETENTION 2 YEAR;

You can enable default flash back archive by connecting as sysdba,

Specify the name of an existing Flashback Data Archive in the SET DEFAULT clause of the ALTER FLASHBACK ARCHIVE statement. For example:

SQL>Alter flashback archive fla1 SET DEFAULT;

If fla1 does not exist, Include DEFAULT in the CREATE FLASHBACK ARCHIVE statement when you create a Flashback Data Archive. For example:

SQL>Create flashback archive DEFAULT fla2 TABLESPACE tbs1 QUOTA 2G RETENTION 1 YEAR;

The default Flashback Data Archive for the system is the default Flashback Data Archive for every user who does not have his or her own default Flashback Data Archive.

Create table employee and store the historical data in the Flashback Data Archive fla1:

SQL>Create table employee (EMPNO NUMBER(4), ENAME VARCHAR2(10), JOB VARCHAR2(9)) FLASHBACK ARCHIVE fla1;

Enable flashback archiving for the table employee and store the historical data in the default Flashback Data Archive:

SQL>Alter table employee FLASHBACK ARCHIVE;

Enable flashback archiving for the table employee and store the historical data in the Flashback Data Archive fla1:

 SQL>Alter table employee FLASHBACK ARCHIVE fla1;

Disable flashback archiving for the table employee:

SQL>Alter table employee NO FLASHBACK ARCHIVE;

Using Flashback Data Archive to Enforce Digital Shredding:

Your company wants to “shred” (delete) historical data changes to the Taxes table after ten years. When you create the Flashback Data Archive for Taxes, you specify a retention time of ten years:

SQL>Create flashback archive taxes_archive TABLESPACE tbs1 RETENTION 10 YEAR;

 

Using Flashback Data Archive to Access Historical Data:

Create a default Flashback Data Archive named fla1 that uses up to 10 G of tablespace tbs1, whose data are retained for five years:

 SQL>Create flashback archive DEFAULT fla1 TABLESPACE tbs1 QUOTA 10G RETENTION 5 YEAR;

Enable Flashback Data Archive for the tables, and store the historical data in the default Flashback Data Archive.

Using Flashback Data Archive to Generate Reports:

You want users to be able to generate reports from the table investments, for data stored   in the past five years. uses this query:

 SQL>Select * FROM investments AS OF TIMESTAMP TO_TIMESTAMP (‘2015-10-26 16:00:00’, ‘YYYY-MM-DD HH24:MI:SS’)  WHERE name = ‘XYZ’;

Using Flashback Data Archive to Recover Data:

An end user recovers from erroneous transactions that were previously committed in the   database. The undo data for the erroneous transactions is no longer available, but because     the required historical information is available in the Flashback Data Archive, Flashback   Query works seamlessly.

SQL>Delete employee WHERE MANAGER = ‘ ABC’;

 SQL>Insert into employee  Select *  from EMPLOYEE AS OF TIMESTAMP (SYSTIMESTAMP – INTERVAL ‘2’ DAY)  WHERE MANAGER =’ABC’;

0

 

0