点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
你好
我正在使用HANA上的ECC系统。 该系统中没有标准的ABAP CDS,但我为销售订单建立了自己的数据模型。
为简单起见,假设我有
-销售订单标题的ZI_SalesOrder视图
-销售订单项目的ZI_SalesOrderItem视图
-销售订单项目条件的ZI_SalesCondition视图(表KONV)
让我们专注于销售订单项目以及与条件的关联。 定义如下:
定义视图ZI_SalesOrderItem 从vbap中选择 vbak.vbeln上的内部连接vbak = vbap.vbeln vbap.vbeln上的内部连接vbup = vbup.vbeln 和vbap.posnr = vbup.posnr 在$ projection.SalesOrder = _SalesOrder.SalesOrder上,将[1..1]与ZI_SalesOrder关联为_SalesOrder 将[*]与ZI_SalesCondition关联为_Conditions 在$ projection.ConditionId = _Conditions.ConditionId上 和$ projection.SalesOrderItem = _Conditions.ConditionItem ...
条件视图如下所示:
定义视图ZI_SalesCondition 从konv中选择 { 将konv.knumv键作为ConditionId, konv.kposn键作为ConditionItem, 将konv.stunr键作为ConditionStep, konv.zaehk密钥为ConditionCounter, konv.kschl作为ConditionType, konv.kwert作为ConditionValue, konv.waers作为ConditionCurrency, 案件 当konv.krech ='A'时div(konv.kbetr,10) 否则konv.kbetr 以ConditionAmount结尾 案件 当konv.krech ='A'时强制转换('%'为abap.char(3)) 否则konv.waers 以ConditionAmountUnit结尾 } 其中konv.kappl ='V'和konv.kinak =''
现在,在此数据模型之上,我创建了一个在Fiori应用程序中使用的消耗视图。 在此视图中,我需要显示项目和一些条件值。 例如,我在一栏中需要MWST条件值。
这就是我使用关联的方式:
//税 Item._Conditions [1:ConditionType ='MWST']。ConditionAmount作为TaxRate, Item._Conditions [1:ConditionType ='MWST']。ConditionAmountUnit作为TaxRateUnit, Item._Conditions [1:ConditionType ='MWST']。ConditionValue作为TaxValue,
一切正常...但是速度很慢。 非常慢。 在生产环境中,仅显示一个包含4个项目的销售订单可能需要8到9秒钟。
我使用ST05 tcode获取跟踪计划,并在Eclipse中将其打开。 我没有使用此工具,但我了解数据库会读取所有条件类型为MWST的记录,然后将其与所选销售订单的条件ID进行比较,而不是通过逻辑方式搜索,而是从 销售订单,然后在KONV中获取相应的记录。
是什么让我这样想:
如您所见,条件表中选择了15905812条记录! 如果我看一下细节:
我可以看到所有这些都是针对KONV条件的,如果它来自条件ID(KNUMV),我将获得超快的速度。
我的问题是:对此我该怎么办? 在CDS视图或数据库中我可以做些什么吗?
我在CDS中尝试过,但是没有改变:
Item._Conditions [1:ConditionId = ConditionId和ConditionItem = ConditionItem and ConditionType ='MWST']。ConditionAmount作为TaxRate,
真的需要您的帮助...谢谢。
(14.1 kB)
根据提供的信息,不可能正确理解是什么原因导致性能下降。
我看到的是这样的结果:
对于实际手段,这些谓词不会过滤KONV表
这导致大量数据的实现(请参见创建临时表计划运算符)
基于此,最可能出现的顶级查询 不能提供有效的筛选条件,该条件可能会减少数据量(对于客户端查询结果集而言,近16 Mio行通常太多)。
此外,应该检查是否最需要查询的列实际上是计算得出的列(例如,如果查询是简单的SELECT * FROM ...,那么仅指定相关列会很有帮助)。
如第一句话所述,这是一项不完整的评估,因为缺少许多信息(顶部查询,解释计划,完整计划即跟踪,完整CDS源,表统计信息...) 但是,从列出的观察结果中应该清楚的是,数据模型的"性能"不仅取决于该模型的设计方式。
相反,它是基于
顶部查询+数据建模+表中的数据
希望仍然有帮助。
在这种设计中,我总是使用从VBAK-KNUMV到KONV-KNUMV的链接。
问题的答案可以这么简单吗?
好吧,SQL语句不是很有趣,因为它只是CDS视图上的Select。 是的,系统的反应方式相同。
我所做的是使用ST05创建跟踪,下载请求SQL解释并在Eclipse中打开它。
我们的CD中字段Mandt存在一些问题,我不知道表 您使用了它,但是尝试添加它(如果它存在于您的表中)
为了明确起见,在top-query中,我指的是应用程序中使用的实际查询,而不是CDS视图。
关于分解方法:这些表之间的联接条件中缺少MANDT字段,这可能导致执行计划不使用现有索引。
当然,如果没有此联接的解释计划/计划的解释,我们所能做的就是猜测为什么它很慢。
一周热门 更多>