Ensuring Data Protection Using Oracle Flashback Features - Presentation

Editor's Notes

• #7: Ensuring Data Protection is one of the most important tasks every Oracle DBA is faced with. Data Protection is a wide term that refers to the protection from many different potential issues in Oracle Databases such as: Disaster Recovery – Ranges from large-scale natural disasters such as floods, earthquakes, and fires, to small/medium disasters like power outages and viruses. Data Corruptions – Block corruption could be either physical or logical: Physical Corruption (also called media corruption) - When the block has an invalid checksum, therefore it cannot even be recognized as an Oracle block. Logical Corruption - When the block checksum is valid but its content is logically inconsistent; for example, when there is a missing index entry or missing row piece. 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.
• #8: 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.
• #9: 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.
• #11: 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.
• #12: 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
• #13: Now, we will determine the current SCN and time. Click… In the final step, we will update the row.
• #14: By using Flashback Query we will be able to view the contents of the table prior to the data modifications. Note: It is possible to convert between SCN to TIMESTAMP using the SCN_TO_TIMESTAMP function
• #15: 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 It is also possible to specify a relative time by subtracting the current timestamp using the INTERVAL clause.
• #17: Undo tablespace 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.   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.  Autoextend Undo Tablespace For auto extend undo tablespace, the UNDO_RETENTION parameter specifies the minimum retention period Oracle will attempt to honor. 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.   
• #18: Active undo extents are used by running transactions. These extents will never be overwritten as they are needed in order to perform ROLLBACK operations.  Expired Undo Extents hold committed information that is older than the UNDO_RETENTION period. Unexpired undo Extents hold committed information that its age is less than the UNDO_RETENTION period. 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. 
• #19: 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).
• #20: Version 10g introduced some great flashback-related enhancements and new features
• #21: 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). Click By using Flashback Version Query, we can see the history of the row modifications. Click 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).  
• #22: 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 Click
• #23: Let us see an example of the output of the query after an insertion and deletion of a row.
• #24: 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: Click 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:
• #25: 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: Click 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.  
• #26: The following is a demonstration of this feature
• #27: 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: Click 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 would not be able to recover the table prior to the execution of DDL command. Also, if a table has been dropped, Oracle would not be able to recover it using this feature.
• #29: Starting with Oracle version 10g, Oracle introduced a new parameter named “RECYCLEBIN” (defaults to “ON”): Click 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 Note: It is possible to query the recycle bin of the entire instance using DBA_RECYCLEBIN, and CDB_RECYCLEBIN in 12c
• #30: 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 recycle bin system-generated names, however, it is not possible to execute DML or DDL commands against the tables in the recycle bin. Click Table will be restored with its original name, but the associated objects will be restored with system-generated names so it is possible to rename these objects later as an optional step.
• #31: The associated objects will be restored with system-generated names so it is possible to rename these objects later as an optional step. 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 last one that was dropped will be restored.
• #32: 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
• #33: The most simple and straightforward way to rewind the entire database to a historical point in time. It is so fast and simple because it does not require restoring database backups using either RMAN or user-managed backup.It can only recover “logical failures”, i.e. unnecessary data modifications due to human error. 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 uses 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.
• #34: The prerequisites for enabling this feature are: The database must be running in ARCHIVELOG mode. Enable the FRA (Flash Recovery Area).
• #35: 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 are needed, and delete them once they are no longer needed (based on the retention policies that are defined by the DBA).
• #36: DB_FLASHBACK_RETENTION_TARGET parameter 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. It is 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 there is not enough disk space, then Oracle will reuse the oldest flashback logs which might be within the retention period. In the following demonstration, the FRA is set with a 100GB size limit and flashback retention target of 1 week (=10080 minutes): Note: Starting with 11gR2, it is possible to enable the Flashback Database with no downtime by executing this command when the instance is in OPEN status.
• #37: In the following example, a sample table is created, populated with a 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 entire database prior to the truncate command that was executed using the “before_truncate” restore point.
• #38: 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 Time. Another simple way is to create a restore point in which a name represents a specific point in time, and then the flashback will restore the database to the time that the restore point had been created.
• #40: 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.
• #42: Using the Flashback Transaction feature, we can rollback the changes made by a transaction and its dependent transactions (optionally).
• #43: 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
• #44: The parameters of the TRANSACTION_BACKOUT procedure are: numtxn - Number of transactions passed as input xids - List of transaction IDs in the form of an array Options – Whether to Backout dependent transactions 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 second transaction that updates the row depends on the first transaction that inserts the row; therefore, Oracle raises an error. We can tell Oracle to rollback the dependent transactions using the CASCADE value for the “options” parameter, as follows:  
• #45: 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 Undo Guarantee property In order to allow an 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 remain 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 - Maximum amount of storage that can be allocated on the tablespace Retention – The amount of time that information will be kept in the 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.
• #46: 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: Click The retention information for the Flashback Archives is available in the DBA_FLASHBACK_ARCHIVE dictionary view Click Once the Flashback Archive has been configured, the user can easily enable and disable this feature for the desired tables, as follows: Click The information about the quota per each Flashback Archive and the associated tablespace is available in the DBA_FLASHBACK_ARCHIVE_TS dictionary view
• #47: Once the Flashback Archive has been configured, the user can easily enable and disable this feature for the desired tables, as follows Click The DBA_FLASHBACK_ARCHIVE_TABLES dictionary view displays all of the tables that have a Flashback Archive configured:
• #49: In Oracle 11gR2 the following enhancements were introduced: Flashback Database – Prior to 11gR2, the DBA had to restart the database to a MOUNTED state and only then enable the Flashback Database feature. Now, the DBA can enable the Flashback Database when the instance is open with no downtime. Flashback Data Archive – Prior to Oracle 11gR2, several DDL commands on a table with Flashback Archive enabled raised an error: “ERROR at line 1 ORA-55610: Invalid DDL statement on history-tracked table”. This includes the following DDL operations: TRUNCATE TABLE ALTER TABLE [ADD| DROP| RENAME| MODIFY] Column DROP|TRUNCATE Partition ALTER TABLE RENAME ALTER TABLE [ADD| DROP| RENAME| MODIFY] Constraint Staring with Oracle 11gR2, these operations are now supported on tables with Flashback Archive enabled.
• #51: 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 to understand not only what the changes were but also 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.
• #53: 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 of 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).
• #55: The great thing about Oracle Flashback technology is that it allows recovering from various human errors with the 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 does not require restoring and recovering data 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   In this session wer have 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 empower the DBAs by making their lives easier when it comes to protecting the data from various human errors.
• #56: Oracle Flashback technology provides a set of tools which 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