Ensuring Data Protection Using Oracle Flashback Features

COLLABORATE 16 – IOUG Forum

Database Track

1 | P a g e “Ensur ing Dat a Prot ect ion Us ing Orac l e F l a shback Feature s ”

Wh i t e Paper

Ensuring Data Protection Using Oracle Flashback Features

Pini Dibask, Dell

ABSTRACT Ensuring Data Protection for Oracle Databases is one of the most important tasks every Oracle DBA is faced with. Without protecting the data, the DBA will never be able to ensure high level of SLA (Service Level Agreement) to the business. Data

Protection is a wide term that refers to the protection from many different potential issues in Oracle Databases such as:

Data Corruptions – Block corruption could be either physical or logical:

o Physical Corruption (also called media corruption) - When the block has an invalid checksum, therefore it cannot even be recognized as an Oracle block.

o Logical Corruption - When the block checksum is valid but its content is logically inconsistent; for example, when there is a missing index entry or a row piece.

Disaster Recovery – Ranges from large-scale natural disasters such as floods, earthquakes, and fires, to small/medium disasters like power outages and viruses.

Human Errors - A user operation that causes data to become unavailable (e.g. dropping/truncating a table, deleting rows) or logically wrong; for example, by modifying the contents of existing rows to wrong values.

This session paper will illustrate how to protect data from various human errors with minimum time and effort by using Oracle Flashback features.

TARGET AUDIENCE Oracle Database administrators and developers

EXECUTIVE SUMMARY Learners will be able to:

Understand how Oracle flashback technology empowers the Oracle DBA.

Design Oracle environments to have maximum protection using the Oracle flashback features.

BACKGROUND Every DBA should have a clear and tested recovery strategy in order to enforce the organization's Data Protection policy, which is usually defined by 2 important objectives, RPO and RTO:

RPO (Recovery Point Objective) - The maximum amount of data that a business can allow itself to lose; for example, if the RPO of a company is 5 hours, then the DBA must restore and recover the database to a point in time in the last 5 hours. In some companies, the RPO is 0, i.e. the business can’t afford any data loss.

RTO (Recovery Time Objective) - The maximum amount of downtime that a business can incur until the system is up and available again for the users. For example, if a database was crashed due to a physical corruption of a data file that belongs to SYSTEM tablespace, then assuming the RTO is 1 hour, the DBA must restore and recover the data file to ensure the database will be up and running within 1 hour since the crash occurred.


Database Track


Wh i t e Paper

Figure 1: the RPO and RTO data protection objectives

Oracle provides a set of tools and features that can be used by the DBA for protecting Oracle Databases from various scenarios:

Data Corruptions - The most common way for detecting and recovering data corruptions is by using RMAN and user-managed backup/recovery methods.

Disaster Recovery - There are various ways for ensuring server protection, e.g. RAC, RAC One Node and Failover Clusters. For ensuring storage-level protection Oracle provides ASM 2-way or 3-way mirroring, and for ensuring site protection Oracle provides replication solutions such as Oracle Data Guard and Oracle Golden Gate.

Human Errors - There are various ways to handle human errors including using backups (either RMAN or user-managed backups); however, by using flashback features the DBA can recover from human errors in a much faster and simpler way.

Figure 2: Oracle High Availability and Disaster Recovery Solutions

This article will be focused on the last item - how to recover from various human errors scenarios, with the minimum RTO using Oracle Flashback features.


Database Track


Wh i t e Paper

TECHNICAL DISCUSSIONS AND EXAMPLES

The Beginning - Oracle Flashback Query (Version 9i)

The first Oracle flashback feature named "Flashback Query" was introduced in Oracle 9i. This feature allows querying a table's data as of a specific point in the past by providing either a TIMESTAMP or an SCN. Let's see a demonstration of this feature. In the below first step, we will create a sample table named “EMP” with a single row:

SQL> CREATE TABLE EMP (ID NUMBER, NAME VARCHAR2(20));

Table created.

SQL> insert into EMP values (1, 'DAVID');

1 row created.

SQL> select * from EMP;

ID NAME

---------- --------------------

1 DAVID

SQL> commit;

Commit complete.

Now, we will determine the current SCN and time:

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

476372816

SQL> select to_char(systimestamp, 'YYYY-MM-DD HH24:MI:SS') CURRENT_TIME from dual;

