Using the RETENTION GUARANTEE option is a mixed blessing, and one that must be carefully considered. On the one hand, you ensure that undo records necessary for all of your Flashback and read-consistency needs will be retained. On the other hand, if space runs out and the undo tablespace cannot be extended, Oracle will stubbornly enforce the guarantee and allow new transactions to fail.

To summarize, these sections offered you a brief overview of undo and AUM. First you learned about undo and its purpose. You saw how Oracle automatically manages undo on your behalf. And you learned how undo sizing and undo record retention play a key role in Flashback technologies. But what exactly are Flashback technologies? You are about to find out.

Using Flashback Technologies

In the following sections, we will explore each of the various Flashback options and provide examples of how they can be used in the real world. First, we will discuss the Flashback Drop option and the Recycle Bin and how the two work together to recover dropped objects in the database. Next, we will use the Flashback Query option to view data as it existed at a point in the past.

We will continue on to discuss Flashback Versions Query, and you’ll learn how to retrieve a historical view of changes made to the database. We will show how to use the Flashback Transaction Query option to retrieve information about past transactions and then show how to use the Flashback Transaction functionality to reverse those transactions.

Using Flashback Drop and the Recycle Bin

In Oracle Database 10g, the Recycle Bin feature was added to the Oracle Database. This feature enabled tables (and their associated objects) to persist in the database after they were dropped. Oracle 10g also introduced the Flashback Drop feature, which allows objects to be recovered from the Recycle Bin. These features remain largely unchanged in Oracle Database 11g.

In the following sections, we will provide an overview of the Recycle Bin feature. We will also demonstrate how to use the Flashback Drop feature to recover objects from the Recycle Bin.

Using the Recycle Bin

The Recycle Bin is a logical container for dropped tables and their associated objects (indexes, constraints, triggers, nested tables, large-object [LOB] segments, and LOB index segments).

When a table is dropped in Oracle Database 11g, it is not actually removed from the database. Instead, it is moved into the Recycle Bin. These objects remain in the Recycle Bin until they are purged explicitly or due to space pressure (permanently removed) or restored via the Flashback Drop feature.

In this section, we will cover the usage of the Recycle Bin, including how to use it, how to purge objects from it, how to enable and disable it, and how to recover objects from it using Flashback Drop.

358  Chapter 9  n  Understanding Flashback Technology

The Recycle Bin is a logical container, as opposed to a physical container. There is no Recycle Bin tablespace or datafile into which the dropped objects are moved. Instead, the objects remain in their original tablespace and are simply renamed using a special naming convention. This naming convention ensures that database objects with the same name will not be assigned duplicate identifiers when they are moved into the Recycle Bin.

To demonstrate how objects interact with the Recycle Bin, this section will provide a series of examples showing how a dropped table is represented in the Recycle Bin. To begin, we first must drop a table, as shown here:

SQL> drop table job_history;

Table dropped.

Once the table has been dropped, our next step is to view the contents of the Recycle Bin to verify that the table is truly there. One simple way to do this is to use the SHOW RECYCLEBIN command, as shown here:

SQL> show recyclebin

The SHOW RECYCLEBIN command confirms that our table now resides in the Recycle Bin, as expected. It also provides several other pieces of useful information. These are described in Table 9.1.

Next, we will create a new table named JOB_HISTORY, insert some data, and then drop it. We will then look in the Recycle Bin to verify that both tables are there, even though both tables had the same name.

SQL> create table job_history (job_id number);

Table created.

SQL> insert into job_history values(1); 1 row created.

SQL> commit;

Commit complete.

SQL> drop table job_history;

Table dropped.

SQL> show recyclebin

As promised, Oracle assigned the second version of the JOB_HISTORY table a unique identifier (RECYCLEBIN NAME). This ensures that either version of the table could be restored if required.

Besides the SHOW RECYCLEBIN command, Oracle also offers views named USER_RECYCLEBIN and DBA_RECYCLEBIN, which can be used to query objects in the Recycle Bin. These views offer much more information than the simple SHOW RECYCLEBIN command. For example, look at the following query:

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

