关于UNDO表空间及undo_retention参数的一点研究

http://203.208.39.132/search?q=cache:rtbPH3ijyEsJ:blog.oracle.com.cn/index.php/5563/viewspace-33650.html+Oracle+UNDO_RETENTION&cd=2&hl=zh-CN&ct=clnk&gl=cn&client=aff-360homepage&st_usg=ALhdy2_T79O1hokt8eBCJTDWyJqrAaS4DA[@more@]

对于UNDO表空间大小的定义需要考虑UNDO_RETNETION参数、产生的UNDO BLOCKS/秒、UNDO BLOCK的大小。undo_retention：对于UNDO表空间的数据文件属性为autoextensible,则undo_retenion参数必须设置，UNDO信息将至少保留至undo_retention 参数设定的值内，但UNDO表空间将会自动扩展。对于固定UNDO表空间，将会通过表空间的剩余空间来最大限度保留UNDO信息。如果FIXED UNDO表空间没有对保留时间作GUARANTEE（alter tablespace xxx retention guarantee;），则undo_retention参数将不会起作用。（警告：如果设置UNDO表空间为retention guarantee，则未过期的数据不会被复写，如果表空间不够则会导致DML操作失败或者transation挂起）

Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性。设置的 undo_retention 参数只是一个指导值,，Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误.。通过查询V$UNDOSTAT（该视图记录4天以内的UNDO表空间使用情况，超过4天可以查询DBA_HIST_UNDOSTAT视图） 的 tuned_undoretention （该字段在10G版本才有，9I是没有的）字段可以得到Oracle 根据事务量（如果是文件不可扩展，则会考虑剩余空间）采样后的自动计算出最佳的 retenton 时间.。这样对于一个事务量分布不均匀的数据库来说,，就会引发潜在的问题--在批处理的时候可能 Undo 会用光， 而且这个状态将一直持续， 不会释放。

SQL：

查询tuned_undoretention：

select to_char(begin_time,'DD-MON-RR HH24:MI') begin_time,to_char(end_time,'DD-MON-RR HH24:MI') end_time,tuned_undoretention from v$undostat order by end_time;

检查一天平均每秒产生的UNDO BLOCK

select (sum(undoblks)/sum((end_time-begin_time)*86400) from v$undostat;

生成的结果是UNDO BLOCK，如果需要计算出实际大小，则需要乘以db_block_size（通过show parameter db_block_size查出来）

如何计算合适的UNDO表空间大小：

select (UR*(UPS*DBS))+(DBS*24) as "bytes" from (select values as UR from v$parameter where name='undo_retention'),(select (sum(undoblks)/sum(((end_time-begin_time)*86400))) as ups from v$undostat),(select values as DBS from v$parameter where name='db_block_size');

英文部分原文：

After a transaction is committed, undo data is no longer needed for rollback or transaction recovery purposes. However, for consistent read purposes, long-running queries may require this old undo information for producing older images of data blocks. Furthermore, the success of several Oracle Flashback features can also depend
upon the availability of older undo information. For these reasons, it is desirable to retain the old undo information for as long as possible.
When automatic undo management is enabled, there is always a current undo retention period, which is the minimum amount of time that Oracle Database attempts to retain old undo information before overwriting it. Old (committed) undo information that is older than the current undo retention period is said to be expired. Old undo information with an age that is less than the current undo retention period is said to be unexpired.
Oracle Database automatically tunes the undo retention period based on undo tablespace size and system activity. You can specify a minimum undo retention period (in seconds) by setting the UNDO_RETENTION initialization parameter. The database makes its best effort to honor the specified minimum undo retention period, provided that the undo tablespace has space available for new transactions. When available space for new transactions becomes short, the database begins to overwrite expired undo. If the undo tablespace has no space for new transactions after all expired undo is overwritten, the database may begin overwriting unexpired undo information. If any of this overwritten undo information is required for consistent read in a current long-running query, the query could fail with the snapshot too old error message.
The following points explain the exact impact of the UNDO_RETENTION parameter on undo retention:
The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace. The database may overwrite nexpired undo information when tablespace space becomes low.For an undo tablespace with the UTOEXTEND option enabled, 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.
Retention Guarantee
To guarantee the success of long-running queries or Oracle Flashback operations, you can enable retention guarantee. If retention guarantee is enabled, the specified minimum undo retention is guaranteed; the database never overwrites unexpired undo data even if it means that transactions fail due to lack of space in the undo tablespace. If retention guarantee is not enabled, the database can overwrite unexpired undo when space is low, thus lowering the undo retention for the system. This option is disabled by default.
WARNING: Enabling retention guarantee can cause multiple DML operations to fail. Use with caution.
You enable retention guarantee by specifying the RETENTION GUARANTEE clause for the undo tablespace when you create it with either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Or, you can later specify this clause in an ALTER TABLESPACE statement. You disable retention guarantee with the RETENTION NOGUARANTEE clause.You can use the DBA_TABLESPACES view to determine the retention guarantee setting for the undo tablespace. A column named RETENTION contains a value of GUARANTEE, NOGUARANTEE, or NOT APPLY (used for tablespaces other than the undo tablespace).
Automatic Tuning of Undo Retention
Oracle Database automatically tunes the undo retention period based on how the
undo tablespace is configured.If the undo tablespace is fixed size, the database tunes the retention period for the
best possible undo retention for that tablespace size and the current system load. This tuned retention period can be significantly greater than the specified minimum retention period.
If the undo tablespace is configured with the AUTOEXTEND option, the database tunes the undo retention period to be somewhat longer than the longest-running query on the system at that time. Again, this tuned retention period can be greater than the specified minimum retention period.Note: Automatic tuning of undo retention is not supported for LOBs. This is because undo information for LOBs is stored in the segment itself and not in the undo tablespace. For LOBs, the database attempts to honor the minimum undo retention period specified by UNDO_RETENTION. However, if space becomes low, unexpired LOB undo information may be overwritten.
You can determine the current retention period by querying the TUNED_UNDORETENTION column of the V$UNDOSTAT view. This view contains one row for each 10-minute statistics collection interval over the last 4 days. (Beyond 4 days, the data is available in the DBA_HIST_UNDOSTAT view.) TUNED_UNDORETENTION is given in seconds.
select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time, tuned_undoretention
from v$undostat order by end_time;
External Views
Monitor transaction and undo information with V$TRANSACTION and V$ROLLSTAT.
For automatic undo management, the information in V$ROLLSTAT reflects the
behaviors of the automatic undo management undo segments.
The V$UNDOSTAT view displays a histogram of statistical data to show how well the
system is working. You can see statistics such as undo consumption rate, transaction
concurrency, and lengths of queries run in the instance. Using this view, you can better
estimate the amount of undo space required for the current workload.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/450962/viewspace-1027438/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/450962/viewspace-1027438/