CURRENT_TIME

-------------------

2016-01-04 14:37:12

In the final step, we will update the row, and by using Flashback Query we will be able to view the contents of the table prior to the data modifications:

SQL> update emp set name = 'ROBERT';

1 row updated.


ID NAME

---------- --------------------

1 ROBERT

SQL> commit;

Commit complete.


Database Track


Wh i t e Paper

SQL> select * from EMP as of scn 476372816;

ID NAME

---------- --------------------

1 DAVID

SQL> select * from EMP as of TIMESTAMP

TO_TIMESTAMP('2016-01-04 14:37:12', 'YYYY-MM-DD HH24:MI:SS');

ID NAME

---------- --------------------

1 DAVID

This feature can be very useful for investigating the contents of the table in a specific point in time in the past. It can also be used to restore the value of a row, a set of rows, or even the entire table. In the following example, an update sets the name of EMPLOYEE with ID #1 to be as of a specific time point in the past:

SQL> update EMP set name =

(select name

from EMP

as of TIMESTAMP TO_TIMESTAMP('2016-01-04 14:37:12', 'YYYY-MM-DD HH24:MI:SS') WHERE ID=1)

WHERE ID=1;

1 row updated.


ID NAME

---------- --------------------

1 DAVID

It is also possible to specify a relative time by substracting the current timestamp using the INTERVAL clause, as follows:

select * from emp

as of TIMESTAMP (SYSTIMESTAMP - INTERVAL '60' MINUTE);

In the following example, an INSERT AS SELECT command is using flashback query in order to insert all the rows that existed in “emp” table 2 hours ago:

INSERT INTO emp

(SELECT *

FROM emp AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '2' HOUR));

Note: It is possible to convert between SCN to TIMESTAMP using the SCN_TO_TIMESTAMP function


Database Track


Wh i t e Paper

How does the Flashback Query feature work? The Flashback Query feature uses the contents of the undo tablespace. The undo tablespace is a key component in Oracle Databases. It consists of undo segments which hold the "before" images of the data that has been changed by users running transactions. The undo is essential for rollback operations, data concurrency and read consistency. In order to use Flashback Query, the instance must have an automatic undo management by setting the UNDO_MANAGEMENT initialization parameter to be TRUE (default since version 11gR1). It is also important to set a proper value for the UNDO_DETENTION parameter. The UNDO_RETENTION specifies the low threshold (in seconds) for the undo retention period (defaults to 900, i.e. 15 minutes). It is important to bear in mind the different behaviors of this parameter in a fixed-size undo tablespace vs. autoextend undo tablespace.

Fixed-Size Undo Tablespace

For fixed-size undo tablespaces, the UNDO_RETENTION parameter is being ignored and Oracle automatically tunes for the maximum possible undo retention period based on the undo tablespace size and undo usage history.

Autoextend Undo Tablespace

For auto extend undo tablespace, the UNDO_RETENTION parameter specifies the minimum retention period Oracle will attempt to honor. When space in the undo tablespace becomes low (due to running transactions which generate undo records) Oracle will increase the tablespace size (up to the MAXSIZE limit). Once it will reach the upper limit of the MAXSIZE, it will begin to overwrite unexpired undo information; therefore, the retention period defined in the UNDO_RETENTION period is not guaranteed. This is why the actual undo retention period might be lower or even higher than the one defined in the UNDO_RETENTION parameter. The actual undo retention period can be obtained by querying the TUNED_UNDORETENTION column in V$UNDOSTAT dynamic performance view. Note: It is possible to specify the RETENTION GUARANTEE clause in the CREATE UNDO TABLESPACE or ALTER TABLESPACE commands, and then Oracle will never overwrite unexpired undo data even if it means that transactions will fail due to lack of space in the undo tablespace.

Oracle 10g Flashback features

Version 10g introduced some great flashback-related enhancements and new features. We can categorize these features into two main categories, Flashback query enhancements and additional flashback features.

Figure 3: Oracle 10g Flashback Features


Database Track


Wh i t e Paper

Oracle Flashback Query enhancements

This category contains all of the Oracle 10g flashback query enhancements including the following: Flashback Version Query, Flashback Transaction Query, and Flashback Table. The reason these features are categorized as enhancements to the 9i Flashback query feature is because they all rely on the undo records in the Undo Tablespace, where the “Additional Flashback Features” are flashback capabilities that do not rely on the undo tablespace, but rather on other Oracle Database components and features.

