全部
我的团队正在努力解决我们偶尔看到的一个真正给我们带来麻烦的 oracle 问题。
我们有一个更新过程，它通过一个使用 Apply 作业的包导入 .dmp 文件。（不是我们选择以这种方式实施它......）
问题是，我们正在让这个应用作业中止，错误为 4031 无法从内存中分配 <100 字节（各种值，通常从 60 到 90），共享池被标记为罪魁祸首。ASMM 开启。服务器预配了大约 500 MB 的运行内存（这些是旧的 Server 2003 环境，因此内存需求量很大）。我很担心这个错误——在我看来，错误应该总是报告 4k 的倍数，因为这是我们的粒度，但也许我误解了释放内存的过程。我还担心服务器没有根据需要释放包。
我相信解决方法是使用 dbms_shared_pool.keep("PACKAGE NAME") 来固定用于运行应用作业的包，这样它就不必再次分配内存，但是我们需要在部署之前测试这个修复，出于各种组织原因。我们还计划为 oracle 数据库分配更多内存。设置最小大小不是解决方案，因为我们已经在池的大小超过最小值且启用 ASMM 时看到了这个问题。我们还尝试将 sga 最大大小设置为更高的值，并固定有问题的包，但同样，无法重现该问题，这是一个等待游戏，看看它是否会再次发生。
我们的主要问题是可靠地重现问题——即使禁用 ASMM 并将共享池设置得尽可能小，我们也无法可靠地重现问题。我们已经得到足够小的共享池，以至于 Web 界面甚至无法从数据库中提取图像标签，或从适当的表中查询登录信息，但应用作业仍然可靠地运行。
我们没有内部 DBA，因此很自然地我们可能会遗漏一些明显的步骤。
在 8 台服务器的环境中，此问题偶尔会出现在 2-3 台服务器上。这些单独的服务器都看到了不同组的类似使用。我不清楚为什么只有部分服务器会遇到此问题，但无法确定任何确凿的原因。
我希望输入可靠地完全避免此问题，或者可靠地强制共享池无法为该作业分配字节，以便我们可以确认这些修复确实有效。
请记住，此时我已经阅读了关于 SO 的大部分 4031 帖子——这个问题已经调查了数周。将此问题标记为重复问题并将我引导至另一个问题可能不合适 - 我已经阅读过它。它没有回答我的问题。这是来自普通旧Stackoverflow的交叉帖子
我检查了其中一台服务器的跟踪文件，但没有启发性——我不确定要查找什么。
我们已经尝试刷新共享池，但同样，由于无法重现该问题，它变成了“观望”修复，这并不是我们的资助者真正感兴趣的答案。