Oracle 事務流程有哪些

Oracle 事務流程有哪些，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

事務表：
事務表存放在undo段頭部（undo段頭塊），每一個undo段最多可以存放47個事務。
事務表按行存放事務記錄，每行一個事務記錄。
事務開始后，服務進程分配一個XID，將事務信息（XID UBA）存放在undo的段頭塊。

Oracle盡量一個事務使用一個回滾段，如果事務太多，會出現回滾段重用，多個事務使用同一個回滾段。并且Oracle會均勻的將事務分配在回滾段中。

查看當前事務信息

select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction ；
XID XIDUSN XIDSLOT XIDSQN UBABLK UBAFIL
06001C004B040000 6 28 1099 711 3

查看所有回滾段。
SYS@prod>Select * from v$rollname；
 0 SYSTEM
 1 _SYSSMU1_3724004606$
 2 _SYSSMU2_2996391332$
 3 _SYSSMU3_1723003836$
 4 _SYSSMU4_1254879796$
 5 _SYSSMU5_898567397$
 6 _SYSSMU6_1263032392$
 7 _SYSSMU7_2070203016$
 8 _SYSSMU8_517538920$
 9 _SYSSMU9_1650507775$
10 _SYSSMU10_1197734989$

從事務信息中可以看出，當前事務使用的是6號undo段。
找到6號undo段的段頭塊的位置：
SYS@prod>select header_file,header_block from dba_segments where segment_name = ‘_SYSSMU6_1263032392$’;
HEADER_FILE HEADER_BLOCK
  3         208

3號文件208塊就為undo段的段頭塊。
可以將其轉儲查看事務表：
Alter system dump datafile 3 block 208
select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) block,id
from t1
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) BLOCK ID
               1      91041      5
               1      91041      5
               1      91041      5
查看行數據所在數據塊的位置進而轉儲查看數據塊結構。

事務槽ITL：
事務槽存放在數據塊的頭部，事務修改一個數據塊，需要在事務槽中記錄事務信息。

XID 既是編號 又是地址。
1.使用了哪個回滾段的段頭塊
2.段頭塊使用了哪行來記錄事務。
3.第幾次覆蓋。 （第幾次循環使用）。

先簡單敘述一下事務的流程：

1.開始一個事務，首先Oracle給這個事務分配XID，并找到一個回滾段，在回滾段頭塊將事務信息存放在事務表中，并給這個事務分配undo塊，并將undo塊的地址也寫入事務表中（UBA地址） 。
2.事務準備修改一個數據塊，在該數據塊的頭部的事務槽中寫入事務信息（XID ，UBA（這個UBA指向相對應的undo塊））。
3.開始修改數據，將數據塊修改的前映像存放在undo塊中。

事務表中與事務槽中的UBA是不同的：
事務表中的UBA：

事務表中的UBA是指向事務操作的最后一個undo塊，同時也是事務回滾開始的位置。
rollback回滾時，根據事務表中的UBA直接定位事務回滾的起點。
并且要知道回滾塊與回滾塊之間是串起來。

事務槽中的UBA：
數據塊中事務槽的UBA指向相對應的undo塊，意義在于加快構造CR塊的效率，
執行select時，服務進程如果發現該行數據正在有事務進行，且未提交，那么就會結合當前塊以及undo塊生成CR塊（能夠更加快速的找到相對應的undo塊）。

事務槽中記錄XID意義在于指向事務表，直接定位到事務表的位置，與Oracle提交方式有關，具體原因，后面描述。

一個DML事務開始時，需要修改的位置：
回滾段頭部的事務表被修改
數據塊塊頭部的事務槽被修改
undo塊被修改
數據塊的行數據被修改
（以上四種修改都會產生redo）

事務槽的數量查看：
Select ini_trans,max_trans from dba_tables where table_name = ‘T1’

事務槽的爭用問題：
會話A啟動第一個事務修改該數據塊中的一行數據，
需要在該數據塊中獲取一個事務槽（未提交）
（沒有提交事務槽不能被覆蓋，只有事務已經提交的事務槽才可以被覆蓋）

會話B啟動第二個事務修改該數據塊中另一行數據
也需要在該數據塊中獲取一個事務槽
當事務槽獲取上限以后
再來一個事務修改該數據塊的其他行，就需要等待事務槽釋放。

