Oracle优化选择错误的索引而不是表全扫描

2020-09-21 23:23发布

         点击此处--->   EasySAP.com群内免费提供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

         点击此处--->   EasySAP.com群内免费提供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

付费偷看设置
发送
11条回答
哎,真难
1楼 · 2020-09-21 23:51.采纳回答

已经有一些出色的输入,我也同意您的数据和统计数据存在某些特殊性,这导致Oracle选择索引。

我看到您的统计数据是最近的,因此它们可能没有错。 但是我有另一种理论可以提供:ARBID字段通常是填充的还是很多为空? 归结为数据分发,有时统计可能会误解数据分发。 如果唯一性是100%,则应选择全表扫描。 但是,如果90%的行为空,或者您有多次重复出现的值(通常是状态字段),那么唯一性就很低,从统计学上讲,优化程序可能会决定我们很可能在非 索引字段很容易,因为大多数值都相似。 在几乎为空的列中搜索值时,这尤其是个问题。

此外,仅出于兴趣考虑,请查看"最多1行"的行为是否与"选择单个"不同。 在进行此操作的同时,还请尝试选择SELECT而不加任何限制和变化...高达10/100/1000 ROWS。

Alawn_Xu
2楼-- · 2020-09-22 00:12

我们无法告诉您,因为Oracle会基于决策 根据您的数据。 请发布EXPLAIN(通过ST05进行跟踪,显示它,然后单击Explain),表和索引的统计信息(在EXPLAIN中单击表名)。

您可能会在Oracle论坛上获得更多信息。

哎,真难
3楼-- · 2020-09-21 23:51

创建新索引有什么问题? 特别是如果在注释中建议使用它?

在我看来,问题在于您的自定义索引。 如果创建自己的索引,如果选择不正确,可能会严重破坏索引。 了解何时添加了自定义索引以及出于什么目的-也许只有一个自定义程序,开发人员认为这是个好主意。 也许该程序只需要重写,就可以删除自定义索引。

您应联系Basis并确保数据库统计信息是最新的。 如果不是,那也会使事情变慢。

风早神人
4楼-- · 2020-09-22 00:03

好吧,我认为这是一个很好的结果。 因为这意味着不是因为您的索引。

我会尝试删除您的Z-index。 如果它随后表现不佳,请在您的OSS上记下它,因为那样我会把它归类为SAP应该修复的错误。

黑丝骑士
5楼-- · 2020-09-21 23:48

嗨,

如果要专门为此查询创建自定义索引,请使用给定顺序的列:MANDT,ARBID。

Oracle很少选择FULL TABLE SCAN,特别是在这样的大表情况下。 有一个参数会影响索引访问和表访问之间的选择,即optimizer_index_cost_adj。 在SAP世界中,我们并没有真正进行调整或尝试。 根据使用OLTP或OLAP系统类型的情况,我们有自己的建议。
在我看来,似乎还不存在相应的索引(如果仅存在AFRU〜Z01和AFRU〜0) ,因此优化器选择了BAD索引访问,因为它"认为"最好使用错误的索引而不是扫描所有表块。<​​/p>

因此,使用给定的列创建新索引将对您有所帮助,特别是因为覆盖了where条件中的所有列,因此可以通过扫描更少的块并使用所有其他索引来完成数据的第一次过滤 值可以从表中读取。


SC_Yao
6楼-- · 2020-09-21 23:58

我的系统是BW并与HANA一起运行。

SC_Yao
7楼-- · 2020-09-21 23:59

请与您的基础管理员/DBA讨论此问题,如果他们没有其他输入,请与SAP支持联系。

有500万条记录,我也强烈建议尽快考虑进行数据归档。

一周热门 更多>