0% found this document useful (0 votes)
9 views4 pages

Oracle Database Undo Space

The Oracle Undo Tablespace is essential for maintaining rollback information and ensuring read consistency in the database. It consists of three types of extents: ACTIVE, EXPIRED, and UNEXPIRED, with specific roles in transaction management. Management operations include adding data files, switching tablespaces, and setting retention parameters to prevent errors related to undo space usage.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views4 pages

Oracle Database Undo Space

The Oracle Undo Tablespace is essential for maintaining rollback information and ensuring read consistency in the database. It consists of three types of extents: ACTIVE, EXPIRED, and UNEXPIRED, with specific roles in transaction management. Management operations include adding data files, switching tablespaces, and setting retention parameters to prevent errors related to undo space usage.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

ORACLE UNDO

TABLESPACE
MANAGEMENT.
Undo tablespace contains before-images of data written to
the database.
ORACLE UNDO TABLESPACE MANAGEMENT.

Oracle Database Undo space.


Oracle Database must have a method of maintaining information 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.

The Undo tablespace is used for several features:

 ROLLBACK.
 READ CONSISTENCY.
 FLASHBACK technology.

There are three states or types of extents in the Undo tablespace: ACTIVE, EXPIRED and UNEXPIRED.

1> ACTIVE
Active undo extents are used by transactions and will always be active, because they are needed for
Rollback. The UNDO_RETENTION setting is not used here, because one can not say something like: ‘after
900 seconds you are not allowed to rollback anymore…’
You will get ‘ORA-30036 unable to extend segment in Undo tablespace’errors when no more space is
left to store ACTIVE Undo. This will automatically rollback the transaction causing it.
The NOSPACEERRCNT column in V$UNDOSTAT is a good indication how many times this has occurred.

2> EXPIRED
Expired extents are not used by transactions, the data in these extends is committed and the
UNDO_RETENTION time has passed, so it is not needed for Read Consistency.

3> UNEXPIRED
Unexpired extents are non-active extents that still honour UNDO_RETENTION. The transactions belonging
to these undo extents are committed, but the retention time has not passed: You still want/need these
for Read Consistency!
ORACLE UNDO TABLESPACE MANAGEMENT.

SHRINK UNDO TABLESPACE


The Undo tablespace can only grow larger, but it can not shrink by itself. If you want to shrink the Undo
tablespace, create a new one and set the UNDO_TABLESPACE parameter to the new Undo tablespace.

RETENTION GUARANTEED
When you create the Undo tablespace with the RETENTION GUARANTEE option, UNEXPIRED Undo
information will never get stolen. Set this if you want to guarantee Read Consistency or when you want
to use Flashback with a guaranteed point-in-time!

select retention from dba_tablespaces where tablespace_name='UNDOTBS1';

Beware that when this is set, the chance of ORA-30036 errors increases. It’s your choice: ORA-30036 or
ORA-01555…

SETTING THE UNDO_RETENTION PARAMETER TO THE LONGEST RUNNING QUERY


A good practice is to set the UNDO_RETENTION parameter to the longest running query,
to avoid ORA-01555 (read consistency) errors. To get a good indication about the longest running query
in the last 7 days, try:

select max(maxquerylen) from v$undostat;:

DETAILS FOR UNDO EXTENTS:


select status,
round(sum_bytes / (1024*1024), 0) as MB,
round((sum_bytes / undo_size) * 100, 0) as PERC
from
(
select status, sum(bytes) sum_bytes
fromdba_undo_extents
group by status
),
(
select sum(a.bytes) undo_size
fromdba_tablespaces c
joinv$tablespace b on b.name = c.tablespace_name
joinv$datafile a on a.ts# = b.ts#
wherec.contents = 'UNDO'
andc.status = 'ONLINE'
);
ORACLE UNDO TABLESPACE MANAGEMENT.

FOLLOWING SET OF OPERATIONS CAN BE PERFORMED ON UNDO TABLESPACE, SINCE MOST


ASPECTS OF UNDO TABLESPACE ARE SYSTEM GOVERNED.

- 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

SWITCHING UNDO TABLESPACES.

You can switch from using one undo tablespace to another. Because the UNDO_TABLESPACE
initialization parameter is a dynamic parameter, the ALTER SYSTEM SET statement can be used to
assign a new undo tablespace.

The following statement switches to a new undo tablespace:

ALTER SYSTEM SET UNDO_TABLESPACE = UNDO_TBS1;

When your UNDO Tablespace has increased in size, you need to Create new Undo tablespace ,
make it as default and drop the old one. You can only drop Old undo tablespace when there are no
active extents in it.

You might also like