RAC 環境中最常見的 5 個資料庫和/或例項效能問題 (文件 ID 1602076.1)

文件內容

用途

適用範圍

詳細資訊

問題 1：大量塊丟失 (gc lost blocks, gc current/cr lost blocks)

問題 2：大量 log file sync 等待

問題 3：Mutexes 上的長時間等待

問題 4：高 enq: TX -row lock contention, enq: TX - index contention, enq: TX - ITL allocate entry 等待

問題 5：高 CPU 和記憶體開銷

參考

適用於:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 11.2.0.3 [發行版 10.1 到 11.2]
本文件所含資訊適用於所有平臺

用途

本文旨在提供關於 RAC 環境中最常見的資料庫和/或例項效能問題的摘要以及可能的解決方案

請注意，問題 3（Mutexes 上的大量等待）和問題 5（高 CPU 和記憶體開銷）是一般性資料庫問題，並非特定於 RAC 的問題。不過，本文中討論這些問題是因為這些是最常見的問題之一，會在 RAC 環境中的某一個例項發生。

適用範圍

DBAs

詳細資訊

問題 1：大量塊丟失 (gc lost blocks, gc current/cr lost blocks)

症狀

I. AWR 報告中顯示有大量塊丟失。

II. netstat -s 報告資料包重新組裝故障（reassambly failure）和丟失資料包（dropped packets）增加。

解決方案

使用以下文件進行故障排除並解決丟失塊問題。該文件描述了症狀、可能原因以及解決方案。

Document 563566.1 - gc block lost diagnostics

問題 2：大量 log file sync 等待

症狀

I. AWR 報告中顯示 log file sync 始終位於 Top 5 等待事件列表中。

II. 平均 log file sync 時間很長（> 20 毫秒）。

III. 平均 log file parallel write 時間很長（> 10 毫秒）。

III. 平均 redo write broadcast ack time 或者 wait for scn ack 時間很長（> 10 毫秒）。

IV. 平均 log file sync 時間很短，但 log file sync 等待次數太多。

背景

使用者會話在提交或回退時，會話的重做資訊需要由 LGWR 重新整理到重做日誌檔案。使用者會話等待“log file sync”的同時，等待 LGWR 通知確認所有重做更改已安全存放在磁碟上。

示例：

WAIT #0: nam='log file sync' ela= 977744 buffer#=754 p2=0 p3=0 obj#=114927 tim=1212384670107387

引數：

P1 = buffer#
P2 = 未使用
P3 = 未使用
obj# = object_id

對這個 buffer（在重做日誌緩衝區）的所有更改必須重新整理到磁碟並確認寫入，以確保事務處理已提交，並且在例項關閉之前一直保持為已提交狀態。

“log file sync”等待的典型生命週期

1. 使用者會話釋出提交或回退操作，然後開始等待 log file sync。
2. LGWR 收集要寫入重做日誌檔案的重做資訊，釋出 IO 並將 BOC 入隊到 LMS 程式，然後通知 LMS 程式。
3. LGWR 等待將重做資訊重新整理到磁碟以及等待 SCN 被確認收到
4. 完成 IO 並從 LMS 收到 SCN 的確認資訊，表示寫入完成。LGWR 然後通知前臺程式繼續。
5. 前臺程式被喚醒，並且 log file sync 等待結束。

與 log file sync 相關的重要統計資訊和事件

redo write time - 從重做日誌緩衝區向當前重做日誌檔案寫入所用的總時間，以10毫秒為單位。
redo writes - LGWR 向重做日誌檔案寫入的總次數。“寫入重做塊數”除以此統計資訊等於每次寫入的塊數。
log file parallel write - 完成 I/O 的用時。雖然重做記錄是並行寫入的，但在最後一個 I/O 寫入到磁碟上之前，並行寫入不會完成。
redo write broadcast ack time - 在提交時，除了日誌寫入等待時間之外，與廣播相關的總等待時間長度，以毫秒為單位。
user commits - 使用者提交的數量。在使用者提交事務時，必須將所生成的、反映對資料庫塊更改的重做寫入到磁碟。提交操作通常代表的是最接近使用者事務率的內容。
user rollbacks - 使用者手動釋出 ROLLBACK 語句的次數或者使用者事務處理出誤的次數。
Document 1064487.1 - Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql) 中提供的指令碼可以用於蒐集診斷log file sync問題的有用資訊。

