Flashback article on Oracle Blogs

Oracle Database und Temporal Validity

What is the difference between Temporal Validity and Flashback? The two are usually used together.
Further Reading: Oracle Database and Time Validity

Time validity is also known as Flashback Time Travel.

Show invisible columns:

set colinvisible on
desc <table_name>; 

The time-effective SELECT clause is:

VERSIONS PERIOD FOR VALID_TIME BETWEEN <start> AND <end>

The association with Flashback is through the procedure DBMS_FLASHBACK_ARCHIVE :

-- level可以是All，CURRENT和ASOF
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME (
   level          IN    VARCHAR2, 
   query_time     IN    TIMESTAMP DEFAULT SYSTIMESTAMP);

DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA (
   owner_name     IN    VARCHAR2, 
   table_name     IN    VARCHAR2);

Why Is Flashback Often Better Than Backups?

Logic errors refer to errors caused by humans and applications. But the database did not report an error.

Replication does not protect against logic errors unless replication is delayed.

Backup and recovery can cope with logic errors, but is usually too slow and complex.

This sentence is wrong, and the following explanation is also completely wrong:

In Oracle, we can perform a flashback table operation. The database must have flashback logging enabled.

This article can only give 2 stars.

Flashback Database and Flashback Logs

This article talks about the difference between Reuse and Delete Flashback Logs. Not bad, give 4 stars.

Flashback is a highly available feature with the advantage of simplicity.

Flashback technology includes logical and physical two types:

• Logical Flashback, relying on Undo data, restores tables and transactions.
• Physical Flashback, relying on Flashback logs, restores the entire database.

Prerequisites for Flashback Database:

• open archive
• Placement fast recovery area
• Set flashback retention target

The retention target signals the database to copy images of each altered block in every data file into the flashback log at regular intervals. These images are later used to reconstruct a previous incarnation of the database on demand. Any remaining changes are recovered using online and archived redo logs if available.

The four operations for managing flashback logs are as follows:

• Create, creates a flashback log if the following conditions are met:
  • There is enough space in the fast recovery area
  • DB_FLASHBACK_RETETION_TARGET is set
• Delete, flashback logs may be deleted only if
  • The flashback logs satisfy a normal restore point and there is space pressure in the fast recovery area
  • Flashback logs are obsolete as per retention target and corresponding archived redo logs have been deleted due to space pressure
  • Flashback logs have already been backed up to tape
• Reuse or Overwrite, the flashback log is reused or overwritten in the following cases
  • retention goals not met
  • Not a guaranteed restore point
  • Oldest flashback log when FRA is under space pressure
• Retain, keep flashback logs only if
  • Flashback logs are required to satisfy guaranteed restore points
  • FRA has no space pressure

It is also important to note that apart from setting flashback retention targets and creating guaranteed restore points, flashback logs cannot be managed in the flash recovery area.

Why You Can Get ORA-00942 Errors with Flashback Query

This article talks about Flashback Data Archive.

Normally you can only use this to query for the furthest time undo allows (the default/standard Flashback Query). With Flashback Data Archive (FBA), Oracle can permanently store the history of a table (up to the retention period).

Flashback Database

Flashback Database is like the rewind button on a cassette recorder or the reset button on a CD player.

While rarely used on production systems, since all data is lost after resetting the time (unless you export it beforehand), there are many possible uses, especially for test or standby systems:

• Application upgrade failed system reset
• Alternative Point-in-Time Recovery (PITR) with subsequent roll-forward (especially useful for standby systems)
• A test database for a reproducible starting point (e.g. for real application testing)
• Database upgrade test

Some database functions implicitly use Flashback Database, all related to ADG:

• Snapshot Standby
• Reinstantiation of the standby database (e.g. Fast Start Failover)

Some people are hesitant to use Flashback Databases because of performance overhead and space management, but:

• The load with Flashback Logs enabled is usually relatively low (around 5%)
• The additional space required for flashback logs can also be determined with relative precision.

Extended readingFlashback Database

This article mentions that there are two ways to enable Flashback Log, standard and implicit.

-- 标准
alter database flashback on
-- 隐式
create restore point SolbachGRP guarantee flashback database;