6 rows selected.

Upon first glance, you might have assumed that this query would have returned the exact same results as the SHOW RECYCLEBIN command. Instead we see four additional rows showing the indexes that were moved to the Recycle Bin when we dropped the first JOB_ HISTORY table.

The SHOW RECYCLEBIN command shows only tables that reside in the Recycle Bin. It filters out the dependent objects such as indexes and constraints. Furthermore, the USER_ RECYCLEBIN view also offers many other columns, as listed in Table 9.2.

Tables residing in the Recycle Bin can be queried directly, just like any other table. The only caveat is that they cannot have any Data Definition Language (DDL) or Data Manipulation Language (DML) statements performed on them. Any attempt to do so will result in an error.

To query a table currently residing in the Recycle Bin, simply use the system-assigned name (OBJECT_NAME), not the original name. Also, since this name consists of mixed-case

362  Chapter 9  n  Understanding Flashback Technology

characters, you must enclose the name in double quotes in your select statement. Here’s an example:

SQL> select * from “BIN$XwE0KAONSRGwYREWXnjkKw==$0”;

JOB_ID

----------

1

Purging the Recycle Bin

As was mentioned previously, objects are never physically moved into the Recycle Bin. Therefore, there is no tablespace associated with it. Instead, the objects remain in their respective tablespaces but are no longer listed in the data dictionary. So, they appear to have been dropped, yet they are still available for recovery.

However, this poses a problem for a user who is dropping tables to reclaim tablespace. Or perhaps you have a temporary table that you have no further need for and will never need to restore. For situations like these, the purge option should be used. Purging objects from the Recycle Bin will remove them permanently and release the storage space that they were occupying. However, it also means that they cannot be restored.

Purging can be accomplished in several ways. The first is by adding the PURGE option to the drop command, as shown here:

SQL> drop table employees purge;

Table dropped

By adding PURGE to the end of the DROP command, you make the table will bypass the Recycle Bin altogether. It will not be recoverable, so proceed with caution.

To purge objects that already reside in the Recycle Bin, you have several options. First, you can purge a specific table, as shown:

SQL> purge table employees;

Table purged

When purging a single table, you can reference the table by using either the original table name or the system-assigned name. If you use the system-assigned name, be sure to use double quotes around the name.

You can also purge all objects from a specific tablespace by using the TABLESPACE option, as shown:

SQL> purge tablespace users;

Tablespace purged

You can also purge the entire Recycle Bin (all objects you have dropped, regardless of tablespace) as shown here:

SQL> purge recyclebin;

Recyclebin purged

This command will purge all of the objects from the Recycle Bin. By the same token, a DBA can purge all of the objects from all users’ Recycle Bins at once using the following:

SQL> purge dba_recyclebin;

DBA Recyclebin purged

There may also be times when Oracle itself will purge objects from the Recycle Bin. This will occur when Oracle can no longer allocate new extents in a tablespace where the dropped objects reside without extending the tablespace. This is referred to as space pressure. Before extending the tablespace, Oracle will choose to purge Recycle Bin objects.

When space pressure occurs, Oracle will purge the oldest objects first, and it will purge dependent objects (in other words, indexes and triggers) before purging the table itself.

Because of the threat of space pressure, objects in the Recycle Bin are not guaranteed to be recoverable.

In Exercise 9.1, you’ll purge a table from the Recycle Bin.

E x e r c i s e 9 .1

Purging a Table from the Recycle Bin

To purge a table from the recycle bin, do the following:

1.Create a table and add rows of data.

2.Drop the table.

3.Purge the table from the Recycle Bin.

4.Verify that the table is no longer in the Recycle Bin:

SQL> create table foo (x number, y varchar2(10)); Table created.

SQL> insert into foo values (1,’test1’); 1 row created.

SQL> insert into foo values (2,’test2’); 1 row created.

SQL> insert into foo values (3,’test3’); 1 row created.

364  Chapter 9  n  Understanding Flashback Technology

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

SQL> commit;

Commit complete.

SQL> drop table foo;

Table dropped.

