執行DDL必須請求一個行緩衝鎖（row cache lock）來鎖住資料字典（Data Dictionary）資訊。共享池（Shared Pool）包含來自資料字典的的行緩衝區，可以減少磁碟的I/O訪問，並允許對行進行加鎖。資料字典行鎖被叫做行緩衝佇列鎖（Row Cache Enqueue Locks）。這個佇列鎖結構從共享池中按需求分配，當這些請求在等待並超時就會看到行緩衝佇列鎖。row cache lock等待事件是一個共享池相關的等待事件，是由於對字典緩衝的訪問造成的。每一個行緩衝佇列鎖都對應一個特定的資料字典物件，這被叫做佇列鎖型別，並可以在V$ROWCACHE檢視中找到。

SELECT * FROM V$EVENT_NAME D WHERE D.NAME = 'row cache lock';

SELECT *

  FROM DBA_HIST_ROWCACHE_SUMMARY D

 WHERE D.SNAP_ID BETWEEN 1 AND 3014

   AND D.GETS > 0;

SELECT * FROM V$ROWCACHE WHERE CACHE# IN ('7', '10');

SELECT A.PARAMETER FROM V$ROWCACHE  A WHERE CACHE# =P1;

SELECT * FROM DBA_AUDIT_TRAIL d WHERE /*RETURNCODE IN (1017) AND*/ d.action_name='LOGON' AND D.returncode>0 AND D.returncode<>1017;

[root@rhel6lhr ~]# oerr ora 1005

01005, 00000, "null password given; logon denied"

// *Cause:

// *Action:

[root@rhel6lhr ~]# oerr ora 1017

01017, 00000, "invalid username/password; logon denied"

// *Cause:

// *Action:

[root@rhel6lhr ~]#

在AWR中需要檢視Dictionary Cache Stats部分用以確定問題。

Resolving Issues Where 'Row Cache Lock' Waits are Occurring (文件 ID 1476670.1)

In this Document

APPLIES TO:

PURPOSE

TROUBLESHOOTING STEPS

 Brief Definition:

The shared pool contains a cache of rows from the data dictionary that helps reduce physical I/O on the data dictionary tables. The row cache lock is used primarily to serialize changes to the data dictionary and is waited on when a lock on a data dictionary cache is required. Waits on this event usually indicate some form of DDL occuring, or possibly recursive operations such as storage management and incrementing sequence numbers.

Problem Confirmation:

• Significant wait for latch: row cache objects
• Slow overall performance with row cache lock
• High CPU usage

Row Cache Lock

When DDLs execute, they must acquire locks on the row cache in order to access and change the Data Dictionary information. Once the locks are taken then they can be allowed to modify individual rows in the data dictionary. 

Reducing Waits

1. The data dictionary resides in the shared pool. If the shared pool is not sized correctly then the data dictionary might not be fully cached. This should be handled automatically with the automatic shared memory tuning feature. The following documents provide more details: 

 2. Find which cache is being waited for:

In this example the cache is the "DC_SEQUENCES" cache.

3. Take cache dependent actions:

DC_SEQUENCES
For DC_SEQUENCES, consider caching sequences using the cache option.

DC_OBJECTS
Look for any object compilation activity which might require an exclusive lock, blocking other activities

DC_SEGMENTS
Contention here is most likely to be due to segment allocation.  Investigate what segments are being created at the time.

DC_USERS
This may occur if a session issues a GRANT to a user and that user is in the process of logging on to the database. Investigate why grants are being made while the users are active.

DC_TABLESPACES
The most likely cause is the allocation of new extents. If extent sizes are set low then the application may constantly be requesting new extents and causing contention. Do you have objects with small extent sizes that are rapidly growing? (You may be able to spot these by looking for objects with large numbers of extents). Check the trace for insert/update activity, check the objects inserted into for number of extents.

4. For further information on row cache issues, review the following:

Measuring Success

Once you have applied the changes to resolve the issues you have found, compare the latest AWR to the AWR that led you here via Guided Resolution (that AWR becomes your baseline). Look at the percentage decrease total wait time for this event. If there are still issues, re- evaluate those and address them according to the specific symptom.