解決：
可以增加pctfree減少爭用
Oracle為了結局對事務槽的爭用，對insert操作，Oracle會將其分布到多個塊中。
但是對update 與 delete無能為力，只能增加事務槽，所以update與delete容易出現事務槽爭用。

事務槽中記錄XID的意義：
Oracle結合延遲塊的清除實現快速提交：
如果一個事務修改了1000個塊，事務信息在1001個塊中存在（undo段頭部塊）
當事務提交時，需要在1001個塊的位置將事務記錄修改為已提交的狀態，會很慢。

并且還可能出現一種情況事務修改了1000個塊，當要提交時，已經有800個塊被寫入磁盤。
Oracle不可能再將這800個塊重新讀入磁盤，來將數據塊頭部事務槽中記錄的事務修改為已提交狀態。

Oracle延遲塊清除的辦法：
當事務提交時，Oracle僅更新undo段頭的事務信息，根據buffer的數量，并且僅會更新部分buffer，剩余buffer Oracle會在下次讀取這些數據塊時清除事務記錄。

所以說 數據塊中事務槽記錄未必準確， 如果數據塊中事務槽記錄的事務未提交，Oracle還需要根據事務槽頭部的XID去undo段頭事務表來進一步判斷事務是否提交，如果undo段頭事務表記錄該事務已經提交，那么Oracle會選擇相信undo段頭，進而修改數據塊，并且將上一個事務的事務槽中的事務記錄修改為已提交。

Oracle的多種提交方式：
事務修改的數據塊少時：
事務提交時
修改undo段頭記錄的事務狀態
修改數據塊頭部事務槽中記錄的事務狀態
修改數據行標志（事務槽編號，指向事務槽，就是Oracle行級鎖）

事務修改的塊一般多時：
事務提交時
會將undo段頭的事務表以及數據塊頭部的事務槽中的事務狀態修改為已提交。
數據行標記（行鎖）會在下次select訪問時清鎖。
（這也是有時select也會產生redo日志的原因）

事務修改的塊很多時：
當事務提交時
僅會修改undo段頭的記錄。
事務槽，數據行標記（行鎖）在下次select訪問時修改清鎖。

另一種情況：
如果一個數據塊長時間未被讀入到buffer cache，而且數據塊事務槽以及鎖還未清除，如果此時讀取，服務進程會去undo段頭的事務表中判斷事務是否已經提交，但是服務進程讀取undo段頭的事務表時發現，事務表已經被覆蓋15次，此時Oracle會認定事務已經提交，因為事務未提交在事務表中不可能被覆蓋，然后服務進程清除該數據塊事務槽的記錄，清除數據塊行鎖。

Select流程總結：
（數據塊中每行數據都會有指向事務槽的標記）
當客戶端執行select查詢時，服務進程接收請求，將符合要求的數據塊讀入到buffer cache中，服務進程會先去讀取數據塊中的行。
如果數據塊的行上有事務槽標記（行鎖）,服務進程會去事務槽中查看該事務槽中記錄的事務是否已經提交。（由于快速提交，延遲塊清除原則，鎖信息并不代表事務情況）
如果事務槽中記錄的事務已經提交，那么服務進程會清除數據塊中這行記錄的事務槽標記（行鎖），直接讀取該行數據。
如果事務槽中記錄的事務沒有提交，Oracle會產生懷疑，服務進程會根據事務槽中的XID去undo段頭部中的事務表中讀取事務狀態（事務槽中記錄XID的意義）。
如果事務表中的事務狀態為已提交，那么服務進程會認定這行數據所對應的事務已經提交，清空行標記，將事務槽中未提交狀態修改為已提交。
如果事務表中的事務狀態為未提交，那么Oracle會認定該數據塊中行對應的事務未提交，此時服務進程就會根據當前塊中的行數據來結合undo塊來構造CR塊，用于一致性讀。

Update流程總結：
簡單的說，就是如果該行數據有事務正在進行，那么就需要等待
如果該行數據沒有事務正在進行，那么就正常修改。
Oracle兩個事務可以同時修改一個數據塊，只要行不沖突即可。行級鎖的并發性

關于Oracle 事務流程有哪些問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。