Explores Undo Management:

Benefit from this session:

Will have better understanding, how undo information stored in undo TS and how long.
Will help to find if your undo tablespace under pressure or oversized.
Will help to understand Undo Block allocation algorithm
Use auto extent TS or fixed sized TS for UNDO?
Do we need to set UNDO_RETENTION in init.ora? Y/N
What to look in case of STO (snapshot too old)/OOS(out of space) issues?

Benefit of AUM:

Dynamic: Adapts to changing workload

Automatic performance tuning
Predictable consistent-read
Predictable Flashback feature usage

AUM Administration:

Steps Description 9.1.9.2 10.1 10.2

1 Create undo tablespace Yes Yes Yes

2 Set undo_management=auto Yes Yes Yes

3 Set undo_retention Yes optional Yes/No

I was under the impression that, if the undo_retention=1800, I can "always"

flashback 30 minutes into the past or TS will retain undo data for at least for 30
minutes.

But Looks like that is not the case if the undo_tablespace reaches its maxsize and can not
grow any further, and hence the undo space will try to steal/reused first expired block and
then it will try to steal unexpired extent/reused unexpired block. If there is space pressure,
then undo_retention keep decreasing to satisfy more and more space.

When a transaction commits the undo data is not required anymore, the undo data
however will stay in the undo tablespace unless space is required then newer transactions
will overwrite it. Long running queries that need to retain older undo data for consistency
purposes , there is a possibility that some data it needs has been over written by other new
transactions, this would produce the "snapshot too old" error message, which indicates
that the before image has been overwritten. To prevent this oracle uses the
undo_retention system parameter which try and keeps the data in the undo tablespace for
as long as possible meeting the undo_retention target, however this is not guaranteed.
Undo data can be in 3 states.

Undo space will go to 100% in order to satisfy your undo retention and then and only
then will it start stealing expired or unexpired extents from itself and moving them
around.

Undo retention can be thought of as a "desire" -- if there is no way to get the undo
space AND the undo space can be reused - it will reuse it. If the datafiles are
autoextend or the undo tablespace is big enough all by itself, it will not reuse it.
State Description When undo data over written

Active or uncommitted undo data that Never

undo information supports active

transactions and
required in the
event of

rollback

Committed undo unexpired undo, Will expire after undo_retention period

information required passed or undo tablespace space pressure
(unexpired) unless guaranted option is set
to support
undo_retention
interval

Committed undo undo information Always

information (expired) that is no longer

needed

There are times when you want to guarantee the undo retention at any cost even if it
means transactions fail, the option retention guarantee will guarantee that the data will
stay in the undo tablespace until the interval has expired even if there are space pressure
problems in the undo tablespace, the default is not to set the guarantee retention period.

The Undo Block allocation algorithm in Automatic Undo Management is the following:

1. If the current extent has more free blocks then the next free block is allocated.

2. Otherwise, if the next extent expired then wrap in the the next extent and return the
first block.
3. If the next extent does not expired then get space from the UNDO tablespace. If a free
extent is available then allocate it to the transaction table and return the first block in the
new extent.

4. If there is no free extent available and we cannot autoextent datafile then steal an
expired extent from another undo segment. Deallocate the extent from the from another
undo segment and add it to the current undo segment. Return the first free block of the
extent.

6. If it still fails because there are no extents with expired status then try to reuse
unexpired extents from own undo segment. If all extents are currently busy(they contains
uncommitted information) go to the step 7. Otherwise wrap into the next extent.

7. Steal unexpired extents from another undo segment.

8. If all the above fails then return ORA-30036 unable to extend segment by %s in undo
tablespace '%s'

UNDO_RETENTION Parameter:

The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace. The
database may overwrite unexpired undo information when tablespace space becomes
low.
For AUTOEXTEND undo tablespace, the database attempts to honor the minimum
retention period specified by UNDO_RETENTION. When space is low, instead of
overwriting unexpired undo information, the tablespace auto-extends. If the MAXSIZE
clause is specified for an auto-extending undo tablespace, when the maximum size is
reached, the database may begin to overwrite unexpired undo information.
Use for Flashback purposes when GUARANTEE enabled.
Current Undo retention: Select TUNED_UNDORETENTION from V$UNDOSTAT where
rownum <2;
Current undo retention period may be automatically tuned to be greater than
UNDO_RETENTION, or, unless retention guarantee is enabled, less than
UNDO_RETENTION if space is low. This only happen tbs is fixed size.
Monitor v$undostat in case of STO(snapshot too old)/OOS (Out of space):

UNXPSTEALCNT- uS - unexpired extents stolen from other transactions