Known Issues

REFERENCES

WAITEVENT: "row cache lock" Reference Note (文件 ID 34609.1)

"row cache lock" Reference Note

• Brief definition
• Individual wait details (eg: For waits seen in V$SESSION_WAIT)
• Systemwide wait details (eg: For waits seen in V$SYSTEM_EVENT)
• Reducing waits / wait times
• Troubleshooting
• Known Bugs

Definition:

• Versions: 7.3 - 12.1
  Documentation: 12.1 11.2 11.1 10.2 10.1 
  
  
• This event is used to wait for a lock on a data dictionary cache specified by "cache id" (P1).

  If running Real Application Clusters (RAC) then LCK0 is signalled to get the row cache lock for the foreground waiting on this event. The LCK0 process will get the lock asynchronously. In exclusive mode the foreground process will try to get the lock.

Individual Waits:

  Parameters:

• P1 = cache - ID of the dictionary cache
• P2 = mode - Mode held
• P3 = request - Mode requested

• cache - ID of the dictionary cache

  Row cache lock we are waiting for. Note that the actual CACHE# values differ between Oracle versions. The cache can be found using this select - "PARAMETER" is the cache name:

  SELECT cache#, type, parameter 
    FROM v$rowcache     
   WHERE cache# = &P1
  ;

  In a RAC environment the row cache locks use global enqueues of type "Q[A-Z]" with the lock id being the hashed object name.

  
  

• mode - Mode held

  The mode the lock is currently held in:

    KQRMNULL 0   null mode - not locked
    KQRMS    3   share mode
    KQRMX    5   exclusive mode KQRMFAIL 10  fail to acquire instance lock

• request - Mode requested

  The mode the lock is requested in:

    KQRMNULL 0   null mode - not locked
    KQRMS    3   share mode
    KQRMX    5   exclusive mode KQRMFAIL 10  fail to acquire instance lock

  Wait Time:

In exclusive mode any process other than PMON will timeout after 8 hours (10000 waits of 3 seconds)

In RAC the foreground will wait 60 seconds for the LCK0 to get the lock, the foreground will wait in infinite loop until the lock has been granted (LCK0 will notify foreground).

In either case PMON will wait for only 5 seconds.

If a session times out when waiting for a row cache lock then it will report this to the alert log and tracefile with a message like:

WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK

  Finding Blockers:

Holders and requesters can be seen in view X$KQRFP for parent objects, and X$KQRFS for subordinates. 
eg: The following select will show all holders of parent row cache objects so can be used to help find the blocking session.

SELECT * FROM x$kqrfp WHERE kqrfpmod!=0;

(KQRFPSES is the address of the holding session V$SESSION.SADDR)

Systemwide Waits:

It is important to determine which cache is being waited for. The V$ROWCACHE view gives an overview of which caches are being used most, but the waits may not necessarily be on the most used cache. The V$ACTIVE_SESSION_HISTORY view can be used to get an idea of which cache ids (P1) are involved in waits.

• If the issue is general across various caches (different cache ids) then the shared pool may need increasing in size to allow more dictionary information to be cached
• If the issue is focused on a specific cache id then options typically depend on the cache involved - see the Troubleshootingsection below.

Reducing Waits / Wait times:

Options to reduce waits depends on the specific cache that has the contention. See the documents in the Troubleshooting section below for advice on various caches.

Troubleshooting

See the following documents for help troubleshooting issues relating to "row cache lock" waits

Document:1476670.1 Resolving Issues Where 'Row Cache Lock' Waits are Occurring
Document:278316.1 Troubleshooting "WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!"

Known Issues / Bugs:

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
                

