您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關undo表空間該怎么理解,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
相關視圖:
1、v$sysstat(查看用戶提交數和回滾數)
SQL> SELECT name,value from v$sysstat where name like 'user %';
NAME VALUE
---------------------------------------------------------------- ----------
user commits 176
user rollbacks 0
user calls 328
user I/O wait time 3132
我們數據庫中的awr報告中,Rollback per transaction %的值就是通過這兩個值計算出來:
Round(User rollbacks/(user commit+user rollback),4)*100%
該指標數越接近于0說明數據庫的回滾越少。
2、V$ROLLNAME:回滾段名稱和回滾段ID信息。
對于回滾表空間,oracle默認會初始化10個回滾段,然后自動的分配或回收
3、V$ROLLSTAT:該視圖保存著所有UNDO表空間中每一個已分配的回滾段當前狀態以及相關的統計信息,不顯示狀態在OFFLINE的回滾段。
從v$rollstat中也可以看到對應的回滾段信息,XACTS是代表活動的事務。
USN:回滾段標識
RSSIZE:回滾段默認大小
XACTS:活動事務數
WRITES:回滾段寫入數(單位:bytes)
SHRINKS:回滾段收縮次數
EXTENDS:回滾段擴展次數
WRAPS:回滾段翻轉(wrap)次數
GETS:獲取回滾段頭次數
WAITS:回滾段頭等待次數
SQL> select usn,writes,rssize,xacts,hwmsize,shrinks,wraps from v$rollstat;
USN WRITES RSSIZE XACTS HWMSIZE SHRINKS WRAPS
---------- ---------- ---------- ---------- ---------- ---------- ----------
0 7620 385024 0 385024 0 1
21 267816 2088960 0 2088960 0 0
22 36122 253952 1 253952 0 0
4、DBA_ROLLBACK_SEGS:此字典顯示所有回滾段的當前狀態以及與存儲空間分配相關的信息,包括undo表空間的使用情況。
select segment_name,owner from dba_rollback_segs where tablespace_name='UNDOTBS3';
SEGMENT_NAME OWNER
------------------------------ ------
_SYSSMU21$ PUBLIC
_SYSSMU22$ PUBLIC
5、V$UNDOSTAT:保存了某一時間段的整個UNDO表空間使用的統計信息以及UNDO自動優化的結果,超出時間就會到DBA_HIST_UNDOSTAT中。
6、DBA_UNDO_EXTENTS:保存了UNDO表空間中所有已分配的數據區的存儲空間分配情況與使用情況,是得到UNDO數據當前存在狀態的一個重要的視圖。
SQL> select tablespace_name,status,sum(bytes)/1024/1024/1024 from dba_undo_extents group by tablespace_name,status;
SQL> select owner,segment_name,extent_id,file_id,blocK_id from dba_undo_extents;
OWN SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID
--- ------------------------------ ---------- ---------- ----------
SYS _SYSSMU20$ 0 9 153
SYS _SYSSMU20$ 1 9 161
SYS _SYSSMU19$ 0 9 137
7、V$TRANSACTION 當前正在進行事務的信息,與UNDO管理相關的是當前事務所涉及的UNDO段,UNDO空間占用等等信息
XIDUSN 表示回滾段號
XIDSLOT表示對應事務槽
START_UBABLK表示事務使用的undo起始block,
UBABLK 表示的是最后一個被使用的undo block,
XIDSQN 表示事務槽重用的遞增序號
UBASQN 回滾段重用的遞增序號
The slots in the transaction table in the undo segment header
are continuously being reused. Each time a slot it re-used,
its sequence number (xidsqn) goes up.(表示事務槽重用的遞增序號)
Similarly, undo blocks are re-used (though it takes more
time to get round to re-using them than transaction slots).
Each time an undo block is "newed" and reused, its
sequence number UBASQN goes up.(回滾段重用的遞增序號)
8、v$undostat
該視圖可以用來查看回滾段開始使用時間和結束時間,回滾段被盜用的信息,空間不足,或ORA-01555錯誤發生等。
基本信息
?BEGIN_TIME:統計開始時間
?END_TIME:統計結束時間
使用信息
?UNDOTSN:最后報告的活動的UNDO表空間的ID。
?UNDOBLKS:期間產生的UNDO數據塊的總數。
?TXNCOUNT:期間執行事務的總數。
?MAXQUERYLEN:期間完成的單個查詢執行時間最長的長度,單位是秒。此時間計算方法是從游標打開到最后一次執行/提取數據所花費的時間。利用此時間可以調整相應的UNDO RETENTION。不過由于存在游標打開但是中間等待了很長時間沒有操作之后再度取數據的情況,因此次數據也不一定準確。
?MAXQUERYID:上面所說查詢的SQL ID。
?MAXCONCURRENCY:期間并發事務的最大數值。
未過期UNDO數據盜用信息
?UNXPSTEALCNT:期間發生的未過期UNDO數據盜用的次數。
?UNXPBLKRELCNT:期間發生的未過期UNDO數據被盜用數據塊的數量。
?UNXPBLKREUCNT:期間發生的未過期UNDO數據盜用后被重用的數據塊的數量。
已過期UNDO數據盜用信息
?EXPSTEALCNT:期間發生的盜用次數。
?EXPBLKRELCNT:期間發生的被盜用UNDO數據塊數量。
?EXPBLKREUCNT:期間發生的被盜用數據塊被重用的數量。
錯誤發生信息
?SSOLDERRCNT:期間ORA-1555錯誤發生次數。
?NOSPACEERRCNT:期間空間不足錯誤發生次數。
采樣時UNDO數據使用信息
?ACTIVEBLKS:采樣時刻活動的UNDO塊數量。
?UNEXPIREDBLKS:采樣時刻未過期的UNDO塊數量。
?EXPIREDBLKS:采樣時刻已過期的UNDO塊數量。
自動UNDO優化結果
?TUNED_UNDORETENTION:UNDO表空間中不會被回收的UNDO數據到現在的時間,以秒計。通過查詢這個字段我們能知道在之前某個特定時間完成的事務的UNDO數據是否還存在,對估計Flashback的可用時間很有幫助。
undo數據盜用是指undo數據在還沒有過期的情況下,因為undo表空間大小或者undo_retention的設置等導致的數據塊的被盜用,
可以分為未過期的undo數據盜用和已過期的undo數據盜用,所有的信息都可以在v$undostat視圖中查看:
未過期UNDO數據盜用信息
UNXPSTEALCNT:期間發生的未過期UNDO數據盜用的次數。
UNXPBLKRELCNT:期間發生的未過期UNDO數據被盜用數據塊的數量。
UNXPBLKREUCNT:期間發生的未過期UNDO數據盜用后被重用的數據塊的數量。
已過期UNDO數據盜用信息
EXPSTEALCNT:期間發生的盜用次數。
EXPBLKRELCNT:期間發生的被盜用UNDO數據塊數量。
EXPBLKREUCNT:期間發生的被盜用數據塊被重用的數量。
相關的話,還有dba_extents,一張類似于dba_undo_extents的表,以及dba_esgments和dba_data_files,不過查詢的時候需要指定undo表空間。
字典V$ROLLSTAT和V$UNDOSTAT在名字上面看起來有點相像,但是實際上這兩個視圖的差別還是很大的,V$ROLLSTAT記錄的是整個UNDO表空間各個回滾段使用情況的統計,屬于橫向的;而V$UNDOSTAT記錄的則是各個時間段上面整個UNDO使用情況的統計,屬于縱向的。
一般來說,對于一個insert操作,由于只需記錄插入的rowid所以產生的undo最少,而update操作,相對較多,而delete操作則花費最多的undo空間,一旦回滾,所需要的時間開銷也最大。
oracle一方面不允許其他用戶讀取未提交數據,一方面要保證用戶讀取的數據要來自同一時間點。
undo表空間的幾個參數:
SQL> show parameter undo
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS3
undo_management:用來定義數據庫使用的回滾段是使用自動管理方式還是手動管理方式(AUTO/MANUAL)
undo_tablespace:定義自動管理模式下,當前實例使用哪一個undo表空間。
undo_retention:在自動管理模式下,當回滾段狀態為非激活時,回滾段的保留時間,默認900秒
undo_retention 只是指定undo 數據的過期時間,并不是說,undo 中的數據一定會在undo表空間中保存15 分鐘,比如說剛一個新事務開始的時候,如果undo 表空間已經被寫滿,則新事務的數據會自動覆蓋已提交事務的數據,而不管這些數據是否已過期,但是如果undo_retention的時間過了,那么已經提交的事務中的原數據就立刻不能訪問了,但是他只是失效,只要沒有被覆蓋,他會仍然存在。
只有在一種情況下,undo 表空間能夠確保undo 中的數據在undo_retention 指定時間過期前一定有效,就是為undo 表空間指定Retention 參數,指定之后,oracle 對于undo 表空間中未過期的undo數據不會覆蓋,例如:
SQL> Alter tablespace undotbs1 retention guarantee;
禁止undo 表空間retention guarantee,例如:
SQL> Alter tablespace undotbs1 retention noguarantee;
總的來說,我們去查看undo表空間大小的時候,可以結合dba_data_files查看表空間分配大小,結合dba_undo_extents查看使用大小(包括expired和unexpired)
二v$sysstat和v$rollnamev$rollstat,v$undostat可去查看undo的統計信息,dba_rollback_segs和v$transaction可以查看undo的使用信息,并且通過v$transaction結合v$session還可以查找到對應使用回滾段的回話的sid。
當回滾表空間爆滿處理:
一般來說,我們可以做如下處理:
1、添加undo表空間數據文件,這是要仔細研究過的,除非是你的undo表空間創建的時候真的設置太小,無法滿足需求,才增加數據文件。
2、切換undo表空間,這是采用做多的做法,一般情況下,只有表空間使用非常大,消耗太多的磁盤空間。
------替換表空間:
遵循步驟:1、新建表空間----2、修改參數文件默認undo信息------3、查看回滾段的 使用情況(只用沒有回話使用undo時才能刪除。結合dba_rollback_segs或者v$rollstat查看)---offline原undo表空間---drop表空間
當回滾段損壞的處理:
一般情況下,一旦undo損壞,數據庫就無法正常打開,模擬該環境,物理上刪除undo數據文件:
SQL> startup
ORACLE instance started.
Total System Global Area 218103808 bytes
Fixed Size 1266680 bytes
Variable Size 79694856 bytes
Database Buffers 134217728 bytes
Redo Buffers 2924544 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: '/oracle/app/oradata/orcl/undotbs1.dbf'
數據庫啟動報錯,
此時我們可以將數據庫的回滾段管理改成手動,AUTO---MANL并將回滾表空間改成系統回滾段來啟動數據庫。
SQL> create pfile='/oracle/initorcl.ora' from spfile;
File created.
修改參數文件:
#*.undo_tablespace='UNDOTBS1'
#*.undo_management='AUTO'
undo_management='MANUAL'
rollback_segments='SYSTEM'
修改完啟動到mount階段,offline并刪除損壞undo數據文件,打開數據庫。
SQL> startup mount pfile='/oracle/initorcl.ora';
SQL> alter database datafile '/oracle/app/oradata/orcl/undotbs1.dbf' offline drop;
SQL> alter database open;
刪除原來的undo表空間,創建新的undo表空間。
SQL> drop tablespace undotbs1 including contents and datafiles
Tablespace dropped.
SQL> create undo tablespace undotbs1 datafile '/oracle/app/oradata/orcl/undotbs1.dbf' size 50m autoextend on;
Tablespace created.
重新將參數文件參數改回,啟動數據庫。
SQL> select XIDUSN,XIDSLOT,XIDSQN,UBAFIL,UBABLK,UBASQN,UBAREC from v$transaction;
XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC
---------- ---------- ---------- ---------- ---------- ---------- ----------
22 12 66 10 175 98 28
表示回滾段號為22,事務槽為12
從v$rollstat中也可以看到對應的回滾段信息,XACTS是代表活動的事務。
SQL> select usn,writes,rssize,xacts,hwmsize,shrinks,wraps from v$rollstat;
USN WRITES RSSIZE XACTS HWMSIZE SHRINKS WRAPS
---------- ---------- ---------- ---------- ---------- ---------- ----------
0 7620 385024 0 385024 0 1
21 267816 2088960 0 2088960 0 0
22 36122 253952 1 253952 0 0
v$rollname視圖可以用來獲得回滾段名稱。
SQL> select * from v$rollname where usn=22;
USN NAME
---------- ------------------------------
22 _SYSSMU22$
dump回滾段段頭信息:
SQL> alter system dump undo header '_SYSSMU22$';
System altered.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug tracefile_name;
/oracle/app/admin/orcl/udump/orcl_ora_5949.trc
對于dump出來的文件:
Unix process pid: 5949, image: oracle@linux-4.7 (TNS V1-V3)
*** 2011-11-01 21:52:05.679
*** ACTION NAME:() 2011-11-01 21:52:05.666
*** MODULE NAME:(sqlplus@linux-4.7 (TNS V1-V3)) 2011-11-01 21:52:05.666
*** SERVICE NAME:(SYS$USERS) 2011-11-01 21:52:05.666
*** SESSION ID:(159.10) 2011-11-01 21:52:05.666
********************************************************************************
Undo Segment: _SYSSMU22$ (22)
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x0042 0x0001 0x0000.000c4af7 0x028000af 0x0000.000.00000000 0x00000001 0x00000000 1320152385
0x01 9 0x00 0x0042 0x0006 0x0000.000c4b1a 0x028000af 0x0000.000.00000000 0x00000001 0x00000000 1320152431
0x02 9 0x00 0x0041 0x0005 0x0000.000c4581 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x03 9 0x00 0x0041 0x000a 0x0000.000c44eb 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x04 9 0x00 0x0042 0x002e 0x0000.000c4a7c 0x028000af 0x0000.000.00000000 0x00000001 0x00000000 1320152138
0x05 9 0x00 0x0041 0x0012 0x0000.000c458b 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x06 9 0x00 0x0042 0x002b 0x0000.000c4b38 0x028000af 0x0000.000.00000000 0x00000001 0x00000000 1320152432
0x07 9 0x00 0x0041 0x001a 0x0000.000c464d 0x028000ad 0x0000.000.00000000 0x00000001 0x00000000 1320149924
0x08 9 0x00 0x0041 0x0023 0x0000.000c47e2 0x028000ad 0x0000.000.00000000 0x00000001 0x00000000 1320150762
0x09 9 0x00 0x0041 0x0014 0x0000.000c45b0 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x0a 9 0x00 0x0041 0x000b 0x0000.000c44ff 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x0b 9 0x00 0x0041 0x000e 0x0000.000c4513 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x0c 10 0x80 0x0042 0x0002 0x0000.00000000 0x028000af 0x0000.000.00000000 0x00000001 0x00000000 0
0x0d 9 0x00 0x0041 0x0008 0x0000.000c47ae 0x028000ad 0x0000.000.00000000 0x00000001 0x00000000 1320150644
0x0e 9 0x00 0x0041 0x000f 0x0000.000c4527 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x0f 9 0x00 0x0041 0x0010 0x0000.000c453b 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
0x10 9 0x00 0x0041 0x0013 0x0000.000c454e 0x028000ac 0x0000.000.00000000 0x00000001 0x00000000 1320149738
首先0x0c代表16進制,轉換為2進制就是12,代表其占用第12個事務槽。stat為狀態,9為非活動事務,10為活動事務。
dba即為data block address 指的是包含這個事務的前鏡像的數據塊地址0x028000af 將該地址做2進制轉換即為0000 0010 1000 0000 0000 0000 1010 1111
前10位0000 0010 10運算代表所處的文件地址,后22位代表塊地址運算得數值175,即該前鏡像信息位于10號文件的175號塊上.
這與事務中查詢結果一致。
現在我們模擬另外一個回滾段事務的流程:
commit之前的事務,重新修改多條記錄:
select * from emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
7369 SMITH CLERK 7902 17-DEC-80 800 20
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
7566 JONES MANAGER 7839 02-APR-81 2975 20
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
7698 BLAKE MANAGER 7839 01-MAY-81 4000 30
7782 CLARK MANAGER 7839 09-JUN-81 4000 10
7788 SCOTT ANALYST 7566 19-APR-87 4000 20
7839 KING PRESIDENT 17-NOV-81 5000 10
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
7876 ADAMS CLERK 7788 23-MAY-87 1100 20
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- --------- ---------- ---------- ----------
7900 JAMES CLERK 7698 03-DEC-81 950 30
7902 FORD ANALYST 7566 03-DEC-81 3000 20
7934 MILLER CLERK 7782 23-JAN-82 3000
SQL> update emp set sal=2000 where empno=7934;
SQL> update emp set sal=2000 where empno=7902;
SQL> update emp set sal=2000 where empno=7900;
SQL> update emp set sal=2000 where empno=7876;
SQL> select XIDUSN,XIDSLOT,XIDSQN,UBAFIL,UBABLK,UBASQN,UBAREC from v$transaction;
XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC
---------- ---------- ---------- ---------- ---------- ---------- ----------
23 8 65 10 901 67 39
我們dump出回滾段中對應的10號文件的901號塊:
SQL> alter system dump datafile 10 block 901;
SQL> oradebug setmypid;
SQL> oradebug tracefile_name;
/oracle/app/admin/orcl/udump/orcl_ora_6091.trc
查看信息:
UNDO BLK:
xid: 0x0017.008.00000041 seq: 0x43 cnt: 0x27 irb: 0x27 icl: 0x0 flg: 0x000
0
Rec Offset Rec Offset Rec Offset Rec Offset Rec Offset
---------------------------------------------------------------------------
0x01 0x1f3c 0x02 0x1ed0 0x03 0x1e64 0x04 0x1de8 0x05 0x1d7c
0x06 0x1d10 0x07 0x1ca4 0x08 0x1bf8 0x09 0x1b8c 0x0a 0x1b08
0x0b 0x1aa8 0x0c 0x1a10 0x0d 0x198c 0x0e 0x1910 0x0f 0x183c
0x10 0x17b8 0x11 0x1734 0x12 0x1698 0x13 0x1644 0x14 0x15c0
0x15 0x1538 0x16 0x14b4 0x17 0x1460 0x18 0x13c4 0x19 0x1340
0x1a 0x12c4 0x1b 0x1240 0x1c 0x11b4 0x1d 0x1108 0x1e 0x1060
0x1f 0x0fac 0x20 0x0f60 0x21 0x0e7c 0x22 0x0e14 0x23 0x0dbc
0x24 0x0d24 0x25 0x0ccc 0x26 0x0c70 0x27 0x0c18
其中irb字段指的是回滾段中記錄的最近的未提交變更開始出:
irb: 0x27
我們也可以發現,最后一個偏移地址正好是0x27 的信息。
找到0x27的信息:
* Rec #0x27 slt: 0x08 objn: 52173(0x0000cbcd) objd: 52173 tblspc: 4(0x000000
04)
* Layer: 11 (Row) opc: 1 rci 0x26
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
op: C uba: 0x02800385.0043.26
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x010000fc hdba: 0x010000fb
itli: 1 ispac: 0 maxfr: 4858
tabn: 0 slot: 10(0xa) flag: 0x2c lock: 0 ckix: 191
ncol: 8 nnew: 1 size: 0
Vector content:
col 5: [ 2] c2 0c
對于c2 0c 轉換為10進制為1100,即為我最后一個修改的數據的前鏡像。
而rci則是代表了之后的一個偏移量。(同一事務中)
* Rec #0x26 slt: 0x08 objn: 52173(0x0000cbcd) objd: 52173 tblspc: 4(0x000000
04)
* Layer: 11 (Row) opc: 1 rci 0x25
Undo type: Regular undo Last buffer split: No
Temp Object: No
Tablespace Undo: No
rdba: 0x00000000
*-----------------------------
KDO undo record:
KTB Redo
op: 0x02 ver: 0x01
op: C uba: 0x02800385.0043.25
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x010000fc hdba: 0x010000fb
itli: 1 ispac: 0 maxfr: 4858
tabn: 0 slot: 11(0xb) flag: 0x2c lock: 0 ckix: 191
ncol: 8 nnew: 1 size: 1
col 5: [ 3] c2 0a 33
同樣c2 0a 33 代表了10進制中的950;也就是倒數第二條更新的記錄的前鏡像。
依次跳轉直到最后一undo chain 的rci為0x00
當有其他用戶來讀數據的時候,oracle會構造一致性讀,通過前鏡像把變化前的數據讀取給用戶。
看完上述內容,你們對undo表空間該怎么理解有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。