Oracle運維筆記之事務復原處理

客戶的跑批任務由于邏輯放生錯誤，導緻了insert上億條資料，表空間使用率即将爆滿，在和開發商量後，隻能kill跑批，復原事務。在復原期間，觀察了以下3個視

有關復原的幾個視圖：

v$session_longops

該視圖記錄了所有時間超過6秒(絕對時間)的操作，這些操作包括：備份、恢複、統計資訊收集、查詢等，以及

Oracle的每個版本中新增的操作。

sofar：到目前為止完成的工作量，機關為units列值，一般為block

totalwork：總共的工作量，機關為units列值，一般為block

time_running：預計完成操作的剩餘時間，機關為秒

elapsed_seconds：從操作開始總花費時間，機關為秒

v$fast_start_transactions

該視圖記錄了Oracle的復原事務。

實際上不是所有的復原都會記錄在該視圖中，例如一般的rollback就不會記錄；當服務程序在送出事務(commit)前意外終止的話就會形成死事務(dead transaction)，PMON程序負責輪詢Oracle程序，找出這類意外終止的死程序(dead process)，通知SMON将與該dead process相關的dead transaction復原清理，這才會記錄在該視圖中，例如事務在送出前會話被kill，以及資料庫執行個體意外關閉，shutdown abort等。

STATE: TO BE RECOVERED(即将復原), RECOVERED(復原完畢), or RECOVERING(復原中)

UNDOBLOCKSDONE：目前復原的undo blocks數量

UNDOBLOCKSTOTAL：總共需要復原的undo blocks數量

v$transaction

記錄了所有active的事務。

需要重點關注used_ublk，多次查詢，如果used_ublk在增大，說明正在執行資料處理；如果used_ublk在減小，說明正在執行rollback，一直到used_ublk為0表示rollback結束，可以通過這個值大緻估算出rollback的時間。

在事務復原時，修改FAST_START_PARALLEL_ROLLBACK參數為true，以加快復原速度。同時還需要觀察undo空間的使用率，通常是需要臨時增加undo檔案，以避免undo沒有空餘空間。

with free_sz as

(select tablespace_name, sum(f.bytes) / 1048576 / 1024 free_gb

from dba_free_space f

group by tablespace_name),

a as

(select tablespace_name,

sum(case
          when status = 'EXPIRED' then
           blocks
        end) * 8 / 1048576 reusable_space_gb,
    sum(case
          when status in ('ACTIVE', 'UNEXPIRED') then
           blocks
        end) * 8 / 1048576 allocated_gb           

from dba_undo_extents

where status in ('ACTIVE', 'EXPIRED', 'UNEXPIRED')

undo_sz as

(select tablespace_name, df.user_bytes / 1048576 / 1024 user_sz_gb

from dba_tablespaces ts

join dba_data_files df

using (tablespace_name)

where ts.contents = 'UNDO'

and ts.status = 'ONLINE')           

select tablespace_name,

user_sz_gb,
  free_gb,
  reusable_space_gb,
  allocated_gb,
  free_gb + reusable_space_gb + allocated_gb total           

from undo_sz

join free_sz

using (tablespace_name)

join a

using (tablespace_name);