cartersian 笛卡尔积 4295M极限 DFS lock handle

笛卡尔积遇到hash join可以使用几个T的Temp

4294M是极限 1001*6K本来是6M，如果该表一条记录3分钟，那么实际X条记录就是3X分钟，所以导致要跑几个小时。 temp 增长很快。

In 12c database, create or truncate table is very slow. High "DFS lock handle" waits are observed.  Same create or truncate statement runs faster in 11g.

This bug is only relevant when using Real Application Clusters (RAC)

The Past Image of block in buffer (PI buffer) may be created incorrectly.
That PI buffer is not flushed from cache and checkpoint will never complete.
This situation brings hang issues, and restart of DB instance is required to resolve this situation.
 
As a reported case caused by this bug, "ALTER DATABASE BEGIN BACKUP" waits for "DFS lock handle".
In this case, CKPT process holds CI enqueue, and the server process waits for this enqueue.
But CKPT never releases CI enqueue, and BEGIN BACKUP hangs until restarting instance.

Slow truncate is seen on top of 12.1 due to 'DFS lock handle' contention.
 
Rediscovery Notes
 
Waits are observed as follows:
... 
WAIT #139702114289904: nam='DFS lock handle' ela= 554 ype|mode=1128857605 id1=123 id2=3 obj#=3055619 tim=1956896600472
...
 
where (id1=123) indicates "Nuke ILM file stats" as per Note:34631.1
 
This can occur even if "_enable_heatmap_internal" is set to false or with heat_map=off.

Transaction Recovery Slow And High Row Lock Contention After Killed Large Transaction in RAC (Doc ID 2668617.1)

Top 5 Database and/or Instance Performance Issues in RAC Environment (Doc ID 1373500.1)