您好，Karthik

我的观点基于经验，而不是SAP的观点或建议（尽管可能不是，Dunno）：

我不会选择那些表现出色的SAP 注释并定期将它们作为默认设置实施。

您可能需要仔细阅读它们并检查有意义的内容，但是出于谨慎的考虑，也许没有实施那些SAP注释，而是等待下一个SP 堆栈更新：

这可能会产生功能上的影响，这取决于编码中的哪些更改以及是否在某处引用了编码-考虑客户使用自定义代码，然后再引用并使用SAP标准编码。 因此，您将不得不努力确定是否可能出现这种情况，然后甚至花时间对它进行适当的测试（如果可能的话）。 某些非生产性客户环境根本不能代表实际生产环境，因此很难模拟效果。

它可能会对性能产生负面影响，同样，这种情况可能发生，因为 例如，创建额外的索引以加快进程X的速度，这实际上可以加快op进程X的速度，但也可能以负面方式影响进程Y和Z。 同样，可能涉及自定义代码，但不一定非要那样。 由于客户X遇到特定问题，因此可以创建SAP注释。 另一个客户Y可能以不同的方式使用该系统，例如，我在扩展仓库管理中已经看到了这一点，SAP建议的实施对第二个客户Y在仓库中的性能产生了负面影响，同时解决了客户X的性能问题。 性能一点也不在乎，收益将是微不足道的，我也不会实施SAP注释以保持我的环境更加稳定。

就热点新闻而言，这还取决于它是什么，以及 为什么等。如果最新消息指出SAP HANA数据库内容可能损坏，而您正在为客户运行该版本，则不必等待太长时间来安排该SAP注释/更正的实施，以免发生这种情况

安全性SAP注释是在补丁程序日发布的，补丁程序日的预定时间更长，因此您可以利用这些日程安排来分析和计划这些SAP注释的实施。

通常，我会通读并分析/检查这些类别中的每个SAP注释，以及安全性SAP注释，因为这些注释也肯定会以各种方式影响系统并决定应实施的内容（基于 在紧急程度，可行性上-有些人可能会说对SPx进行了补丁）以及需要进行多少测试才能避免任何形式的中断。

最诚挚的问候

汤姆