NB	Prob	Bug	Fixed	Description
	-	17828499	12.1.0.1.4, 12.1.0.2, 12.2.0.1	Opening PDB hangs waiting for row cache lock on open UPGRADE
	-	16921340	12.1.0.1.1, 12.1.0.2, 12.2.0.1	Non-CDB to PDB plugin hangs
	II	13884774	12.1.0.2, 12.2.0.1	Deadlock from concurrent select/ALTER SUMMARY and ALTER TABLE if query_rewrite_enabled set to true/force - superseded
	II	16994952	12.1.0.1	Unable to unschedule propagation due to CJQ self-deadlock / hang
	II	14117976	11.2.0.3.BP14, 11.2.0.4, 12.1.0.1	Database hangs when executing multiple MV DDL's in parallel
	III	13496395	11.2.0.4, 12.1.0.1	Hang / deadlock involving ACCOUNT_STATUS object for concurrent LOGON and ALTER USER
	III	7715339	11.2.0.1	Logon failures causes "row cache lock" waits - Allow disable of logon delay
	III	21153142	12.2.0.1	Row cache lock self deadlock accessing seed PDB
	II	21091431	12.1.0.2.160419, 12.1.0.2.DBBP13, 12.2.0.1	row cache lock during trigger creation using editions
	II	19907473	12.2.0.1	GEN0 process causing database hang
	III	15850031	11.2.0.4, 12.1.0.2, 12.2.0.1	Rare instance hang: deadlock between 'row cache lock' and 'cursor: pin S wait for X'
	II	13622515	11.2.0.4, 12.1.0.2, 12.2.0.1	library cache <-> row cache deadlock / hang when altering constraint with MV involved - superseded
	II	13869467	12.1.0.2	Many waits for 'row cache lock' in RAC while creating many tables with constraints
	II	13979519	11.2.0.3.BP11, 11.2.0.4, 12.1.0.1	Locks on dc_users kept too long
	II	13916228	11.2.0.4, 12.1.0.1	Enabling/disabling constraints makes DML timeout in RAC - superseded
	II	13502860	11.2.0.4, 12.1.0.1	"row cache lock" contention on SYS_PLSQL_xx objects using PIPELINED functions
	-	13387978	11.2.0.4, 12.1.0.1	Sessions running TRUNCATE causing a deadlock, even if the constraints are disabled
	-	12953743	11.2.0.3.BP13, 11.2.0.4, 12.1.0.1	Parallel CTAS of table with a Securefile is slower than parallel IAS / PIDL
	I	12889054	11.2.0.2.BP16, 11.2.0.3.BP05, 11.2.0.4, 12.1.0.1	AWR snapshot hangs on dc_objects row_cache_lock held by ctas job
