關於undo的幾個引數：
1、undo_management：
undo段的管理方式（AUTO）
2、undo_retention：
一個事務提交以後，事務所對應的undo資料儘量保留900秒
查詢引數：
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- -----------
undo_management string AUTO -- undo段是自動管理的
undo_retention integer 900 -- 一個事務提交以後，事務所對應的undu資料，儘量保證在900秒以內不被覆蓋，這個引數我們經常會改為24小時
undo_tablespace string UNDOTBS1
undo_retention：
這個引數改了以後，還不能保證它確確實實能夠把一個事務提交以後，事務所對應的undo資料保留900秒；如果要確認能保留的話，還需要做幾件事：
1、查詢undo表空間，裡面有一個引數 RETENTION 必須是：GUARANTEE
select * from dba_tablespaces where tablespace_name='UNDOTBS1';
修改retention引數：
SQL> alter tablespace UNDOTBS1 retention guarantee;
Tablespace altered.
select * from dba_tablespaces where tablespace_name='UNDOTBS1';
2、還要確認UNDOTBS1表空間，所對應的資料檔案是可以自動擴充套件的：
select * from dba_data_files;
查詢undo表空間裡面的undo段（預設11個undo段）：
select * from v$rollname;
隨著事務越來越繁忙，undo段會自己增加（這是因為段的自動管理方式）
或者（這個資訊更多一些）：
select * from dba_rollback_segs
查詢一個undo段裡面的區的組成：
select * from dba_extents where segment_name='_SYSSMU1_3724004606$'
使用EM，看一下undo相關的一些維護：
undo表空間大小的影響因素：
1、undo資料的生成速度
2、最大select的執行時間
一個事務的開始和結束（挖掘日誌分析：DDL、commit、rollback）：
SQL> create user u1 identified by u1 default tablespace testtb1;
User created.
SQL> grant connect,resource,dba to u1;
Grant succeeded.
SQL> connect u1/u1
Connected.
SQL> select sid from v$mystat where rownum=1;
SID
----------
932
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 CURRENT
2 INACTIVE
3 INACTIVE
切換一下日誌（希望所有的操作都在同一個日誌裡面）：
SQL> alter system switch logfile;
System altered.
SQL> alter system flush buffer_cache; -- 清空buffer cache裡面的髒塊（也就是將所有髒塊寫入到磁碟）
System altered.
現在系統用2號redo log日誌：
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 CURRENT
3 INACTIVE
然後建一個表t1，插入一行資料：
SQL> create table t1(id int,name varchar2(20));
Table created.
SQL> insert into t1 values(1,'zyr');
1 row created.
SQL> commit;
Commit complete.
SQL> update t1 set id=2 where id=1;
1 row updated.
SQL> rollback;
Rollback complete.
SQL> update t1 set id=2 where id=1;
1 row updated.
SQL> create table t2(id int);
Table created.
檢視日誌狀態：
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 CURRENT -- 還是2號日誌
3 INACTIVE
切換日誌，讓剛才的這些操作都在2號日誌裡，方便檢視：
SQL> alter system switch logfile;
System altered.
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 ACTIVE
3 CURRENT
挖掘日誌，檢視2號日誌的內容：
啟用日誌的追加功能，挖掘的資訊就會多一些了
模擬一個事務（大事務）沒有提交，資料庫突然崩潰，資料庫重新啟動，select訪問這個表，檢視日誌、以及執行時統計資訊
檢視日誌狀態：
SQL> select group#,status from v$log;
GROUP# STATUS
---------- ----------------
1 INACTIVE
2 INACTIVE
3 CURRENT
SQL> select GROUP#,BYTES/1024/1024,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
GROUP# BYTES/1024/1024 FIRST_CHANGE# NEXT_CHANGE#
---------- --------------- ------------- ------------
1 50 1295995 1314696
2 50 1314696 1318831
3 50 1318831 2.8147E+14
新增日誌組：
查詢日誌狀態：
SQL> select GROUP#,BYTES/1024/1024,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
GROUP# BYTES/1024/1024 FIRST_CHANGE# NEXT_CHANGE#
---------- --------------- ------------- ------------
1 50 1295995 1314696
2 50 1314696 1318831
3 50 1318831 2.8147E+14
4 100 0 0
5 100 0 0
建一個表：
SQL> show user;
USER is "U1"
SQL> create table t3 as select a.* from dba_objects a,dba_objects b where rownum<=1000000; -- 建立了t3表，有1000000行Table created.
再次查詢日誌狀態：
SQL> select GROUP#,BYTES/1024/1024,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
GROUP# BYTES/1024/1024 FIRST_CHANGE# NEXT_CHANGE#
---------- --------------- ------------- ------------
1 50 1295995 1314696
2 50 1314696 1318831
3 50 1318831 1321928
4 100 1321928 2.8147E+14 -- 現在用第四組日誌了
5 100 0 0
刪除t3表（相當於一個大事務，t3表有1000000行）：
SQL> delete from t3;
1000000 rows deleted.
這時候，事務沒有提交
檢視日誌狀態：
SQL> select GROUP#,BYTES/1024/1024,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
GROUP# BYTES/1024/1024 FIRST_CHANGE# NEXT_CHANGE#
---------- --------------- ------------- ------------
1 50 1322555 1322591
2 50 1322591 1322624
3 50 1322624 1322661
4 100 1322661 2.8147E+14
5 100 1322473 1322555
5組日誌已經迴圈使用了一遍
SQL> select GROUP#,BYTES/1024/1024,FIRST_CHANGE#,NEXT_CHANGE# from v$log;
GROUP# BYTES/1024/1024 FIRST_CHANGE# NEXT_CHANGE#
---------- --------------- ------------- ------------
1 50 1322555 1322591
2 50 1322591 1322624
3 50 1322624 1322661
4 100 1322661 1322755
5 100 1322755 2.8147E+14
現在日誌又切換到第5組了
關閉資料庫（模擬一個事務未提交，資料庫崩潰了）：
SQL> shutdown abort;
ORACLE instance shut down.
重新啟動資料庫，速度會有點慢，因為要進行大量的前滾和回滾（之前資料庫有事務未提交，資料庫崩潰了）：
SQL> startup
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 1375734944 bytes
Database Buffers 218103808 bytes
Redo Buffers 7319552 bytes
Database mounted.
Database opened.
查詢日誌狀態：
SQL> select GROUP#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,STATUS from v$log;
GROUP# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# STATUS
---------- ---------- ------------- ------------ ----------------
1 14 1343262 1343624 INACTIVE
2 15 1343624 1343714 INACTIVE
3 16 1343714 1343766 ACTIVE
4 17 1343766 1343859 ACTIVE
5 18 1343859 2.8147E+14 CURRENT
資料庫重啟過程中，產生了好多日誌，redo log又被迴圈使用了一遍
================================================================================================================
undo表空間全新認識：
1、undo段、undo extent、undo表空間最佳實踐、undo表空間監控(EM)
2、rollback、commit
3、事務的開始和結束、挖掘日誌分析
DDL、commit、rollback
4、模擬一個事務沒有提交，資料庫突然崩潰，資料庫重新啟動，select訪問這個表，檢視日誌、以及執行時統計資訊
5、dump undo段頭塊分析事務表、dump表的資料庫分析事務槽（整個操作在一個事務模擬中分析）
6、分析xid、v$transaction
7、模擬ORA-01555錯誤及MOS解決方案
8、模擬insert、update、delete對資源的消耗