Flashback Version Query

The Flashback Version Query allows viewing the historical versions of a specific row or set of rows. Let us continue with the previous example of table EMP. In the previous example, there was an update of employee with ID #1 to be named ROBERT instead of DAVID, and then using by the flashback query, it was updated to be DAVID (as it was originally).

By using Flashback Version Query, we can see the history of the row modifications:

SQL> SELECT versions_starttime, versions_endtime,

versions_xid, versions_operation, name

FROM EMP

VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('2016-01-10 18:02:28', 'YYYY-MM-DD HH24:MI:SS') AND

TO_TIMESTAMP('2016-01-10 18:03:00', 'YYYY-MM-DD HH24:MI:SS')

WHERE id = 1

ORDER BY VERSIONS_STARTTIME; VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V NAME ---------------------- ---------------------- ---------------- - -------------------- 10-JAN-16 06.02.47 PM 10-JAN-16 06.04.08 PM 060016000A2A0100 U ROBERT 10-JAN-16 06.04.08 PM 01000200EBFA0000 U DAVID

The VERSIONS_XID column represents the ID of the transaction that is associated with the row. The transaction ID is useful for retrieving the undo SQL statement for the transaction using the Flashback Transaction Query (more details to follow in the next section). The VERSIONS_OPERATION column value is ‘U’ which indicates that an update has occurred. Other possible values are ‘I’ (which indicates an INSERT) and ‘D’ (which indicates a DELETE). The “VERSIONS BETWEEN” clause allows the DBA to specify SCN MINVALUE AND MAXVALUE, which takes all of the undo information that is available in the undo tablespace as follows: SQL> SELECT versions_starttime, versions_endtime,


FROM EMP

VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE WHERE id = 1

ORDER BY VERSIONS_STARTTIME;

VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V NAME ---------------------- ---------------------- ---------------- - -------------------- 10-JAN-16 06.02.47 PM 10-JAN-16 06.04.08 PM 060016000A2A0100 U ROBERT 10-JAN-16 06.04.08 PM 01000200EBFA0000 U DAVID

Let us see an example of the output of the query after an insertion and deletion of a row.


Database Track


Wh i t e Paper

SQL> insert into EMP values (2, 'STEVE');

1 row created.

SQL> commit;

Commit complete.

SQL> delete EMP where id=2;

1 row deleted.

SQL> commit;

Commit complete.



FROM EMP

VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE

ORDER BY VERSIONS_STARTTIME;

VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V NAME ---------------------- ---------------------- ---------------- - -------------------- 10-JAN-16 06.02.47 PM 10-JAN-16 06.04.08 PM 060016000A2A0100 U ROBERT 10-JAN-16 06.04.08 PM 01000200EBFA0000 U DAVID 10-JAN-16 06.27.55 PM 10-JAN-16 06.28.01 PM 08000E007A330100 I STEVE 10-JAN-16 06.28.01 PM 0A0000009C120100 D STEVE

Flashback Transaction Query

The flashback transaction query feature allows the DBA to view the transaction information including the start and the end of the transaction as well as the undo SQL statements for rolling back the transaction. In order to use this feature Oracle introduced a new dictionary view in version 10g named FLASHBACK_TRANSACTION_QUERY which requires having the SELECT ANY TRANSACTION system privilege. In the example above, we found out that transaction ID 0A0000009C120100 has deleted the row of employee named “STEVE” by using the flashback version query. The flashback transaction query can assist in rolling back the transaction by using the UNDO_SQL column, as follows:

SQL> SELECT xid, start_scn, commit_scn,

operation OP, undo_sql FROM flashback_transaction_query

WHERE xid = HEXTORAW('0A0000009C120100');

XID START_SCN COMMIT_SCN UNDO_SQL ---------------------------- ----------------- ------------------ ----------------------------------------------------------- 090017001B380100 483051290 483051291 insert into "PINI"."EMP"("ID","NAME") values ('2','STEVE');

Note that in order to have the UNDO_SQL column populated with data, a minimal database supplemental logging must be enabled, which will add additional information to the redo logs. Verify whether minimal database supplemental logging is enabled or not by querying SUPPLEMENTAL_LOG_DATA_MIN from V$DATABASE. If minimal database supplemental logging is disabled (the output of the query is “NO”), you can enable it by executing the following command:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;