可能原因

I. 重做日誌檔案所在裝置的 IO 服務時間和吞吐量不理想。

II. Oracle Bug。有關已知 Oracle Bug，請檢視 WAITEVENT: "log file sync" Reference (Document 34592.1)。

III. LMS 未在 RT（實時）類中執行。

IV. LGWR 程式排程延遲。

V. 提交數太多。

VI. 作業系統資源緊張。

解決方案

I. 如果日誌檔案並行寫入始終很高（> 10 毫秒），則將重做日誌檔案移動到具有較高吞吐量和更短響應時間的磁碟上。日誌檔案並行寫入理想範圍應在 1-2 毫秒之間。

II. 應用適用於您的環境的已知 Oracle Bug 修復。獲取這些修復的最有效方法是應用最新 PSU 補丁程式。Document 756671.1 提供了有關最新 PSU 的詳細資訊。

III. 確保 LMS 程式在 RT 類中執行。LMS 程式預設情況下在 RT 類中執行。

IV. 使用批次提交而不是在每次 DML 操作之後提交，可以減少提交數量。

V. 檢視是否有任何活動可以使用 NOLOGGING/UNRECOVERABLE 選項安全地完成。

VI. 檢視是否可以使用 COMMIT NOWAIT 選項。有關詳細資訊，請參閱 Document 857576.1。

@For Support Only: Renice LGWR to run at higher priority or run LGWR in RT class by adding LGWR to the parameter: _high_priority_processes='VKTM|LMS|LGWR". Consider doing this only if log file sync is high and scheduling delay of LGWR is found to be causing it. Be prepared to test it thoroughly.

問題 3：Mutexes 上的長時間等待

Mutexes 是比閂鎖(latches)更為輕型且粒度更細的並行機制。獲取 Mutex 的目的是為了確保正確管理特定操作的並行執行，例如，如果一個會話正在更改記憶體中的資料結構，則其他會話等到獲取Mutex 後，才能進行類似的更改。下面是最常見的與 Mutex 相關的等待：

A. cursor: pin S wait on X
B. cursor: pin S
C. library cache: Mutex X

症狀 (A)

AWR 報告中顯示“cursor: pin S wait on X as one of the top wait”。

背景 (A)

會話等待此事件是在它嘗試獲取共享模式的 Mutex 鎖時，其他會話在相同遊標物件上以獨佔方式持有 Mutex 鎖。通常，等待“Cursor: pin S wait on X”是症狀而非原因。其中可能需要進行底層的最佳化或者是已知問題。

可能原因 (A)

請檢視 Troubleshooting 'cursor: pin S wait on X' waits (Document 1349387.1).

解決方案 (A)

請檢視 Troubleshooting 'cursor: pin S wait on X' waits (Document 1349387.1).

症狀 (B)

AWR 報告中顯示“cursor: pin S as one of the top waits”

背景 (B)

會話在申請共享模式下特定遊標上的特定 Mutex 時，雖然沒有並行的排他持有者，但無法立即獲取 Mutex，這時會等待“cursor: pin S”。這看上去有些不合理，因為使用者可能會不理解為什麼在沒有排他模式持有者的情況下會存在這種等待。出現這種等待的原因是，為了在共享模式下獲取 Mutex（或釋放Mutex），會話必須增加（或減少）Mutex 引用計數，這需要對 Mutex 結構本身進行獨佔原子更新。如果有並行會話在嘗試對 Mutex 進行這樣的更新，則一次只有一個會話能夠實際增加（或減少）引用計數。如果由於其他並行請求使得某個會話無法立即進行這種原子更新，則會出現等待“cursor: pin S”。
在 RAC 環境中，Mutex 只作用於本地例項。

引數：
   P1 = idn
   P2 = 值
   P3 = where（10.2 中為 where|sleeps）

idn 是 Mutex 識別符號值，與正在等待以獲取 Mutex 的 SQL語句的 HASH_VALUE 相匹配。可以用以下格式的查詢找到使用對應 IDN 的 SQL 語句：

