Database Administration

Unit 5: Concurrency, Backups and Auditing

5.1 Undo Management:

 Undo Data Overview
 Monitor and Administer Undo
 Configure Undo Retention
 Specify the Retention Period
 Guarantee Undo Retention
 Retention Period for Flashback Queries
 Switch Undo Tablespaces
 View Undo Space Information
 use the Undo Advisor
 Size the Undo Tablespace
 Alter an Undo Tablespace to a Fixed Size
What is Undo Data ?

In oracle, Undo data, also known as rollback data, is information stored in the database that records the changes made
by transactions. The information allows database to undo changes in case of rollback. Undo data is pre-modified data
that is recorded or captured for all transactions which changes data.

In other words, Oracle creates and manages data that is used to roll back, or undo, changes to the database. Such
information consists of records of the actions of transactions, primarily before they are committed. These records are
collectively referred to as undo.

Undo records are used to undo changes that were made to the database by the uncommitted transaction. Undo records
provide read consistency by maintaining the before image of the data for users who are accessing the data at the same
time that another user is changing it. During database recovery, undo records are used to undo any uncommitted
changes applied from the redo log to the data files.
Why we need Undo Data ?
1.Rollback Operations: Undo data allows transactions to be rolled back to their previous state in case of a rollback
operation (e.g., due to an error or explicit rollback command).
2.Recovery: Undo data is essential for database recovery operations, such as rolling forward or rolling back changes
during instance recovery or media recovery.
3.Read Consistency: Undo data provides read consistency by maintaining previous versions of data. It ensures that
queries return consistent results, even when other transactions are modifying the data concurrently.
4.PITR using Oracle Flashback Query and Recovery from logical corruptions using oracle flashback features.

Undo Data Components ?

1.Undo Segments: Undo segments are allocated in the undo tablespace to store undo data. They consist of one or more
extents and are managed by Oracle to accommodate transactional changes.
2.Undo Tablespaces: Undo data is stored in dedicated undo tablespaces, which are separate from other database
tablespaces. These tablespaces are used exclusively for storing undo information.
 Undo Management
Oracle offers an automated system known as automatic undo management to handle undo data and space. With this
feature, the database takes care of managing undo segments within an undo tablespace.
Automatic undo management is the default mode for newly installed databases. When you create a database using
Database Configuration Assistant (DBCA), an auto-extending undo tablespace named UNDOTBS1 is automatically
generated.
UNDO_MANAGEMENT=AUTO , If MANUAL, sets manual undo management mode. Otherwise
SELECT tablespace_name, file_name, bytes, maxbytes FROM dba_data_files WHERE tablespace_name = 'your_undo_tablespace’;

SQL>Show parameters undo; Gives values on UNDO_MANAGEMENT, UNDO_RETENTION and UNDO_TABLESPACE

You can also explicitly create an undo tablespace. Upon starting the database instance, Oracle automatically selects the
first available undo tablespace. If no undo tablespace is available, the instance starts without one, and undo records are
stored in the SYSTEM tablespace. This practice is not recommended, and a warning message is written to the alert log
file.
If the database contains multiple undo tablespaces, you can optionally specify which one to use at startup by setting the
UNDO_TABLESPACE initialization parameter. For example:
UNDO_TABLESPACE = undotbs_01
undotbs_01
If the specified tablespace does not exist, the STARTUP command will fail. The UNDO_TABLESPACE parameter can also be
used to assign a specific undo tablespace to an instance in an Oracle Real Application Clusters (RAC) environment.
Alternatively, the database can operate in manual undo management mode, where undo space is managed through
rollback segments without using an undo tablespace.
1.Create UNDO Tablespace :
Administering Undo Data
•You can create a specific undo tablespace using the UNDO TABLESPACE clause of the CREATE DATABASE statement OR The CREATE
UNDO TABLESPACE statement is the same as the CREATE TABLESPACE statement

ALTER TABLESPACE undotbs_01 ADD DATAFILE '/u01/oracle/rbdb1/undo0102.dbf' AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;
CREATE DATABASE rbdb1
CONTROLFILE REUSE
.
.
.
UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';
2.Undo Tablespace Management:
You can alter an undo tablespaces using the ALTER TABLESPACE statement.
However, since most aspects of undo tablespaces are system managed, you need only be concerned with the following
actions:
•Adding a data file
•Renaming a data file
•Bringing a data file online or taking it offline
•Beginning or ending an open backup on a data file
•Enabling and disabling undo retention guarantee
These are also the only attributes you are permitted to alter.
If an undo tablespace runs out of space, or you want to prevent it from doing so, you can add more files to it or resize
existing data files.
ALTER TABLESPACE undotbs_01 ADD DATAFILE '/u01/oracle/rbdb1/undo0102.dbf' AUTOEXTEND ON NEXT 1M
MAXSIZE UNLIMITED;
 Administering Undo Data
