本文探讨了在BCP中搜索“SD_COND_ACCESSbuffer”关键词的重要性，通过具体案例分析，指出全表扫描和条件表缓存导致的性能瓶颈。建议对于超过5MB的大型条件表，如A910和A004，应遵循Note23877和Note886773的指导，取消缓存以提升系统效率。
https://archive.sap.com/discussions/thread/2057614
1：帮你找好reference了，在BCP用关键词“SD_COND_ACCESS buffer”搜就行，如下3个都是very High，数量级和Coty的近似或者更高，但都是指向明显的full table scan和高频table invalidation
0000341769 2017
A910 contains 655.332 rows
switching to generic key buffering as per note 23877
0000316275 2017
71,360,005 records
ST12 traces show that this table is being access using a full table scan
In order to help eliminate these full table scan accesses, very large condition tables such as this should be unbuffered
0000103821 2016
The Table A004 which is around 60 million is accessed with Full Table Scan with the SQL
It is recommended to not buffer a condition table which has size above 5MB.
To improve performance please follow the advice of note 23877, mentioned also in
note 886773 point 4., and deactivate the buffering of condition table A004.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
