378  Chapter 9  n  Understanding Flashback Technology

Ta b l e 9 . 4   ​  FLASHBACK​ _TRANSACTION_QUERY View Columns  (continued)

If you’ve ever used Oracle Log Miner, the columns listed in Table 9.4 may look familiar to you. In fact, Flashback technology offers functionality that is very similar to Log Miner, but is much simpler to use. It allows you to drill down to the transactional level to analyze data changes. It also provides the SQL necessary to undo any transaction, provided the necessary undo records still exist in the undo tablespace.

Using Additional Flashback Operations

In the following sections, you will first learn how to perform Flashback Table operations and then learn how to perform point-in-time recovery on tables in a live database. Then you will learn how to configure, monitor, and perform Flashback Database operations.

Lastly, you will learn to set up and use a Flashback Data Archive.

Using Flashback Table

All of the previous Flashback options we’ve covered in this chapter have allowed you to view and correct specific data elements within a table. They have not affected the table as a whole. Flashback Table is a little different in that regard.

Flashback Table is a Flashback technology that allows you to recover an entire table (or set of tables) to a specific point in time without the hassle of performing an incomplete recovery. This means that rather than rolling back a single transaction, the entire table will be rolled back. If the table has dependent objects associated with it, they are also rolled back automatically.

So why would you choose to use Flashback Table instead of performing an incomplete recovery? There are several reasons:

Speed  ​  It​ is much faster than incomplete recovery. Simplicity   ​ ​It is much easier than incomplete recovery.

Availability   ​ Flashback​ Table does not impact the availability of the database. Unlike with other recovery methods, the database remains available, and the tablespace remains online the entire time.

Accessibility  ​  ​Users can flash back their own tables, so DBA involvement is not required.

Like other Flashback technologies, Flashback Table is limited only by the availability of undo data. Flashback Table also uses RETENTION GUARANTEE in the same manner as the previously discussed Flashback options.

There are two main clauses that are used with the Flashback Table:

To flash back a table, the table must have ROW MOVEMENT enabled. This can be accomplished with the following command: ALTER TABLE tablename

ENABLE ROW MOVEMENT.

It is important to get the current SCN from the database. The current SCN can be identified by querying the CURRENT_SCN column in the V$DATABASE view. To show that Flashback Table is recovered, you can create a change to the data. In the following example, you will update the SALARY value for an employee and commit the transaction. Then you will perform a Flashback Table operation to recover the table to its state prior to the update. This change will be missing if the table is recovered to an SCN before the change is introduced.

Let’s walk through performing a Flashback Table operation with SCN:

1.Enable row movement on the employees table:

SQL> alter table employees enable row movement; Table altered.

2.Retrieve the current SCN from the database. This is for reference, so make a note of it:

SQL> select current_scn from v$database;

CURRENT_SCN

-----------

623411

380  Chapter 9  n  Understanding Flashback Technology

3.Query the employees table to verify the current salary for the employee with an employee_id = 110:

SQL> select employee_id, salary from employees

where employee_id = 110; EMPLOYEE_ID SALARY

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

1103000

4.Update the employees table as shown. Be sure to commit the change too:

SQL> update employees set salary=4000 where employee_id = 110;

1 row updated. SQL> commit; Commit complete.

5.Query the employees table to verify the new salary for our sample employee:

SQL> select employee_id, salary from employees

where employee_id = 110;

EMPLOYEE_ID SALARY

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

1104000

6.Perform a Flashback Table operation to recover the table to the SCN retrieved in step 2:

SQL> flashback table employees to scn 623411;

7.Query the employees table again to verify that the change was eliminated because of the Flashback Table operation:

SQL> select employee_id, salary from employees

where employee_id = 110;

EMPLOYEE_ID SALARY

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

110 3000

As the example shows, the table has been recovered to its previous state, as it existed back at SCN 623411. Also, if any dependent objects such as indexes existed on the table, they would have also been recovered to maintain consistency.

If a table contains triggers, however, there are some special rules that apply when a Flashback Table operation is performed. All triggers are disabled during a Flashback Table operation. By default, they will remain disabled after the operation is complete, regardless of whether the trigger was previously enabled or not.

If a table has one or more enabled triggers and you want them to remain enabled after the Flashback Table operation is complete, you can add the ENABLE TRIGGERS clause to the statement, as shown here:

SQL> flashback table employees to scn 623411

enable triggers;

When you specify the ENABLE TRIGGERS option, all triggers that were previously enabled will be reenabled after the operation is complete. Note that the trigger did not remain enabled during the Flashback Table operation. As stated before, all triggers are disabled during the operation (they will not fire in conjunction with the recovery operation). They are then reenabled only after the operation is complete.

As you can see, the Flashback Table operation is a valuable recovery method. Now when a user updates a table using an incorrect WHERE clause, you can simply undo the change using Flashback Table. They could even do it themselves. And, best of all, the availability of the database is not impacted by the operation. Please keep in mind that more complex flashback operations may be required, depending on the number of objects and relations impacted.

In Exercise 9.3, you’ll practice using the Flashback Table feature; continue using the table created in Exercise 9.2.

E x e r c i s e 9 . 3

Using Flashback Table

To practice using the Flashback Table feature, continue using the table created in Exercise 9.2, and perform the following:

1.Select all rows from the table.

2.Verify the system time at which the last two rows were inserted.

3.Flash back the table to the system time returned in step 2:

SQL> alter table foo enable row movement; Table altered.

382  Chapter 9  n  Understanding Flashback Technology

E x e r c i s e 9 . 3   ( c o n t i n u e d )

SQL> select * from foo;

SQL> flashback table foo to timestamp to_timestamp( ‘04-NOV-08 20:31:19’,’DD-MON-YY HH24:MI:SS’);

Flashback complete.

SQL> select * from foo;

Configuring and Monitoring Flashback Database

and Performing Flashback Database Operations

Flashback Database was introduced in Oracle 10g. There is one main difference between the other Flashback technologies and Flashback Database: Flashback Database relies on “before” images in the flashback logs, whereas the other Flashback features rely on the undo data.

Flashback Database allows you to flash the entire database back to a specific point in time. This is extremely useful to recover from errors such as truncating a large table, not completing a batch job, or dropping a user. Flashback Database recovery is also the best choice for most logical corruptions such as a bad complex transaction that gets propagated throughout the database.

Before you can use Flashback Database, you must set up the flash recovery area. Please refer to Chapter 2 for an introduction to the flash recovery area, and refer to Chapter 3 to learn how to configure it.

One major technological benefit of Flashback Database is that it allows you to reverse user errors or logical corruption much quicker than performing a traditional incomplete recovery or using the Oracle Log Miner utility. The reason Flashback Database recovery is much quicker than traditional recovery operations is that recovery is no longer impacted by the size of the database. The mean time to recovery (MTTR) for traditional recovery is dependent on the size of the datafiles and archive logs that need to be restored and applied. Using Flashback Database recovery, recovery time is proportional to the number of changes that need to be backed out of the recovery process, not the size of datafiles and archive logs. This makes the Flashback Database recovery process the most efficient recovery process in most user-error or logical-corruption situations.

The Flashback Database architecture consists of the recovery writer RVWR background process and Flashback Database logs. When the Flashback Database is enabled, the RVWR process is started. Flashback Database logs are a new type of log file that contain a “before” image of physical database blocks. The RVWR writes the Flashback Database logs in the flash recovery area. Enabling the flash recovery area is a prerequisite to using Flashback Database because the Flashback Database logs are written to the flash recovery area.

Configuring the Flashback Database

The database must have multiple features configured prior to configuring Flashback Database. The database must have ARCHIVE LOG enabled. As mentioned earlier, the flash recovery area must be configured to store the Flashback Database logs.

First, make sure the database is shut down. Next, the database must be started in MOUNT mode. Then, the database parameter DB_FLASHBACK_RETENTION_TARGET can be set to the desired value, which is based on minutes. This value determines how far back in time you can flash back the database. This is like a baseline for Flashback Database. Next, Flashback Database can be enabled with the ALTER DATABASE FLASHBACK ON command. Finally, the database can be opened for normal use.

Let’s walk through these steps in more detail:

1.Start the database in MOUNT mode:

384  Chapter 9  n  Understanding Flashback Technology

Database mounted.

2.Set the DB_FLASHBACK_RETENTION_TARGET parameter to the desired value. This value is in minutes, which equates to three days:

SQL> alter system set db_flashback_retention_target=4320;

3.Enable the flashback capability:

SQL> alter database flashback on;