Database Track


Wh i t e Paper

Flashback Table

The flashback table feature allows restoring the entire table’s data into an historical point in time in a very simple and straight-forward way- by specifying either SCN or TIMESTAMP. This feature is the best way for the DBA to recover the entire table’s data from human errors or undesired application changes (e.g. inserts, updates, deletes). In order to use this feature, make sure to be aligned with following prerequisites: Have either FLASHBACK object privilege on the table or FLASHBACK ANY TABLE system privilege. In addition, have the following privileges on the table: ALTER, SELECT, INSERT, UPDATE, and DELETE.

Enable row movement for the table using ALTER TABLE … ENABLE ROW MOVEMENT. The reason for this requirement is because rows will be moved (inserted, updated, and deleted) during the FLASHBACK TABLE, which is the reason that the user must be granted with the INSERT, UPDATE, DELETE privileges on the table.

Following is a demonstration of this feature:

SQL> CREATE TABLE EMP (ID NUMBER, NAME VARCHAR2(20));

Table created.

SQL> insert into EMP values (1, 'DAVID');

1 row created.

SQL> insert into EMP values (2, 'ROBERT');

1 row created.

SQL> insert into EMP values (3, 'DANIEL');

1 row created

SQL> commit;

Commit complete.

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

483077247

SQL> delete EMP;

3 rows deleted.

SQL> commit;

Commit complete.


no rows selected

SQL> flashback table EMP to scn 483077247;

flashback table emp to scn 483077247

*

ERROR at line 1:

ORA-08189: cannot flashback the table because row movement is not enabled


Database Track


Wh i t e Paper

The ORA-08189 is expected because as previously mentioned, one of the prerequisites for using this feature is to enable row movement, and then it would be possible to execute the flashback table command, as follows:

SQL> alter table EMP enable row movement;

Table altered.

SQL> flashback table EMP to scn 483077247;

Flashback complete.


ID NAME

---------- --------------------

1 DAVID

2 ROBERT

3 DANIEL

Note that this feature is using the information in the undo tablespace in order to recover the table so it can only be used to recover the data and not the structure of the table. If there was a change in the structure of the table, for example, by adding a column, Oracle will not be able to recover the table prior to the execution of DDL command. Also, if a table has been dropped, Oracle won’t be able to recover it using this feature.

Additional Flashback Features

So far we have reviewed the Flashback features that rely on the contents of the undo tablespace. In this section we will explore the other 10g Flashback features: Flashback Drop and Flashback Database. These features do not rely on the contents of the undo tablespace.

Flashback Drop

Starting with Oracle version 10g, Oracle introduced a new parameter named “RECYCLEBIN” (defaults to “ON”):

SQL> show parameter RECYCLEBIN

NAME TYPE VALUE

------------------------------------ ----------- --------

recyclebin string on

Assuming that RECYCLEBIN parameter is set to ON, then once the object is dropped, it will remain in the tablespace and Oracle will keep the information about the dropped table and its associated objects in a dictionary view named USER_RECYCLEBIN (it has a synonym named RECYCLEBIN), which shows per each schema its objects in the recycle bin, as follows:

SQL> SELECT object_name, original_name, droptime FROM RECYCLEBIN;

OBJECT_NAME ORIGINAL_NANE TYPE DROPTIME

------------------------------ ------------- ----- --------------

BIN$ZW5M6bSsRKe6PiqynWR9Xw==$0 EMP TABLE 2016-01-21:17:24:26

BIN$tWgtlRlzTZ2lCoZd0Ex7Rg==$0 ID_PK INDEX 2016-01-21:17:24:25


Database Track


Wh i t e Paper

Note: that it is possible to query the recycle bin of the entire instance using DBA_RECYCLEBIN, and CDB_RECYCLEBIN in version 12c to query the recycle bin of all the schemas across all the containers. As seen in the demonstration above, the names of the table and its associated objects in the RECYCLEBIN have a system-generated name (starts with BIN$). It is possible to query directly the recyecle bin system-generated names:

SQL> select * from "BIN$ZW5M6bSsRKe6PiqynWR9Xw==$0";

ID NAME

---------- --------------------

1 DAVID

2 ROBERT