SELECT sql_id, sql_text, version_count
FROM V$SQLAREA where HASH_VALUE=&IDN;

如果遊標顯示的 SQL_TEXT 格式為“table_x_x_x_x”，則這是特殊的內部遊標，有關將此類遊標對映到物件的詳細資訊，請參閱 Document 1298471.1。

P1RAW 是採用十六進位制值的相同值，可用於在跟蹤檔案中搜尋與該 hash（雜湊）值匹配的 SQL。

可能原因 (B)

I. 某個特定 Mutex 有大量並行操作，特別是在多個 CPU 的系統上。

II. 在高負載情況下，會等待非常多不同的“idn”值。

III. Oracle Bugs
       - ORA-600[kgxEndExamine-Bad-State] / mutex waits after a self deadlock
       - Wrong wait events in 11.2 ("cursor: mutex S" instead of "cursor: mutex X")
       - Improve concurrent mutex request handling
       - Prevent preemption while holding a mutex (fix only works on Solaris)
       - Missing entries in V$MUTEX_SLEEP.location

解決方案 (B)

I. 應用的修復。

II. 對於任何已標識的“熱點”SQL，使用者可以透過將 SQL 替換為一些由其他會話執行的變體，來減少特定遊標上的並行操作。有關詳細資訊，請檢視 WAITEVENT: cursor: pin S Reference (Document 1310764.1)。

III. 應用其他已知 Oracle bug 的修復。獲取修復的最有效方法是應用最新 PSU patch（補丁程式）。 Document 756671.1 提供了有關推薦補丁程式的詳細資訊。

症狀 (C)

AWR 報告中顯示“library cache: Mutex X as one of the TOP waits”。

背景 (C)

在以前的 Oracle 版本中，獲取 library cache Mutex 與獲取 library cache latches 的目的相似。在 10g 中，為 library cache 中的特定操作引入了 Mutex。從 11g 開始，Mutex 取代了 library cache latches。只要某個會話以獨佔模式持有 library cache mutex 並且其他會話需要等待釋放 Mutex，就會出現此等待事件。

單獨等待：
引數：
P1 = "idn" = 唯一的Mutex識別符號
P2 = "value" = 持有Mutex的會話ID
P3 = "where" = 等待 Mutex 的程式碼中的位置（內部識別符號）

系統範圍等待：
在系統範圍級別，有兩個檢視可用於幫助診斷此等待：

GV$MUTEX_SLEEP（對於非 RAC 為 V$MUTEX_SLEEPS）
和 GV$MUTEX_SLEEP_HISTORY（對於非 RAC 為 V$MUTEX_SLEEP_HISTORY）

在例項啟動後，這些檢視在例項範圍內跟蹤 Mutex 的使用情況。由於這些檢視顯示了自啟動以來的總數，在出現問題時，您可以獲取短時間間隔內值的差異，因此這些資料是非常有意義的。瞭解這些資訊最簡單的方法是檢視 AWR 或 statspack 報告的“Mutex Sleep Summary”部分。

可能原因 (C)

I. 頻繁硬解析。

II. 高版本數。

III. 失效和重新載入。

IV. Oracle Bug。有關詳細資訊，請檢視 WAITEVENT: "library cache: mutex X" (Document 727400.1) 以獲取已知 Oracle Bug 列表。

解決方案 (C)

I. 減少硬解析、失效和重新載入。有關詳細資訊，請檢視 Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention (Document 62143.1)。

II. 檢視 Troubleshooting: High Version Count Issues (Document 296377.1) 以解決高版本數問題。

III. 應用已知 Oracle bug 的修復。獲取修復的最有效方法是應用最新 PSU patch（補丁程式）。Document 756671.1 提供了有關推薦 patch（補丁程式）的詳細資訊。

問題 4：高 enq: TX -row lock contention, enq: TX - index contention, enq: TX - ITL allocate entry 等待

A. enq: TX - Index Contention
B. enq: TX - ITL allocate entry waits
C. enq: TX - row lock contention

症狀 (A)

I. AWR 報告中顯示，在模式 4 下，“enq: TX - index contention and enq: TX - row lock contention”上有大量等待。

II. AWR 報告中顯示有大量的branch node splits, leaf node splits 和leaf node 90-10 splits