4.Now the database can be opened for normal use:

SQL> alter database open;

As you can see, enabling Flashback Database is fairly simple. A key point for you to know is how far back in time you need to be able to flash back from, or know the

DB_FLASHBACK_RETENTION_TARGET parameter value. The DB_FLASHBACK_RETENTION_TARGET value will determine how far you can flash back the database in minutes. In the preceding example, you specified the value of 4,320, which is for three days; the default value is 1,440, or one day.

Monitoring Flashback Database

The Flashback Database can be monitored by using a few dynamic views: V$DATABASE,

V$FLASHBACK_DATABASE_LOG, and V$FLASHBACK_DATABASE_STAT. These views provide some valuable information regarding the status of the Flashback Database and the supporting operations.

The V$DATABASE view displays if the Flashback Database is on or off. This tells you whether the Flashback Database is enabled or not.

Let’s query the V$DATABASE view and see the results:

SQL> select flashback_on from v$database;

FLASHBACK_ON

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

YES

SQL>

Query the V$FLASHBACK_DATABASE_LOG to determine the amount of space required in the recovery area to support the flashback activity generated by changes in the database. The values in the OLDEST_FLASHBACK_SCN and OLDEST_FLASHBACK_TIME columns give you information regarding how far back you can use Flashback Database. This view also shows the size of the flashback data in the FLASHBACK_SIZE column. The column ESTIMATED_FLASHBACK_SIZE

can be used to identify the estimated size of flashback data that you need for your current target retention. Shown next is an example of querying the V$FLASHBACK_DATABASE_LOG:

SQL> select

2.oldest_flashback_scn,

3.oldest_flashback_time,

4.retention_target,

5.estimated_flashback_size

6.from v$flashback_database_log;

OLDEST_FLASH_SCN OLDEST_FLASH_TIME RET_TARGET EST_FLASHBACK_SIZE

SQL>

The V$FLASHBACK_DATABASE_STAT view is used to monitor the overhead of maintaining the data in the Flashback Database logs. This view allows you to make estimates regarding future Flashback Database operations. This is done by coming up with an estimate about potential required space.

Let’s look at the V$FLASHBACK_DATABASE_STAT:

SQL> select * from v$flashback_database_stat;

BEGIN_TIM END_TIME FLASHBACK_DATA DB_DATA REDO_DATA

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

ESTIMATED_FLASHBACK_SIZE

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

20-JUL-08 20-JUL-08 61784064 35880960 99203072 0

SQL>

As you can see, the V$FLASHBACK_DATABASE_STAT dynamic view shows the utilization of the Flashback Database log. This is determined by the begin and end times.

Using Flashback Database

The Flashback Database can be used with SQL*Plus to perform recoveries. Once the database is configured for the Flashback Database, you just need to start the database in MOUNT mode, and you are ready to perform a Flashback Database recovery. You also need to get either OLDEST_FLASHBACK_SCN or OLDEST_FLASHBACK_TIME from the V$FLASHBACK_DATABASE_LOG view. This will allow you to utilize the TO SCN or TO TIME clause in the FLASHBACK DATABASE clause. If you have established a restore point, you can recover to it if it is newer than the oldest_flashback_scn.

386  Chapter 9  n  Understanding Flashback Technology

Let’s walk through performing a Flashback Database recovery to an SCN:

1.First, query the V$FLASHBACK_DATABASE_LOG view to retrieve the OLDEST_FLASHBACK_SCN:

SQL> select oldest_flashback_scn, oldest_flashback_time 2 from v$flashback_database_log;

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME

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

979720 20-JUL-08

SQL>

2.Next, shut down and start the database in MOUNT mode:

3.Next, issue the Flashback Database recovery command:

SQL> flashback database to scn 979721; Flashback complete.

SQL>

4.Finally, open the database with the RESETLOGS option, because you recovered to a time prior to the current database:

SQL> alter database open resetlogs; Database altered.

SQL>

As you can see, the Flashback Database recovery is a fairly simple process. The V$FLASHBACK_DATABASE_LOG dynamic view is useful for both TO SCN and TO TIME recoveries. The Flashback Database recovery is a quick and efficient method for recovering from user errors or logical corruptions in the database. This is a great alternative to performing a traditional incomplete recovery.

