本帖最后由 jiawang 于 2024-5-7 11:22 编辑
db:11.2.0.4 现象: Top 10 Foreground Events by Total Wait Time
Event | Waits | Total Wait Time (sec) | Wait Avg(ms) | % DB time | Wait Class | DB CPU |
| 640.4 |
| 56.5 | | reliable message | 193,457 | 179.2 | 1 | 15.8 | Other | log file switch (checkpoint incomplete) | 174 | 129.2 | 742 | 11.4 | Configuration | gc current block 2-way | 122,953 | 64.3 | 1 | 5.7 | Cluster | enq: TX - index contention | 7,662 | 35.6 | 5 | 3.1 | Concurrency | gc buffer busy release | 4,108 | 27.8 | 7 | 2.5 | Cluster | gc current block busy | 18,403 | 23.4 | 1 | 2.1 | Cluster | buffer busy waits | 5,378 | 22.6 | 4 | 2.0 | Concurrency | SQL*Net more data from dblink | 34,351 | 17.1 | 0 | 1.5 | Network | gc buffer busy acquire | 7,979 | 12 | 2 | 1.1 | Cluster
|
具体可以参考《WAITEVENT: "reliable message" Reference Note (Doc ID 69088.1)》。
SQL> SELECT CHANNEL, SUM(wait_count) sum_wait_count 2 FROM GV$CHANNEL_WAITS 3 GROUP BY CHANNEL 4 ORDER BY SUM(wait_count) DESC;
CHANNEL SUM_WAIT_COUNT ---------------------------------------------------------------- -------------- Result Cache: Channel 1283422273 MMON remote action broadcast channel 1399425 kxfp control signal channel 1069929 RBR channel 925520 obj broadcast channel 507549 kill job broadcast - broadcast channel 960 parameters to cluster db instances - broadcast channel 960 LCK0 ksbxic channel 18 service operations - broadcast channel 2 quiesce channel 2
10 rows selected. 到此可以得出简单结论:该库的这个等待事件可能和Result Cache有关。
解决方案: 在mos上搜索相关关键字,发现了匹配的官方文档《Very High Waits for 'reliable message' After Upgrade to 11.2.0.4 When Using Result Cache (Doc ID 1951729.1)》,命中了bug 18416368。 当前版本是11.2.0.4版本,并配置了result cache,如下图: SQL> show parameter result_cache_max_size
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ result_cache_max_size big integer 536096K
文档中给出了3种解决方案,若业务有影响,可根据情况选择其中一种方式进行修复: 升级到12C以上版本。 应用patch 18416368小补丁。 禁用result cache,并重启实例。 SQL> alter system set result_cache_max_size=0; |