> Oracle redo undo 學習，主要來自《Oracle程式設計藝術》  --by Firsouler 2021.1.13

重做日誌是資料庫的事務日誌

```
--測量redo
set autotrace traceonly statistics;
insert into t_2021 as select * from all_objects;
```

undo“邏輯的”恢復到原來的樣子，它無法撤銷其他事務對當前塊的更改。Oracle的回滾是相反動作，每個insert，是delete，每個delete，Oracle會做insert，update也是相反操作。如果回滾大事務，比較消耗資料庫資源。

> 直接路徑操作的undo生成機制會不一樣，這種操作可能不生成或生成很少的undo資料

舉例：

```
create table t_objects as select * from all_objects where 1=0;
set autotrace traceonly statustics
select * from t_objects;
insert into t select *from all_objects;
rollback;
select * from t_objects;
--回滾不撤銷原來已經分配的塊，
```

#### 9.3 redo和undo如何協作
   資料庫緩衝區裡面會有一些被修改過而未提交的資料塊，在磁碟的重做日誌裡也會有一些為提交的與這些修改相關的redo資訊，這樣的狀態對資料庫來說，比較常見。

#### 9.4 提交和回滾
     commit的開銷主要兩個方面， 客戶端與伺服器直接的往返通訊兩會增大，每次提交時，都必須等待redo寫入磁碟， 從而造成更多等待事件(log file sync)

執行commit，或如下操作：
- 為事務生成一個SCN
- LGWR將所有未寫入磁碟的重做日誌條目寫至磁碟，並把scn記錄到線上重做日誌檔案中。這一步後，事務的狀態為提交，此時v$transaction中被“刪除”。
- v$lock中會記錄會話持有的鎖，鎖被釋放。
- 如果事務修改的某些塊還在緩衝區緩衝中，Oracle會快速的模式訪問並“清理”.塊清楚(block cleanout)指清除儲存在資料塊首部與鎖相關的資訊，實際是清除塊上的事務資訊。LGWR會在修改的同時以增量方式將日誌緩衝區的內容寫到磁碟上，避免了commit需要過長時間等待刷所有redo資訊。

> PL/SQL 非同步提交，雖然在語句或儲存塊寫了多次commit，最後只能一次日誌寫入，如果用Oracle11以上版本，可在PL/SQL內執行commit work write wait來避免使用提交最佳化

rollback時，還要做如下工作：
- 撤銷所有修改，Oracle資料庫會讀取undo段，將undo資料應用到資料塊，並將相應的undo條目標記為已應用。如果之前插入了一行，rollback會刪除，其他操作一樣。
- 會話持有的所有鎖都被是否

commit比rollback工作量小的多，不要輕易回滾。

#### 9.5 分析redo

force logging:所有操作記錄日誌，忽略（nologging)
supplemental logging：兩種，庫級和表級。基於重做的應用程式可能需要在重做日誌檔案中記錄其他列。記錄這些附加列的過程稱為補充日誌記錄。

> 參考：http://www.dbsnake.net/oracle-supplemental-logging.html

###### 分析redo log檔案

```
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> alter system dump logfile ‘C:\APP\CUIHUA\ORADATA\CUIHUA112\REDO03.LOG’ scn min 7518013947 scn max 7518013970;
SQL> oradebug tracefile_name

```
##### 塊清除
鎖實際是資料的屬性，它儲存在塊首部。

任何事務都會有一個提交列表，Oracle會透過這個列表來記錄已修改的塊。每個列表都會去跟蹤20個資料塊，Oracle會根據需要分配多個這樣的列表，直至達到某個臨界點。如果修改的塊加起來超過塊緩衝區的10%，Oracle會停止分配新的列表。如果修改的塊沒超過快取總塊數的10%，塊仍在緩衝區中並且是可用的，Oracle會在提交時清理這些塊。

select會產生redo，清除髒塊資訊。 例如db_chache_size 大小16M,2048*8K，表中插入了10000個塊，提交。因為超過10%，有的已寫入磁碟，提交時也無法清理所有髒塊，在第一次查詢時清理髒塊。

如果一個塊被修改，下一個會話訪問時，會去查最後一個修改的這個塊的事務是否還活動，如果該事務部活動，就會進行塊清除。在塊清除的過程中，Oracle會從塊首部讀出前一個事務所用的undo段，然後再去undo首部檢視此事務是否提交，如果已提交，就會查提交時間。

##### 臨時表
- INSERT會產生很少甚至不產生undo/redo
- 臨時表的update會生成永久表update大約一般的redo
- delete在臨時表和永久表生成的redo一樣多

12C之後，可以透過引數TEMP_UNDO_ENABLED 將臨時表的undo放臨時表空間上，當引數為TRUE，任何臨時表的dml都會產生很少的redo

#### 9.6分析undo

注意：必須把索引的維護也考慮在內，與有索引的列相比，對一個未加索引的列的更新不僅執行更快，生成的undo也會少的多。

v$transaction.used_ublk ：顯示事務當前使用了多少undo塊

##### ora-01555

發生上述錯誤存在以下3個原因
- undo段太小，不足以支撐系統上執行的工作
- 程式跨commit獲取資料
- 塊清除

一些修改或插入的事務用undo段來獲取一致的資料，還要用它以備將來事務失敗時所帶來的回滾，可能會導致ora-01555

大批次的update或insert會導致塊清除，在這些操作後建議收集統計資訊。

【REDO】Oracle redo undo 學習

相關文章