我们有个问题。"恭喜你。"但这是个棘手的问题。"那就加倍祝贺。"—克莱门特·斯通

这篇博客描述了我遇到的SAP IDM最具挑战性的故障排除问题。基于这一点和我们的一些相关发现，我认为有必要与你们分享这个问题和我们的解决方案。但我想先警告一下：虽然SAP支持部门参与了此问题的部分工作，但最终解决方案及其实施并未得到SAP的正式批准，尽管部分解决方案确实来自SAP文档。而且，如果没有数据库管理员、系统管理员，当然还有BASIS的帮助，这个问题是无法解决的。这类问题很少单独解决。

都是从周一早上开始的（这些事情不总是从周一早上开始吗？）我们首先得到一些关于发生了什么的信息。在大约15分钟的时间内，SAP IDM的主要用户无法再更新用户条目，大数据的解决方案，随后很快就无法创建新条目。通过web UI访问任务时，抛出了一条非常通用的NetWeaver应用程序服务器消息：

如果您想知道，此特定组织正在使用SAP IDM 7.2 SP7，NetWeaver 7和Oracle 11。我们很快就找到了一个Java扩展，关闭它虽然有点烦人，但并不是什么大问题，我们认为我们正在摆脱这种状况。然而，当我们再次尝试该任务时，我们得到了一个全新的错误。

在系统中，我们很快看到，任何来自UI的用于更新条目的任务都会出现此问题。进一步的测试还表明，所有条目类型都会发生这种情况。我们认为这将使事情变得更容易，因为有一个共同的因素，返利啦，即所有的错误都来自同一类型的任务，但有几个项目让我们挠头：

我们在IDM日志、NetWeaver跟踪或Oracle日志中看不到任何与此消息匹配的错误。在google和搜索SAP/SCN时，唯一已知的原因是数据库/designtime/runtime修补程序级别不匹配。由于我们中的一些人参与了上一次升级和测试（那是很久以前的事了），我们可以放心地忽略这种可能性，因为我们知道在相当长的一段时间内没有任何变化。而且，由于所有的更新任务都会发生这种情况，因此它可能是IDM模式中的某个内容。这也使得它不太可能与任务本身有关，并且很可能是浪费时间重新创建作业，以防它被损坏。（很有意思的是，修复的频率有多高）

在这个时候，我们也开始关注IDM之外的问题，查看上周末的服务器更新名册，我们能够划掉IDM之外导致错误的东西。所以，这意味着我们需要回到IDM及其基础设施。我们尝试的一件事就是通过MMC控制台尝试一个测试配置任务。我们收到了另一个错误。

虽然信息丰富，而且有点有趣，但在Oracle日志和跟踪中，我们仍然看不到与我们的测试相匹配的任何内容，这很麻烦。当DBA继续致力于获得更好的跟踪信息时，我们确实看到了一些潜在的有趣的项目，但我们没有看到足够一致的趋势，从而导致解决方案。

我的一位同事提出了一个有趣的问题，我们使用UI和MMC进行了测试，但实际上我们还无法进行测试任何实际的资源调配，那么当资源调配发生在UI或MMC之外时会发生什么呢，免费云服务器永久使用，所以我们看了两件事：

这在日志中给了我们一些非常有用的信息，以至于我们可以实际看到发生了什么。

有了这些信息，我们可以检查存储过程，并注意到是指试镜专栏。虽然Oracle将列设计为数字（10），但实际值相当高，约为2^31，这是各种编程语言中某些数字类型的限制。我们似乎很清楚，这就是我们的问题所在。

我知道在SAP的文档中，特别是在解决方案操作指南中，有一个关于维护审计表的参考。

这就是我们需要"调整"SAP建议的地方。通常，这里的目标只是减少数据库中的行数。然而，这个系统已经建立并运行了大约10年**，我们真正需要做的是清除审计并重置起始值。我们的dba熟悉这种类型的操作，就像他们在其他应用程序中看到的那样，能够截断表并重置auditd。（博客更新：我忘了提到，怎么查看大数据，当然，在修改表之前，已经备份了现有的审计数据，以便回滚和参考，因为这些表在公司的某些报告和KPI相关功能中非常重要。谢谢K.B.）在这之后，我们的系统运行得很好，我们又开始工作了。当然，有一些小的清理工作要做，赶上每天的文件删除和什么不，但我们在我们的道路上很好。

另一件事，我认为需要提到的是，我认为这整个问题基本上是一个应用程序中的错误。audit的值应该在应用程序编码和数据库中以相同的方式设置。此外，SAP应该有一个已发布的解决此问题的方法。大多数运行最老的IDM系统都将开始看到这种情况，如果有一个存储过程使这一切变得更容易，那就更好了。我们还注意到changenumber值也开始出现在那里，应该考虑对其进行修复。我还想指出，计算机大数据，如果UI抛出这样的错误，它应该与一些诊断信息一起转储到某个地方，比如UI中警告后面的错误。在某些情况下，Java跟踪和NetWeaver跟踪似乎并没有切断它。