However, it is not possible to exectute DML or DDL commands against the tables in the recycle bin.

Once the table is being restored from the recycle bin, it will be restored with its original name, but the associated objects will be restored with system-generated names so it’s possible to rename these objects later as an optional step.

Following is an example that demonstrates how simple it is to restore a dropped table using this feature:

SQL> FLASHBACK TABLE EMP TO BEFORE DROP;

Flashback complete.


ID NAME

---------- --------------------

1 DAVID

2 ROBERT

It is also possible that the object will be restored with a different name (for example, when other object with the same name already exists), using a very simple syntax, as follows: SQL> FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_OLD;

Flashback complete.

Note that it is not guaranteed to have the dropped objects in the recycle bin. In the following scenarios the objects will not be available in the recycle bin:

Execution of a DROP TABLE command with the PURGE clause

Manual execution of PURGE RECYCLEBIN or PURGE DBA_RECYCLEBIN commands

Drop of the entire tablespace will not leave its objects in the recycle Bin

When dropping a user, all its objects are not placed in the recycle Bin

Space-pressure in the tablespace on which the objects reside Another thing to keep in mind is that Oracle restores the objects from the recycle bin in a LIFO (Last In First Out) order, so if there are several objects with the same name in the recycle bin and the DBA restores that object using the Flashback Drop feature, then the that last one that was dropped will be restored.


Database Track


Wh i t e Paper

Flashback Database

The Flashback Database feature is the most simple and straight forward way to rewind the entire database to a historical point in time. The reason it’s so fast and straight-forward is because it doesn’t require restoring database backups using either RMAN or user-managed backup. However, its biggest disadvantage is that it can only recover “logical failures”, i.e. unnecessary data modifications due to human errors. It cannot be used to recover from block corruptions or a loss of a file (e.g. Data Files, Control File). In order to undo changes in the database this feature is using flashback logs. Flashback logs are being generated once the Flashback Database is enabled. The flashback logs contain before-images of data blocks prior to their change. The Flashback Database operates at a physical level and revert the current data files to their contents at a past time using the flashback logs. The prerequisites for enabling this feature are:

The database must be running in ARCHIVELOG mode.

Enable the FRA (Flash Recovery Area).

The FRA is a storage location that contains recovery-related files such as archived logs, RMAN backups, and of course, flashback logs. Once configured, the FRA will simplify the DBA’s daily tasks by retaining the recovery-related files as long as they needed, and delete them once they are no longer needed (based on the retention policies that are defined by the DBA). Once the FRA prerequisites have been configured properly, it is possible to enable the Flashback Database feature by executing the following command:

SQL> ALTER DATABASE FLASHBACK ON;

Prior to 11gR2, in order to execute this command, the database had to be restarted to a mounted state and only then it was possible to execute the above command. Starting from 11gR2 it is possible to enable the Flashback Database with no downtime by executing this command when the instance is in OPEN status. It is possible to set the DB_FLASHBACK_RETENTION_TARGET parameter which specifies the upper limit (in minutes) on how far back in time the database may be flashed back. Its default value is 1440 minutes (=one day) of retention for the flashback logs. The reason that it is only an upper limit and not a guaranteed retention period is because if the FRA is full (reached the maximum FRA size limit defined by the DB_RECOVERY_FILE_DEST_SIZE parameter) or if is not enough disk space, then Oracle will reuse the oldest flashback logs which might be within the retention period. It is possible to monitor the oldest possible flashback time via the V$FLASHBACK_DATABASE_LOG dictionary view. In the following demonstration, the FRA is set with a 100GB size limit and flashback retention target of 1 week (=10080 minutes):

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=100g;

System altered.

SQL> alter system set db_recovery_file_dest='/oravl01/oracle/FRA';

System altered.

SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=10080;

System altered.

SQL> ALTER DATABASE FLASHBACK ON;

Database altered.

In order to rewind the database, restart the database in a MOUNT mode, and then execute the FLASHBACK DATABASE command. It is possible to rewind the database to an exact SCN or Time. It is also possible to rewind the database prior to the SCN or the Time. Another simple way is to create restore point which is a name that represents a specific point in time, and then the flashback will restore the database to the time that the restore point has been created.


Database Track


Wh i t e Paper