2.Automatic Undo Management (AUM):
•Enable Automatic Undo Management (AUM) to let Oracle manage undo space automatically. You can enable AUM using the following
command: ALTER SYSTEM SET undo_management = 'AUTO';
3.Undo Retention Adjustment:
•Adjust the undo retention parameter (UNDO_RETENTION) to ensure that undo data is retained long enough to support the needs of
your application.
4.Monitoring and Tuning Undo Performance:
•Regularly monitor undo performance using AWR reports or Oracle Enterprise Manager.
•Tune undo performance by adjusting parameters such as UNDO_RETENTION, UNDOTBS1, and UNDO_TABLESPACE based on workload
requirements.
5.Monitoring and Resolving Undo Space Issues:
•Monitor for undo space issues such as space exhaustion or undo tablespace full events.
•Resolve undo space issues by adding additional data files to the undo tablespace, increasing the size of existing data files, or adjusting
undo retention.
6.Undo Advisor:
•Use the Undo Advisor to estimate the undo tablespace size and recommend changes to undo retention settings based on workload
characteristics.
 Configure Fixed Size Undo
Automatic tuning of undo retention typically achieves better results with a fixed-size undo tablespace. If you decide to use a fixed-
size undo tablespace, then the Undo Advisor can help you estimate needed capacity. You can access the Undo Advisor through
Oracle Enterprise Manager Database Express (EM Express) or through the DBMS_ADVISOR PL/SQL package.

The Undo Advisor relies for its analysis on data collected in the Automatic Workload Repository (AWR). It is therefore important
that the AWR have adequate workload statistics available so that the Undo Advisor can make accurate recommendations. For
newly created databases, adequate statistics may not be available immediately. In such cases, continue to use the default auto-
extending undo tablespace until at least one workload cycle completes.
An adjustment to the collection interval and retention period for AWR statistics can affect the precision and the type of
recommendations that the advisor produces
To use the Undo Advisor, you first estimate these two values:
•The length of your expected longest running query
After the database has completed a workload cycle, you can view the Longest Running Query field on the System
Activity subpage of the Automatic Undo Management page.
•The longest interval that you will require for Oracle Flashback operations For example, if you expect to run Oracle
Flashback queries for up to 48 hours in the past, your Oracle Flashback requirement is 48 hours. We ca then take the
maximum of these two values and use that value as input to the Undo Advisor. Running the Undo Advisor does not alter
the size of the undo tablespace. The advisor just returns a recommendation. You must use ALTER DATABASE statements
to change the tablespace data files to fixed sizes.
The following example assumes that the undo tablespace has one auto-extending data file named undotbs.dbf. The example
changes the tablespace to a fixed size of 300MB.
ALTER DATABASE DATAFILE '/oracle/dbs/undotbs.dbf' RESIZE 300M;
ALTER DATABASE DATAFILE '/oracle/dbs/undotbs.dbf' AUTOEXTEND OFF;
 Monitoring Undo Data
• Undo Tablespace Size:
Regularly monitor the size of the undo tablespace to ensure it has sufficient space to accommodate undo data
for all active transactions. You can check this using the following query:

SELECT tablespace_name, file_name, bytes/1024/1024, maxbytes /1024/1024 FROM dba_data_files WHERE

tablespace_name = 'your_undo_tablespace’;

• Undo Retention:
Monitor undo retention to ensure that it's set appropriately based on the database workload. Use the
following query to check the undo retention time:

SELECT name, value FROM v$parameter WHERE name = 'undo_retention’;

• Undo Usage Statistics:

Monitor undo usage statistics to understand the rate at which undo data is generated and consumed. Use the
following query to view undo usage statistics:

SELECT * FROM v$undostat;

 Undo Retention
The undo retention period is the minimum duration during which Oracle Database tries to keep old undo information
before replacing it.

Undo Retention Period

When automatic undo management is enabled, Oracle Database always maintains a current undo retention period. This
period represents the minimum duration for which Oracle Database retains old undo information before considering it
for overwrite.
SELECT name, value FROM v$parameter WHERE name = 'undo_retention';
After a transaction is committed, undo data becomes unnecessary for rollback or transaction recovery purposes.
However, for consistent read purposes, long-running queries may require this old undo information to produce older
versions of data blocks. Additionally, the success of several Oracle Flashback features also relies on the availability of
older undo information. Hence, it is desirable to retain the old undo information for as long as possible.
Undo information that is older than the current undo retention period is considered expired, and its space becomes
available to be overwritten by new transactions. On the other hand, undo information with an age less than the current
undo retention period is considered unexpired and is retained for consistent read and Oracle Flashback operations.
 Undo Retention Period
