Adaptive Log File Sync

Adaptive Log File Sync 為 Oracle 12c 的新功能，目的在於減少 log file sync 等待事件的延遲，其核心概念在於 user commit 後的行為模式分為兩種 : Post/wait 與 Polling 。

• Post/wait

為 user session 執行 commit 時的預設機制。當 user 發出 commit 後，會通知 LGWR 進行 redo log 的寫入；在此期間， user session 會進入等待（sleep）狀態，待 LGWR 完成 I/O 寫入並回報後，才會喚醒該 session ；當 user session 收到 LGWR 的回應，即表示此次 commit 已完成，並可繼續後續操作。

這個模式之下好比老闆交代員工一個任務之後，老闆就不管這個任務的進度直到員工主動回報完成，也就是 user 使用 commit 賦予 LGWR 任務之後， user session 就不再管此事，直到 LGWR 告知它任務完成了。

好處是當 user session進入等待 (sleep) 時不會消耗 CPU 資源；壞處是 user session 需要等 LGWR 回報後才能喚醒，這個過程會造成些許的延遲，當 commit rate 極高時， LGWR 必須逐一發送信號給每一個在 log file sync 等待隊列中的 User Session ，這種「一對多」的喚醒工作會讓 LGWR 成為系統瓶頸。

• Polling

為 Adaptive Log File Sync 機制中新增的模式，與 Post/wait 模式最大的差別在於， user 執行 commit 之後， user session 不會進入等待 (sleep)  模式，而是不斷的主動輪詢 LGWR 完成了沒，主動詢問 LGWR 且收到完成的訊息之後，即表示此次 commit 已完成。

這個模式用同一個比喻下，就好比老闆交代員工一個任務，並且老闆持續追蹤員工進度直到任務完成，也就是 user 使用 commit 賦予 LGWR 任務之後， user session 會主動持續關注 LGWR 是否已經完成它的任務了。

好處是 LGWR 不需要喚醒 user session 的動作，減少延遲，在高 commit rate 的場合中表現較佳；缺點是 user session 必須消耗 CPU 資源來持續輪詢 LGWR 是否完成，如果系統 CPU 資源較緊的話就不適合這個模式。

Adaptive Log File Sync 會依據系統的可用資源來自動切換這兩種模式，用以達到 log file sync 最佳的吞吐量，觀察 LGWR 的 trace 可以知道目前是使用何種模式進行 :

*** 2012-10-02 08:15:47.050 Log file sync switching to polling Current scheduling delay is 4 usec   *** 2012-10-02 08:16:23.325 Log file sync switching to post/wait Current approximate redo synch write rate is 8 per sec

從 AWR 或者是 v$sysstat 也可以觀察到是否有使用 polling 模式 :

早期這個功能剛推出的時候，於 RAC 環境可能會遭遇到 Bug 25178179 : Several sessions wait on 'log file sync' in a RAC environment ，這個 Bug 導致於 Polling 模式效能不佳，具體的現象為使用 Polling 模式、 log file sync 時間很長但 log file parallel write 時間很短。不過這個 Bug 已經於多數 12.2 的版本進行修復了，在現今的環境當中是不會再遇到這個問題。

最後提一下，如果系統 CPU 資源較緊，不希望使用到 Polling 模式，可以設定隱藏參數 "_use_adaptive_log_file_sync" = FALSE 來關閉 adaptive log file sync 功能，參數可以動態更改。

Log File Sync 事件分析

在 Oracle 資料庫進行 commit 的行為就會產生 log file sync 事件，對於一個交易型的系統來說，理解 log file sync 是非常重要的一件事， log file sync 等待時間的長短往往直接決定了交易型系統的整體效能。

log file sync 等待事件指的是 commit 從開始到結束整個過程，流程大致如下 :

user session 執行 commit 指令，此時會通知 LGWR 將 redo buffer 的信息寫入 redo log ， LGWR 接收到通知後，開始進行 I/O 寫入的動作，完成後告知 user session 完成整個 commit 的流程。

log file sync 一定會伴隨著 log file parallel write 事件，也就是中間 LGWR 進行 I/O 寫入的過程，當發生 log file sync 的效能問題時，必須與 log file parallel write 等待事件一起分析，因為有可能是 I/O 效能不佳進而增加整個 log file sync 等待時間。

一般 log file sync 等待時間過長有幾種可能 :

• redo log 切換太頻繁

Redo Log 切換太頻繁往往是影響 log file sync 等待時間的主因，頻繁的 commit 或 rollback ，或是 redo log 的大小與數量不合適都有可能造成 redo log 切換太頻繁。

• LGWR 的 I/O 性能不佳

I/O 性能不佳也是造成 log file sync 事件拉長的原因之一， LGWR 寫入的速度來不及處理頻繁的 commit 行為，也就是 log file parallel write 的時間過長。