-- 可以从flashback_on属性看出区别，标准是YES，隐式是RESTORE POINT ONLY
SQL> SELECT flashback_on, log_mode FROM v$database;

FLASHBACK_ON       LOG_MODE
------------------ ------------
RESTORE POINT ONLY ARCHIVELOG

Flashback in Oracle Database

Oracle Database provides technologies such as Flashback Query, Flashback Delete (DROP), Time Validity, Flashback Database, Flashback Transaction, Flashback Data Archive, or Flashback Version Query.

All technologies can be used ahead of time, no additional installation required. And both are included in the Enterprise Edition.

Further reading: Flashback in Oracle
which mentions:

NOTE: It is important to know that Flashback Database technology can also be used without Flashback Logging. However, this requires the use of guaranteed restore points.

To be precise, it should be guaranteed that the restore point implicitly enables Flashback Database.

The following table is also useful:

technology	configuration
Flashback Query	Automatic UNDO management
Flashback Versions Query	Automatic UNDO management
Flashback Query	Automatic UNDO management
Flashback Transaction Query	Automatic UNDO management + Supplemental Logging
Flashback Table	Automatic UNDO Management + Table Row Movement
Flashback Drop	Initialization parameter RECYCLEBIN
Flashback Transaction	Archive Log 和 Supplemental Logging
Flashback Database	Archive Log and Flashback Log modes
Flashback Data Archive	Flashback Archive
Temporal Validity	hidden column

About licensing:
Flashback Table, Flashback Database, Flashback Transaction, and Flashback Transaction Query are available in Enterprise Edition. Archiving was first introduced as a stand-alone option in Oracle Database 11gR1 Enterprise Edition under the name Total Recall - meaning "Perfect Memory". It was later renamed Flashback Time Travel, which was also free. That said, FDA, Total Recall, and Flashback Time Travel are the same thing.

Total Recall is a feature of 11g, mentioned in the OBE article Using Total Recall :

The Flashback Data Archive feature is part of the Total Recall option.

Very interesting, this document Oracle Total Recall Oracle Banking ELCM Release specifically introduces Total Recall.

Only the Optimization for Flashback Time Travel feature requires the Advanced Compression option.

In the License Guide of 11gR2, it says so:

For releases earlier than Oracle Database 11g Release 2 (11.2.0.4): You must license the Oracle Advanced Compression option to use Flashback Data Archive (formerly known as Total Recall).
Beginning with Oracle Database 11g Release 2 (11.2.0.4): You must license the Oracle Advanced Compression option to use Optimization for Flashback Data Archive history tables. Basic Flashback Data Archive—without history table optimization—is available in all editions.

How to Recover Data (Without a Backup!)

The technology of Flashback is introduced in different scenarios:

• Restore a Whole Table - Flashback Table
• Recover a Few Rows - Flashback Query
• Recover a Few Rows++ - Flashback Data Archive
• Restore Dropped Tables - Flashback Drop
• Revert the Whole Database! - Flashback Database

A Fresh Look at Auditing Row Changes

Auditing using triggers is common and is still often seen as the only possible solution for capturing row changes on Oracle database tables. However, in Oracle Database 11.2.0.4 and later, it is now possible to use Flashback Data Archive to meet auditing requirements—a simpler, more efficient, and more secure solution.

References to tables in FDA can be seen in the execution plan.

Restore to the Point

This article focuses on Restore Point, which is an alias for SCN. And its applicable scenarios:

1. Repeat the test, after the test, you need to return to the test data baseline
2. When the batch modification data is wrong, it will fall back to before the batch processing.
3. After the upgrade fails, go back to before the upgrade

Flashback Database is 10g Release 2 technology. Its activation process:

1. open archive
2. set FRA
3. enable flashback logging

The restore point does not guarantee that it can be restored, but the guaranteed restore point can.

Flashback logs are retained for as long as specified by the db_flashback_retention_target database parameter.

Older logs are not automatically deleted; however, the maximum size of the flash recovery area is determined by the db_recovery_file_dest_size database parameter, in this case 2GB. When Tom's flash recovery area reaches 2GB, Oracle Database must delete some logs older than 1,440 seconds to make room for new logs. So when Tom wants to perform a flashback, the logs required for the selected restore point are out of date, causing an error.

