好的，我可以预先告诉我，我不知道是什么原因造成的。

我所能提供的是一些指向要考虑和寻找答案的指针。

首先，我认为重要的是要弄清楚这种模式的原因既可能是SAP HANA的内部原因，也可能是SAP HANA的内部原因。

例如，可能存在定期的外部查询/job导致额外的内存分配。 想想，一致性检查，数据导出，长期运行的报告……之类的东西。

然后可能会有内部因素，例如计划的过程，数据流程图，数据量回收等。

由于内存分配/取消分配的数量似乎相对均匀，因此一个好的第一步就是更详细地描述其特征。 每次分配/释放多少内存？

并且由于相对容易发现系统当前处于哪种情况，我建议在两种情况下都对内存分配进行快照并进行比较

这应该提供相对直接的提示，以指示此处是否涉及（以及哪些）DB对象（实际上是列），或者内存是否属于瞬态过程（例如查询）。

如果我不得不猜测原因，那么我猜这是一些表/列集，它通过某种检查/监视过程加载到内存中，否则就不使用。 一段时间后，列将从内存中卸载，只是再次加载以进行下一轮检查/监视。

希望如此。

干杯

< p> Lars

嗨丽莎，

正如Lars已经提到的那样，没有更多细节可能有很多原因。 如我所见，您正在使用HANA座舱，只是通过使用受影响时间范围的工作负载分析（后台作业，顶级sql和线程）来深入了解更多细节。 我的猜测是备份工作或大型表的增量合并。

但是，如果可以分析运行时oom dump，也可以在trace文件夹中查看。

此致

Jens