從 AWR Report 看到 log file sync 等待事件時，可以從幾個方向開始分析 :

首先必須檢查資料庫的 alert log ，先確認是否有 redo log 切換太頻繁的問題，如果 alert log 有顯示出大量的 Checkpoint not complete 訊息，那就表示 redo log 因為來不及切換導致等待事件發生 :

如果有這種現象，那就表示 redo log 數量不足，或者是 redo log 大小不合適，那麼只需調整 redo log 數量與大小即可。

若是沒有這個現象，那就表示沒有 redo log 切換太頻繁的問題，此時就很有可能是 I/O 效能的問題，可以檢查 AWR 的 Background Wait Events 是否 log file parallel write 的等待時間過長，或者是從 lgwr 的 trace file 檢查 LGWR 的寫入速度 :

以這個例子來說， LGWR 只有寫入幾 KB 或是幾十 KB 就需要十幾秒甚或至百秒，那就可以確定 I/O 的效能有問題，此時就必須請系統管理員協助處理 I/O 效能的問題。

當發生 log file sync 效能問題時，除了檢查 alert log 、 lgwr trace 之外， DB 層面還可以收集 ASH (dba_hist_active_sess_history 、 wrh$_active_session_history) 資訊 ，作業系統層面可以收集監控資訊如 OSWatcher 、 NMON …等，更進一步可以執行 strace(Linux) 、 truss(AIX) 例如 :

# strace -rfttT -o /tmp/start_trace.out -p <PID_of_ LGWR process>

透過 strace 可掌握 I/O 行為實際停滯的 system call ，對於深入分析 log file parallel write 等待事件的效能根因具有相當大的幫助。

 

總結 log file sync 等待事件對交易型系統（OLTP）的效能影響相當重大。建議將 redo log 放置於效能較佳、延遲較低的磁碟設備上；同時在應用程式設計上，對交易行為盡量採用批次處理，降低 commit 的發生頻率。透過這些做法，有助於有效縮短 log file sync 的等待時間，進而提升整體交易效能與系統吞吐量。

 

10. PDB Lockdown Profile

PDB lockdown profile 主要是用來限制 PDB 的某些操作，當一個使用者在多個 PDB 共用時

(例如 common user) ，使用者的權限就有被放大的風險，透過設定 PDB lockdown profile 可

以用來避免 common user 利用特定 PDB 所允許的功能進而對其它 PDB 造成影響。

PDB lockdown profile 可以限制三個層級 :

• Statement : 限制命令的操作，例如於 CDB 層級建立 PDB lockdown profile 限制 alter system 操作 :

SQL> create lockdown profile lkp1; SQL> alter lockdown profile lkp1 disable statement=('alter system');

於 PDB 設定參數 pdb_lockdown 套用 lockdown profile :

SQL> alter session set container=pdb1; SQL> alter system set pdb_lockdown=lkp1;

套用之後此 PDB 就不能使用 alter system 命令 :

更進一步的設定可以只限制某個 alter system 操作，例如只限制 set 操作 :

SQL> alter lockdown profile lkp1 enable statement=('alter system'); SQL> alter lockdown profile lkp1 disable statement=('alter system') clause=('set');

這樣子設定可以執行 alter system 但 set 操作則是不允許 :

• Feature : 限制 PDB 使用某些功能如 NETWORK_ACCESS (UTL_HTTP 、 UTL_TCP …等) 、 

  COMMON_SCHEMA_ACCESS (存取 common schema 共用物件) 、 OS_ACCESS (UTL_FILE …等) 、 

  JAVA與 JAVA_RUNTIME ，例如限制 PDB 不能使用 UTL_HTTP :

SQL> create lockdown profile lkp2; SQL> alter lockdown profile lkp2 disable feature=('UTL_HTTP');

套用之後 PDB 使用 UTL_HTTP 就會出現 ORA-01031: insufficient privileges :

SQL> alter session set container=pdb1; SQL> alter system set pdb_lockdown=lkp2;

• Option : 限制 PDB 不能使用某些資料庫功能如 Partitioning 、 Advanced Queuing 、 

  Data Guard …等，例如限制 PDB 不能使用 Partition :

SQL> create lockdown profile lkp3; SQL> alter lockdown profile lkp3 disable option=('PARTITIONING');

 

 套用之後於 PDB 建立 partition table 就會出現 ORA-00439: feature not enabled :

SQL> alter session set container=pdb1; SQL> alter system set pdb_lockdown=lkp3;

透過 dba_lockdown_profiles 可以查詢目前所有 lockdown profile 的設定 :

SQL> select PROFILE_NAME,RULE_TYPE,RULE,status from dba_lockdown_profiles;

PDB Lockdown Profile 提供了一種以 PDB 為邊界的安全控管機制，可有效限制系統操作、

功能與授權選項的使用範圍。