There is a small mistake here, 1440 seconds should be 1440 minutes, because this is the default value of DB_FLASHBACK_RETENTION_TARGET, which is 1 day.

Flashback Technologies Features

This is the description on the official website. The full text is transcribed as follows:

Flashback supports recovery at all levels including the row, transaction, table, and the entire database. Flashback provides an ever growing set of features to view and rewind data back and forth in time, namely:

• Flashback Database: restore the entire database to a specific point-in-time, using Oracle-optimized flashback logs, rather than via backups and forward recovery.
• Flashback Table: easily recover tables to a specific point-in-time, useful when a logical corruption is limited to one or a set of tables instead of the entire database.
• Flashback Drop: recover an accidentally dropped table. It restores the dropped table, and all of its indexes, constraints, and triggers, from the Recycle Bin (a logical container of all dropped objects).
• Flashback Transaction: undo the effects of a single transaction, and optionally, all of its dependent transactions. via a single PL/SQL operation or by using an Enterprise Manager wizard.
• Flashback Transaction Query: see all the changes made by a specific transaction, useful when an erroneous transaction changed data in multiple rows or tables.
• Flashback Query: query any data at some point-in-time in the past. This powerful feature can be used to view and logically reconstruct corrupted data that may have been deleted or changed inadvertently.
• Flashback Versions Query: retrieve different versions of a row across a specified time interval instead of a single point-in-time.
• Total Recall: efficiently manage and query long-term historical data. Total Recall automatically tracks every single change made to the data stored inside the database and maintains a secure, efficient and easily accessible archive of historical data.

The Flashback features offer the capability to query historical data, perform change analysis, and perform self-service repair to recover from logical corruptions while the database is online. With Oracle Flashback Technology, you can indeed undo the past.

Oracle Database Flashback Technologies

Also from the official website.

Oracle Database Flashback Technologies is a set of data recovery solutions that reverse human errors by selectively and efficiently undoing the effects of a mistake. Oracle Database Flashback supports recovery at all levels, including the row, transaction, table, and the entire database.

Snapshots Are NOT Backups

Author Tim Chien is the Product Manager for Backup and Recovery. This article compares the difference between storage-based snapshots and RMAN.

Storage-Based Snapshots There are benefits to using snapshots for development or testing on non-production systems, but they should not be considered effective data protection or backups for Oracle databases. The correct approach is RMAN+FRA.

RMAN was introduced in Oracle 8.

Storage snapshots are unaware of the Oracle block structure (as they operate at the storage block level), and more importantly, they are physically different from backups (which consist of pointers rather than blocks).

Benefits of RMAN:
RMAN is an integrated data protection solution for Oracle Database that provides multiple levels of protection. At the granular block level, RMAN fully validates Oracle blocks at backup and restore time - validating blocks through physical checksum comparisons and logical checks within the blocks themselves (for example, verifying that row fragments or index entries are consistent). Backups can be used to restore production data to the last available archived redo logs, or to a specific point in time (according to the RMAN retention policy) in case of any data loss or physical corruption. In addition, the VALIDATE command can be used to verify physical and logical block correctness of the entire database or a single tablespace/datafile at the user's discretion. Likewise, backups can be validated at any time to ensure that they can be successfully restored using the RESTORE VALIDATE command. RMAN also provides block media recovery capabilities, allowing single block corruption in a database to be quickly repaired while unaffected data remains online and accessible to users.

Disadvantages of Storage Snapshots
Snapshots were not designed for Oracle data protection. They have no knowledge of Oracle block structures, so they do not and cannot validate Oracle data when they are created. They cannot be used in case of any data loss or physical damage. If blocks do not change over time, undetected block corruption may affect a series of snapshots. Because snapshots reside on the same array as the source database, they are vulnerable to failures affecting the storage array. This is why a snapshot, even if created very quickly, does not constitute a backup of the original data. For a snapshot to be used as a valid backup, it must be reconstructed as a complete set of blocks to another storage array or to tape, which involves the same performance issues as a full copy. Finally, restoring a snapshot has the side effect of invalidating all snapshots taken after it unless the snapshot is fully restored to an alternate location as a copy of the production data. Given these inherent drawbacks of snapshots, it is clear that only Oracle-aware RMAN backups can provide true data protection "peace of mind".