SQL> select * from recyclebin;

SQL> purge table foo; Table purged.

SQL> select * from recyclebin; no rows selected

SQL>

Disabling and Enabling the Recycle Bin

It is important to understand that even though the Recycle Bin is extremely useful, its use is entirely optional. Though it is enabled by default, it can be turned off at either the system or session level to suit the users’ needs. For instance, if you work in an environment that is very tight on space, the Recycle Bin might be more of a hindrance than a help.

The Recycle Bin feature is governed by an initialization parameter named RECYCLEBIN. As with other initialization parameters, it can be set in the INIT.ORA file as shown:

RECYCLEBIN=OFF

For a database using spfiles, the same thing can be accomplished as shown here:

SQL> alter system set recyclebin = off scope=spfile;

System altered.

It can also be set at the session level, as shown in the following example:

SQL> alter session set recyclebin = off;

Session altered.

And, as you can probably guess, the Recycle Bin feature can be reenabled by all the same methods; just substitute ON for OFF.

Using Flashback Drop

Now that you’ve seen how the Recycle Bin works, it’s time to use the Flashback Drop feature to restore objects from it. The syntax for the Flashback Drop command is as follows:

FLASHBACK TABLE table_name TO BEFORE DROP

[RENAME TO new_table_name];

By default, a Flashback Table operation will restore the table using the same name it had originally. The optional rename clause allows you to restore the table under a different name. This may be required if an object with the original name already exists in your schema.

Let’s take a look at how it all works. In this example, we will restore the JOB_HISTORY table and rename it JOB_HIST:

SQL> flashback table job_history to before drop rename to job_hist;

Flashback complete.

Now we’ll query the restored table, as shown here:

SQL> select * from job_hist;

JOB_ID

----------

1

366  Chapter 9  n  Understanding Flashback Technology

As you can see, the Flashback Drop feature was successful in restoring the table. However, we had two different versions of the JOB_HISTORY table in the Recycle Bin. Why did Oracle choose to restore this one instead of the other one? The answer is that Oracle will always choose to restore the most recently dropped version of the table (if it has two identically named tables).

To recover the previous version of the JOB_HISTORY table, we have two options. Since we already recovered the first one, we can simply execute the Flashback Drop command again to restore the second version (however, we must rename one of them). However, a better alternative is to use the system-assigned object name whenever you want to recover a specific version of a table. Here’s an example:

SQL> flashback table “BIN$F2JFfMq8Q5unbC0ceE9eJg==$0” to before drop;

Flashback complete.

By specifying the system-assigned object name in your Flashback Drop, you avoid duplicatename issues and ensure that only the specific table that you’ve selected (and the specific version of that table) will be restored.

Flashback Drop functionality offers a simple way to recover from logical corruption caused when a table has been dropped in error. It is simple, fast, and works well. But there are other types of logical corruption that you must also be able to deal with, and those will require different tools. In the next section, we will introduce you to the next one: Flashback Query.

Regarding the Behavior of Dependent Objects after Undropping

When you recover a table from the Recycle Bin, the triggers, constraints, and indexes are also brought back; however, the names of the dependent objects remain as they were

in the Recycle Bin. For example, if table T has an index IN_T, a primary key constraint PK_T, and a trigger named TR_T and the table is dropped and later flashed back, all these dependent objects will revert back to table T but with different names:

SQL> select trigger_name from user_triggers where table_name = ‘T’; TRIGGER_NAME

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

BIN$VJSEhlG2cMngQA4KH2h7+A==$0

SQL> select index_name from user_indexes where table_name = ‘T’; INDEX_NAME

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

BIN$VJSEhlG0cMngQA4KH2h7+A==$0

BIN$VJSEhlG1cMngQA4KH2h7+A==$0

SQL> select constraint_name from user_constraints where table_name = ‘T’; CONSTRAINT_NAME

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

BIN$VJSEhlGzcMngQA4KH2h7+A==$0

You will need to explicitly rename these objects to their former names, if you so choose. Additionally, the following statements are true:

NNIt’s possible that some indexes may have been erased from the Recycle Bin, even when the table remained (typically under space pressure). So, it’s not guaranteed that all the indexes will be reverted back when the table is flashed back before drop.

Using Flashback Query

In the previous section you learned how to restore tables that had been dropped by accident. But oftentimes, logical corruption issues are not as blatant as a dropped table. It is much more common that a user will make a mistake on a data-entry form, delete a row by accident, or make any of a number of other mistakes. When a problem like this occurs, wouldn’t it be nice to be able to go back in time to fix it? Flashback Query allows you to do just that—in a manner of speaking.

Flashback Query provides a method of viewing data as it existed at a prior point in time. So when a user makes a mistake, you can just go back in time and fix it.

Flashback Query is implemented through the AS OF clause of the SELECT statement. The AS OF clause is used to specify a particular point in time (either a timestamp or an SCN number) for one or more tables in the query. When the query is executed, Flashback Query will return the data exactly as it existed at a specified point in time. It is important to note that Flashback Query will return only committed data. It will never return uncommitted data. So if the query happened to specify a point in time that fell in the middle of a transaction, Flashback Query will ignore the transaction and simply return the committed data.

As you can imagine, Flashback Query can be used in many situations encountered by a DBA in the course of their duties:

NNSimplifying certain programming tasks by alleviating the need to store certain types of temporary data

In the past, these types of problems could be addressed only through a costly and timeconsuming recovery process. With Flashback Query, they can be handled with ease. Also, Flashback Query functionality is not limited to the DBA. Any user who has been granted SELECT and FLASHBACK privileges can take advantage of it.

368  Chapter 9  n  Understanding Flashback Technology

Let’s take a look at Flashback Query in action. To begin with, we will look at the

JOB_HISTORY table:

SQL> select * from job_history;

10 rows selected.

Now, let’s simulate a user accidentally dropping a row:

SQL> delete from job_history where employee_id = 102;

1 row deleted.

SQL> commit;

Commit complete.

You can see that the row has indeed been deleted:

SQL> select * from job_history;

9 rows selected.

Now, we can use Flashback Query to view the data that existed prior to the delete, as shown here:

SQL> select *

from job_history as of timestamp(

to_timestamp(‘08-MAY-2008 11:50:00’,’DD-MON-YYYY HH24:MI:SS’)) where employee_id = 102;

The Flashback Query successfully returned the missing row, but we have only displayed it. We haven’t actually recovered it. To do so, we can simply run the same query but wrap it inside an INSERT statement as shown here:

SQL> insert into job_history (select * from job_history as of timestamp(

to_timestamp(‘08-MAY-2008 11:50:00’,’DD-MON’)) where employee_id = 102);

1 row created.

SQL> commit;

Commit complete.

370  Chapter 9  n  Understanding Flashback Technology

10 rows selected.

We have now successfully recovered from the accidental deletion and, as you can see, the effort was minimal.

In the example, our Flashback query pulled data only from a single table, and at a single point in time. Flashback Query is not limited to such simple queries. It can be used in multitable join queries as well. It can also be mixed and matched with tables that are not flashed back as well as tables that are flashed back to a different point in time. Look at the following example:

SQL> select e.last_name, d.department_name, j.job_title from employees as of timestamp(to_timestamp( ‘08-MAY-2008 11:50:00’,’DD-MON-YYYY HH24:MI:SS’)) e, departments as of timestamp(

to_timestamp(‘08-MAY-2008 11:53:00’,’DD-MON-YYYY HH24:MI:SS’)) d,

jobs j

where e.department_id = d.department_id and e.job_id = j.job_id

and e.employee_id = 200;

This query joined a total of three tables. Two of these tables were flashed back to different points in time. The third table was not flashed back at all. This demonstrates the flexibility of Flashback Query. In fact, a single table could even be joined multiple times, each join flashed back to a different point in time. As has been discussed before, the only limitation is how far back in time you can flash back, and that is determined by the undo retention period.

It is important to understand that the data present in the undo segment governs the ability to flash back to a point in time. Undo retention is only a guideline.