D	-	12792862	11.2.0.4, 12.1.0.1	Performance of INSERT using binary xml is very slow due to "row cache lock" in RAC environment - superseded
	II	12351027	11.2.0.4, 12.1.0.1	Redefinition causing deadlock between "row cache lock" and "library cache lock"
	II	11693365	11.2.0.3, 12.1.0.1	Concurrent Drop table and Select on Reference constraint table hangs (deadlock)
	I	10382754	11.2.0.2.BP17, 11.2.0.3, 12.1.0.1	Poor performance/ rowcache contention in 11g with partitioning due to invalidation of objects
	IIII	10204505	11.2.0.3, 12.1.0.1	SGA autotune can cause row cache misses, library cache reloads and parsing
	II	10126219	11.2.0.1.BP08, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1	Undetected deadlock 'library cache lock'/'row cache lock' with concurrent DDLs on partition tables.
	II	9952554	11.2.0.2.8, 11.2.0.2.BP18, 11.2.0.3, 12.1.0.1	Undetected deadlock 'library cache lock'/'row cache lock' with a session modifying a constraint
	II	9866045	11.2.0.3, 12.1.0.1	Long wait on 'wait for master scn' in LCK causing long row cache lock waits
	III	9776608	11.2.0.2, 12.1.0.1	Hang from concurrent login to same account with a wrong password
	II	9278979	11.2.0.2, 12.1.0.1	Instance hang / ORA-4021 with OPTIMIZER_USE_PENDING_STATISTICS = true
	I	8268775	11.1.0.7.4, 11.2.0.1.2, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1	High US enqueue contention during a login storm or session failover
	-	8364676	11.1.0.7.2, 11.2.0.1	row cache lock waits from background space preallocation
	III	7529174	10.2.0.5, 11.1.0.7.3, 11.2.0.1	Deadlock / hang between SMON and foreground process
	-	7416901	11.1.0.7.1, 11.2.0.1	Deadlock between QC and PQ slaves when CELL_PARTITION_LARGE_EXTENTS = ALWAYS
	II	7313166	10.2.0.5, 11.2.0.1	Startup hang with self deadlock on dc_rollback_segments
	II	6870994	10.2.0.5, 11.1.0.7.3, 11.2.0.1	High US enqueue / rowcache lock while trying to online a NEW undo segment
	III	6027068	10.2.0.5, 11.2.0.1	Contention on ORA_TQ_BASE$ sequence
	-	5756769	10.2.0.4.1, 10.2.0.5, 11.1.0.7, 11.2.0.1	Deadlock between Create MVIEW and DML
	III	6143420	10.2.0.5, 11.1.0.6	Deadlock involving "ROW CACHE LOCK" on dc_users AND "CURSOR: PIN S WAIT ON X"
	III	6004916	10.2.0.5, 11.1.0.6	Hang involving row cache enqueues in RAC (ORA-4021)
	II	5883112	10.2.0.4, 11.1.0.6	False deadlock in RAC
	II	5138741	10.2.0.4, 11.1.0.6	High waits on 'row cache lock' when using materialized views on RAC
	II	4604972	11.1.0.6	Deadlock on dc_users by Concurrent Grant/Revoke
	-	4579381	10.1.0.5, 10.2.0.2, 11.1.0.6	Deadlock on DC_USERS in RAC (ORA-4020)
	-	4446011	9.2.0.8, 10.1.0.5, 10.2.0.2, 11.1.0.6	Hang with row cache lock deadlock from concurrent ALTER USER / TRUNCATE
	II	4390868	10.1.0.5, 10.2.0.3, 11.1.0.6	Contention on DC_SEGMENTS due to small cache size on SYS.AUDSES$
	-	4313246	9.2.0.8, 10.1.0.5, 10.2.0.2, 11.1.0.6	PLSQL execution can hold dc_users row cache lock leading to hang / deadlocks
	I	4153150	9.2.0.8, 10.2.0.2, 11.1.0.6	Deadlock on dc_rollback_segments from concurrent parallel load and undo segment creation
	I	6051177	10.2.0.4.1, 10.2.0.5	Hang / deadlock between coalesce and DBMS_STATS.gather_table_stats
	-	5983020	10.2.0.4	MMON deadlock with user session executing ALTER USER
	-	4275733	9.2.0.8, 10.1.0.5, 10.2.0.1	Deadlock between library cache lock and row cache lock from concurrent rename partition
	I	5641198	10.2.0.1	Some waits may be longer than needed ("row cache lock") in RAC
	-	4137000	10.1.0.5, 10.2.0.1	Concurrent SPLIT PARTITION can deadlock / hang
	-	3627263	9.2.0.6, 10.1.0.4, 10.2.0.1	Deadlock / hang during RAC instance startup
	II	3424721	9.2.0.6, 10.1.0.3, 10.2.0.1	Hang/deadlock from ALTER INDEX REBUILD on partition with concurrent SQL
	-	2615271	9.2.0.6, 10.1.0.2	Deadlock from concurrent GRANT and logon

• '*' indicates that an alert exists for that issue.
• '+' indicates a particularly notable issue / bug.
• See Note:1944526.1 for details of other symbols used

Related:

Document:1628089.1 AWR Report Interpretation Checklist for Diagnosing Database Performance Issues
Document:1359094.1 How to Use AWR Reports to Diagnose Database Performance Issues
Document:1274511.1 General SQL_TRACE / 10046 trace Gathering Examples

Troubleshooting: "WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! " (文件 ID 278316.1)

故障排除："WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! " (文件 ID 2016422.1)

文件內容

適用於:

用途

本文件的目的是幫助排查原因"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "

排錯步驟

什麼是 row cache enqueue 鎖（Row Cache Enqueue Lock）？

行快取（Row Cache）或資料字典快取（Data Dictionary Cache）是儲存資料字典資訊的共享池的記憶體區域。row cache 儲存資料時並不是以資料塊的形式，而是以行的形式。row cache enqueue 鎖是在資料字典行的鎖。此 enqueue 是關於特定資料字典物件的。這就是所謂的 enqueue 型別，可以在檢視 V$rowcache 中找到。