Oracle Database automatically adjusts the undo retention period based on the configuration of the undo tablespace.
•When the undo tablespace is configured with the AUTOEXTEND option, the database dynamically adjusts the undo
retention period to be slightly longer than the longest-running active query on the system. However, this may not
always be sufficient to support Oracle Flashback operations. If snapshot too old errors occur during Oracle Flashback
operations, it indicates that additional undo data is needed. To address this, you can set the UNDO_RETENTION
parameter to accommodate the longest expected Oracle Flashback operation or convert the undo tablespace to a
fixed size.
•In the case of a fixed-size undo tablespace, the database optimizes the undo retention period to ensure the best
possible retention given the tablespace size and current system load. This typically results in a significantly longer
retention period than the duration of the longest-running active query.
If you choose to switch the undo tablespace to a fixed size, it's crucial to select a size that is large enough.
Otherwise, you may encounter errors such as DML failures due to insufficient space for undo data or snapshot too
old errors for long-running queries, indicating insufficient undo data for read consistency.
 Undo Retention Period
Oracle Database automatically adjusts the undo retention period based on undo tablespace size and system activity. You
can optionally set a minimum undo retention period (in seconds) by configuring the UNDO_RETENTION initialization
parameter.
The impact of the UNDO_RETENTION parameter on undo retention is as follows:
1. For a fixed-size undo tablespace, the UNDO_RETENTION parameter is disregarded. The database always tunes the undo
retention period based on system activity and undo tablespace size.
2. For an auto-extending undo tablespace, the database attempts to honor the minimum retention period specified by
UNDO_RETENTION. If space is low, the tablespace auto-extends instead of overwriting unexpired undo information.
However, if the maximum size is reached (specified by MAXSIZE), the database may begin to overwrite unexpired undo
information. The UNDOTBS1 tablespace created by DBCA is auto-extending.
ALTER SYSTEM SET UNDO_RETENTION = 3600; -- for example, set to 1 hour
ALTER SYSTEM SET UNDO_RETENTION = 3600;
Undo Retention Period
Retention Period in oracle database can be done automatically or manually.

1. Using Automatic Undo Management

 Determine the appropriate undo retention period based on your application's needs. This can be estimated by considering the
longest-running query or the duration required for Oracle Flashback operations.
 Enable automatic undo management if it's not already enabled. This is the default mode for Oracle databases. ALTER SYSTEM
SET undo_management = 'AUTO' SCOPE=SPFILE;
 Configure the undo retention period using the UNDO_RETENTION initialization parameter. Set it to the desired
value in seconds. ALTER SYSTEM SET undo_retention = 3600;
 Restart the database instance for the changes to take effect. SHUTDOWN IMMEDIATE; STARTUP;

2. Using Manual Undo Management

 If you're using manual undo management, you'll need to create and manage rollback segments instead of undo
tablespaces.
 To set the undo retention period in manual mode, you need to ensure that your rollback segments have enough
space to retain undo data for the desired duration.
 You can specify the retention period for individual rollback segments using the RETENTION clause when creating or
altering the rollback segments.
 However, it's recommended to use automatic undo management for better manageability and performance.
Guarantee Retention Period
In oracle database to ensure the success of long-running queries or Oracle Flashback operations, you have the option to
enable retention guarantee.

When retention guarantee is enabled, the specified minimum undo retention is assured; the database never overwrites
unexpired undo data, even if it leads to transaction failures due to insufficient space in the undo tablespace. By contrast, if
retention guarantee is not enabled, the database may overwrite unexpired undo data when space is low, potentially
reducing the overall undo retention for the system. This option is disabled by default.

Enabling retention guarantee can result in multiple DML operations failing. Exercise caution when enabling this feature.

Retention guarantee can be enabled by specifying the RETENTION GUARANTEE clause for the undo tablespace when
creating it using either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Alternatively, you can specify this
clause later in an ALTER TABLESPACE statement. You can disable retention guarantee using the RETENTION NOGUARANTEE
clause.
To determine the retention guarantee setting for the undo tablespace, you can query the DBA_TABLESPACES view. The
RETENTION column contains values of GUARANTEE, NOGUARANTEE, or NOT APPLY, with NOT APPLY used for tablespaces
other than the undo tablespace.
Guarantee Retention Period
In oracle database to ensure the success of long-running queries or Oracle Flashback operations, you have the option to
enable retention guarantee.

When retention guarantee is enabled, the specified minimum undo retention is assured; the database never overwrites
unexpired undo data, even if it leads to transaction failures due to insufficient space in the undo tablespace. By contrast, if
retention guarantee is not enabled, the database may overwrite unexpired undo data when space is low, potentially
reducing the overall undo retention for the system. This option is disabled by default.

Enabling retention guarantee can result in multiple DML operations failing. Exercise caution when enabling this feature.

Retention guarantee can be enabled by specifying the RETENTION GUARANTEE clause for the undo tablespace when
creating it using either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Alternatively, you can specify this
clause later in an ALTER TABLESPACE statement. You can disable retention guarantee using the RETENTION NOGUARANTEE
clause.
To determine the retention guarantee setting for the undo tablespace, you can query the DBA_TABLESPACES view. The
RETENTION column contains values of GUARANTEE, NOGUARANTEE, or NOT APPLY, with NOT APPLY used for tablespaces
other than the undo tablespace.