您所描述的听起来真的像是不同的数据集是问题的根源。

Visualize View功能在分析时没有太大用处，因为它显示了视图数据流结构的静态表示形式，而不是执行计划。

我的直觉是要检查两个系统中的基表是否显示相同类型的存储（行或列），以及数据是否经过类似的压缩。 通过简单地确保表是具有活动增量合并的列存储表，我已经看到很多性能问题消失了。

除了这些一般性提示外，如果不实际查看说明计划，PlanViz等，就不可能对这个问题说太多。

"迁移"是什么意思？ 根据您的描述，听起来您的意思是"已运输"。

如果您的意思是将计算视图从DEV传输到PRD，现在执行计划看起来有所不同，那可能就不成问题了。 通常，DEV系统中的数据与PRD不同（较旧，数据较少，...）。 由于优化程序会在查询执行时（而不是在编写时）对查询进行优化，因此会考虑数据差异。

请注意，我所说的是表中的实际记录，而不仅仅是这里的表结构。

嗨，大卫，

如果您尝试导出（SAP支持模式）带有数据的calc视图，然后将其导入测试系统。

会发生什么？ 如果执行计划相同，则可能是传输DU问题。

否则，这可能是HANA DB的问题，建议您向SAP的HAN-DB团队报告事件。

需要使用PlanViz文件来详细研究此问题。

最诚挚的问候，
糖果

对不起-运输正确。 计算视图已导出，然后作为交付单位导入。

我遇到的问题是目标系统中的查询用尽了内存并且无法完成，在DEV中的工作正常。 体积非常相似，不完全相同，但是数量级相同。 例如DEV中的5.63m（测试中为5.64m）。

据我所了解的执行计划，它所引用的主事务表超出了我的预期，或者它确实在DEV中完成了：(还可以在TST上通过DEV查看更多的ROW搜索操作

有什么想法吗？

Dave

快速更新-今天有一点时间可以看得更远，而不是我想要的。

不确定这是否有任何影响，但可能是有用的信息...

在_SYS_BIC中查看计算视图，然后从上下文菜单中选择"可视化视图"，将在DEV和TEST中产生完全相同的表示，并显示事实表被拉入，然后依次连接维度。

已经比较了基表中的数据，尽管在数量上有细微的差异，但是在两种环境之间所有数据都是一致的-结构相同，键列没有差异。 我还比较了所传输的内容，发现两者之间没有区别。

在TEST中，查询将不会执行，导致HANA挂起，并在几分钟后返回内存不足错误。 在DEV中，查询会在大约20-30秒内返回数据-这是通过执行的数据预览或上下文菜单中GENERATE SELECT进行的查询。

再次-关于此内容的下一个建议或尝试尝试的任何想法/建议，将不胜感激。 如果有其他信息可以帮助您在：）