Oracle 面試寶典-UNDO篇

一：請描述什麼是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期間的資料不會被覆蓋。

Retention Guarantee
為了保證長時間執行的查詢或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

官方解釋如下：

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.
建議：
(1)減少查詢的執行時間（調優）。
(2)保證使用的事務“大小適當”。確保沒有不必要地過於頻繁地提交。
(3)使用DBMS_STATS掃描相關的物件，載入之後完成這些物件的清理。由於塊清除是極大量的UPDATE或INSERT造成的，所以很有必要這樣做。
(4)允許UNDO表空間擴大，為之留出擴充套件的空間，並增加UNDO保持時間。

如何找到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.

2.) OUT OF LINE LOBs
"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段。
1. 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段聯機並使用它。
2. If no undo segment found then oracle tries to online an off-line undo segment and use it.
3.如果沒有要聯機的UNDO段，則建立一個新的UNDO段並使用它。
3. If no undo segments to online, then we create a new undo segment and use it.
4.如果空間不允許建立undo段，那麼我們嘗試重用現有undo段中過期的區段。
4. 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的可用塊。
1. If the current extent has more free blocks then use the next free block that is all ready allocated to the extent.
2.如果當前區段沒有空閒塊，並且該段的下一區段已過期，則在下一區段中包裝該區段並返回第一個區段。
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段，並返回新擴充套件資料塊中的第一個塊。
3. 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段。返回資料塊的第一個空閒塊。
4. 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段。返回資料塊的第一個空閒塊。
5. 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段新增一個區段，然後返回塊。
6.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。否則，請換行到下一個擴充套件資料塊。
7. 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段以供重用。
8. 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”中）
9. 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=(SELECT MAX(undoblks) FROM v$undostat);
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表空間中所有資料檔案的實際大小。
a. 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保留值的值。
c. 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的自動調整
d. 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
包含撤消段資訊

(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

(16) 檢視UNDO Advisor

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;
/

Sample Output

- 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.

#####chenjuchao 20210614#####