III. AWR 報告（Segments by Row Lock Waits）中顯示特定段上有大量行鎖等待。

IV. AWR 報告中顯示其他等待，例如索引分支或葉塊上的 gc buffer busy 等待、遠端回滾段段頭上的 gc current block busy 和 gc current split。

示例：

Top 5 Timed Foreground Events

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
enq: TX - index contention 29,870 1,238 41 9.52 Concurrency

Instance Activity Stats:

Statistic Total per Second per Trans
branch node splits 945 0.26 0.00
leaf node 90-10 splits 1,670 0.46 0.00
leaf node splits 35,603 9.85 0.05

Segments by Row Lock Waits:

Owner Tablespace Object Name Obj.Type Row Lock Waits % of Capture
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_PK INDEX 3,425 43.62
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_ST INDEX 883 11.25
ACSSPROD ACSS_IDX03 ACSS_ORDER_HEADER_DT INDEX 682 8.69

背景 (A)

如果事務在索引中插入行時需要等待其他事務正在操作的索引塊拆分結束，則會話將等待事件“enq: TX - index contention”。

可能原因 (A)

I. 大量並行插入導致過量索引塊拆分。

II. 對於索引值由序列產生的索引，它不斷向右增長。

解決方案 (A)

解決方案是採用避免爭用或熱點的方式重新組織索引。選項包括

I. 將索引重新建立為反向索引(不適合大表，需要相應增加buffer cache)

II. 全域性Hash（雜湊）分割槽索引

III. 如果索引關鍵字是從序列（sequence）生成的，則增加序列的快取記憶體大小，在應用程式支援時，使用“無序”序列。

症狀 (B)

AWR 報告中顯示，在模式 4 下，“enq: TX - allocate ITL”和“enq: TX - row lock contention”上有大量等待。

背景 (B)

會話希望鎖定塊中的一行但一個或多個其他會話鎖定了相同塊中的行，並且塊中沒有空閒的 ITL 槽時，該會話會等待“enq: TX - allocate ITL”。通常，Oracle 資料庫將動態新增另一個 ITL 槽。如果塊中沒有足夠的空閒空間來新增 ITL，則這可能無法實現。

可能原因 (B)

相對於並行事務數量，initrans 數設定得太低

解決方案 (B)

從 AWR 報告中查詢具有高 ITL 等待的段，或者使用以下 SQL：

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM V$SEGMENT_STATISTICS
WHERE STATISTIC_NAME = 'ITL waits' AND VALUE > 0
ORDER BY VALUE;

增加出現高 ITL 等待的段的 initrans值。

症狀 (C)

AWR 報告中顯示，在獨佔模式 (6) 下，“enq: TX - row lock contention”上有大量等待。

背景(C)

會話等待由其他會話持有的行級別鎖定時，等待“enq: TX - row lock contention”。當某個使用者更新或刪除了行但尚未提交或回滾，而另一個會話希望更新或刪除相同行時，會出現這種情況。

解決方案 (C)

這是應用程式問題，需要由應用程式開發人員參與查詢涉及的 SQL 語句。下面的文件對進一步研究該問題可能會有所幫助：

Document 102925.1 - Tracing sessions: waiting on an enqueue
Document 179582.1 - How to Find TX Enqueue Contention in RAC or OPS
Document 1020008.6 - SCRIPT: FULLY DECODED LOCKING
Document 62354.1 - TX Transaction locks - Example wait scenarios
Document 224305.1 -Autonomous Transaction can cause locking

問題 5：高 CPU 和記憶體開銷

A. 高 CPU 佔用率
B. 高記憶體使用率

症狀 (A)

I. TOP、prstat、vmstat 等作業系統工具顯示使用者 CPU 佔用率非常高，而佔用 cpu 最高的程式是 Oracle 程式或後臺程式。

II. AWR 報告中顯示最高等待數為以下一項或多項：
    latch free
    cursor pin S wait on X 或 cursor pin S wait 或 library cache mutex X
    latch: cache buffers chains
    resmgr: cpu quantum
    enq: RO - fast object reuse
    DFS lock handle

III. AWR 報告（SQLs ordered by buffer gets ）中顯示一些 SQL 語句每次執行都讀取很多buffer並消耗很多 cpu 時間。