In this section, you’ve seen a sample of what Flashback Query can do and what a powerful tool it can be in a DBA’s arsenal. It allows you to look into the past to view data as it existed at a specific point in time. But what if you’re not sure exactly when a change was made? Or suppose you wanted to see all the changes that were made to a column over a period of time. Those are different types of problems and require a different type of tool— Flashback Versions Query.

In Exercise 9.2, you’ll practice using the Flashback Query feature.

E x e r c i s e 9 . 2

Using Flashback Query

To practice using the Flashback Query feature, perform the following:

1.Create a table, insert rows of data, and commit.

2.Select all rows from the table.

3.Select the system time.

4.Insert more rows of data into the table, and commit.

5.Select all rows from the table prior to the system time returned in step 3:

SQL> create table foo (x number, y varchar2(10));

Table created.

SQL> insert into foo values (1,’test1’);

1 row created.

SQL> insert into foo values (2,’test2’);

1 row created.

SQL> insert into foo values (3,’test3’);

1 row created.

SQL> commit;

Commit complete.

SQL> alter session set nls_date_format = ‘DD-MON-YY HH24:MI:SS’;

Session altered.

SQL> select sysdate from dual;

SYSDATE

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

04-NOV-08 20:31:19

372  Chapter 9  n  Understanding Flashback Technology

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

SQL> insert into foo values (4,’test4’);

1 row created.

SQL> insert into foo values (5,’test5’);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from foo;

XY

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

1 test1

2 test2

3 test3

4 test4

5 test5

SQL> select * from foo as of timestamp(to_timestamp( ‘04-NOV-08 20:31:19’,’DD-MON-YY HH24:MI:SS’));

XY

Using Flashback Versions Query

Flashback Versions Query allows you to query a table and retrieve all of the versions of the data that have existed between two specific points in time (specified by a timestamp or an SCN). What’s more, Flashback Versions Query offers a host of metadata columns that can also be included in your query, allowing you to view details regarding each change, such as the date/time that the change took place and the SCN that governed the change.

Like Flashback Query, Flashback Versions Query returns only the committed occurrences of the data. Uncommitted data will be ignored. Also just like Flashback Query, Flashback Versions Query works by retrieving data from the UNDO tablespace and is therefore limited by the undo retention period. It also requires the same privileges as Flashback Query: SELECT and FLASHBACK.

Flashback Versions Query is implemented by adding a VERSIONS BETWEEN clause to a SELECT statement. Just like the AS OF clause in Flashback Query, the VERSIONS BETWEEN clause allows the starting point in time to be expressed as either a timestamp or as an SCN.

Let’s look at Flashback Versions Query in action. First, we will update a single row in our table several times to simulate changes that may have occurred over time:

SQL> update employees

set salary=salary*1.03 where employee_id = 193;

1 row updated.

SQL> commit;

Commit complete.

SQL> update employees

set salary=salary*1.05 where employee_id = 193;

1 row updated.

SQL> commit;

Commit complete.

SQL> update employees set salary=salary/2

where employee_id=193;

1 row updated.

SQL> commit;

Commit complete.

374  Chapter 9  n  Understanding Flashback Technology

As you can see, our sample employee received a 3 percent raise, a 5 percent raise, and then had his salary cut in half. Next, we will query the table using the versions between clause to view the history of changes:

SQL> select salary from employees

versions between scn minvalue and maxvalue where employee_id = 193;

SALARY

----------

2108.93

4217.85

4017

3900

The results show us, from most to least recent, the history of our employee’s salary changes. He started off at a salary of $3,900, his 3 percent raise boosted him to $4,017, and his 5 percent raise boosted him to $4,217.85. Finally, our hapless employee’s salary was cut in half, to $2,018.93 (presumably after he was unable to quickly restore the rows his boss deleted since he didn’t know about Flashback technologies).

You will also notice that the sample query used the clause between scn minvalue and maxvalue to identify the range of versions to select. This construct allows the user to quickly select all versions that are available in the undo tablespace. This is a much cleaner solution than using artificially low and high date ranges such as BETWEEN TIMESTAMP TO_TIMESTAMP(’01-JAN- 1700’,’DD-MON-YYYY’)