In the following example, a sample table is created, populated with few records and truncated right after a restore point name “before_truncate” has been created. In this demo, a Flashback Database is used to rewind the enitre database prior to the truncate command that was executed using the “before_truncate” restore point.

SQL> create table test_flashback (id number, name varchar2(20));

Table created.

SQL> insert into test_flashback values (1, 'DAVID');

1 row created.

SQL> insert into test_flashback values (2, 'JOHN');

1 row created.

SQL> commit;

Commit complete.

SQL> create restore point before_truncate;

Restore point created.

SQL> truncate table test_flashback;

Table truncated.

SQL> select name,scn,time from V$RESTORE_POINT;

NAME SCN TIME

--------------- ---------- -------------------------------

BEFORE_TRUNCATE 119193304 24-JAN-16 09.14.06.000000000 PM

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 809500672 bytes

Fixed Size 2929600 bytes

Variable Size 318770240 bytes

Database Buffers 482344960 bytes

Redo Buffers 5455872 bytes

Database mounted.

SQL> FLASHBACK DATABASE TO RESTORE POINT before_truncate;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

SQL> select * from test_flashback;

ID NAME

---------- ---------------

1 DAVID

2 JOHN


Database Track


Wh i t e Paper

Oracle 11gR1 Flashback features

Oracle version 11gR1 introduced 2 main features in the flashback area: Flashback Transaction and Flashback Data Archive.

Flashback Transaction

In the “Flashback Version Query” section we have demonstrated how to view historical changes of records in a table and also how find the associated Transaction ID (XID) per each version of record in the table. In the “Flashback Transaction Query” we have demonstrated how we can also view the undo statement for the selected transaction. Starting from Oracle 11g, using the Flashback Transaction feature, we can even take these 2 features one step further by rolling-back the changes made by a transaction and its dependent transactions (optionally). In the following example, a sample table is created. Afterwards, the first transaction will insert a single record, and then a second transaction updates the record. In the last step of this demo we will perform a rollback for the first transaction: SQL> CREATE TABLE DEPARTMENTS

(

DEPT_ID NUMBER,

Name VARCHAR2 (20),

CONSTRAINT id_pk PRIMARY KEY (DEPT_ID)

);

Table created.

SQL> insert into DEPARTMENTS values (1, 'SALES');

1 row created.

SQL> commit;

Commit complete.

SQL> update DEPARTMENTS set name = 'HR' where dept_id = 1;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from DEPARTMENTS;

DEPT_ID NAME

---------- --------------------

1 HR


versions_xid, versions_operation, dept_id, name

FROM DEPARTMENTS

VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE;

VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V DEPT_ID NAME

------------------------- ------------------------- ---------------- - ---------- ------

28-JAN-16 06.18.10 PM 28-JAN-16 06.19.01 PM 000A001A0000BF39 I 1 SALES

28-JAN-16 06.19.01 PM 000800110000648B U 1 HR

SQL> EXECUTE DBMS_FLASHBACK.transaction_backout(numtxns=>1, xids=>xid_array('000A001A0000BF39'));

ERROR at line 1:

ORA-55504: Transaction conflicts in NOCASCADE mode

ORA-06512: at "SYS.DBMS_FLASHBACK", line 37

ORA-06512: at "SYS.DBMS_FLASHBACK", line 70

ORA-06512: at line 2


Database Track


Wh i t e Paper

The reason that the “ORA-55504: Transaction conflicts in NOCASCADE mode” error has been raised is because the DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure has a parameter named “options” which defaults to NOCASCADE, meaning that if a dependent transaction has been found, Oracle will raise an error. In our demonstration the 2nd transaction that updated the row depends on the 1st transaction (that inserted the row), therefore Oracle raised the error. We can tell Oracle to rollback the dependent transactions using the CASCADE value for the “options” parameter, as follows:

SQL> BEGIN

DBMS_FLASHBACK.transaction_backout (numtxns=> 1,

xids => xid_array('000A001A0000BF39'),

options => DBMS_FLASHBACK.cascade);

END;

PL/SQL procedure successfully completed.

SQL> select * from DEPARTMENTS;

no rows selected

Note that supplemental logging for primary key columns must be enabled in order to use Flashback Transaction:

Flashback Data Archive As mentioned, most of the Flashback Features (including: Flashback Version Query, Flashback Transaction Query, and Flashback Table and Flashback Transaction) rely on the undo information that reside in the Undo Tablespace. If the information is not available in the Undo Tablespace, the flashback operation will fail. Whether the information is available or not depends on several factors including:

Size of the undo tablespace

UNDO_RETENTION parameter

Auto extend property

Flashback Guarantee property

In order to allow more extended and even unlimited historical undo information for flashback purposes, Oracle introduced in version 11gR1 a new feature named Flashback Data Archive (also known as Total Recall). Flashback Data Archive is a repository for storing undo records and it is transparent to the application, i.e. once configured, the usage of the Oracle Flashback features remains the same in terms of syntax. In order to configure this feature, an object named Flashback Archive must be created. Flashback Archive has the following properties:

Tablespace – Where the information will be stored

Quota on the tablespace

Retention – The amount of time that information will be kept in that tablespace Oracle introduced a new process named “fbda” that takes care of all the Flashback Data Archive related tasks such as writing the information into the Flashback Archive and purging it once the information is older than the retention period.

In the following example a new default Flashback Archive object named “my_fda” with 25GB quota on a tablespace named “my_fda_ts” and a retention period of 5 years is created:

SQL> CREATE TABLESPACE my_fda_ts DATAFILE SIZE 100M AUTOEXTEND ON NEXT 10M;

TABLESPACE created.

SQL> CREATE FLASHBACK ARCHIVE DEFAULT my_fda TABLESPACE my_fda_ts QUOTA 25G RETENTION 5 YEAR;

FLASHBACK archive created.


Database Track


Wh i t e Paper

