点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
当我们更换工作中心时,它非常慢。 这需要超过10分钟的时间并超时。 OSS注释415031讨论了AFRU表上的索引。 AFRU本身的查询大约需要9分钟。 AFRU表大约有500万行。
我有几个问题,当我查看我的解释语句时,它正在选择一个没有" WHERE"字段的自定义索引。 我很好奇,为什么oracle优化器不选择表扫描? 我希望对AFRU表进行全表扫描(具有超过500万行的速度比使用没有适当字段的索引还要快)。 是否可能由于选择了错误的索引而导致延迟?
我试图将HINT放入自定义程序中,看看是否可以强制执行TABLE FULL SCAN,它的速度似乎更快。
我很困惑。 这是一个一次性的方案,我当时认为表扫描可能不会那么糟糕。 但是优化器从不选择表扫描。 我想避免为此类异常情况创建新索引,但是超时不是一种选择。
统计
解析时间戳:20180208 17:57:45
系统:RQ1
SQL_ID 18fyjygmadgtd,子编号1
-------------------------------------
SELECT/* + FIRST_ROWS(1)*/*来自" AFRU",而" MANDT" =:A0 AND
" ARBID" =:A1和ROWNUM <=:A2
计划哈希值:4214817510
--------------------------------------------------- --------------------------------------------------
| ID | 操作| 姓名| 行| 字节数| 费用(%CPU)| 时间|
--------------------------------------------------- --------------------------------------------------
| 0 | 选择声明| | | | 256(100)| |
| * 1 | COUNT STOPKEY | | | | | |
| * 2 | 表访问按索引行分批| AFRU | 1 | 585 | 256(0)| 00:00:01 |
| * 3 | 索引范围扫描| AFRU〜Z01 | | | 8(0)| 00:00:01 |
--------------------------------------------------- --------------------------------------------------
查询块名称/对象别名(由操作ID标识):
--------------------------------------------------- --------------
1-SEL $ 1
2-SEL $ 1/AFRU @ SEL $ 1
3-SEL $ 1/AFRU @ SEL $ 1
谓词信息(由操作ID标识):
--------------------------------------------------- ----
1-过滤器(ROWNUM <=:A2)
2-filter(" ARBID" =:A1)
3-访问(" MANDT" =:A0)
列投影信息(由操作ID标识):
--------------------------------------------------- ------------
1-" MANDT" [VARCHAR2,9]," AFRU"。" RUECK" [VARCHAR2,30]," AFRU"。" RMZHL" [VARCHAR2,24],
" AFRU"。" GRUND" [VARCHAR2,12]," AFRU"。" PERNR" [VARCHAR2,24]," AFRU"。" ISDD" [VARCHAR2,24],
" AFRU"。" ISDZ" [VARCHAR2,18]," AFRU"。" IERD" [VARCHAR2,24]," AFRU"。" IERZ" [VARCHAR2,18],
" AFRU"。" ISBD" [VARCHAR2,24]," AFRU"。" ISBZ" [VARCHAR2,18]," AFRU"。" IEBD" [VARCHAR2,24],
" AFRU"。" IEBZ" [VARCHAR2,18]," AFRU"。" ISAD" [VARCHAR2,24]," AFRU"。" ISAZ" [VARCHAR2,18],
" AFRU"。" KAPTPROG" [VARCHAR2,12]," AFRU"。" OBMAT" [VARCHAR2,54],
" AFRU"。" OBCHA" [VARCHAR2,30]," AFRU"。" LICHA" [VARCHAR2,45]," AFRU"。" MYEAR" [VARCHAR2,12],
" AFRU"。" ME_SFCID" [VARCHAR2,180]," AFRU"。" ROLE_ID"
3-" AFRU" .ROWID [ROWID,10]," MANDT" [VARCHAR2,9]," AFRU"。" CATSBELNR" [VARCHAR2,30],
" AFRU"。" STZHL" [VARCHAR2,24]
表AFRU
最后统计日期02/06/2018 23:35
分析方法充足5,775,114行
行数5,775,114
已分配块数490,556
空数 块0
平均空间0
链数0
平均行长585
分区NO
并行度1
非唯一索引AFRU〜Z01
列名#Distinct
MANDT 2
CATSBELNR 964,686
STZHL 11,121
非唯一索引AFRU〜Z02
列名#Distinct
佛得角5,792
WERKS 104
唯一索引AFRU〜0
列名#Distinct
MANDT 2
RUECK 3,146,901
RMZHL 80,338
列统计
列#Distinct U #BU AVGL数据类型Len
ABARB 101 1 4 VARCHAR2 9
AENAM 632 1 3 VARCHAR2 36
ANZMA 1 1 2 NUMBER 22
APLFL 2 1 5 VARCHAR2 18
APLZL 541 1 9 VARCHAR2 24
> ARBID 1146 1 9 VARCHAR2 24
AUERU 3 1 2 VARCHAR2 3
AUFNR 2167229 1 13 VARCHAR2 36
AUFPL 2203561 1 11 VARCHAR2 30
AUSOR 2 1 2 VARCHAR2 3
BELNR_IST 1 1 2 VARCHAR2 30
BELNR_UMB 1 1 2 VARCHAR2 30 BEMOT 2 1 3 VARCHAR2 6
BUDAT 5792 1 9 VARCHAR2 24
CANUM 1 1 5 VARCHAR2 12 12
CATSBELNR 964686 1 4 VARCHAR2 30
STZHL 11121 1 9 VARCHAR2 24
已经有一些出色的输入,我也同意您的数据和统计数据存在某些特殊性,这导致Oracle选择索引。
我看到您的统计数据是最近的,因此它们可能没有错。 但是我有另一种理论可以提供:ARBID字段通常是填充的还是很多为空? 归结为数据分发,有时统计可能会误解数据分发。 如果唯一性是100%,则应选择全表扫描。 但是,如果90%的行为空,或者您有多次重复出现的值(通常是状态字段),那么唯一性就很低,从统计学上讲,优化程序可能会决定我们很可能在非 索引字段很容易,因为大多数值都相似。 在几乎为空的列中搜索值时,这尤其是个问题。
此外,仅出于兴趣考虑,请查看"最多1行"的行为是否与"选择单个"不同。 在进行此操作的同时,还请尝试选择SELECT而不加任何限制和变化...高达10/100/1000 ROWS。
嗨,克里希,
我提到的参数对CBO在全表扫描和索引扫描之间的决定方式有很大的影响。
更多信息记录在下面的链接中:
https://docs.oracle.com /database/121/REFRN/GUID-BA25DBA7-3826-48CA-849B-6D8E3326A1B4.htm#REFRN10143
根据我们在SAP中的经验,此参数存在2个可接受的值。
20或100,具体取决于SAP System类型。 对于OLAP,我们设置为20,对于OLTP,我们没有设置(意味着采用Oracle默认值,即100)。
我想说的是,SAP中只有这两个值。 我们之所以没有设置任何其他值的原因是,此参数影响整个系统,并且与SAP标准的任何偏差都会使整个SAP系统发疯,因此性能会下降。
值20和100已经在SAP中进行了多年的测试,并且只有使用这两个值(同样取决于SAP系统类型),我们才能绝对确保总体系统性能与我们期望的最接近。/p>
但是,这当然并不意味着不会发生任何性能问题。 总是存在例外,尤其是在IT部门和SAP中也是如此。
您是否可以运行SQL跟踪并通过"解释"按钮发布" SQL访问路径的解释"显示(替代 ,请使用ST04或ST04n)
是的,后来使用Netweaver对其进行了标记。 尽管有许多Netweaver标签,但我不确定这些天大多数Basis用户都聚集在SCN上...
谢谢!
这是解释计划,是的,但是没有计划统计中的实际行。
一周热门 更多>