undo表空間的作用和管理

一、UNDO的產生

dml操作會產生undo的數據塊。
update時, server process會在 databuffer中找到該記錄的記錄塊,沒有就從datafile中找并讀入 data buffer。在修改之前,先放到undo段 active狀態,并在數據塊頭記錄undo段中該數據塊的位置,讀寫這個塊時會占用事務槽,會將該事務號記錄在數據塊的頭部。然后進行 update,并將該塊放到 dirty list檢查點隊列,等待dbwr進行寫操作。

二、UNDO的作用

還原段的引入，主要是為了解決三個問題。

1 事務恢復：在進行DML操作時，insert、update、delete操作時，undo段記錄事務的反向操作并且redo日志也記錄undo段的操作，既redo保護undo段的信息。當實例關閉或意外崩潰后，再次open時實例需要對沒有commit的事務進行回滾，完成事務的恢復。
2 事務回滾：用戶進行DML操作后沒有進行commit，需要修改前的數據。只要該操作在undo段保護的時間內，此時執行rollback操作可以回滾到最近記錄點或上一次commit操作后的狀態，恢復到數據修改前的狀態。
3 讀一致性：當進行DML操作時，undo段會記錄數據變更前的狀態（通過構造原數據的一致性數據塊）。如果用戶還沒有進行commit操作，其他人查詢此條數據會看到數據變更前的狀態。因為其他用戶讀到的數據是undo段中原數據塊中的數據，保證沒有commit的數據讀取的一致性。

4 倒敘查詢: flashback query、 flashback table
10G后增加了新特性一一閃回。利用undo已經提交的塊,閃回數據庫和表。已經提交的塊 inactive數據是不能提交的,但可以倒回到某個時間點。
SQL>select name, flashback_on from v$database;

我們常常會忽略對它的監控，這會導致UNDO表空間可能出現以下問題：
1).空間使用率100%，導致DML操作無法進行。
2).告警日志中出現大量的ORA-01555告警錯誤。
3).實例恢復失敗，數據庫無法正常打開。

三、undo參數解析

SQL> show parameter undo;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
undo_management              string     AUTO
undo_retention                 integer     900
undo_tablespace              string     UNDOTBS1

1 初始化參數undo_management

該初始化參數用于指定UNDO數據的管理方式.如果要使用自動管理模式,為AUTO；如果使用手工管理模式,為MANUAL。

使用自動管理模式時,oracle會使用undo表空間管理undo管理；使用手工管理模式時,oracle會使用回滾段管理undo數據。
如果使用自動管理模式時,如果沒有配置初始化參數UNDO_TABLESPACE。Oracle會自動選擇第一個可用的UNDO表空間存放UNDO數據,如果沒有可用的UNDO表空間,oracle會使用SYSTEM回滾段存放UNDO記錄,并在ALTER文件中記載警告

2 undo_retention

該參數是一個時間值。說明當還原段中的事務在提交后繼續保留的時間，為flashback等工具進行如閃回數據等操作，該參數默認值為900秒，可以動態修改。
當保留時間超過undo_retention所指定的時間以后，該undo塊才能夠被其他事務覆蓋。當我們使用AUM的時候，并且設置了undo_retention以后，undo塊的狀態就會存在如下4種情況：

active：活躍的，表示正在使用該數據塊的事務還沒有提交或回滾。
inactive：不活躍的，表示該數據塊上沒有活動的事務，該狀態的數據塊可以被其他事務覆蓋。
expired：達到時間上限的，表示該數據塊持續inactive的時間已經超過了undo_retention所指定的時間，如果沒有freed、
freed：已經釋放的，表示該數據塊是空的，從來沒有使用過。

查看Oracle自動調整undo_retention的值可以通過以下查詢獲得：

select to_char(begin_time,'mm/dd/yyyy hh34:mi:ss') begin_tiem,TUNED_UNDORETENTION from v$undostat;

undo表空間獲取空間的申請順序
freed=>expired=>自動拓展（必須該參數為yes狀態才可以）=>inactive（下面詳細解釋此種狀態的覆蓋）=>ORA-30036
而且在使用數據塊時盡量使用相對更短的連續extent，如不足時才使用更連續的extent。這樣能夠減少碎片的產生。并且盡量不去覆蓋inactive狀態的數據塊，如果空間足夠會最大限度的保存此種狀態的數據塊包含的信息。

數據查詢出現ORA-1555的原因，和如何避免出現？
ORA-1555錯誤的出現，共有兩種原因。
首先解釋一下Oracle在數據變更后，如何保證原始數據能夠在變更數據不提交的情況下如何得到保護。
原始數據已經被update、delete等DML操作，但變更數據還未進行commit，此時Oracle通過UNDO段構造與原數據相同的一致性數據塊，保證其他用戶數據不會出現臟讀。但在commit后該事務占用的回滾段事務狀態會被標記為不活躍的（inactive），回滾段中此區段可以被覆蓋重用。
a、回滾段數據被覆蓋
出現原因：如果一個查詢需要使用已經變更為inactive并且被覆蓋的回滾段一致性讀塊內的數據，想實現一致性讀，那么此時就會出現Oracle著名的ORA-01555錯誤。原因有SQL語句執行時間太長、UNDO表空間過小、事務量過大，提交過于頻繁，導致執行SQL過程中進行一致性讀時，修改的原數據（UNDO數據）在UNDO表空間中已經被覆蓋，不能構造一致性讀塊。
避免出現的方法：盡量加大回滾段的容量，盡量將undo_retention參數內的提交后保留時間設置更大一些。如果需要保證原數據在retention保留時間內絕對能夠查找，那么在保證回滾段容量足夠用的前提下可以將表空間參數中加入 retention guarantee以保證原數據的不被任何情況的覆蓋。優化出錯的SQL和盡量將大事務分割成小事務，并且不進行頻繁的提交。