When enabling Flashback Archive for a table, unless explicitly specifying the Flashback Archive name, the default Flashback Archive will be used (in our case, “my_fda”. There can be only 1 default Flashback Archive. Let’s create an additional non-default Flashback Archive with a 5GB quota and a retention period of 1 year:

SQL> CREATE FLASHBACK ARCHIVE one_year_fda TABLESPACE my_fda_ts QUOTA 5G RETENTION 1 YEAR;

Flashback archive created.

The retention information for the Flashback Archives is available in the DBA_FLASHBACK_ARCHIVE dictionary view:

SQL> SELECT flashback_archive_name, retention_in_days, status FROM DBA_FLASHBACK_ARCHIVE;

FLASHBACK_ARCHIVE_NAME RETENTION_IN_DAYS STATUS

------------------------ ----------------- -------

MY_FDA 1825 DEFAULT

ONE_YEAR_FDA 365

The information about the quota per each Flashback Archive and the associated tablespace is available in the DBA_FLASHBACK_ARCHIVE_TS dictionary view:

SQL> SELECT flashback_archive_name, tablespace_name, quota_in_mb/1024 QUOTA_GB FROM

DBA_FLASHBACK_ARCHIVE_TS;

FLASHBACK_ARCHIVE_NAME TABLESPACE_NAME QUOTA_GB

------------------------- ------------------------------ ----------

MY_FDA MY_FDA_TS 25

ONE_YEAR_FDA MY_FDA_TS 5

Once the Flashback Archive has been configured, user can easily enable and disable this feature for the desired tables, as follows:

SQL> alter table departments flashback archive;

Table altered.

SQL> alter table departments no flashback archive;

Table altered.

To enable FDA for a table using a non-default Flashback Archive, the Flashback Archive must be explicitly set, as follows:

SQL> alter table departments flashback archive ONE_YEAR_FDA;

Table altered.

The DBA_FLASHBACK_ARCHIVE_TABLES dictionary view displays all the tables with FDA confiured:

SQL> SELECT table_name,owner_name,flashback_archive_name FROM DBA_FLASHBACK_ARCHIVE_TABLES;

TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME

----------- ----------- -------------------------

DEPARTMENTS SALES ONE_YEAR_FDA


Database Track


Wh i t e Paper

Oracle 11gR2 Flashback enhancements

In Oracle 11gR2 the following enhancements were introduced:

Flashback Database – Enable the Flashback Database when that instance is open. Prior to 11gR2 the DBA must restart the database to a MOUNTED state and only then enable the Flashback Database feature

Flashback Data Archive – Prior to Oracle 11gR2, several DDL commands on a table with Flashback Archive enabled will raise an error: “ERROR at line 1 ORA-55610: Invalid DDL statement on history-tracked table”. This includes the following DDL operations:

o TRUNCATE TABLE o ALTER TABLE [ADD| DROP| RENAME| MODIFY] Column o DROP|TRUNCATE Partition o ALTER TABLE RENAME o ALTER TABLE [ADD| DROP| RENAME| MODIFY] Constraint

Staring with Oracle 11gR2 these operations are now supported on tables with Flashback Archive enabled.

Oracle 12cR1 Flashback enhancements

12.1.0.1 New Features:

In Oracle version 12.1.0.1, new enhancements were introduced to the Flashback Data Archive feature including:

The user context information for the transactions is now tracked as well. This allows us understanding not only what the changes were but also understand who is responsible for those changes.

Support for tables that use the Hybrid Columnar Compression (HCC) feature.

Support for exporting and importing the Flashback Data Archive tables.

12.1.0.2 New Features:

In version 12.1.0.1, the Flashback Data Archive feature was supported only for Non-CDB environments. Starting from version 12.1.0.2 the Flashback Data Archive feature is supported for a Container Database (also known as the Multitenant Architecture) in addition to Non-CDB option.


Database Track


Wh i t e Paper

Additional notes regarding licensing

Most of the powerful Flashback features require having a license for the Enterprise Edition. This includes the following features:

Flashback Table

Flashback Drop

Flashback Transaction Query

Flashback Transaction

Flashback Database

Flashback Query and Flashback Version Query are available for all Oracle Editions. As for Flashback Data Archive, starting from 11.2.0.4, it is supported for all the Oracle Editions, but for versions earlier than 11.2.0.4, it requires having a license for the Enterprise Edition + Oracle Advanced Compression option (extra cost option).

Figure 4: Oracle Flashback Features Licensing


Database Track


Wh i t e Paper

SUMMARY

Oracle Flashback technology provides set of tools that can be used by the DBA in order to recover from various human errors that caused undesired data loss or data modifications. The following table summarizes this article by explaining which Oracle Flashback feature is most suitable per each scenario:

Figure 5: Various Use Cases for using Oracle Flashback Features

The great thing about Oracle Flashback technology is that it allows recovering from various human errors with minimum effort and time, which results in a reduced RTO (Recovery Time Objective), having said that, Oracle Flashback technology should never be used as a replacement of the traditional backups, but rather as a complementary solution that provides a very effective way to recover from various human errors and doesn’t require restoring and recovering using backup (either RMAN or user-managed backups). For example, Oracle Flashback technology will not protect against the following scenarios:

Loss of data file or control file

Block corruptions (either physical or logical)

Site disaster

The article reviewed the Oracle Flashback technology from Oracle version 9i – where the first flashback feature named “Flashback Query” was introduced, up to the most recent Oracle Database version (12.1.0.2). Oracle Flashback technology can definitely empowers the DBA’s by making his life easier when it comes to protecting the data from various human errors.


Database Track


Wh i t e Paper

REFERENCES – ORACLE DOCUMENTATION

Using Oracle Flashback Technology https://docs.oracle.com/database/121/ADFNS/adfns_flashback.htm#ADFNS1008

Managing Undo Tablespaces

https://docs.oracle.com/database/121/ADMIN/undo.htm#ADMIN013

Configuring the Fast Recovery Area https://docs.oracle.com/database/121/BRADV/rcmconfb.htm#BRADV89418

Using Flashback Database and Restore Points https://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV71000

DBMS_FLASHBACK Package Reference https://docs.oracle.com/database/121/ARPLS/d_flashb.htm#ARPLS142

CREATE FLASHBACK ARCHIVE statement https://docs.oracle.com/database/121/SQLRF/statements_5011.htm#SQLRF20008

ALTER FLASHBACK ARCHIVE statement https://docs.oracle.com/database/121/SQLRF/statements_1010.htm#SQLRF20009

FLASHBACK DATABASE statement https://docs.oracle.com/database/121/RCMRF/rcmsynta023.htm#RCMRF194

https://docs.oracle.com/database/121/ADFNS/adfns_flashback.htm#ADFNS1008

https://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV71000

https://docs.oracle.com/database/121/ARPLS/d_flashb.htm#ARPLS142

https://docs.oracle.com/database/121/SQLRF/statements_5011.htm#SQLRF20008

https://docs.oracle.com/database/121/SQLRF/statements_1010.htm#SQLRF20009