IV. 高 cpu 開銷程式的堆疊資訊顯示該程式在不斷自旋（spinning）。

可能原因 (A)

I. Oracle bugs:
   - Mutex waits may cause higher CPU usage in 11.2.0.2.2 PSU / GI PSU
   - NUMA enabled by default can cause high CPU
   - Excessive CPU usage / OERI:kkfdPaPrm from Parallel Query / High Version
count on PX_MISMATCH
   - Slow Truncate / DBWR uses high CPU / CKPT blocks on RO enqueue
   - High "resmgr:cpu quantum" but CPU has idle time
   - Higher CPU / Higher "cache buffer chains" latch gets / Higher "consistent gets"
after truncate/Rebuild

II. Linux x86-64 平臺上配置了非常大的 SGA，但是沒有實施 Hugepages。

III. 高開銷的 SQL 語句，使用了未最佳化的執行計劃。

IV. 無法找到的程式。

解決方案 (A)

I. 對所遇到的 Bug 應用修復。獲取所有這些修復的最有效方法是應用最新 PSU patch（補丁程式）。Document 756671.1 提供了有關最新 PSU 的詳細資訊。

II. 實施 hugepages。有關更多說明，請參閱 Document 361670.1 - Slow Performance with High CPU Usage on 64-bit Linux with Large SGA。

III. 最佳化導致過多 buffer gets和消耗高 cpu 時間的 SQL。有關詳細資訊，請參閱 Document 404991.1 - How to Tune Queries with High CPU Usage。

症狀 (B)

I. ps、pmap 等作業系統工具顯示記憶體中的程式在不斷增長。pmap 顯示程式的 heap（堆）和/或 stack（堆疊）記憶體不斷增加。例如，

#pmap -x 26677

Address      Kbytes   RSS   Anon   Locked Mode   Mapped File
00010000    496        480     - - r-x--             bash
0009A000   80          80       24    - rwx-- bash
000AE000 160        160     40           - rwx-- [ heap ]
FF100000   688        688     -             - r-x--              libc.so.1

II. Oracle 程式的 session uga memory 和/或 session pga memory 在不斷增長。

        select se.sid,n.name,max(se.value) maxmem
           from v$sesstat se,
                    v$statname n
        where n.statistic# = se.statistic#
            and n.name in ('session pga memory','session pga memory max',
                                    'session uga memory','session uga memory max')
         group by n.name,se.sid
         order by 3;

III. 會話/程式的遊標數不斷增長。

可能原因 (B)

I. Oracle bugs:
       - High resource / memory use optimizing SQL with UNION/set functions with
      many branches
       HIGH MEMORY GROUP IN GES_CACHE_RESS AND ORA-4031 ERRORS
       BIG PGA MEM ALLOC DURING PARSE TIME - KXS-HEAP-C
       - ORA-04031 SHARED POOL "KKJ JOBQ WOR"
       - OCI memory leak using non-blocking connection for fetches
       - Memory leak / high CPU selecting from V$SQL_PLAN
       - Long parse time / high memory use from query rewrite
       - High version count for INSERT .. RETURNING statements with
      reason INST_DRTLD_MISMATCH
       - PLSQL cursor leak / ORA-600[kglLockOwnersListDelete]
       - Memory leak if connection to database is frequently opened and closed
       - Memory leak using BULK COLLECT within cursor opened using native
      dynamic sql

II. 應用程式未顯式關閉遊標導致遊標洩漏。

III. 具有異常大的 hash（雜湊）聯接和/或排序操作的SQL語句。

可能解決方案 (B)

I. 應用適用 Bug 的修復。獲取這些修復的最有效方法是應用最新 PSU patch（補丁程式）。Document 756671.1 提供了有關最新 PSU 的詳細資訊。

II. 確保應用程式顯式關閉了遊標。

III. 避免非常大的 hash（雜湊）聯接和/或排序操作。

參考

- ORA-04031 SHARED POOL "KKJ JOBQ WOR"

- HIGH MEMORY GROUP IN GES_CACHE_RESS AND ORA-4031 ERRORS
- MEMORY LEAK OCCURS WITH NON-BLOCKING APP IN THE LATER VERSION 10.2.0.4