出現原因：相比第一種，這種出現的幾率11g會低很多。不做深入。

設置undo_retention參數

SQL> alter system set undo_retention=1500;

再次查詢

SQL> show parameter undo_retention;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
undo_retention                 integer     1500

3 UNDO表空間guarantee屬性

SQL> SELECT tablespace_name, retention FROM dba_tablespaces where tablespace_name='UNDOTBS1';

TABLESPACE_NAME            RETENTION
------------------------------ -----------
UNDOTBS1               NOGUARANTEE

修改RETENTION

SQL> alter tablespace undotbs1 retention guarantee;

再次查詢

SQL> SELECT tablespace_name, retention FROM dba_tablespaces where tablespace_name='UNDOTBS1';

TABLESPACE_NAME            RETENTION
------------------------------ -----------
UNDOTBS1               GUARANTEE

四、創建、維護undo表空間

1 創建

SQL> create undo tablespace undotab1 datafile '/ooradata/lxtab/test_undotab1.dbf' size 200m autoextend on;

--查詢

SQL> select tablespace_name,extent_management,contents,logging,status from dba_tablespaces where tablespace_name='UNDOTAB1';

TABLESPACE_NAME            EXTENT_MAN CONTENTS  LOGGING   STATUS
------------------------------ ---------- --------- --------- ---------
UNDOTAB1               LOCAL      UNDO        LOGGING   ONLINE

--查詢

SQL> col FILE_NAME for a50

select file_name,file_id,bytes/(1024*1024) M,autoextensible from dba_data_files where tablespace_name='UNDOTAB1';

FILE_NAME                          FILE_ID           M AUT
-------------------------------------------------- ---------- ---------- ---
/ooradata/lxtab/test_undotab1.dbf                7         200 YES

具體語法看之前表空間語法部分，創建了一個200MB的undo表空間已經聯機，管理方式為本地管理，已經受到日志保護，并且空間不足時自動增長空間。

2 undo表空間重命名

--先查看undo有哪些表空間

SQL> select tablespace_name,status,contents from dba_tablespaces where CONTENTS='UNDO';

TABLESPACE_NAME            STATUS     CONTENTS
------------------------------ --------- ---------
UNDOTBS1               ONLINE     UNDO
UNDOTBS2               ONLINE     UNDO
UNDOTBS                ONLINE     UNDO
UNDOTAB1               ONLINE     UNDO
UNDOTAB2               ONLINE     UNDO

--查詢默認undo表空間

SQL> show parameter undo_tablespace;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace              string     UNDOTBS1

a） 修改非系統默認UNDO表空間名

SQL> alter tablespace UNDOTAB1 rename to UNDOTAB_one;

驗證

SQL> select tablespace_name,status,contents from dba_tablespaces where TABLESPACE_NAME='UNDOTAB_ONE';

TABLESPACE_NAME            STATUS     CONTENTS
------------------------------ --------- ---------
UNDOTAB_ONE               ONLINE     UNDO

非系統默認UNDO表空間修改后立即生效

b）修改系統默認undo表空間名

SQL> alter tablespace UNDOTBS1 rename to UNDOTBS_ONE;

驗證

SQL> show parameter undo_tablespace;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace              string     UNDOTBS1

五、閃回

1 閃回需要開歸檔

a）查看歸檔狀態

SQL> show parameter recovery;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest             string
db_recovery_file_dest_size         big integer 0
recovery_parallelism             integer     0

b）建立歸檔路徑，并改變授權

ORACLE>mkdir /flash

ORACLE>chown oracle:oinstall /flash

c）設置大小和歸檔路徑--一定要先制定大小

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=4g scope=both;

SQL> alter system set db_recovery_file_dest='/flash' scope=both;

d）關閉數據庫，啟動到mount狀態

shutdown immediate

startup mount

e）開啟歸檔

SQL> alter database flashback on;

f）啟動數據庫

alter database open;

驗證

SQL> show parameter recovery;

NAME                     TYPE     VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest             string     /flash
db_recovery_file_dest_size         big integer 4G
recovery_parallelism             integer     0

SQL> select name,flashback_on from v$database;

NAME      FLASHBACK_ON
--------- ------------------
TEST      YES

關閉閃回：需要重復步驟d，e步驟是SQL>alter database flashback off;   再進行步驟f

注意 ：步驟c也可以使用修改參數的方式

ORACLE>cd $ORACLE_HOME/dbs

vi intitest.ora

2 閃回的作用

查詢閃回文件大小

SQL> select name,bytes/1048576 m from v$sgastat where pool='shared pool' and name like '%flash%';

后續再細講