對於每個版本 row cache 型別的列表，請參閱：

"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 警告資訊是什麼意思？

當我們試圖獲得 row cache 鎖，這種等待事件將被使用。
當 row cache 衝突發生時，如果不能在一個預定的時間週期內得到 enqueue，將在 USER_DUMP_DEST 或 background_dump_dest 目錄下生成一個跟蹤檔案，這取決於是使用者還是後臺程式建立的跟蹤檔案。alert.log 通常會相應的更新警告訊息和跟蹤檔案的位置。
資料庫檢測到核心資源被持有太久並通知管理員，從而讓這種情況可以得到解決。這也可能伴隨著資料庫掛起或變慢。
alert.log 的訊息和生成的跟蹤檔案趨向於包含訊息：

如果不能立即獲取 rowcache entry 鎖，那麼進入一個迴圈，先釋放 row cache 物件閂鎖，等待（等待上述等待事件），重新獲得閂鎖，然後再次嘗試獲取 rowcache 鎖。在單例項模式，會重複 1000次直到程式報錯“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。在 RAC 環境會一直重複，直到不能獲得例項鎖或者被中斷。

Systemstate dump 可以提供一些有用的資訊診斷爭用的原因。

"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 可能的原因

SGA收縮（shrink）/調整大小的操作（resize）

如果 SGA 動態地改變大小，需要持有各種 latches 來避免其它程式同時操作，直到操作完成。如果調整大小需要一段時間，或者是經常發生，你會看到"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!"的發生。定位這種情況的方法是，有很多'SGA: allocation forcing component growth'等待事件，或 AWR 的 TOP 列表有類似等待,以及阻塞等待"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 的會話在等待'SGA: allocation forcing component growth'（或類似）。有一些可用的程式碼修復，請參閱：

row cache enqueue 型別

對於每一個 enqueue 型別，都有對應的一些操作會需要獲取這類 enqueue。佇列的型別,可能給出由於操作可能導致的問題的指示。一些常見的原因如下：

最可能的原因是新 extent 的分配。如果 extent 大小設定過小，那麼應用程式可能會不斷地要求新的 extent，這可能導致爭用。你有很小的 extent 尺寸，正在迅速增長的物件嗎？（通過查詢具有大量 extents 的物件可以定位它們）。檢查 insert/update 活動的 trace，查詢那些就有很多 extents 的物件。

檢查應用程式用到的 sequence 的 cache 的大小：

一個會話正在對一個使用者執行 GRANT，與此同時此使用者正在登入到資料庫中，此時可能會發生死鎖或導致"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 。

這很可能是 segment 的分配導致的。確定持有鎖的使用者正在做什麼並使用 errorstacks 進行診斷。

這可能是由於 rollback 段的分配導致的。正如 dc_segments，確定誰持有鎖並收集 errorstack 來進行診斷。請記住，在多節點系統（RAC）上，持有者可能在另一節點上，因此需要所有節點的 systemstate。

此 enqueue 關係到 AWR（Automatic Workload Repository）的控制權。任何操縱 AWR 資料庫的操作將持有它. 要分析這個問題,需要查詢是那些程式阻塞了它們。

  RAC 相關的 Bugs

我可以收集哪些資訊，以確定原因？

Systemstate dump

當問題發生時，錯誤會記入 alert.log，並自動產生一個 systemstate dump 檔案。

AWR，ADDM 和 ASH 報告

收集兩份 AWR 報告，一份有問題時間段的,另一個是沒有問題時間段的，因為這些可以幫助我們理解問題發生時資料庫的狀況 AWR，ADDM，ASH 報告，可以相互取長補短，從而更完整地理解整個問題。

取決於 AWR 快照生成的時間間隔，收集最小時間間隔的報告。預設的快照是一個小時的時間間隔。

鑑於分析 systemstate 是一件很複雜的事情，您可以建立一個服務請求，並上傳 alert.log，systemstate dump，以及問題發生前和問題發生時的 AWR 報告請 Oracle 技術支援來分析。