- QUERY_REWRITE_ENABLED TAKE LONG PARSE TIME AND CONSUME ALL SERVER MEMORY
- DBWR IS CONSUMING HIGH CPU
- MEMORY LEAK IF CONNECTION TO DATABASE SERVER IS FREQUENTLY OPENED AND CLOSED
NOTE:62354.1 - Waits for 'Enq: TX - ...' Type Events - Transaction (TX) Lock Example Scenarios
NOTE:857576.1 - Alternative and Specialised Options as to How to Avoid Waiting for Redo Log Synchronization
- ADD DIFFERENT WAIT SCHEMES FOR MUTEX WAITS
- STATSPACK.SNAP COSUMES ALMOST 100% CPU
- HIGHER "CONSISTENT GETS" AFTER TRUNCATE

NOTE:756671.1 - Oracle Recommended Patches -- Oracle Database
NOTE:786507.1 - How to Determine the Blocking Session for Event: 'cursor: pin S wait on X'
NOTE:873243.1 - Troubleshooting 'enq: TX - index contention' Waits
- MEMORY LEAK USING BULK COLLECT WITHIN CURSOR OPENED USING NATIVE DYNAMIC SQL
NOTE:102925.1 - Tracing Sessions that are Waiting on an Enqueue or a Lock
NOTE:1064487.1 - Script to Collect Log File Sync Diagnostic Information (lfsdiag.sql)
NOTE:1356828.1 - FAQ: 'cursor: mutex ..' / 'cursor: pin ..' / 'library cache: mutex ..' Type Wait Events
NOTE:1357946.1 - Troubleshooting 'library cache: mutex X' Waits.
NOTE:164768.1 - Troubleshooting: High CPU Utilization
NOTE:179582.1 - How to Find TX Enqueue Contention in RAC or OPS
NOTE:361670.1 - Slow Performance with High CPU Usage on 64-bit Linux with Large SGA
NOTE:404991.1 - How to Tune Queries with High CPU Usage
NOTE:563566.1 - Troubleshooting gc block lost and Poor Network Performance in a RAC Environment
NOTE:34592.1 - WAITEVENT: "log file sync" Reference Note
NOTE:62143.1 - Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contention
NOTE:727400.1 - WAITEVENT: "library cache: mutex X"

- BIG PGA MEM ALLOC DURING PARSE TIME - KXS-HEAP-C

- INCORRECT WAIT EVENTS IN 11.2

NOTE:1511700.1 - ORA-00060 Single-Resource Deadlock Occurs on Autonomous Transaction
NOTE:1298015.1 - WAITEVENT: "cursor: pin S wait on X" Reference Note
NOTE:1298471.1 - H$PSEUDO_CURSOR
NOTE:1310764.1 - WAITEVENT: "cursor: pin S" Reference Note
NOTE:1349387.1 - Troubleshooting 'cursor: pin S wait on X' waits.
NOTE:1020008.6 - SCRIPT: FULLY DECODED LOCKING

- HIGH VERSION COUNT FOR INSERT STATEMENTS WITH REASON INST_DRTLD_MISMATCH

About Me

...............................................................................................................................

● 本文來自於MOS轉載文章(文件 ID 1602076.1)

● 小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/

● QQ群：230161599 微信群：私聊

● 聯絡我請加QQ好友(642808185)，註明新增緣由

● 版權所有，歡迎分享本文，轉載請保留出處

...............................................................................................................................

手機長按下圖識別二維碼或微信客戶端掃描下邊的二維碼來關注小麥苗的微信公眾號：xiaomaimiaolhr，免費學習最實用的資料庫技術。

【MOS】RAC 環境中最常見的 5 個資料庫和/或例項效能問題 (文件 ID 1602076.1)

RAC 環境中最常見的 5 個資料庫和/或例項效能問題 (文件 ID 1602076.1)

適用於:

用途

適用範圍

詳細資訊

問題 1：大量塊丟失 (gc lost blocks, gc current/cr lost blocks)

問題 2：大量 log file sync 等待

問題 3：Mutexes 上的長時間等待

問題 4：高 enq: TX -row lock contention, enq: TX - index contention, enq: TX - ITL allocate entry 等待

問題 5：高 CPU 和記憶體開銷

參考

相關文章