For copy-on-write based snapshots, the database performance impact is reflected in two aspects. First, after the snapshot is created, the first write to a database block is converted into two storage I/O writes - one to copy the original block to the new snapshot storage location, and one to write the new block to the original Data blocks are blocked. Increased I/O usage can have a severe impact on production database performance. Second, after reverting the production database volume to a previous snapshot, the active storage block version now includes references to the snapshot blocks, which are likely to be spread out on disk rather than in order (the database still expects this to happen when an I/ O). For example, in the previous copy-on-write snapshot diagram, block C's I/O request is redirected to the snapshot version of block C, while block B's I/O request is not redirected because it is relative to the time the snapshot was taken No change. When the database issues a 1 MB I/O, it doesn't read the data sequentially in a single large read , but instead issues 128 random I/Os (assuming an 8K block size). Creating and restoring multiple snapshots over time, the resulting fragmented block layout can result in a 10-100x decrease in database performance.

For these reasons, it is never a good idea to create and use snapshots on production database storage.
Because of the severe impact on I/O performance, it is not recommended to use snapshot clones on production databases, but rather on secondary copies of the database.

Why CDM is not a snapshot

Author Tim Chien is Senior Director of Product Management in Oracle's High Availability and Storage Management group, focusing on backup and recovery, including Zero Data Loss Recovery Appliance, Recovery Manager (RMAN), and Flashback Technology.

Why (CDM) Snapshots are NOT Backups - Pt. 1

Why (CDM) Snapshots are NOT Backups - Pt. 2

It all boils down to the following table:

CDM vendors claim	What does using a CDM solution mean for Oracle Database?	What this means when using RA with an Oracle database
incremental forever backup	After an incremental backup is taken, a snapshot of the copy of the datafile is created, and then RMAN on the Oracle database performs an incremental merge to bring the copy up to date. For large database change volumes, merge operations can result in heavy production server load and CDM storage I/O utilization, extending the time that the latest copy is available for recovery.	Incremental-forever backups to devices result in an up-to-date virtual full backup without using incremental merge operations. The database only sends the changes, and the recovery device does the work. This frees up production resources for more business-critical workloads.
restore to any point in time	Database recovery requires more than reverting to an older set of snapshot files. Snapshot files and archive log backups from that point on must be cataloged by RMAN on the Oracle database and restored to a transactionally consistent point so that the database can be opened. This multi-step process increases recovery time, especially for large databases.	The appliance integrates directly with RMAN to perform all restore and recovery operations in a seamless manner familiar to DBAs. Virtual full backups are restored by RMAN directly on the Oracle database—without incremental merges—for fast recovery to any point in time. In addition, restoring the backup on the appliance continuously verifies the recoverability of the database, which is a unique advantage over CDM storage products.
instant recovery	RMAN 'switch to copy' is used to redirect database file pointers to snapshot file copies, then restore and recover using archived logs so that the database can be opened for access.	The appliance provides fast, virtual full recovery directly to production storage, up to 38 TB/hour in a single rack. Additionally, for "instant recovery" needs, Oracle Data Guard allows switching of the primary database to the latest copy of the standby database within seconds to minutes.
Reduce production RTO and RPO	While "instant recovery" using CDM snapshots sounds good, production recovery databases are expected to provide production service levels. Running the database files directly on CDM storage will not yield production-grade performance, especially since copy-on-write operations must also be maintained for new snapshots created. Also, Oracle Exadata does not support this usage (MOS Note 2663308.1 - Using External Storage with Exadata). With all traditional backup methods, RPO is controlled at the time of the last good backup, which can be hours or more exposed to data loss.	Virtual full recovery goes directly to production storage without sacrificing database performance. Zero to sub-second RPO is achieved through industry-proven Oracle Redo Block Transport, which backs up transactions to devices in real time.