如何分析收集到的診斷資訊？

Systemstate dump

通常情況下， row cache enqueue 是一系列事件的一部分，阻塞了申請 row cache enqueue 的程式的程式很可能被另一個程式阻塞。Row cache enqueue 經常是問題的表象。

Systemstate dump 可以幫助查詢申請的是哪一個 row cache ，並可能有助於發現阻塞程式。

trace 的標題顯示下列內容：

• 等待 row cache enqueue 鎖的 Oracle 程式號（PID）（在這個案例，程式 77）。
• 正在申請的 row cache enqueue 的模式（請求：S）。

因此，在上述例子中，程式 77 是在請求以共享模式獲得 row cache（請求：S）。

Systemstate 包含資料庫中每一個程式的狀態資訊，因此可以在 systemstate 中查詢這個程式：

從上面我們看到，程式 77 請求共享模式獲得 row cache dc_users。
程式 77 處於等待狀態，意味著被其它程式阻塞，我們現在需要檢查 systemstate 判斷誰持有資源並阻塞了這個程式。

搜尋引用的物件，在這個例子中，是 object=0x1dc9a5d30。
這樣做完以後，我們發現，程式 218 正以獨佔模式持有這個物件：

獨佔模式的請求，將會一直阻塞共享模式的請求，直到該程式獨佔模式的請求被滿足並稍後釋放了這個資源。因此，這將阻止其他共享模式請求。請注意，這是請求獨佔而不是獨佔持有，所以這個請求也一定被阻塞了。檢視其他程式中，我們看到程式 164 在以共享模式（mode=s）持有這個物件。

因此，程式 164 以共享模式持有 row cache enqueue（mode= S），從而防止了程式 218 以獨佔模式獲得該 row cache enqueue。此外，我們看到，程式 164 在 ON CPU（systemstate 顯示最後一個等待是'SQL*Net message from client'，而不是等待'SQL*Net message from client'）。為了進一步診斷，技術支援需要檢查堆疊呼叫，以確定為什麼這個程式在 ON CPU 並持有該佇列這麼久（從開始已經等待了2539秒）。

在這個例子中，程式 18（MMON）等待以共享模式獲得型別為 dc_awr_control 的 row cache。

物件（object=39a79f090）的 row cache lock 被程式 269 以獨佔模式（mode=x）持有。程式在等待'SGA: allocation forcing component growth'。

因此根本原因就是 SGA 的大小調整，等待 row cache 是次要結果。
我們使用該期間的 AWR 報告看相關資訊：

AWR 報告

Top 5 Timed Events                                         Avg %Total               
~~~~~~~~~~~~~~~~~~                                        wait   Call               
Event                                 Waits    Time (s)   (ms)   Time Wait Class    
------------------------------ ------------ ----------- ------ ------ ----------    
SGA: allocation forcing compon   42,067,317      38,469      1    7.6      Other    
CPU time                                          2,796           0.6               
db file sequential read             132,906         929      7    0.2   User I/O    
latch free                        4,282,858         704      0    0.1      Other    
log file switch (checkpoint in          904         560    620    0.1 Configurat    
          -------------------------------------------------------------       

我們可以清楚地看到，在 Top 5 等待事件中，整個系統中有針對此事件的一個顯著等待；並且'SGA: allocation forcing component growth' 是這一時間點的一個主要問題。"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!" 訊息的根本原因就是記憶體調整活動，TOP 5 的等待事件甚至不顯示等待“row cache"症狀。

對於頻繁的記憶體調整，有幾個潛在的可用修復，請參閱：

10g 以前的版本可能存在的問題

10g 之前的版本，檢測 row cache 級別死鎖的方法有限。為了儘量減少發生死鎖的可能性，可能的解決方法：

• 設定 TIMED_STATISTICS=FALSE
• 設定 _row_cache_cursors=20 以上（預設值 10）
• 不要做任何 tracing

其他問題疑難解答

對於其他效能問題的故障排除,請參閱：

Bug 12772404 - Significant "row cache objects" latch contention when using VPD (Doc ID 12772404.8)

參考