The possible causes for Excessive Undo generation

1)Transactions with huge undo.
——————————-
It is obvious to see high undo usage when there are huge transactions. If that is going to be the case this growth should be expected behavior.

2)The Higher value setting of UNDO_RETENTION.
————————————————
The higher value of UNDO_RETENTION will increase much undo. As it can’t be marked undo extents as EXPIRED till the duration of the UNDO_RETENTION.

3)Autoextensible mode of Undo data files.
————————————————–
Disabling the auto extensible mode of the datafiles of active undo tablespace will reuse the UNEXPIRED extents when undo tablespace suffer in space pressure.If they are set to auto extensible, it will not reuse the space for the new transaction. In such scenarios new transaction will allocate a space and your undo tablespace will start growing.

4)Undo tablespace is using Autoallocate option:
———————————————-
UNDO is using auto allocate option of LMT. As the number of the extents goes up, the extent size will be increased too.When the number is extents reaches hundred the extent size will be bigger. If it reaches thousands it will be even more bigger.If you know the size of most of your transactions you can use UNIFORM rather than AUTO.

Expert are always welcome for their valuable comment or suggestion for the above post.

Related Post:

https://samadhandba.wordpress.com/2011/01/04/oversize-of-datatype-varchar2-causes-performance-issue/

https://samadhandba.wordpress.com/2011/02/16/what-and-when-index-scans-is-used/

https://samadhandba.wordpress.com/2011/02/16/index-skip-full-fast-full-index-index-joins-bitmap-indexes-scan/

https://samadhandba.wordpress.com/2011/02/14/sample-table-scans-in-oracle/

https://samadhandba.wordpress.com/2011/02/14/when-you-would-make-index-and-when-not/

https://samadhandba.wordpress.com/2011/02/14/optimize-data-access-path-in-oracle-2/

https://samadhandba.wordpress.com/2011/02/13/troubleshoot-unusable-index-in-oracle/

https://samadhandba.wordpress.com/2011/02/13/the-possible-causes-for-excessive-undo-generation-2/

https://samadhandba.wordpress.com/2011/02/13/three-basic-steps-of-sql-tuning/

https://samadhandba.wordpress.com/2011/02/13/goals-for-tuning-2/

https://samadhandba.wordpress.com/2011/02/04/ora-12054-cannot-set-the-on-commit-refresh-attribute-for-the-materialized-view/

Read Full Post »

The possible causes for Excessive Undo generation

1)Transactions with huge undo.
——————————-
It is obvious to see high undo usage when there are huge transactions. If that is going to be the case this growth should be expected behavior.

2)The Higher value setting of UNDO_RETENTION.
————————————————
The higher value of UNDO_RETENTION will increase much undo. As it can’t be marked undo extents as EXPIRED till the duration of the UNDO_RETENTION.

3)Autoextensible mode of Undo data files.
————————————————–
Disabling the auto extensible mode of the datafiles of active undo tablespace will reuse the UNEXPIRED extents when undo tablespace suffer in space pressure.If they are set to auto extensible, it will not reuse the space for the new transaction. In such scenarios new transaction will allocate a space and your undo tablespace will start growing.

4)Undo tablespace is using Autoallocate option:
———————————————-
UNDO is using auto allocate option of LMT. As the number of the extents goes up, the extent size will be increased too.When the number is extents reaches hundred the extent size will be bigger. If it reaches thousands it will be even more bigger.If you know the size of most of your transactions you can use UNIFORM rather than AUTO.

Read Full Post »

Optimizing Undo

Calculate UNDO_RETENTION for given UNDO Tablespace

You can choose to allocate a specific size for the UNDO tablespace and then set the UNDO_RETENTION parameter to an optimal value according to the UNDO size and the database activity. If your disk space is limited and you do not want to allocate more space than necessary to the UNDO tablespace, this is the way to proceed. The following query will help you to optimize the UNDO_RETENTION parameter:

Because these following queries use the V$UNDOSTAT statistics, run the queries only after the database has been running with UNDO for a significant and representative time!
Actual Undo Size
SELECT SUM(a.bytes) UNDO_SIZE FROM v$datafile a, v$tablespace b, dba_tablespaces c WHERE c.contents = ‘UNDO’ AND c.status = ‘ONLINE’ AND b.name = c.tablespace_name AND a.ts# = b.ts#;
UNDO_SIZE
———-
209715200
Undo Blocks per Second
SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) UNDO_BLOCK_PER_SEC FROM v$undostat;
UNDO_BLOCK_PER_SEC
——————
3.12166667
DB Block Size
SELECT TO_NUMBER(value) DB_BLOCK_SIZE [KByte] FROM v$parameter WHERE name = ‘db_block_size’;
DB_BLOCK_SIZE [Byte]
——————–
4096
Optimal Undo Retention
209’715’200 / (3.12166667 * 4’096) = 16’401 [Sec]
Using Inline Views, you can do all in one query!
SELECT d.undo_size/(1024*1024) “ACTUAL UNDO SIZE [MByte]”,
SUBSTR(e.value,1,25) “UNDO RETENTION [Sec]”,
ROUND((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) “OPTIMAL UNDO RETENTION [Sec]”
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = ‘UNDO’
AND c.status = ‘ONLINE’
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
) g
WHERE e.name = ‘undo_retention’
AND f.name = ‘db_block_size’
/
ACTUAL UNDO SIZE [MByte]
————————
200
UNDO RETENTION [Sec]
——————–
10800
OPTIMAL UNDO RETENTION [Sec]
—————————-
16401
Calculate Needed UNDO Size for given Database Activity

If you are not limited by disk space, then it would be better to choose the UNDO_RETENTION time that is best for you (for FLASHBACK, etc.). Allocate the appropriate size to the UNDO tablespace according to the database activity:

Again, all in one query:
SELECT d.undo_size/(1024*1024) “ACTUAL UNDO SIZE [MByte]”,
SUBSTR(e.value,1,25) “UNDO RETENTION [Sec]”,
(TO_NUMBER(e.value) * TO_NUMBER(f.value) *
g.undo_block_per_sec) / (1024*1024)
“NEEDED UNDO SIZE [MByte]”
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = ‘UNDO’
AND c.status = ‘ONLINE’
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
) g
WHERE e.name = ‘undo_retention’
AND f.name = ‘db_block_size’
/
ACTUAL UNDO SIZE [MByte]
————————
200
UNDO RETENTION [Sec]
——————–
10800
NEEDED UNDO SIZE [MByte]
————————
131.695313
The previous query may return a “NEEDED UNDO SIZE” that is less than the “ACTUAL UNDO SIZE”. If this is the case, you may be wasting space. You can choose to resize your UNDO tablespace to a lesser value or increase your UNDO_RETENTION parameter to use the additional space.

Read Full Post »