原文地址：https://www.modb.pro/db/70802?xzs=
一：請描述什么是Oracle Undo。
二：請描述UNDO的作用。
三：請談談你對Manual Undo Management和Automatic Undo Management管理的理解。
四：請描述UNDO Retention。
五：如何確保在undo_retention期間的數據不會被覆蓋。
六：請描述ORA-01555錯誤原因和解決思路。
七：請描述LOB字段產生ORA-01555錯誤原因和解決思路。
八：請描述ORA-30036錯誤原因和解決思路。
九：當UNDO表空間不足時，如何將相關信息記錄在告警日志中。
十：如何評估所需UNDO大小。
十一：請描述處理過UNDO相關的ORA-600錯誤。
十二：如何限制指定用戶使用UNDO大小。
十三：如果設置Temporary Undo。
十四：DML(insert/delete/update)哪種操作產生的UNDO最多。
十五：請介紹UNDO常用的數據字典和視圖有哪些。
十六：請介紹UNDO常用查詢語句。
一:請描述什么是Oracle Undo？
官方解釋如下：
什么是UNDO？
What Is Undo?
Oracle數據庫創建和管理用於回滾或撤消對數據庫的更改的數據。
Oracle Database creates and manages 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.
這些記錄統稱為undo。
These records are collectively referred to as undo.
二：請描述UNDO的作用?
1.回滾事務。
2.實例恢復。
實例恢復過程中，想通過redo記錄對checkpoint之后的臟塊隊列進行前滾操作。
對於所有未提交的臟塊，oracle根據undo的前鏡像進行回滾（行級別的邏輯反操作），重新將內存中緩存的相關數據臟塊換為非臟塊。
3.提供一致性讀。
執行查詢時，服務器進程掃描這個表中的數據塊時，會把每個數據塊ITL槽中最大的SCN與查詢SCN進行比較，如果比查詢SCN小則說明這個數據塊沒有被修改服務器進程直接進行數據讀取即可。
如果數據塊ITL槽中的SCN大於查詢SCN那么說明這個數據塊在發起查詢后被修改了，需要借助undo去獲取發起查詢那個時刻數據塊的數據。
4.閃回部分相關操作
閃回查詢
例如：
select * from t1 as of timestamp (systimestamp - interval '120' second); ---查詢t1表120秒之前的數據
select * from t1 as of timestamp (systimestamp - interval '2' minute); ---查詢t1表2分鍾之前的數據
select * from t1 as of timestamp (systimestamp - interval '12' hour); ---查詢t1表12小時之前的數據
select * from t1 as of timestamp (systimestamp - interval '12' day); ---查詢t1表12天之前的數據
select * from t1 as of timestamp to_timestamp('2021-05-23 19:30:30','yyyy-mm-dd hh24:mi:ss'); ---查詢之前指定時間點數據
select * from t1 as of timestamp sysdate-2; ---查詢t1表2天之前的數據
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;
SELECT * FROM FLASH_TBL AS OF SCN 1257245; ---查詢指定scn時刻數據
select timestamp_to_scn(to_timestamp('2014-08-24 05:15:22','yyyy-mm-dd hh24:mi:ss')) scn from dual; --時間和scn之間的轉換
閃回版本查詢
select versions_starttime,
versions_endtime,
versions_xid,
versions_operation,
rate
from rates versions between timestamp minvalue and maxvalue
order by VERSIONS_STARTTIME;
注：versions_starttime : 這個數據開始生效的時間
VERSIONS_ENDTIME ：這個數據失效的時間--一般就是下面一條記錄開始的時間
versions_xid : 顯示了更改該行的事務標識符。
VERSION_OPERATION ：這條記錄執行的操作(Insert/Update/Delete)
SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = '000A000D00000029';
閃回事務查詢。
閃回事務查詢有別於閃回查詢的特點有以下3個：
（1）其正常工作不但需要利用撤銷數據，還需要事先啟用最小補充日志。
（2）返回的結果不是以前的“舊”數據，而是能夠將當前數據修改為以前的樣子的撤銷SQL（Undo SQL）語句。
（3）集中地在名為flashback_transaction_query表上查詢，而不是在各個表上通過“as of”或“versions between”子句查詢。
SQL> alter database add supplemental log data;
例如：
select versions_xid, versions_startscn, department_id, department_name
from hr.departments versions between timestamp minvalue and maxvalue
where department_id = 999
order by 2 nulls first;
官方解釋如下：
Undo記錄用於：
Undo records are used to:
1 當執行rollback命令時，回滾事務。
Roll back transactions when a ROLLBACK statement is issued
2 恢復數據庫。
Recover the database
3 提供一致性讀。
Provide read consistency
4 使用Oracle Flashback查詢分析截至較早時間點的數據
Analyze data as of an earlier point in time by using Oracle Flashback Query
5 使用Oracle Flashback功能從邏輯損壞中恢復
Recover from logical corruptions using Oracle Flashback features
When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction.
During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the data files.
Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.
三：請談談你對Manual Undo Management和Automatic Undo Management管理的理解？
Manual Undo Management
手工管理重做段的創建、分配、調整。Oracle9i之前的唯一方法。
回滾段的分配和使用
當有事務產生時，數據庫會給事務分配一個回滾段。當然我們可以指定事務使用某個回滾段。
select SEGMENT_ID ,SEGMENT_NAME from dba_rollback_segs;
set transaction use rollback segment rbsxxx;
如果我們不人為的指定使用哪個回滾段，則數據庫會根據回滾段中事務來權衡，以使得所有回滾段中事務壓力盡可能平均。
在這種模式下，通過回滾段管理撤消空間，不使用UNDO表空間。
The database can also run in manual undo management mode.
In this mode, undo space is managed through rollback segments, and no undo tablespace is used.
注：
回滾段的空間管理很復雜。Oracle強烈建議將數據庫置於自動撤消管理模式。
Note:
Space management for rollback segments is complex. Oracle strongly recommends leaving the database in automatic undo management mode.
Automatic Undo Management
請描述自動撤銷管理Automatic Undo Management
Introduction to Automatic Undo Management
Oracle提供了一種完全自動化的機制，稱為自動撤消管理，用於管理撤消信息和空間。
Oracle provides a fully automated mechanism, referred to as automatic undo management, for managing undo information and space.
通過自動撤消管理，數據庫管理撤消表空間中的撤消段。
With automatic undo management, the database manages undo segments in an undo tablespace.
當數據庫實例啟動時，數據庫會自動選擇第一個可用的undo表空間。
When the database instance starts, the database automatically selects the first available undo tablespace.
如果沒有可用的undo表空間，則實例將在沒有undo表空間的情況下啟動，並在SYSTEM系統表空間中存儲undo記錄。
If no undo tablespace is available, then the instance starts without an undo tablespace and stores undo records in the SYSTEM tablespace.
不建議這樣做，並且會向警報日志文件中寫入一條警報消息，以警告系統在沒有撤消表空間的情況下運行。
This is not recommended, and an alert message is written to the alert log file to warn that the system is running without an undo tablespace.
如果數據庫包含多個undo表空間，則可以選擇在啟動時指定要使用特定undo表空間。這是通過設置UNDO_TABLESPACE初始化參數來完成的，如本例所示：
If the database contains multiple undo tablespaces, then you can optionally specify at startup that you want to use a specific undo tablespace.
This is done by setting the UNDO_TABLESPACE initialization parameter, as shown in this example:
UNDO_TABLESPACE = undotbs_01
如果初始化參數中指定的表空間不存在，則STARTUP命令失敗。
UNDO_TABLESPACEE參數可用於將特定的UNDO表空間分配給Oracle Real Application Clusters環境中的實例。
If the tablespace specified in the initialization parameter does not exist, the STARTUP command fails.
The UNDO_TABLESPACE parameter can be used to assign a specific undo tablespace to an instance in an Oracle Real Application Clusters environment.
以下是撤消管理的初始化參數摘要：
The following is a summary of the initialization parameters for undo management:
UNDO_MANAGEMENT
如果為AUTO或null，則啟用自動撤消管理。如果為MANUAL，則設置手動撤消管理模式。默認值為“AUTO”。
If AUTO or null, enables automatic undo management. If MANUAL, sets manual undo management mode. The default is AUTO.
UNDO_TABLESPACE
可選，僅在自動撤消管理模式下有效。指定撤消表空間的名稱。
Optional, and valid only in automatic undo management mode. Specifies the name of an undo tablespace.
僅當數據庫有多個undo表空間並且希望指示數據庫實例使用特定的undo表空間時才使用。
Use only when the database has multiple undo tablespaces and you want to direct the database instance to use a particular undo tablespace.
注意：Oracle數據庫的早期版本默認為手動撤消管理模式。
要更改為自動撤消管理，必須首先創建一個撤消表空間，然后將UNDO_MANAGEMENT初始化參數更改為AUTO。
如果您的Oracle數據庫是Oracle9i或更高版本，並且要更改為自動撤消管理，請參閱《Oracle數據庫升級指南》以獲取說明。
Note:
Earlier releases of Oracle Database default to manual undo management mode.
To change to automatic undo management, you must first create an undo tablespace and then change the UNDO_MANAGEMENT initialization parameter to AUTO.
If your Oracle Database is Oracle9i or later and you want to change to automatic undo management, see Oracle Database Upgrade Guide for instructions.
在Oracle Database 11g及更高版本中，UNDO_MANAGEMENT初始化參數默認為null,即為自動撤消管理模式，但在早期版本中默認為手動撤消管理模式。
因此，將以前的版本升級到當前版本時必須小心。
《Oracle數據庫升級指南》介紹了遷移到自動撤消管理模式的正確方法，包括有關如何調整撤消表空間大小的信息。
A null UNDO_MANAGEMENT initialization parameter defaults to automatic undo management mode in Oracle Database 11g and later,but defaults to manual undo management mode in earlier releases.
You must therefore use caution when upgrading a previous release to the current release.
Oracle Database Upgrade Guide describes the correct method of migrating to automatic undo management mode, including information on how to size the undo tablespace.
Managing Rollback/Undo Segments in AUM (Automatic Undo Management) (Doc ID 135090.1)
AUM下，不能在UNDO表空間下創建表或回滾段。
You cannot use undo tablespaces for other purposes than undo segments and you cannot perform any operation on system generated undo segments:
SQL> create table T (c number) tablespace undo_rbs1;
create table T (c number) tablespace undo_rbs1
*
ERROR at line 1:
ORA-30022: Cannot create segments in undo tablespace
SQL> create rollback segment undo_rs1 tablespace undo_rbs1;
create rollback segment undo_rs1 tablespace undo_rbs1
*
ERROR at line 1:
ORA-30019: RBU Rollback Segment operation not supported in SMU mode
Automatic Undo Management and Real Application Clusters
The Automatic Undo Management feature is also useful in Real Application Clusters environments.
All instances within Real Application Clusters environments must run in the same undo mode.
Set the global parameter UNDO_MANAGEMENT to AUTO in your server parameter file.
四：請描述對UNDO Retention的理解？
undo_retention表示已經提交或回滾的事物在UNDO EXTENT中保留的時間；
當事物結束時間 <= undo_retention時，UNDO EXTENT在dba_undo_extents.status中狀態為UNEXPIRED;
當事物結束時間 > undo_retention時，UNDO EXTENT在dba_undo_extents.status中狀態為EXPIRED;
當事物沒有結束時 ， UNDO EXTENT在dba_undo_extents.status中 狀態為 ACTIVE;
select t.status,sum(t.blocks)*8/1024||'M' from dba_undo_extents t group by t.status;
STATUS SUM(T.BLOCKS)*8/1024||'M'
--------- -----------------------------------------
UNEXPIRED 11.125M
EXPIRED 41.125M
ACTIVE 19.125M
The Undo Retention Period
undo retention period是Oracle數據庫在覆蓋以前嘗試保留舊撤消信息的最短時間。
The undo retention period is the minimum amount of time that Oracle Database attempts to retain old undo information before overwriting it.
About the Undo Retention Period
啟用自動撤消管理時，總是有一個當前撤消保留期，這是Oracle數據庫在覆蓋以前嘗試保留舊撤消信息的最短時間。
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.
事務提交后，回滾或事務恢復不再需要撤消數據。
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.
此外，幾個Oracle Flashback功能的成功還取決於舊的撤消信息的可用性。
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.
舊的（已提交的）撤消信息早於當前撤消保留期，則表示該信息已過期，其空間可被新事務覆蓋。
Old (committed) undo information that is older than the current undo retention period is said to be expired and its space is available to be overwritten by new transactions.
舊的撤銷信息的期限小於當前撤銷保留期，則稱為未過期，並保留用於一致的讀取和Oracle閃回操作。
Old undo information with an age that is less than the current undo retention period is said to be unexpired and is retained for consistent read and Oracle Flashback operations.
Oracle數據庫根據撤消表空間大小和系統活動自動調整撤消保留期。
Oracle Database automatically tunes the undo retention period based on undo tablespace size and system activity.
您可以選擇通過設置UNDO_RETENTION初始化參數來指定最短的撤消保留期（以秒為單位）。
You can optionally specify a minimum undo retention period (in seconds) by setting the UNDO_RETENTION initialization parameter.
此參數對撤消保留的確切影響如下：
The exact impact this parameter on undo retention is as follows:
對於固定大小的UNDO表空間，將忽略UNDO_RETENTION參數。
The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace.
數據庫總是根據系統活動和撤消表空間大小，調整撤消保留期以獲得盡可能好的保留。
The database always tunes the undo retention period for the best possible retention, based on system activity and undo tablespace size.
See "Automatic Tuning of Undo Retention" for more information.
對於啟用了AUTOEXTEND選項的undo表空間，數據庫將嘗試遵守UNDO_RETENTION指定的最短保留期。
For an undo tablespace with the AUTOEXTEND 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.
如果為自動擴展撤消表空間指定了MAXSIZE子句，則當達到最大大小時，數據庫可能會開始覆蓋未過期的撤消信息。
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.
DBCA自動創建的UNDOTBS1表空間是自動擴展的。
The UNDOTBS1 tablespace that is automatically created by DBCA is auto-extending.
Automatic Tuning of Undo Retention
Oracle數據庫根據undo表空間的配置方式自動調整undo保留期。
Oracle Database automatically tunes the undo retention period based on how the undo tablespace is configured.
如果使用AUTOEXTEND選項配置undo表空間，則數據庫會動態調整undo保留期，使其略長於系統上運行時間最長的活動查詢。
If the undo tablespace is configured with the AUTOEXTEND option, the database dynamically tunes the undo retention period to be somewhat longer than the longest-running active query on the system.
但是，此保留期可能不足以容納Oracle Flashback操作。
However, this retention period may be insufficient to accommodate Oracle Flashback operations.
Oracle Flashback操作導致快照太舊錯誤，這表明您必須進行干預，以確保保留足夠的撤消數據來支持這些操作。
Oracle Flashback operations resulting in snapshot too old errors are the indicator that you must intervene to ensure that sufficient undo data is retained to support these operations.
為了更好地適應Oracle Flashback功能，可以將UNDO_RETENTION參數設置為與預期Oracle Flashback操作的最長時間相等的值，也可以將UNDO表空間更改為固定大小。
To better accommodate Oracle Flashback features, you can either set the UNDO_RETENTION parameter to a value equal to the longest expected Oracle Flashback operation, or you can change the undo tablespace to fixed size.
如果undo表空間的大小是固定的，則數據庫會動態調整undo保留期，以獲得該表空間大小和當前系統負載的最佳保留。
If the undo tablespace is fixed size, the database dynamically tunes the undo retention period for the best possible retention for that tablespace size and the current system load.
此最佳可能保留時間通常明顯大於運行時間最長的活動查詢的持續時間。
This best possible retention time is typically significantly greater than the duration of the longest-running active query.
如果決定將撤消表空間更改為固定大小，則必須選擇足夠大的表空間大小。
If you decide to change the undo tablespace to fixed-size, you must choose a tablespace size that is sufficiently large.
如果選擇的撤消表空間太小，則可能會出現以下兩個錯誤：
If you choose an undo tablespace size that is too small, the following two errors could occur:
DML可能會失敗，因為沒有足夠的空間來容納新事務的撤消數據。
DML could fail because there is not enough space to accommodate undo for new transactions.
長時間運行的查詢可能會失敗，並出現快照太舊的錯誤，這意味着沒有足夠的撤消數據來實現讀取一致性。
Long-running queries could fail with a snapshot too old error, which means that there was insufficient undo data for read consistency.
注意：
LOB不支持自動調整撤消保留。
這是因為lob的undo信息存儲在段本身中，而不是undo表空間中。
對於lob，數據庫嘗試遵守由undo_retention指定的最小undo保留期。
但是，如果空間變小，則可能會覆蓋未過期的LOB undo信息。
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.
五：如何確保在undo_retention期間的數據不會被覆蓋。
為了保證長時間運行的查詢或Oracle閃回操作的成功，可以啟用保留保證。
To guarantee the success of long-running queries or Oracle Flashback operations, you can enable retention guarantee.
如果啟用了保留保證，則保證指定的最小撤消保留；
If retention guarantee is enabled, then 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, then the database can overwrite unexpired undo when space is low, thus lowering the undo retention for the system.
默認情況下禁用此選項。
This option is disabled by default.
警告：啟用保留保證可能會導致多個DML操作失敗。小心使用。
WARNING: Enabling retention guarantee can cause multiple DML operations to fail. Use with caution.
在使用create DATABASE或create undo tablespace語句創建undo表空間時，可以通過為該表空間指定retention GUARANTEE子句來啟用retention guarantee。
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.
或者，您可以稍后在ALTER TABLESPACE語句中指定此子句。
Or, you can later specify this clause in an ALTER TABLESPACE statement.
您可以使用RETENTION NOGUARANTEE禁用 retention guarantee。
You disable retention guarantee with the RETENTION NOGUARANTEE clause.
您可以使用DBA_TABLESPACES視圖來確定undo表空間的retention guarantee設置。
You can use the DBA_TABLESPACES view to determine the retention guarantee setting for the undo tablespace.
名為RETENTION的列包含值guarante、noguarante或NOT APPLY，其中NOT APPLY用於undo表空間以外的表空間。
A column named RETENTION contains a value of GUARANTEE, NOGUARANTEE, or NOT APPLY, where NOT APPLY is used for tablespaces other than the undo tablespace.
六：請描述ORA-01555錯誤原因和解決思路。
1. Read Consistency
構建一致性讀時，需要的undo數據已經被覆蓋。
通常原因如下：
(1)SQL語句執行時間太長。
(2)UNDO表空間過小。
(3)事務量過大。
(4)過於頻繁的提交。
比如對一個塊上的10行數據，每次修改1行並提交，就會對這個塊生成10次UNDO鏡像數據。
(5)導致執行SQL過程中進行一致性讀時，SQL執行后修改的前鏡像（即UNDO數據）在UNDO表空間中已經被覆蓋，不能構造一致性讀塊（CR blocks）。
建議：
（1）增加UNDO表空間大小。
（2）增加undo_retention 時間，默認只有15分鍾。
（3）優化出錯的SQL，減少查詢的時間，首選方法。
（4）避免頻繁的提交。
2. Delayed Block Cleanout
SQL語句執行過程中，訪問到的塊，在進行延遲塊清除時，不能確定該塊的事務提交時間與SQL執行開始時間的先后次序。
發生延遲塊清除情況下，如果一個塊已被修改，下一個會話訪問這個塊時，可能必須查看最后一個修改這個塊的事務是否還是活動的。一旦確定該事務不再活動，就會完成塊清除。
Oracle會從塊首部的ITL事務槽（該事務槽指向回滾段段頭的事務槽），確定前一個事務所用的回滾段，然后試圖從這個回滾段首部的事務槽來獲得該事務的提交SCN。
如果事務的前鏡像信息已經被覆蓋，並且查詢SCN也小於回滾段中記錄的最小SCN，那么Oracle將無法判斷查詢SCN和事務提交SCN的大小，此時出現延遲塊清除導致的ORA-01555錯誤。
Troubleshooting Assistant: Resolve Issues with Oracle Undo Management (ORA-01555, ORA-30036, ORA-01628, ORA-01552, etc.) (Doc ID 1575667.2)
ORA-1555 error with query duration 0 or less than UNDO_RETENTION
ORA-1555 error during export
ORA-1555 and ORA-22924 errors on LOB data
ORA-1555 error - generic troubleshooting
建議：
(1)減少查詢的運行時間（調優）。
(2)保證使用的事務“大小適當”。確保沒有不必要地過於頻繁地提交。
(3)使用DBMS_STATS掃描相關的對象，加載之后完成這些對象的清理。由於塊清除是極大量的UPDATE或INSERT造成的，所以很有必要這樣做。
(4)允許UNDO表空間擴大，為之留出擴展的空間，並增加UNDO保持時間。
ORA-01555 "Snapshot too old" - Detailed Explanation (Doc ID 40689.1)
1. Read Consistency
這在Oracle數據庫概念手冊中有記錄，因此將不作進一步討論。
This is documented in the Oracle Database Concepts manual and so will not be discussed further.
但是，就本條而言，如果尚未理解，則應閱讀並理解本條。
However, for the purposes of this article this should be read and understood if not understood already.
oracle server具有多版本讀取一致性的能力，這對您來說是非常寶貴的，因為它可以保證您看到一致的數據視圖（沒有“臟讀取”）。
Oracle Server has the ability to have multi-version read consistency which is invaluable to you because it guarantees that you are seeing a consistent view of the data (no 'dirty reads').
2. Delayed Block Cleanout
最好用一個例子來說明這一點：
This is best illustrated with an example:
考慮一個更新一百萬行表的事務。
Consider a transaction that updates a million row table.
這顯然會訪問大量的數據庫塊來對數據進行更改。
This obviously visits a large number of database blocks to make the change to the data.
當用戶提交事務時，Oracle不會返回並重新訪問這些塊以使更改永久化。
When the user commits the transaction Oracle does NOT go back and revisit these blocks to make the change permanent.
它留給訪問受更新影響的任何塊的下一個事務來“整理”塊（因此稱為“延遲塊清理”）。
It is left for the next transaction that visits any block affected by the update to 'tidy up' the block (hence the term 'delayed block cleanout').
每當Oracle更改數據庫塊（索引、表、聚簇）時，它都會在數據塊的頭中存儲一個指針，該指針標識用於保存事務所做更改的回滾信息的回滾段(如果用戶以后選擇不提交更改並希望“撤消”所做的更改，則需要此選項。）
Whenever Oracle changes a database block (index, table, cluster) it stores a pointer in the header of the data block which identifies the rollback segment used to hold the rollback information for the changes made by the transaction. (This is required if the user later elects to not commit the changes and wishes to 'undo' the changes made.)
提交時，數據庫只是將相關的回滾段頭條目標記為已提交。現在，當重新訪問其中一個已更改的塊時，Oracle會檢查數據塊的頭，這表明它在某個點上已更改。數據庫需要確認更改是已提交還是當前未提交。
Upon commit, the database simply marks the relevant rollback segment header entry as committed. Now, when one of the changed blocks is revisited Oracle examines the header of the data block which indicates that it has been changed at some point. The database needs to confirm whether the change has been committed or whether it is currently uncommitted.
為此，Oracle確定用於上一個事務的回滾段（來自塊的頭），然后確定回滾頭是否指示它是否已提交。
To do this, Oracle determines the rollback segment used for the previous transaction (from the block's header) and then determines whether the rollback header indicates whether it has been committed or not.
如果發現該塊已提交，則更新數據塊的頭，以便對該塊的后續訪問不會引起該處理。
If it is found that the block is committed then the header of the data block is updated so that subsequent accesses to the block do not incur this processing.
下面用一種非常簡單的方式來說明這種行為。這里我們將介紹更新數據塊所涉及的各個階段。
This behaviour is illustrated in a very simplified way below. Here we walk through the stages involved in updating a data block.
ORA-1555錯誤可能發生在查詢無法訪問足夠的undo以在查詢開始時構建數據副本的情況下。
The ORA-1555 errors can happen when a query is unable to access enough undo to build a copy of the data at the time the query started.
塊的已提交“版本”與這些塊的較新未提交“版本”一起維護，以便查詢可以訪問數據庫中在查詢時存在的數據。
Committed "versions" of blocks are maintained along with newer uncommitted "versions" of those blocks so that queries can access data as it existed in the database at the time of the query.
這些被稱為“一致讀取”塊，並使用Oracle撤消管理進行維護。
These are referred to as "consistent read" blocks and are maintained using Oracle undo management.
如何找到ORA-01555對應的SQL
How to find the complete SQL statement caused ORA-1555 :
If the Database was not restarted after the error ORA-1555 , so the Statement can be obtained from :
select SQL_TEXT from v$sqlarea where SQL_ID='<sql id from the error message>';
If the Database was restarted after the error ORA-1555 and an AWR snapshot was gathered before the restart , so the Statement can be obtained from :
select SQL_TEXT from DBA_HIST_SQLTEXT where SQL_ID='<sql id from the error message>';
七：請描述LOB字段產生ORA-01555錯誤原因和解決思路。
LOB不支持自動調整撤消保留。
這是因為lob的undo信息存儲在段本身中，而不是undo表空間中。
對於lob，數據庫嘗試遵守由undo_retention指定的最小undo保留期。
但是，如果空間變小，則可能會覆蓋未過期的LOB undo信息。
LOBs and ORA-01555 troubleshooting (Doc ID 846079.1)
有四種類LOB，分別是CLOB,BLOB,NCLOB,BFILE。
Background
There are four types of LOB:
CLOB, BLOB, NCLOB -> stored internally to Oracle
BFILE -> stored externally
包含LOB（CLOB、NCLOB和BLOB）的表會為每個LOB列創建兩個額外的磁盤段—一個LOBINDEX和一個LOBSEMENT。
A table containing LOBs (CLOB, NCLOB and BLOB) creates 2 additional disk segments per LOB column - a LOBINDEX and a LOBSEGMENT.
These can be viewed, along with the LOB attributes, using the dictionary views:
DBA_LOBS, ALL_LOBS or USER_LOBS
可以允許LOB列在行中存儲數據，也可以不存儲，詳情如下。
LOB columns can be allowed to store data within the row or not as detailed below.
是否允許in-line存儲只能在創建時指定。
Whether in-line storage is allowed or not can ONLY be specified at creation time.
1.) INLINE LOBs
"STORE AS ( enable storage in row )"
允許LOB數據存儲在表段中，前提是它小於約4000字節。
Allows LOB data to be stored in the TABLE segment provided it is less than about 4000 bytes.
實際的最大in-line LOB為3964字節。
The actual maximum in-line LOB is 3964 bytes.
In-line LOB受Oracle中的常規鏈接和行遷移規則的約束。
In-line LOBS are subject to normal chaining and row migration rules within Oracle.
Ie: If you store a 3900 byte LOB in a row with a 2K block size then the row piece will be chained across two or more blocks.
Undo Generation
對於In-Line LOBs，REDO和UNDO都是作為普通行數據的一部分寫入的。
For In-Line LOBs Both REDO and UNDO are written as they are part of the normal row data.
"STORE AS ( disable storage in row )"
如果LOB數據大於3964字節，則LOB數據存儲在LOB SEGMENT中（即：out of line）。
If the LOB data is greater than 3964 bytes, then the LOB data is stored in the LOB SEGMENT (ie: out of line).
out of line LOB的行為與“disable storage in row”下所述的相同，但如果其大小縮小到3964或更小，則可以再次inline LOB。
An out of line LOB behaves as described under 'disable storage in row' except that if its size shrinks to 3964 or less the LOB can again be stored inline.
行中存儲了一個20字節的LOB locator，它為該列的LOB段中的LOB提供了唯一標識符。
A 20 byte LOB locator is stored in the ROW which gives a unique identifier for a LOB in the LOB segment for this column.
Lob Locator實際上向Lob索引提供一個鍵，該索引包含組成Lob的所有塊（或頁）的列表。
The Lob Locator actually gives a key into the LOB INDEX which contains a list of all blocks (or pages) that make up the LOB.
當一個LOB在'enable storage in row'LOB列中行外存儲時，36到84字節之間的控制數據在行塊中保持行內。
When a LOB is stored out-of-line in an 'enable storage in row' LOB column between 36 and 84 bytes of control data remain in-line in the row piece.
• LOBINDEX類似於Ｂ-tree的結構，存儲各個LOB entry的LOB ID,LOB ID指向LOBSEGMENT中的實際存儲區域。
• 如果要delete一條數據，刪除的操作就是更新一下LOBINDEX, 並不會去將LOBSEGMENT中的內容寫入回滾段中，這時候有少量的undo信息產生，但是是因為修改LOGINDEX產生的。
• 如果是update LOB，並不是去update原來的LOB entry，而是插入一條新的LOB entry,並且對LOB自身不產生undo信息,原來舊的數據仍然存放於LOBSEGMENT中（LOBSEGMENT中會存儲相關的SCN信息）
• 這樣query需要讀取old version的數據就不是從回滾段中讀取old value來重構，而是從LOBSEGMENT中讀取原先的LOB entry。
• 如果delete,update操作很多，oracle會不會一直保存這些old version的數據呢？答案是不會。
• 這時就靠創建LOB時的參數PCTVERSION來控制了。PCTVERSION=10的含義就是在HWM下留有10%的空間用於存放Old version的數據.如果存放old version的空間多於PCTVERSION，那么就可以被重用。這時如果有query需要重構舊的數據，就會產生ORA-01555錯誤。想要避免01555的話一個就是盡量縮短query的時間，另外就是增大PCTVERSION，當然這會消耗更多的空間存放舊數據。
一般來說，普通的01555錯誤會指明發生01555的rollback segment,而LOB的則沒有，而是伴隨着ORA-22924出現。
例如：
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
解決方案：
oracle的lob大字段有自己的retention參數，如果只調整undo_retention，而沒有同步到lob大字段，該參數還是默認的900s，確認查詢結果如下：
select table_name,column_name,pctversion,retention from dba_lobs where table_name='T_CJC_001';
修改表含有lob大字段的retention設置
ALTER TABLE T_CJC_001 MODIFY LOB(CONTENT)(retention);
使用pctversion
從結果中可以看到，當顯示指定pctversion的時候，retention參數會失效
alter table T_CJC_001 modify lob(CONTENT) (pctversion 10);
select column_name, pctversion, retention from user_lobs where table_name = 'T_CJC_001';
Undo Generation
UNDO只有在對列locator和LOB INDEX更改時寫入。
UNDO is only written for the column locator and LOB INDEX changes.
不會為LOB段中的頁面生成撤消。
No UNDO is generated for pages in the LOB SEGMENT.
使用頁面版本可以實現一致的讀取，即更新LOB的頁面時，保留舊頁面並創建新頁面。
Consistent Read is achieved by using page versions i.e. When you update a page of a LOB the OLD page remains and a new page is created.
這可能會浪費空間，但舊頁可以回收和重用。
This can appear to waste space but old pages can be reclaimed and reused.
Troubleshooting Steps
ORA-1555意味着我們得到的頁面沒有我們期望的（lob_id+版本），因此可能表示一致的讀取問題或lob段本身的損壞。
ORA-1555 means the page we got to did not have the (lob_id + version) that we expected so can indicate a Consistent Read issue or a corruption on the lob segment itself.
V$undostat將不包含有用的信息，因為它不反映LOB undo信息。
V$undostat would not contain useful information because this does not reflect LOB undo information.
八：請描述ORA-30036錯誤原因和解決思路。
ORA-30036：unable to extend segment by 8 in undo tablespace 'UNDOTBS1'
Troubleshooting ORA-30036 - Unable To Extend Undo Tablespace (Doc ID 460481.1)
When a ORA-30036 will be reported.
當當前UNDO表空間沒有更多可用空間用於活動事務時，將報告ORA-30036錯誤。
ORA-30036 error is reported when the current Undo tablespace has no more free space available for the active transactions.
當事務訪問數據庫時，它們需要UNDO空間。UNDO空間分配按以下順序進行：
When transactions hit a database and they need undo space. The undo space allocation happens in the following sequence:
1.在沒有活動事務的UNDO段中分配數據塊。Oracle嘗試將事務分發到所有UNDO段。
Allocate an extent in an undo segment which has no active transaction. Oracle tries to distribute transactions over all undo segments.
2.如果找不到UNDO段，則oracle會嘗試將脫機UNDO段聯機並使用它。
If no undo segment found then oracle tries to online an off-line undo segment and use it.
3.如果沒有要聯機的UNDO段，則創建一個新的UNDO段並使用它。
If no undo segments to online, then we create a new undo segment and use it.
4.如果空間不允許創建undo段，那么我們嘗試重用現有undo段中過期的區段。
If space does not permit creation of undo segment, then we try to reuse an expired extent from the existing undo segments.
對於與UNDO段/extent關聯的正在運行的事務，如果它需要更多的UNDO空間，則：
For a running transaction associated with undo segment/ extent, if it needs more undo space then:
1.如果當前extent有更多可用塊，則使用下一個已准備好分配給該extent的可用塊。
If the current extent has more free blocks then use the next free block that is all ready allocated to the extent.
2.如果當前區段沒有空閑塊，並且該段的下一區段已過期，則在下一區段中包裝該區段並返回第一個區段。
If the current extent does not have free blocks and if the next extent of the segment has expired then wrap in the the next extent and return the first block.
3.如果下一個extent尚未過期，則從UNDO表空間獲取空間。如果有可用的擴展數據塊，則將其分配給UNDO段，並返回新擴展數據塊中的第一個塊。
If the next extent has not expired then get space from the UNDO tablespace. If a free extent is available then allocate it to the undo segment and return the first block in the new extent.
4.如果沒有可用的extent，則從脫機UNDO段進行竊取。從脫機UNDO段取消分配數據塊，並將其添加到當前UNDO段。返回數據塊的第一個空閑塊。
If there is no free extent available then steal from an offline undo segment. Deallocate the extent from the offline undo segment and add it to the current undo segment. Return the first free block of the extent.
5.從聯機UNDO段竊取。從聯機UNDO段取消分配數據塊，並將其添加到當前UNDO段。返回數據塊的第一個空閑塊。
Steal from online undo segment. Deallocate the extent from the online undo segment and add it to the current undo segment. Return the first free block of the extent.
注意：Bug2900863表示這個步驟在某些情況下是中斷的。這在服務器補丁集9.2.0.5及更高版本和服務器版本10g中已修復。
NOTE: Bug 2900863 indicates this steps is broken in some cases. This is fixed in Server patchset version 9.2.0.5 and above, and in Server release 10g.
6.在UNDO表空間中擴展文件。如果文件可以擴展，則向當前UNDO段添加一個區段，然后返回塊。
Extend the file in the UNDO tablespace. If the file can be extended then add an extent to the current undo segment then return the block.
7.否則，嘗試從自己的UNDO段重用未過期的區段。如果所有擴展數據塊當前都很忙（它們包含未提交的信息），請轉至步驟8。否則，請換行到下一個擴展數據塊。
Otherwise try to reuse unexpired extents from own undo segment. If all extents are currently busy(they contains uncommitted information) go to the step 8. Otherwise wrap into the next extent.
8.從脫機UNDO段隨機竊取未過期的數據塊。如果失敗，則嘗試聯機UNDO段以供重用。
Randomly steal unexpired extents from offline undo segments. If this fails then try to online undo segments for reuse.
9.如果上述操作都失敗，則返回ORA-30036無法將段擴展%s（在UNDO表空間“%s”中）
If all the above fails then return ORA-30036 unable to extend segment by %s in undo tablespace '%s'
這個錯誤說明我們需要添加更多的空間來UNDO表空間，這可能並不總是這樣。
This Error states that we need to add more space to Undo Tablespace, which might not be case always.
如果UNDO的大小太小，並且即使從其他UNDO段進行竊取，事務也無法獲取UNDO塊，則會發生竊取失敗。
Failure to steal occurs where the undo is sized too small and the transaction is unable to get undo blocks even by stealing from other undo segments.
Troubleshooting ORA-30036 Errors
i) Check free space in the undo tablespace.
select sum(bytes) from dba_free_space where tablespace_name='<undo tablespace>';
select sum(bytes) from dba_data_files where tablespace_name='<undo tablespace>';
ii) Check whetherUndo tablespace datafile is autoextensible.
select autoextensible from dba_data_files where tablespace_name='<undo tablespace>;
iii) Check whether unexpired extents are available in the same segment as the current transaction.
SQL> SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*) FROM DBA_UNDO_EXTENTS GROUP BY STATUS;
如果沒有剩余的UNDO空間，那么我們嘗試使用未過期的區段（執行UNDO保留所需的UNDO區段）。
這有時會導致ORA-1555錯誤。
現在，如果沒有未過期的擴展數據塊，則需要添加空間來UNDO表空間。
In case no undo space is left, then we try to use unexpired extents (Undo Extent required to honour UNDO_RETENTION).
This sometimes results in ORA-1555 errors.
Now if you do not have unexpired extents also, then you need to add space to undo tablespace.
iv) Check the status of the Undo extents.
SQL> SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*),TABLESPACE_NAME FROM DBA_UNDO_EXTENTS GROUP BY STATUS,TABLESPACE_NAME;
The actions depends based on the output:
情況1：沒有可用的過期擴展數據塊，並且大部分是活動擴展數據塊。
Case 1: No Expired extents available and mostly Active extents present.
如果沒有可重復使用的過期數據塊，則可能會遇到ORA-30036。
如果我們看到大部分活動區，那么這很可能是UNDO大小調整問題。
在這種情況下，請檢查UNDO表空間的大小是否正確。
If there are no Expired extents that can be re-used then its possible to encounter ORA-30036.
If we see mostly Active extents then this is most likely Undo sizing issue.
In this case, check if Undo Tablespace is correctly sized.
以下查詢計算所需的字節數（基於當前工作負載）：
The following query calculates the number of bytes needed (based on the current workload):
SQL> SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"
FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),
(SELECT (SUM(undoblks)/SUM(((end_time - begin_time)*86400))) AS UPS FROM v$undostat),
(select block_size as DBS from dba_tablespaces where tablespace_name=
(select value from v$parameter where name = 'undo_tablespace'));
*（UR）以秒為單位UNDO保留
*（UPS）每秒生成的UNDO數據塊數
*（DBS）開銷根據范圍和文件大小（db_block_size）而變化
*(UR) UNDO_RETENTION in seconds
*(UPS) Number of undo data blocks generated per second
*(DBS) Overhead varies based on extent and file size (db_block_size)
Refer to below note for more explanation on this
How To Size UNDO Tablespace For Automatic Undo Management (Doc ID 262066.1)
SQL> SELECT undoblks/((end_time-begin_time)*86400) "Peak Undo Block Generation" FROM v$undostat WHERE undoblks
SQL> SELECT (UR * (UPS * DBS)) AS "Bytes"
FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),
(SELECT undoblks/((end_time-begin_time)*86400) AS UPS
FROM v$undostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)),
(SELECT block_size AS DBS
FROM dba_tablespaces
WHERE tablespace_name = (SELECT UPPER(value) FROM v$parameter WHERE name = 'undo_tablespace'));
For 10g and Higher Versions where Tuned undo retention is being used,please use below query:
SQL>SELECT (UR * (UPS * DBS)) AS "Bytes"
FROM (select max(tuned_undoretention) AS UR from v$undostat),
(SELECT undoblks/((end_time-begin_time)*86400) AS UPS
FROM v$undostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)),
(SELECT block_size AS DBS
FROM dba_tablespaces
WHERE tablespace_name = (SELECT UPPER(value) FROM v$parameter WHERE name = 'undo_tablespace'));
情況2：沒有可用的過期擴展數據塊，並且大部分未過期的擴展數據塊都存在。
Case 2: No Expired extents available and mostly Unexpired extents present.
如果沒有可重復使用的過期數據塊，則可能會遇到ORA-30036。
如果我們看到的大部分是未過期的數據塊，則可能是UNDO間距問題，也可能是由於UNDO保留率過高造成的。
換言之，這意味着UNDO空間不足以用於指定的UNDO保留或調整的UNDO保留值。
If there are no Expired extents that can be re-used then its possible to encounter ORA-30036.
If we see mostly Unexpired extents then it can be either a Undo spacing issue or caused by unreasonably high Undo retention. In other words, this means the Undo space is not enough for the specified Undo_Retention or the Tuned_undoretention value.
Check the undo retention and the tuned_undo retention
Show parameter Undo
select max(tuned_undoretention) from v$undostat;
如果保留率太高，則解決方法將是（以下任意一種）：
If the tuned_undoretention is too high the workarounds will be (any one of the following):
a. 啟用UNDO表空間數據文件的自動擴展性，並將MAXSIZE設置為UNDO表空間中所有數據文件的實際大小。
Turn on autoextensibility of the undo tablespace datafiles and set the MAXSIZE to the actual size of the all the datafiles of the undo tablespace.
這改變了用於計算調整后的保留的算法，因此調整后的保留值設置與實際需求相比不會太高。
This alters the algorithm used for calculating tuned_undoretention and thus the tuned_undoretention values set wont be too high compared to the actual requirements.
b. Set _smu_debug_mode=33554432
這又一次改變了用於計算tuned_undoretention的算法，因此tuned_undoretention設置的值與實際需求相比不會太高。
This again alters the algorithm used for calculating tuned_undoretention and thus the tuned_undoretention values set wont be too high compared to the actual requirements.
c. 將_first_spare_parameter參數（10.2）或_highthreshold_undoretention（11.x）實例參數設置為限制優化的UNDO保留值的值。
set the _first_spare_parameter (10.2) or _highthreshold_undoretention (11.x) instance parameter to a value limiting the tuned undo retention value.
此值用作調整的保留時間的上限
This value acts as an upper limit for the tuned_undoretention
d. 通過設置_undo_autotune=false禁用UNDO的自動調整
Disable automatic tuning of undo by setting _undo_autotune=false
有關詳細信息，請參閱自動調整UNDO保留常見問題（Doc ID 1579779.1）。
Refer Automatic Tuning of Undo Retention Common Issues (Doc ID 1579779.1) for details.
情況3：有很多過期的擴展數據塊可用。
Case 3: Lot of Expired extents are available.
如果存在過期的擴展數據塊，但仍然遇到ORA-30036，則表示未重用過期的擴展數據塊。
If Expired extents are present and still ORA-30036 is encountered , it means that the EXPIRED extents are not being reused.
這些過期的擴展數據塊應該被重用，相反，我們得到的是ORA-30036錯誤。
These Expired extents should have been reused and instead we are getting ORA-30036 error.
這可能是因為10.2.0.4（和11g）中修復了未發布的錯誤5442919。
This could be because of Unpublished Bug 5442919 which is fixed in 10.2.0.4 ( and 11g ).
Bug 5442919 - Expired extents not being reused (ORA-30036) (Doc ID 5442919.8)
如果在其他版本上發生這種情況，請向Oracle支持部門報告，以便進一步調查
If this is happening on other versions, then please report the same to Oracle Support for further investigation
九：當UNDO表空間不足時，如何將相關信息記錄在告警日志中。
有時UNDO表空間不足時，相關信息沒有記錄在告警日志中，只是打印在前台。
ORA-30036 not logged in alert log when generated. (Doc ID 444106.1)
為什么沒有記錄到告警日志中?
Why is ORA-30036 generated but not logged in the alert log ?
根據審查代碼時的進展情況，有許多地方發布了ORA-30036，因為這些地方都不提供將消息寫入警報日志的任何工具。
According to development when reviewing the code, there are a number of locations where ORA-30036 is issued because none of these locations provide any facility to write the message to the alert log.
是否將錯誤寫入警報日志的決定完全是主觀的，由代碼所有者決定。
The decision as to whether to write an error to the alert log is totally subjective and up to the code owner.
ORA-30036的編碼非常明確，不能寫入警報日志。
ORA-30036 is very specifically coded not to be written to the alert log.
這不是一個bug，因為內部決定不應該警告這個錯誤。如果在警報日志文件中看到此錯誤，則它將與其他錯誤一起出現。
This is not a bug, since internally it is decided that this error should not be alerted.
If you see this error in the alert log file, then it would be with other errors.
這在未發布的BUG 2099510中進行了討論，它被關閉為“非BUG”。
This is discussed in the Unpublished BUG 2099510, which is closed as "Not a Bug"
Unpublished BUG 2099510 - ORA-30036 ERROR ISN'T REPORTED IN ALERT FILE AT FIRST TIME
ORA-30036如何記錄到后台告警日志？
Oracle提供接口用於診斷Oracle的錯誤信息。
診斷事件可以在Session級設置，也可以在系統級設置，通常如果要診斷全局錯誤，最好在系統級設置。
Errorstack事件：dump 錯誤棧信息，通常Oracle發生錯誤時前台進程將得到一條錯誤信息，但某些情況下得不到錯誤信息，可以采用這種方式得到Oracle錯誤。
Errorstack 和 oradebug 命令類似，都可以幫助診斷錯誤信息。
打開ORA-30036的errorstack
alter system set events '30036 trace name errorstack level 3';
---alter system set events='30036 trace name errorstack off';
表示當出現ORA-30036錯誤時，dump 錯誤棧和進程棧。
或者使用oradebug：
--啟用
SQL> oradebug event 30036 trace name errorstack level 10;
--關閉
SQL> oradebug event 30036 trace name errorstack off;
SQL> oradebug setmypid
SQL> oradebug tracefile_name
十：如何評估所需UNDO大小？
How To Size UNDO Tablespace For Automatic Undo Management (Doc ID 262066.1)
調整UNDO表空間的大小需要三個數據。
Sizing an UNDO tablespace requires three pieces of data.
(UR) UNDO_RETENTION in seconds
(UPS) Number of undo data blocks generated per second
(DBS) Overhead varies based on extent and file size (db_block_size)
所需的undo空間計算如下：
The undo space needed is calculated as:
UndoSpace = UR * (UPS * DBS)
以下公式計算每秒生成的峰值undo塊：
The following formula calculates the peak undo blocks generated per second:
SELECT undoblks / ((end_time - begin_time) * 86400) "Peak Undo Block Generation"
FROM v$undostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat);
列結束時間和開始時間是日期數據類型。
減去日期數據類型后，結果值為兩個日期之間的天數。
要將天轉換為秒，需要將86400乘以一天中的秒數（24小時*60分鍾*60秒）。
Column END_TIME and BEGIN_TIME are DATE data types.
When DATE data types are subtracted, the resulting value is the # of days between both dates.
To convert days to seconds, you multiply by 86400, the number of seconds in a day (24 hours * 60 minutes * 60 seconds).
以下查詢計算處理峰值撤消活動所需的字節數：
The following query calculates the number of bytes needed to handle a peak undo activity:
SELECT (UR * (UPS * DBS)) AS "Bytes"
FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),
(SELECT undoblks / ((end_time - begin_time) * 86400) AS UPS
FROM v$undostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)),
(SELECT block_size AS DBS
FROM dba_tablespaces
WHERE tablespace_name =
(SELECT UPPER(value)
FROM v$parameter
WHERE name = 'undo_tablespace'));
對於使用調優撤消保留的10g及更高版本，請使用以下查詢：
For 10g and Higher Versions where Tuned undo retention is being used,please use below query:
SELECT (UR * (UPS * DBS)) AS "Bytes"
FROM (select max(tuned_undoretention) AS UR from v$undostat),
(SELECT undoblks / ((end_time - begin_time) * 86400) AS UPS
FROM v$undostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v$undostat)),
(SELECT block_size AS DBS
FROM dba_tablespaces
WHERE tablespace_name =
(SELECT UPPER(value)
FROM v$parameter
WHERE name = 'undo_tablespace'));
十一：請描述處理過UNDO相關的ORA-600錯誤。
ORA-00600: internal error code, arguments: [4194], [#], [#], [], [], [], [], []
ORA-600 [4193] When Trying To Open The Database (Doc ID 763566.1)
Single instance
For Rac Instance(If one instance is down and other is up and running)
For 8i database and Below
Step by step to resolve ORA-600 4194 4193 4197 on database crash (Doc ID 1428786.1)
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter (Doc ID 281429.1)
SOLUTION
檢測到重做記錄和回滾（撤消）記錄之間不匹配。
A mismatch has been detected between Redo records and rollback (Undo) records.
ARGUMENTS:
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block
場景1：單實例
Step 1
--------
SQL> Startup nomount ; --> using spfile
SQL> Create pfile='/temp/<corrupt_pfile>.ora' from spfile ;
SQL> Shutdown immediate;
Step 2
-------
Modify the <corrupt_pfile>.ora and set Undo_management=Manual
SQL> Startup mount pfile='/temp/<corrupt_pfile>.ora'
SQL> Show parameter undo
it should show manual
SQL> Alter database open ;
If it comes up
SQL> Create rollback segment r01 ;
SQL> Alter rollback segment r01 online ;
Create a new undo tablespace
SQL> Create undo tablespace undotbs_new datafile '<>' size <> M ;
Please note :- 謹慎刪除舊的undo表空間
You can delay the drop of the Old undo tablespace this is just to allow the block cleanout to happen for dead transaction.
So the below step can be issued after database has been up and running with new undo tablespace for couple of hours.
Also note if your database has been forced open(datafiles are not in sync and archive logs missing ) using any unsupported method then please do not drop the Old undo.
Drop the Old undo tablespace
SQL> Drop tablespace <undo tablespace name> including contents and datafiles
Step 3
-------
SQL> Shutdown immediate;
SQL> Startup nomount ; ---> Using spfile
SQL> Alter system set undo_tablespace=<new Undo tablespace created> scope=spfile;
SQL> Shutdown immediate ;
SQL> Startup
Check if error is reported
場景2：RAC數據庫
For Rac Instance(If one instance is down and other is up and running)
------------------------
If one node is up and running and other node is failing with ORA-00600[4194]/[4193] then
From the instance which is up and running create a new undo tablespace and make it the default one for the other instance which is down with the error.
Startup the failing instance with the new undo tablespace.
From Instance which is up and running
Create undo tablespace undo_new datafile '<filename>' size <> m ;
Alter system set undo_tablespace=<New undo tablespace name> sid=<instance which has corrupt undo tablespace and is down> scope=spfile ;
Now Startup the Instance which is down
SQL>Startup mount
SQL>Show parameter undo
Should show the new undo tablespace created above
SQL>Alter database open ;
SQL>Drop tablespace <Old undo tablespace of the failing instance> including contents and datafiles
If all the Instance is down in the Rac due to this error then following the instruction given for Single instance and create new undo tablespace.
場景3：數據庫版本<=8i
For 8i database and Below
SQL>Startup restrict
Drop the Manual rollback segments and recreate it
場景4：system作為undo表空間時
@Option 3(System undo segment erroring with Ora-00600[4194/4193]
@Option 1 would fail if the undo segment involved is System undo segment.
@Please refer the note given below for patching the same.
@Note.452620.1 :Int/Pub ORA-600 [4193] ORA-600 [4194] IN SYSTEM ROLLBACK SEGMENT. HOW TO @PATCH
和UNDO有關的幾個隱含參數
(1)_corrupted_rollback_segments
(2)_offline_rollback_segments
不建議使用 _corrupted_rollback_segments、_offline_rollback_segments
十二：如何限制指定用戶使用UNDO大小。
建立撤消空間的用戶配額
Establishing User Quotas for Undo Space
可以使用Oracle數據庫資源管理器為UNDO空間建立用戶配額。
數據庫資源管理器指令UNDO_POOL允許dba限制一組用戶（資源使用者組）消耗的撤消空間量。
You can use the Oracle Database Resource Manager to establish user quotas for undo space.
The Database Resource Manager directive UNDO_POOL allows DBAs to limit the amount of undo space consumed by a group of users (resource consumer group).
可以為每個使用者組指定撤消池。撤消池控制使用者組可以生成的撤消總量。
You can specify an undo pool for each consumer group. An undo pool controls the amount of total undo that can be generated by a consumer group.
當使用者組生成的撤消總數超過其撤消限制時，將終止生成撤消的當前更新事務。
When the total undo generated by a consumer group exceeds its undo limit, the current UPDATE transaction generating the undo is terminated.
在從池中釋放撤消空間之前，使用者組的其他成員不能執行進一步的更新。
No other members of the consumer group can perform further updates until undo space is freed from the pool.
如果沒有顯式定義UNDO_POOL指令，則允許用戶使用無限的UNDO空間。
When no UNDO_POOL directive is explicitly defined, users are allowed unlimited undo space.
十三：如果設置Temporary Undo。
管理臨時撤消
Managing Temporary Undo
默認情況下，臨時表的undo記錄存儲在undo表空間中，並記錄在redo中，這與持久表的undo管理方式相同。
By default, undo records for temporary tables are stored in the undo tablespace and are logged in the redo, which is the same way undo is managed for persistent tables.
但是，可以使用TEMP_UNDO_ENABLED初始化參數將臨時表的UNDO與持久表的UNDO分開。
However, you can use the TEMP_UNDO_ENABLED initialization parameter to separate undo for temporary tables from undo for persistent tables.
當此參數設置為TRUE時，臨時表的撤消操作稱為臨時撤消。
When this parameter is set to TRUE, the undo for temporary tables is called temporary undo.
About Managing Temporary Undo
臨時撤消記錄存儲在數據庫的臨時表空間中，因此不會記錄在重做日志中。
Temporary undo records are stored in the database's temporary tablespaces and thus are not logged in the redo log.
啟用臨時撤消時，臨時表空間使用的某些段存temporary undo，這些段稱為臨時撤消段temporary undo segments。
When temporary undo is enabled, some of the segments used by the temporary tablespaces store the temporary undo, and these segments are called temporary undo segments.
啟用臨時撤消后，可能需要增加臨時表空間的大小，以考慮撤消記錄。
When temporary undo is enabled, it might be necessary to increase the size of the temporary tablespaces to account for the undo records.
啟用臨時撤消可提供以下好處：
Enabling temporary undo provides the following benefits:
臨時撤消減少了存儲在UNDO表空間中的撤消量。
Temporary undo reduces the amount of undo stored in the undo tablespaces.
撤消表空間中的撤消次數越少，撤消記錄的撤消保留期要求就越現實。
Less undo in the undo tablespaces can result in more realistic undo retention period requirements for undo records.
臨時撤消減少重做日志的大小。
Temporary undo reduces the size of the redo log.
性能得到了提高，因為寫入重做日志的數據更少，而解析重做日志記錄的組件（如LogMiner）的性能更好，因為要解析的重做數據更少。
Performance is improved because less data is written to the redo log, and components that parse redo log records, such as LogMiner, perform better because there is less redo data to parse.
臨時撤消使用Oracle Active data Guard選項對物理備用數據庫中的臨時表啟用數據操作語言（DML）操作。
但是，創建臨時表的數據定義語言（DDL）操作必須在主數據庫上發出。
Temporary undo enables data manipulation language (DML) operations on temporary tables in a physical standby database with the Oracle Active Data Guard option.
However, data definition language (DDL) operations that create temporary tables must be issued on the primary database.
可以為特定會話或整個系統啟用臨時撤消。
You can enable temporary undo for a specific session or for the whole system.
使用ALTER session語句為會話啟用臨時撤消時，會話將創建臨時撤消，而不會影響其他會話。
When you enable temporary undo for a session using an ALTER SESSION statement, the session creates temporary undo without affecting other sessions.
使用ALTER system語句為系統啟用臨時撤消時，所有現有會話和新會話都將創建臨時撤消。
When you enable temporary undo for the system using an ALTER SYSTEM statement, all existing sessions and new sessions create temporary undo.
當會話第一次使用臨時對象時，將為會話的其余部分設置
TEMP_UNDO_ENABLED初始化參數的當前值
When a session uses temporary objects for the first time, the current value of the TEMP_UNDO_ENABLED initialization parameter is set for the rest of the session.
因此，如果為會話啟用了臨時撤消，並且會話使用臨時對象，則不能為會話禁用臨時撤消。
Therefore, if temporary undo is enabled for a session and the session uses temporary objects, then temporary undo cannot be disabled for the session.
類似地，如果對會話禁用臨時撤消，並且會話使用臨時對象，則不能對會話啟用臨時撤消。
Similarly, if temporary undo is disabled for a session and the session uses temporary objects, then temporary undo cannot be enabled for the session.
對於具有Oracle Active Data Guard選項的物理備用數據庫，默認情況下會啟用臨時撤消。
Temporary undo is enabled by default for a physical standby database with the Oracle Active Data Guard option.
由於默認設置，TEMP_UNDO_ENABLED初始化參數對具有活動數據保護選項的物理備用數據庫沒有影響。
The TEMP_UNDO_ENABLED initialization parameter has no effect on a physical standby database with Active Data Guard option because of the default setting.
Enabling and Disabling Temporary Undo
ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE;
ALTER SESSION SET TEMP_UNDO_ENABLED = FALSE;
ALTER SYSTEM SET TEMP_UNDO_ENABLED = TRUE;
ALTER SYSTEM SET TEMP_UNDO_ENABLED = FALSE;
十四：DML(insert/delete/update)哪種操作產生的UNDO最多。
insert操作回滾段中只記錄這些記錄的ROWID，產生的UNDO最少。
delete操作記錄了所有刪除的記錄的詳細信息，以便於rollback，產生的UNDO最多。
update操作需要記錄相關字段的undo信息 。
十五：請介紹UNDO常用的數據字典和視圖有哪些。
Undo Space Data Dictionary Views
在自動撤消管理模式下，可以查詢一組視圖以獲取有關撤消空間的信息。
You can query a set of views for information about undo space in the automatic undo management mode.
除了這里列出的視圖之外，您還可以從視圖中獲取信息，這些視圖可用於查看表空間和數據文件信息。
In addition to views listed here, you can obtain information from the views available for viewing tablespace and data file information.
See "Data Files Data Dictionary Views" for information on getting information about those views.
以下動態性能視圖可用於獲取有關撤消表空間的空間信息：
The following dynamic performance views are useful for obtaining space information about the undo tablespace:
(1)V$UNDOSTAT
包含用於監視和調整撤消空間的統計信息。
Contains statistics for monitoring and tuning undo space.
使用此視圖可以幫助估計當前工作負載所需的撤消空間量。
Use this view to help estimate the amount of undo space required for the current workload.
數據庫還使用此信息來幫助調整系統中的撤消使用情況。
The database also uses this information to help tune undo usage in the system.
此視圖僅在自動撤消管理模式下才有意義。
This view is meaningful only in automatic undo management mode.
(2)V$TEMPUNDOSTAT
包含用於監視和調整臨時撤消空間的統計信息。
Contains statistics for monitoring and tuning temporary undo space.
使用此視圖可以幫助估計當前工作負載的臨時表空間中所需的臨時撤消空間量。
Use this view to help estimate the amount of temporary undo space required in the temporary tablespaces for the current workload.
數據庫還使用這些信息來幫助調整系統中臨時撤消的使用。
The database also uses this information to help tune temporary undo usage in the system.
只有啟用臨時撤消時，此視圖才有意義。
This view is meaningful only when temporary undo is enabled.
(3)V$ROLLSTAT
對於自動撤消管理模式，信息反映撤消表空間中撤消段的行為。
For automatic undo management mode, information reflects behavior of the undo segments in the undo tablespace.
(4)V$TRANSACTION
Contains undo segment information
包含撤消段信息
(5)DBA_UNDO_EXTENTS
顯示撤消表空間中每個擴展數據塊的狀態和大小。
Shows the status and size of each extent in the undo tablespace.
(6)DBA_HIST_UNDOSTAT
包含V$UNDOSTAT信息的統計快照。
Contains statistical snapshots of V$UNDOSTAT information.
V$UNDOSTAT視圖對於監視事務執行對當前實例中undo空間的影響非常有用。
The V$UNDOSTAT view is useful for monitoring the effects of transaction execution on undo space in the current instance.
統計信息可用於實例中的撤消空間消耗、事務並發性、撤消保留的優化以及長時間運行的查詢的長度和SQL ID。
Statistics are available for undo space consumption, transaction concurrency, the tuning of undo retention, and the length and SQL ID of long-running queries in the instance.
視圖中的每一行都包含實例中每隔10分鍾收集的統計信息。
Each row in the view contains statistics collected in the instance for a ten-minute interval.
行按“BEGIN_TIME”列值降序排列。
The rows are in descending order by the BEGIN_TIME column value.
每一行都屬於由標記的時間間隔(BEGIN_TIME, END_TIME)。
Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME).
每列表示在該時間間隔內為特定統計信息收集的數據。
Each column represents the data collected for the particular statistic in that time interval.
視圖的第一行包含（部分）當前時間段的統計信息。
The first row of the view contains statistics for the (partial) current time period.
該視圖總共包含576行，周期為4天。
The view contains a total of 576 rows, spanning a 4 day cycle.
十六：請介紹UNDO常用查詢語句。
(1)查看UNDO基礎信息
Show parameter Undo
select sum(bytes) from dba_free_space where tablespace_name='<undo tablespace>';
select sum(bytes) from dba_data_files where tablespace_name='<undo tablespace>';
select sum(blocks) "UNEXPIRED BLOCKS" from dba_undo_extents where tablespace_name='UNDOTBS1'and status='UNEXPIRED';
select sum(blocks) "EXPIRED BLOCKS" from dba_undo_extents where tablespace_name='UNDOTBS1'and status='EXPIRED';
select sum(blocks) "ACTIVE BLOCKS" from dba_undo_extents where tablespace_name='UNDOTBS1'and status='ACTIVE';
select count(*) from dba_rollback_segs where status='OFFLINE';
select max(tuned_undoretention) from v$undostat;
(2)查看Retention Guarantee
select tablespace_name,
block_size,
extent_management,
segment_space_management,
contents,
retention
from dba_tablespaces;
(3)查看當前各類型extent使用占比
select tablespace_name, status, round(sum(bytes) / 1024 / 1024, 1) size_m
from dba_undo_extents
group by tablespace_name, status
order by 1, 3;
ACTIVE - Undo Extent is Active, Used by a transaction.
EXPIRED - Undo Extent is expired (Exceeded the Undo Retention).
UNEXPIRED - Undo Extent will be required to honor UNDO_RETENTION.
(4)表空間使用率
set pagesize 9999
set pagesize 9999
set linesize 132
select a.tablespace_name,
a.Total_mb,
f.Free_mb,
round(a.total_MB - f.free_mb, 2) Used_mb,
round((f.free_MB / a.total_MB) * 100) "%_Free"
from (select tablespace_name, sum(bytes / (1024 * 1024)) total_MB
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free_MB
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "%_Free";
select tablespace_name, round(sum(bytes) / 1024 / 1024, 1) size_m
from dba_data_files
where tablespace_name like 'UNDO%'
group by tablespace_name
order by 2;
(5)擴容百分比
set pagesize 9999
set pagesize 9999
set linesize 132
select a.tablespace_name,
a.Total_mb,
f.Free_mb,
' Add' ||
to_char((total_MB * (1 - PCT / 100) - Free_mb) / (PCT / 100) / 1024,
'9990.9') || 'GB to ' || PCT || '%' "Add_Size(GB)"
from (select (&pct) PCT from dual),
(select tablespace_name, sum(bytes / (1024 * 1024)) total_MB
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free_MB
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "Add_Size(GB)";
(6)查看回滾段名稱及大小
select segment_name,
tablespace_name,
r.status,
(initial_extent / 1024) InitialExtent,
(next_extent / 1024) NextExtent,
max_extents,
v.curext CurExtent
From dba_rollback_segs r, v$rollstat v
Where r.segment_id = v.usn(+)
order by segment_name;
(7)前50使用最大undo的SESSION信息
set linesize 200 pagesize 1000
col module for a20 trunc
col username for a12 trunc
col sid for a12 trunc
select *from (
SELECT a.sid||'_'||a.serial# sid,a.username,a.sql_id,round(b.used_ublk*8/1024,1) size_m,b.used_urec,last_call_et, a.module FROM V$SESSION A,V$TRANSACTION B
WHERE A.TADDR=B.ADDR
AND A.TADDR IS NOT NULL
order by b.used_ublk desc)
where rownum<=50;
(8) 前20最大rollback segment
SELECT *
FROM ( SELECT segment_name,
status,
SUM (bytes) / 1024 / 1024 size_m,
COUNT (*)
FROM dba_undo_extents
WHERE tablespace_name = 'UNDOTBS2'
GROUP BY segment_name, status
ORDER BY size_m DESC)
WHERE ROWNUM <= 20;
(9) 前20活躍回滾段
SELECT *
FROM ( SELECT segment_name,
status,
SUM (bytes) / 1024 / 1024 size_m,
COUNT (*)
FROM dba_undo_extents
WHERE tablespace_name = 'UNDOTBS2' AND STATUS = 'ACTIVE'
GROUP BY segment_name, status
ORDER BY size_m DESC)
WHERE ROWNUM <= 20;
(10)過去7*24小時中UNDO表空間的平均使用量
col UNDO_RETENTION for a15
col DB_BLOCK_SIZE for a15
select ur undo_retention,
dbs db_block_size,
((ur * (ups * dbs)) + (dbs * 24)) / 1024 / 1024 as "M_bytes"
from (select value as ur from v$parameter where name = 'undo_retention'),
(select (sum(undoblks) / sum(((end_time - begin_time) * 86400))) ups
from v$undostat),
(select value as dbs from v$parameter where name = 'db_block_size');
(11)以下SQL語句則按峰值情況計算UNDO表空間所需空間
col UNDO_RETENTION for a15
col DB_BLOCK_SIZE for a15
select ur undo_retention,
dbs db_block_size,
((ur * (ups * dbs)) + (dbs * 24)) / 1024 / 1024 as "M_bytes"
from (select value as ur from v$parameter where name = 'undo_retention'),
(select (undoblks / ((end_time - begin_time) * 86400)) ups
from v$undostat
where undoblks in (select max(undoblks) from v$undostat)),
(select value as dbs from v$parameter where name = 'db_block_size');
(12)查看某個事務正在用哪個undo segment
select s.sid,
s.serial#,
s.sql_id,
v.usn,
segment_name,
r.status,
v.rssize / 1024 / 1024 mb
From dba_rollback_segs r, v$rollstat v, v$transaction t, v$session s
Where r.segment_id = v.usn
and v.usn = t.xidusn
and t.addr = s.taddr
order by segment_name;
(13)查詢回滾需要多久
select usn,
state,
undoblockstotal "Total",
undoblocksdone "Done",
undoblockstotal - undoblocksdone "ToDo",
decode(cputime,
0,
'unknown',
sysdate + (((undoblockstotal - undoblocksdone) /
(undoblocksdone / cputime)) / 86400)) "Estimated time to complete"
from v$fast_start_transactions;
(14) 查看_undo_autotune信息
select a.ksppinm name, b.ksppstvl value, a.ksppdesc description
from x$ksppi a, x$ksppcv b
where a.indx = b.indx
and a.ksppinm = '_undo_autotune';
(15) 查看UNDO信息
set pagesize 25
set linesize 100
column UNXPSTEALCNT heading "# Unexpired|Stolen"
column EXPSTEALCNT heading "# Expired|Reused"
column SSOLDERRCNT heading "ORA-1555|Error"
column NOSPACEERRCNT heading "Out-Of-space|Error"
column MAXQUERYLEN heading "Max Query|Length"
select inst_id,
to_char(begin_time, 'MM/DD/YYYY HH24:MI') begin_time,
UNXPSTEALCNT,
EXPSTEALCNT,
SSOLDERRCNT,
NOSPACEERRCNT,
MAXQUERYLEN,
TUNED_UNDORETENTION
from gv$undostat
order by inst_id, begin_time;
SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON",
MAXQUERYLEN, TUNED_UNDORETENTION
FROM v$UNDOSTAT;
字段說明：
UNXPSTEALCNT
從其他撤消段竊取未過期的塊以滿足空間請求時的嘗試次數
The number of attempts when unexpired blocks were stolen from other undo segments to satisfy space requests
UNXPBLKRELCNT
從撤消段中刪除的、供其他事務使用的未過期塊數
The number of unexpired blocks removed from undo segments to be used by other transactions
UNXPBLKREUCNT
事務重用的未過期撤消塊數
The number of unexpired undo blocks reused by transactions
EXPSTEALCNT
從其他撤消段竊取過期擴展數據塊以滿足空間請求的嘗試次數
The number of attempts when expired extents were stolen from other undo segments to satisfy a space requests
EXPBLKRELCNT
為滿足空間請求而從其他撤消段竊取的過期擴展數據塊數
The number of expired extents stolen from other undo segments to satisfy a space request
EXPBLKREUCNT
在相同撤消段中重用的過期撤消塊數
The number of expired undo blocks reused within the same undo segments
SSOLDERRCNT
間隔期間發生的ORA-1555錯誤數
The number of ORA-1555 errors that occurred during the interval
NOSPACEERRCNT
空間不足錯誤數
The number of Out-of-Space errors
當UNXPSTEALCNT到EXPBLKREUCNT列包含非零值時，表示空間壓力。
When the columns UNXPSTEALCNT through EXPBLKREUCNT hold non-zero values, it is an indication of space pressure.
如果列ssoldercnt不為零，則未正確設置UNDO_RETENTION。
If the column SSOLDERRCNT is non-zero, then UNDO_RETENTION is not properly set.
如果NOSPACEERRCNT列不為零，則存在嚴重的空間問題。
If the column NOSPACEERRCNT is non-zero, then there is a serious space problem.
在10g DBA_HIST_UNDOSTAT視圖中，包含V$UNDOSTAT信息的統計快照。
In 10g DBA_HIST_UNDOSTAT view contains statistical snapshots of V$UNDOSTAT information.
注意：如果參數_undo_autotune=FALSE，則在表X$KTUSMST2中不會生成數據，該表是視圖DBA_HIST_UNDOSTAT視圖中，包含V的源表
Note: If the parameter _undo_autotune=FALSE, there will be no data generated in table X$KTUSMST2 which is the source table of view dba_hist_undostats
With Oracle database 10g, you can use the Undo Advisor feature to get Undo sizing Recommendations
Refer: Check Current Undo Configuration and Advise Recommended Setup (Doc ID 1579035.1)
For database version 10g and above, use the following script. Ensure to execute the same as SYSDBA.
RDBMS version 10g and above:
SET SERVEROUTPUT ON
SET LINES 600
ALTER SESSION SET NLS_DATE_FORMAT = 'DD/MM/YYYY HH24:MI:SS';
DECLARE
v_analyse_start_time DATE := SYSDATE - 7;
v_analyse_end_time DATE := SYSDATE;
v_cur_dt DATE;
v_undo_info_ret BOOLEAN;
v_cur_undo_mb NUMBER;
v_undo_tbs_name VARCHAR2(100);
v_undo_tbs_size NUMBER;
v_undo_autoext BOOLEAN;
v_undo_retention NUMBER(5);
v_undo_guarantee BOOLEAN;
v_instance_number NUMBER;
v_undo_advisor_advice VARCHAR2(100);
v_undo_health_ret NUMBER;
v_problem VARCHAR2(1000);
v_recommendation VARCHAR2(1000);
v_rationale VARCHAR2(1000);
v_retention NUMBER;
v_utbsize NUMBER;
v_best_retention NUMBER;
v_longest_query NUMBER;
v_required_retention NUMBER;
BEGIN
select sysdate into v_cur_dt from dual;
DBMS_OUTPUT.PUT_LINE(CHR(9));
DBMS_OUTPUT.PUT_LINE('- Undo Analysis started at : ' || v_cur_dt || ' -');
DBMS_OUTPUT.PUT_LINE('--------------------------------------------------');
v_undo_info_ret := DBMS_UNDO_ADV.UNDO_INFO(v_undo_tbs_name, v_undo_tbs_size, v_undo_autoext, v_undo_retention, v_undo_guarantee);
select sum(bytes)/1024/1024 into v_cur_undo_mb from dba_data_files where tablespace_name = v_undo_tbs_name;
DBMS_OUTPUT.PUT_LINE('NOTE:The following analysis is based upon the database workload during the period -');
DBMS_OUTPUT.PUT_LINE('Begin Time : ' || v_analyse_start_time);
DBMS_OUTPUT.PUT_LINE('End Time : ' || v_analyse_end_time);
DBMS_OUTPUT.PUT_LINE(CHR(9));
DBMS_OUTPUT.PUT_LINE('Current Undo Configuration');
DBMS_OUTPUT.PUT_LINE('--------------------------');
DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace',55) || ' : ' || v_undo_tbs_name);
DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (datafile size now) ',55) || ' : ' || v_cur_undo_mb || 'M');
DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (consider autoextend) ',55) || ' : ' || v_undo_tbs_size || 'M');
IF V_UNDO_AUTOEXT THEN
DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : ON');
ELSE
DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : OFF');
END IF;
DBMS_OUTPUT.PUT_LINE(RPAD('Current undo retention',55) || ' : ' || v_undo_retention);
IF v_undo_guarantee THEN
DBMS_OUTPUT.PUT_LINE(RPAD('UNDO GUARANTEE is set to',55) || ' : TRUE');
ELSE
dbms_output.put_line(RPAD('UNDO GUARANTEE is set to',55) || ' : FALSE');
END IF;
DBMS_OUTPUT.PUT_LINE(CHR(9));
SELECT instance_number INTO v_instance_number FROM V$INSTANCE;
DBMS_OUTPUT.PUT_LINE('Undo Advisor Summary');
DBMS_OUTPUT.PUT_LINE('---------------------------');
v_undo_advisor_advice := dbms_undo_adv.undo_advisor(v_analyse_start_time, v_analyse_end_time, v_instance_number);
DBMS_OUTPUT.PUT_LINE(v_undo_advisor_advice);
DBMS_OUTPUT.PUT_LINE(CHR(9));
DBMS_OUTPUT.PUT_LINE('Undo Space Recommendation');
DBMS_OUTPUT.PUT_LINE('-------------------------');
v_undo_health_ret := dbms_undo_adv.undo_health(v_analyse_start_time, v_analyse_end_time, v_problem, v_recommendation, v_rationale, v_retention, v_utbsize);
IF v_undo_health_ret > 0 THEN
DBMS_OUTPUT.PUT_LINE('Minimum Recommendation : ' || v_recommendation);
DBMS_OUTPUT.PUT_LINE('Rationale : ' || v_rationale);
DBMS_OUTPUT.PUT_LINE('Recommended Undo Tablespace Size : ' || v_utbsize || 'M');
ELSE
DBMS_OUTPUT.PUT_LINE('Allocated undo space is sufficient for the current workload.');
END IF;
SELECT dbms_undo_adv.best_possible_retention(v_analyse_start_time, v_analyse_end_time) into v_best_retention FROM dual;
SELECT dbms_undo_adv.longest_query(v_analyse_start_time, v_analyse_end_time) into v_longest_query FROM dual;
SELECT dbms_undo_adv.required_retention(v_analyse_start_time, v_analyse_end_time) into v_required_retention FROM dual;
DBMS_OUTPUT.PUT_LINE(CHR(9));
DBMS_OUTPUT.PUT_LINE('Retention Recommendation');
DBMS_OUTPUT.PUT_LINE('------------------------');
DBMS_OUTPUT.PUT_LINE(RPAD('The best possible retention with current configuration is ',60) || ' : ' || v_best_retention || ' Seconds');
DBMS_OUTPUT.PUT_LINE(RPAD('The longest running query ran for ',60) || ' : ' || v_longest_query || ' Seconds');
DBMS_OUTPUT.PUT_LINE(RPAD('The undo retention required to avoid errors is ',60) || ' : ' || v_required_retention || ' Seconds');
END;
/
- Undo Analysis started at : 30/08/2013 11:08:40 -
--------------------------------------------------
NOTE:The following analysis is based upon the database workload during the period -
Begin Time : 23/08/2013 11:08:40
End Time : 30/08/2013 11:08:40
Current Undo Configuration
--------------------------
Current undo tablespace : UNDOTBS2
Current undo tablespace size (datafile size now) : 20M
Current undo tablespace size (consider autoextend) : 20M
AUTOEXTEND for undo tablespace is : ON
Current undo retention : 900
UNDO GUARANTEE is set to : FALSE
Undo Advisor Summary
---------------------------
Finding 1:Undo Tablespace is under pressure. Recommendation 1:Size undo tablespace to 26 MB
Undo Space Recommendation
-------------------------
Minimum Recommendation : Size undo tablespace to 26 MB
Rationale : Increase undo tablespace size so that long running queries will not fail
Recommended Undo Tablespace Size : 26M
Retention Recommendation
------------------------
The best possible retention with current configuration is : 9171 Seconds
The longest running query ran for : 2543 Seconds
The undo retention required to avoid errors is : 2543 Seconds
PL/SQL procedure successfully completed.