UNXPBLKRELCNT- uR - unexpired blocks released/stolen by certain undo segments

UNXPBLKREUCNT- uU - unexpired blocks reused by other transactions

EXPSTEALCNT- eS - expired blocks Stolen from other undo segments

EXPBLKRELCNT- eR - expired blocks released/stolen from other undo segments

EXPBLKREUCNT- eU - expired blocks reused with in same undo segment

SSOLDERRCNT- STO – Snapshot too old error(ORA-01555)

NOSPACEERRCNT– OOS – all undo space used by active transaction and no free space
available

MAXQUERYLEN- Identifies the length of the longest query (in seconds) executed in the
instance during the period

The following table explains other useful columns of V$UNDOSTAT view

The number of attempts when unexpired

UNXPSTEALCNT blocks(extents) were stolen from other undo
segments to satisfy space requests
The number of unexpired blocks removed
UNXPBLKRELCNT from undo segments to be used by other
transactions
The number of unexpired undo blocks
UNXPBLKREUCNT
reused by transactions
EXPSTEALCNT The number of attempts when expired
extents were stolen from other undo
 segments to satisfy a space requests
The number of expired extents(blocks)
EXPBLKRELCNT stolen from other undo segments to satisfy a
space request
The number of expired undo blocks reused
EXPBLKREUCNT
within the same undo segments
The number of ORA-1555 errors that
SSOLDERRCNT
occurred during the interval
NOSPACEERRCNT The number of Out-of-Space errors

Unexpired undo reuse/stealing –tablespace too small

Stealing: unexpired Undo extent of other segment used
Reuse: Number of unexpired undo blocks reused by transactions
select UNXPSTEALCNT,UNXPBLKRELCNT, UNXPBLKREUCNT from V$UNDOSTAT;
(WRH$_UNDOSTAT)
When the columns UNXPSTEALCNT through EXPBLKREUCNT hold non-zero values,
it is an indication of space pressure.
V$UNDOSTAT: 10 minute snapshots for 4 days
WRH$_UNDOSTAT: based on AWR retention policy (7 days by default)

After analyzing the session that hits the ORA-1555 error, you can see the error has
occurred for SELECT statement after running hours which is more than undo_retention
time. Most of time, user needs to tune the select query if UNDO tablespace sized
properly. Sometime, you would like to use retention guarantee to avoid ORA-1555 but
make sure you have enough UNDO TS size.

Special Notes about Using AUM:

A transaction can span several extents but must remain in the same rollback segment
throughout the duration of the transaction. One undo segment can have only one active
transaction
If UNDO_MANAGEMENT=AUTO and auto extent tablespace (no matter the setting for
UNDO_RETENTION) automatic undo tuning will be used. MMON will calculate the
MAXQUERYLEN every 30 sec interval. Based upon the MAXQUERYLEN, MMON
decides the TUNED_UNDORETENTION. That means the new UNDO RETENTION
will be set toTUNED_UNDORETENTION.
TUNED_UNDORETENTION = MAXQUERYLEN + 300 Sec.
For a fixed size undo tablespace, the database calculates the maximum undo retention
period based on database statistics and on the size of the undo tablespace. For optimal
undo management, rather than tuning based on 100% of the tablespace size, the database
tunes the undo retention period based on 85% of the tablespace size.
Every 12 hours SMON shrinks idled undo segments. Foreground processes signal SMON
to shrink undo segments when more undo space is needed.
At the instance startup, undo tablespace will contain 10 undo segments and number of
additional segment brought online based on session parameter. The algorithm is roughly
1 undo segment for each 5 sessions.
Undo segments are sized according to auto allocate algorithm for locally managed
tablespace. The basic algorithms is that

first 16 extents are 64KB in size.

next 63 extents are 1MB in size.

next 120 extents are 8MB in size.

and additional extents are 64MB

When the number of concurrent transactions exceeds the number of online undo
segments, more segments are brought online. If there are offline segments in the current
undo tablespace, they are the first ones to be used. If no offline segments exist, new ones
are added as long as sufficient space exists within the tablespace’s datafiles.

Best Practice: Don’t set UNDO_RETENTION and used

fixed undo tbs

Configuring Undo Tablespace:

Initial Setting: New System

Undo generation statistics not available

Undo Advisor not very accurate
Enable AUTOEXTEND datafile attribute
Auto-tuning of undo retention will grow tablespace as needed
Final Setting: Steady State

Disable AUTOEXTEND to isolate from runaway queries

Run Undo Advisor to determine tablespace size
Add 20% (safety margin) and fix tablespace size