For each of these options, we will discuss the requirements, capabilities, and limitations in detail.

Exam objectives are subject to change at any time without prior notice and at Oracle’s sole discretion. Please visit Oracle’s Training and Certification website (http://www.oracle.com/education/certification/) for the most current exam-objectives listing.

Overview of Flashback Technology

Flashback technology was first introduced in Oracle Database 9i. Since then, it has been steadily improved with each successive Oracle release. In Oracle Database 11g, it represents a mature and time-tested technology.

Flashback technology consists of a set of tools that allow users to recover from logical data errors without resorting to a database recovery. However, Flashback can do much more.

The Recycle Bin allows dropped objects to persist in the database, and the Flashback Drop option allows the objects to be restored.

The Flashback Query option allows the user to query tables as they looked at a specific point in the past.

The Flashback Versions Query option allows the user to retrieve a historical view of data as it changed over time. In other words, if a column had been updated multiple times, Flashback Versions Query could provide a list of each of the values and the date and time that they were changed.

Flashback Transaction Query is a useful diagnostic tool that allows the user to retrieve detailed transaction information for previously executed transactions. It can run for a single transaction or for all transactions that occurred during a specified time frame.

Flashback Table allows point-in-time recovery (recovering one or more tables to a specified point in the past) without the need to take any part of the database offline. This offers a very desirable alternative to performing a full-blown point-in-time recovery.

Flashback Database is best used as a replacement for incomplete recovery of the entire database. The main benefit of Oracle Flashback Database over incomplete database recovery is that Flashback Database is much quicker and more efficient. Flashback Database is not based on undo data but on flashback logs. It is best suited to recover from errors such as truncating a large table, an incomplete batch job, or a dropped user.

As you can see, Flashback offers a wide variety of tools for the DBA. However, these options are not exclusive to the DBA. In fact, one of the key advantages to the various Flashback technologies is that they do not require DBA-level privileges. Users and developers can utilize them to recover from their own errors without DBA intervention (except for Flashback Database).

352  Chapter 9  n  Understanding Flashback Technology

Using Automatic Undo Management

Before we can delve too deeply into Flashback technologies, it is important to understand that all of the Flashback options covered in this chapter, except for Flashback Database and Flashback Drop, work in conjunction with Oracle’s undo functionality. Without undo, there would be no Flashback. In fact, without undo, transaction processing as we know it would not exist.

The topics of undo and undo management should not be new to you and will not

be covered in depth here. However, we believe that a brief overview of the subject will be helpful in better understanding Flashback technologies and how they work.

In the following sections, you will take a look at undo and Automatic Undo Management (AUM). First we will define undo and its purpose. You will discover how Oracle can automatically manage undo on your behalf. Then you will learn how undo sizing and undo record retention play a key role in Flashback technologies.

Uncovering Undo

So what exactly is “undo” and why does it need to be managed? Undo is a key component of the Oracle database that stores a record of every change made to data in the database. This record contains the data necessary to “undo” the change (in other words, roll back the transaction) and restore the data to its previous condition. For example, when a row in a table is updated, Oracle will create an undo record that stores the data that was changed. If a new row is inserted into a table, an undo record will be created that would effectively delete the row.

Maintaining undo records serves multiple purposes in the database:

Let’s look at each of these individually.

Transaction Processing

Transaction processing allows SQL statements to be grouped into discrete units of work that can be committed or rolled back as one. The classic example is that of woman walking into a bank and asking to transfer $500 from her checking account to her savings account. Behind the scenes, two SQL statements are executed: one that subtracts $500 from her checking-account balance and one that adds $500 to her savings-account balance.

Now, suppose the bank’s computer system crashed after completing the first statement but not the second. The money would be gone from her checking account but never added to her savings account. She would be out $500 on the deal. Instead, the two statements must be treated as a single, logical unit of work (in other words, a transaction). Only when

both statements have completed successfully should the changes be committed. If either fails, they must both be rolled back.

When a user changes data in a table (via insert, update, or delete), the change does not occur immediately. The user must either commit the change (finalize it) or roll it back (undo it). Until they do, the database must keep track of both versions of the data (before the change and after the change).

In order to meet this requirement, the database will modify the data in the table to reflect the change. It will then create an undo record in the undo tablespace that contains any data needed to undo the change.

Although the transaction remains in limbo (neither committed nor rolled back), other users who query the table will see the data as it looked prior to the change. If the user decides to roll back the transaction, the undo information is used to modify the table data to revert it to its previous value. If the user decides to commit the transaction, the change becomes permanent.

From strictly a transaction-processing standpoint (allowing a transaction the option of committing or rolling back), the undo records for a transaction are useless after the transaction finishes. They have served their purpose and could be deleted. However, by retaining undo information for a period of time after a commit, many new options become available to us.

As you will see, as you continue through this chapter, the whole host of Flashback options becomes available by the simple act of retaining undo records for a period of time after they have been committed.

Failed-Transaction Recovery

A failed transaction is a transaction that never completes; that is, it never commits or rolls back. This can happen for a variety of reasons, but they all boil down to a session closing with a transaction still in progress.

Since most (if not all) Oracle clients are designed to either commit or roll back automatically when a session is closed, simply forgetting to finish a transaction before exiting will rarely result in a failed transaction. In general, a failed transaction occurs because of an abnormal server shutdown (because of hardware failure, loss of power, or even a shutdown abort).

When a failed transaction is discovered (generally at startup time following an abnormal shutdown), Oracle will undo the transaction automatically using the data stored in the undo tablespace.

Read Consistency

When a user issues a query, the database is required to process the query and return the data as it looked at the moment the query started. In other words, if you kicked off a longrunning query at 10 a.m. and it finished at 10:15 a.m., the data should not reflect changes (committed or uncommitted) made by other users in the interim.

To fulfill this requirement, Oracle must retain undo records after their associated transaction has been committed. The length of time that it chooses to retain this data is governed by the undo retention period, which will be covered later in this chapter.

354  Chapter 9  n  Understanding Flashback Technology

Flashback Functionality

Flashback functions allow users to view elements of the database as they appeared at a certain point in time. These functions will be described in much more detail later in this chapter.

Much like the read-consistency requirements, Flashback requires that undo records be retained for a period of time after the associated transaction has completed.

In short, the undo feature creates and maintains records of all transactions that occur in the database and stores the data necessary to undo them. By maintaining these records throughout the life of a transaction, undo provides transaction management and read-consistency capabilities. By maintaining these records after the transaction has been committed, undo provides read-consistency and Flashback options.

Working with Automatic Undo Management

Undo data is temporary. In that respect, the undo tablespace is similar to a temporary tablespace. Information is written there to fulfill a temporary need. As soon as the information is no longer needed, it can be removed to make room for new undo data. To keep things running smoothly requires a considerable amount of management. Luckily, Oracle offers the Automatic Undo Management feature.

Automatic Undo Management (AUM) is a feature whereby Oracle will handle all undo management tasks without interaction from the DBA. Although this is not a new feature in Oracle Database 11g, one important aspect has changed. In previous Oracle versions, manual undo management was the default setting. In order to enable AUM, configuration changes were required by the DBA. Beginning with Oracle Database 11g, AUM will be enabled by default.

When creating a new database with the Database Configuration Assistant (DBCA), Oracle will perform the following actions:

These three steps ensure that Oracle will automatically manage the undo needs for the database

Automatic Undo Management must ensure that Oracle can store undo information for all new transactions as they occur. This means that adequate space must be available in the undo tablespace.

By creating an auto-extending undo tablespace, Oracle can extend the size as needed to maintain adequate undo information.

So how long should Oracle retain committed undo information? The simple answer is, long enough to satisfy the undo retention period. The undo retention period represents the minimum amount of time that Oracle will attempt to retain committed undo information before allowing it to be overwritten.

Please note that it is still possible to run the database in manual undo management mode. This can be done by changing the initialization parameter to UNDO_MANAGEMENT=MANUAL. However, Oracle strongly advises against it.

In Oracle Database 11g, if the UNDO_MANAGEMENT initialization parameter is set to NULL, the database will default to AUTO. However, it was just the opposite in earlier Oracle versions. Therefore, if you are upgrading to version 11g, be aware that a NULL setting will have the opposite effect that it had in the prior version.

Understanding Undo Retention

The undo functionality of Oracle Database 11g is governed by a setting known as the undo retention period. The undo retention period represents the minimum time (expressed in seconds) that committed undo information should be retained in the undo tablespace.

To ensure read consistency, the undo retention period should be set to a value larger than the runtime of your longest-running query. If your longest-running query takes 60 minutes to run and you retain undo information for 65 minutes, your system should not encounter any ORA-01555 Snapshot too old errors.

To ensure that undo data is available for Flashback operations, the undo retention period should be set long enough to retain adequate data to support your Flashback needs. For example, if you want to always maintain a 4-hour window in which to undo data changes, then the setting should be at least 14400 (4 hours expressed in seconds).

It is important to understand that the undo retention setting is actually a target for AUM to achieve; it does not guarantee that data will actually be retained for the entire time. There are circumstances under which AUM may choose to violate the undo retention period.

Undo data is considered to be in one of three possible states at any given time: uncommitted, unexpired, or expired.

Uncommitted data is undo data corresponding to a transaction that has been neither committed nor rolled back. Undo data in this state will remain in the undo tablespace indefinitely. It will never be removed based on the retention period.

Once data has been committed, it enters the unexpired state. This effectively starts the timer running on the retention-period clock. It will remain in this state until the retention period has elapsed.

When the retention period has elapsed, the data will enter the expired state, meaning the data has been retained for the requested amount of time. The expired state tells Oracle that the data is now eligible to be purged from the Undo tablespace to make room for new data.

By keeping track of the state of all undo data, AUM can manage the space and ensure adequate space for new transactions. But suppose a new transaction begins when the undo tablespace is full and none of the undo data is expired? Oracle will attempt to extend the tablespace (if it is enabled) to make more space. If auto-extend is not possible (because it is not enabled or it has reached the MAXSIZE), Oracle must make a choice. It

356  Chapter 9  n  Understanding Flashback Technology

can either forego the retention period by removing unexpired data or honor the retention period, thereby causing the new transaction to fail. By default, Oracle will choose to sacrifice the unexpired data to make room for the new transaction.

In the following sections, you will learn how an undo retention period can be established and what effect it will have. You will also learn about the power and the pitfalls of guaranteeing undo retention.

Establishing an Undo Retention Period

As part of its management duties, AUM monitors system activity and available undo space to derive an optimum undo retention time. This setting may change over time as activity and available space change. Since AUM takes care of this, there is no action required by the DBA to establish an undo retention period.

However, AUM will also allow you to specify the retention period yourself. It can be done by setting the UNDO_RETENTION initialization parameter, as shown here:

SQL> ALTER SYSTEM SET UNDO_RETENTION=14400

SCOPE=BOTH;

System altered

When AUM encounters a manual undo retention setting, it will honor the setting only if it is using an auto-extending tablespace. If AUM is configured with a fixed-size tablespace, it will ignore the setting and will instead follow its default behavior of dynamically setting the retention time based on system activity and available disk space.

Because of this behavior, it is highly recommended that you allow AUM to use an autoextending undo tablespace. If you are concerned that an errant long-running query could cause it to extend too much, use the MAXSIZE option to limit its growth.

Guaranteeing Retention

As mentioned previously, Oracle will violate the undo retention period if it is required to prevent transactions from failing. For most users, it is a fair trade-off. However, there may be situations where it is more important to guarantee the retention period, even at

the expense of failed transactions. This can be accomplished by specifying the RETENTION GUARANTEE clause on the undo tablespace. This can either be done when initially creating the tablespace or by altering the tablespace, as shown here:

SQL> ALTER TABLESPACE UNDOTBS1 RETENTION

GUARANTEE;

System altered

When the retention guarantee clause is invoked on the undo tablespace, Oracle will never remove unexpired data from the undo tablespace, even if it means allowing new transactions to fail.