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 1

Description Create undo tablespace Yes

10.1 Yes

10.2 Yes

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. which indicates that the before image has been overwritten. Long running queries that need to retain older undo data for consistency purposes . then undo_retention keep decreasing to satisfy more and more space. there is a possibility that some data it needs has been over written by other new transactions. When a transaction commits the undo data is not required anymore. But Looks like that is not the case if the undo_tablespace reaches its maxsize and can not grow any further.it will reuse it. If the datafiles are autoextend or the undo tablespace is big enough all by itself. 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. this would produce the "snapshot too old" error message.2 3 Set undo_management=auto Set undo_retention Yes Yes Yes optional Yes Yes/No I was under the impression that. If there is space pressure. however this is not guaranteed. if the undo_retention=1800. it will not reuse it. the undo data however will stay in the undo tablespace unless space is required then newer transactions will overwrite it.if there is no way to get the undo space AND the undo space can be reused . Undo data can be in 3 states. I can "always" flashback 30 minutes into the past or TS will retain undo data for at least for 30 minutes. . Undo retention can be thought of as a "desire" -. 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.

the default is not to set the guarantee retention period. if the next extent expired then wrap in the the next extent and return the first block. Otherwise. . required to support undo_retention interval Will expire after undo_retention period passed or undo tablespace space pressure unless guaranted option is set Committed undo information (expired) undo information that is no longer needed Always There are times when you want to guarantee the undo retention at any cost even if it means transactions fail.State Active or uncommitted undo information Description undo data that supports active transactions and required in the event of rollback When undo data over written Never Committed undo information (unexpired) unexpired undo. 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. 2. 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.

unless retention guarantee is enabled. 4. 6.3. less than UNDO_RETENTION if space is low. If a free extent is available then allocate it to the transaction table and return the first block in the new extent. If there is no free extent available and we cannot autoextent datafile then steal an expired extent from another undo segment. The database may overwrite unexpired undo information when tablespace space becomes low. Current Undo retention: Select TUNED_UNDORETENTION from V$UNDOSTAT where rownum <2. instead of overwriting unexpired undo information. the database may begin to overwrite unexpired undo information. Use for Flashback purposes when GUARANTEE enabled. Return the first free block of the extent. Deallocate the extent from the from another undo segment and add it to the current undo segment. . the tablespace auto-extends. If all extents are currently busy(they contains uncommitted information) go to the step 7. 7. when the maximum size is reached. 8. or. 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. For AUTOEXTEND undo tablespace. This only happen tbs is fixed size. Current undo retention period may be automatically tuned to be greater than UNDO_RETENTION. If the next extent does not expired then get space from the UNDO tablespace. If it still fails because there are no extents with expired status then try to reuse unexpired extents from own undo segment. When space is low. If the MAXSIZE clause is specified for an auto-extending undo tablespace. Steal unexpired extents from another undo segment. Otherwise wrap into the next extent. the database attempts to honor the minimum retention period specified by UNDO_RETENTION.

expired blocks released/stolen from other undo segments EXPBLKREUCNT.uR .expired blocks Stolen from other undo segments EXPBLKRELCNT.unexpired extents stolen from other transactions UNXPBLKRELCNT.uS .Monitor v$undostat in case of STO(snapshot too old)/OOS (Out of space): UNXPSTEALCNT.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 blocks(extents) were stolen from other undo segments to satisfy space requests The number of unexpired blocks removed from undo segments to be used by other transactions The number of unexpired undo blocks reused by transactions The number of attempts when expired extents were stolen from other undo UNXPSTEALCNT UNXPBLKRELCNT UNXPBLKREUCNT EXPSTEALCNT .unexpired blocks reused by other transactions EXPSTEALCNT.STO – Snapshot too old error(ORA-01555) NOSPACEERRCNT– OOS – all undo space used by active transaction and no free space available MAXQUERYLEN.uU .eR .eS .eU .expired blocks reused with in same undo segment SSOLDERRCNT.unexpired blocks released/stolen by certain undo segments UNXPBLKREUCNT.

EXPBLKRELCNT EXPBLKREUCNT SSOLDERRCNT NOSPACEERRCNT segments to satisfy a space requests The number of expired extents(blocks) stolen from other undo segments to satisfy a space request The number of expired undo blocks reused within the same undo segments The number of ORA-1555 errors that occurred during the interval 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. MMON will calculate the MAXQUERYLEN every 30 sec interval. Most of time. Sometime. 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. user needs to tune the select query if UNDO tablespace sized properly. MMON . 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. UNXPBLKREUCNT from V$UNDOSTAT. 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. you can see the error has occurred for SELECT statement after running hours which is more than undo_retention time. Based upon the MAXQUERYLEN. you would like to use retention guarantee to avoid ORA-1555 but make sure you have enough UNDO TS size.UNXPBLKRELCNT. (WRH$_UNDOSTAT) When the columns UNXPSTEALCNT through EXPBLKREUCNT hold non-zero values.

and additional extents are 64MB When the number of concurrent transactions exceeds the number of online undo segments. next 63 extents are 1MB in size. The basic algorithms is that first 16 extents are 64KB in size. undo tablespace will contain 10 undo segments and number of additional segment brought online based on session parameter. For a fixed size undo tablespace. they are the first ones to be used. Foreground processes signal SMON to shrink undo segments when more undo space is needed. the database calculates the maximum undo retention period based on database statistics and on the size of the undo tablespace. more segments are brought online. If there are offline segments in the current undo tablespace. rather than tuning based on 100% of the tablespace size. At the instance startup. new ones are added as long as sufficient space exists within the tablespace’s datafiles. Every 12 hours SMON shrinks idled undo segments. the database tunes the undo retention period based on 85% of the tablespace size. For optimal undo management. Best Practice: Don’t set UNDO_RETENTION and used fixed undo tbs Configuring Undo Tablespace: . next 120 extents are 8MB in size. The algorithm is roughly 1 undo segment for each 5 sessions. TUNED_UNDORETENTION = MAXQUERYLEN + 300 Sec. That means the new UNDO RETENTION will be set toTUNED_UNDORETENTION.decides the TUNED_UNDORETENTION. If no offline segments exist. Undo segments are sized according to auto allocate algorithm for locally managed 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 .

Sign up to vote on this title
UsefulNot useful