AND

TO_TIMESTAMP(’31-DEC-2999’, ‘DD-MON-YYYY’).

As mentioned earlier, there are several pseudocolumns available in conjunction with Flashback Versions Query that can be used to identify when and how the changes were originally made. These columns are identified in Table 9.3.

Ta b l e 9 . 3    ​ Flashback​ Versions Query Pseudocolumns

Ta b l e 9 . 3    ​ Flashback​ Versions Query Pseudocolumns  (continued)

In our next example, we will use some of these pseudocolumns to create a simple history report covering the salary changes of our sample employee. The query is shown here:

SQL> select to_char(versions_starttime,’DD-MON HH:MI’) “START DATE”, to_char (versions_endtime, ‘DD-MON HH:MI’) “END DATE”, versions_operation,

employee_id, salary

from employees

versions between scn minvalue and maxvalue where employee_id = 123;

This simple query has produced a comprehensive report showing a wealth of information regarding this employee’s salary history. By reading from the bottom up, you can see the date and time that the employee was first inserted into the EMPLOYEES table (presumably the day he was hired), as well as his starting salary.

376  Chapter 9  n  Understanding Flashback Technology

The next lines show the dates, times, amounts, and durations of each salary change for the employee. You will notice that the last line (the top one) has no value for END DATE. This shows that this value still represents the current salary for the employee.

The Flashback Versions Query can also be used in DDL and DML subqueries.

So, in conclusion, Flashback Versions Query allows you to see into the past to view the history of data changes in the database. It takes the power of Flashback Query a step further and provides you with additional metadata to identify changes in further detail. It even allows you to identify the specific transaction that made the change.

But wouldn’t it be nice if you could drill down even further, to see specific details about that transaction? Unfortunately, Flashback Versions Query does not allow you to do that. Instead, you need to move ahead to the next section and learn about the tool that will allow you to do that: Flashback Transaction Query.

Using Flashback Transaction Query

Flashback Transaction Query is a diagnostic tool used to identify changes made to the database at the transaction level. Much like Flashback Versions Query, Flashback Transaction Query allows you to identify all changes made between two specific points in time. But Flashback Transaction Query goes a step further, allowing you to perform transactional recovery of tables. In other words, it provides you with the SQL that could be used to undo the transaction.

Before you can begin using Flashback Transaction Query functionality, there are two configuration steps that must be completed.

1.Ensure that the database is running with version 10.0 compatibility.

2.Supplemental logging must be enabled (in other words, ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;).

In addition to these systemwide settings, users who want to take advantage of this feature must be granted the SELECT ANY TRANSACTION privilege. They must also be granted the FLASHBACK privilege on the specific tables they want to flash back, or they must have the broader FLASHBACK ANY TABLE privilege.

Flashback Transaction Query is implemented through the use of the FLASHBACK_ TRANSACTION_QUERY view. The data in this view allows analysis of a specific transaction to identify what changes were made to the data. This view can be large, so it is helpful to use a filter when querying the view. This will generally be the transaction identifier (XID column).

Be sure to note that the transaction identifier is stored as a raw value in Oracle 11g. This is a change from Oracle 10g, which stored it as a character value. Because of this, you can’t simply pass in a string representation of a transaction identifier; you must provide a raw value. You can use Flashback Versions Query to provide it for you. For example, let’s

use the FLASHBACK_TRANSACTION_QUERY view to analyze the transactions that created the changes we viewed in the previous section. To do this, we will join a Flashback Versions Query with the FLASHBACK_TRANSACTION_QUERY view as shown here:

SQL> select table_name, operation, undo_sql from flashback_transaction_query t, (select versions_xid as xid

from employees versions between scn minvalue and maxvalue

3 rows selected.

This query shows you the three update transactions you ran earlier to modify our employee’s salary. It also provides you with a SQL statement that could be run to effectively offset the transaction.

The example query selected only a few of the columns available in the view. Table 9.4 shows the complete list.

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