Flashback Database recovery can also be performed in SQL*Plus with the FLASHBACK DATABASE command as well as with RMAN.

Limitations with the Flashback Database

Flashback Database recovery cannot recover through some common occurrences such as resizing a datafile to a smaller size or a deleted datafile. In these cases, the datafile would need to be restored with traditional methods to a point in time prior to its deletion or resizing. Then you could use Flashback Database recovery to recover the rest of the database.

Flashback Database is a nice substitute for incomplete recovery for logical corruption and user errors. However, there are some limitations to Flashback Database that you should be aware of:

NNMedia failure cannot be resolved with Flashback Database. You will still need to restore datafiles and recover archived redo logs to recover from media failure.

NNResizing datafiles to a smaller size, also called shrinking datafiles, cannot be undone with the Flashback Database.

NNYou cannot flash back the database to an SCN prior to the earliest available SCN in the flashback logs.

Setting Up and Using a Flashback Data Archive

The Flashback Data Archive, also known as Oracle Total Recall, allows you to retain and track all transactional changes to a record over its lifetime. This eliminates the need to write custom programs to archive all transactional changes to data. The uses of the Flashback Data Archive are many, but auditing and compliance are two key areas where this technology can be useful.

388  Chapter 9  n  Understanding Flashback Technology

To utilize the Flashback Data Archive capabilities, create one or more tablespaces as an archive. Each archive has a retention time that determines how long data is retained within it. The DBA can designate a default Flashback Data Archive for the database.

Once you have a created a Flashback Data Archive, you can enable flashback data archiving on a per-table basis. By default, flashback archiving is turned off.

Configuring the Flashback Data Archive

Setting up the Flashback Data Archive is straightforward. Simply name the archive and assign a tablespace, an optional space quota, and the retention time:

SQL> create flashback archive audit_flash_archive tablespace audit_archive quota 20g retention 7 year;

SQL> create flashback archive audit_flash_archive_2

Tablespace audit_archive quota 10m retention 90 day;

SQL>

To establish a default Flashback Data Archive, simply add the default keyword in the create clause:

SQL> create flashback archive default default_flash_archive

Tablespace audit_archive quota 10m retention 90 day;

SQL>

After you’ve created a Flashback Data Archive, of course you will need to alter it. As DBA, you may alter the storage quota and retention time and add, drop, or modify tablespaces in a data archive using the alter flashback archive command. Here are a few examples:

SQL> alter flashback archive default_flash_archive Modify tablespace audit_archive quota 100m;

SQL>

SQL> alter flashback archive default_flash_archive retention 180 day;

SQL>

SQL> alter flashback archive default_flash_archive Remove Tablespace audit_archive;

SQL>

To clean up or purge data to an SCN or timestamp from a Flashback Data Archive, use the alter command with the purge clause:

SQL> alter flashback archive default_flash_archive

Purge before SCN 979271;

SQL>

SQL> alter flashback archive default_flash_archive

Purge before timestamp (SYSDATE – 180);

SQL>

And if you have established a deletion policy for archives, you can drop an archive quite easily:

SQL> drop flashback archive default_flash_archive;

SQL>

Using the Flashback Data Archive

Once the Flashback Data Archive is created, you can begin archiving data from specific tables. To enable archiving for an existing table, use the ALTER TABLE command with the

FLASHBACK ARCHIVE clause:

SQL> alter table employee_history flashback archive audit_flash_archive; SQL>

If you have created a default flashback archive and want to use it, then you don’t need to specify the name of the archive.

Equally straightforward, create a new table with the archive feature to utilize the default Flashback Data Archive:

SQL> create table shipments (ship_id number(9), shipper number(9), ship_date date),

flashback archive; SQL>

To disable archiving for a table, simply alter the table using the NO FLASHBACK ARCHIVE clause:

SQL> alter table shipments no flashback archive;

SQL>

Now that you have established all the structures, query the base table to retrieve archive data using the AS OF TIMESTAMP clause:

SQL> select * from shipments AS OF TIMESTAMP (‘2008-05-01 12:00:00’, ‘YYYY-MM-DD HH24:MI:SS’); SQL>

Certain DDL is not allowed on archived tables: TRUNCATE, DROP, and RENAME as well as ALTER commands that drop, rename, or modify a column, change a long raw to a LOB, perform a partition or subpartition operation, or use the UPGRADE TABLE clause.