ORA-29378报错导致资源管理器消费组优先级混乱，远程协助修复方案分享

ORA-29378报错导致资源管理器消费组优先级混乱，远程协助修复方案分享

前段时间，我通过远程桌面协助了一位朋友处理他们数据库的一个棘手问题，他们的应用团队反映，一些关键的后台报表任务运行得异常缓慢，而一些非紧急的查询却似乎占用了大量资源，初步判断，这很可能是数据库资源管理器（Database Resource Manager）的配置出了问题，特别是消费组（Consumer Group）之间的优先级可能发生了混乱。

登录数据库后，我们首先检查了资源管理器的当前状态和配置，使用DBA_RSRC_PLANS视图查看了当前活跃的资源计划，确认了预期的计划确实已经生效，我们通过DBA_RSRC_CONSUMER_GROUPS视图查看了定义的消费组，包括为报表任务设置的REPORT_GROUP和为即席查询设置的ADHOC_GROUP等,看起来定义都是正确的。

问题的关键线索出现在尝试检查资源计划的详细指令时，当我们查询DBA_RSRC_PLAN_DIRECTIVES视图，想查看每个消费组具体的CPU分配比例、优先级等参数时，数据库抛出了一个明显的错误：ORA-29378: 资源计划指令无效,这个错误代码直接指向了资源计划指令配置存在矛盾或不合法的地方。

根据Oracle官方文档对ORA-29378的解释（来源：Oracle Database Database Administrator’s Guide, 章节：Managing Resources with Oracle Database Resource Manager, 章节：Troubleshooting the Database Resource Manager），这个错误通常意味着在同一个资源计划内，为不同消费组设置的指令发生了冲突，最常见的一种情况是，在使用了多级调度策略（比如CPU分配使用了LEVEL 1和 LEVEL 2）的计划中，指令的优先级（PRIORITY）设置与级别的划分原则相悖,或者百分比分配之和不合理。

为了定位具体的冲突点，我们采取了更细致的排查步骤，由于直接查询DBA_RSRC_PLAN_DIRECTIVES视图会报错，我们改为使用DBMS_RESOURCE_MANAGER包中的子程序来获取信息，我们创建了一个临时脚本来逐条验证指令，大致思路是尝试模拟资源计划的验证过程，通过这个过程，我们逐渐将问题范围缩小到两个消费组：REPORT_GROUP和ADHOC_GROUP。

我们发现，在当前的资源计划中，有人可能在进行在线修改时出现了误操作。REPORT_GROUP被同时分配了高优先级（PRIORITY）和特定的LEVEL 2 CPU百分比，而ADHOC_GROUP也被设置在了同一个LEVEL 2，但优先级较低，问题在于，资源管理器的规则是，在同一级别（LEVEL）内，优先级的设置会覆盖基于百分比的公平分配，高优先级的消费组会“饿死”同级别的低优先级组，配置中又为ADHOC_GROUP设定了一个看似保障性的最小CPU百分比，这个矛盾的需求导致了ORA-29378报错，更糟糕的是，由于指令本身无效，资源管理器可能并未按照任何一方的预期工作，而是进入了一种未定义的“混乱”状态,这解释了为什么报表任务和即席查询的性能表现都异常。

找到了根本原因，修复方案就清晰了，由于是生产环境，我们不能直接删除当前活跃的计划,我们的修复步骤如下：

1. 创建暂存区域：首先使用DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA过程创建一个待处理区域,所有对资源计划的修改都必须在这个区域内进行。
2. 清除冲突指令：我们使用DBMS_RESOURCE_MANAGER.DELETE_PLAN_DIRECTIVE过程，删除了导致冲突的、针对REPORT_GROUP和ADHOC_GROUP在LEVEL 2的指令。
3. 重新定义正确指令：使用DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE过程重新添加指令，我们重新设计了策略：将关键的REPORT_GROUP提升到LEVEL 1，并赋予其一个较高的固定百分比，确保其能获得稳定的资源，将ADHOC_GROUP保留在LEVEL 2，并与其他几个非关键组共享LEVEL 100%的CPU资源，依靠优先级（PRIORITY）设置在同级别内进行微调，但不再与LEVEL 1的指令产生规则冲突。
4. 验证计划：这是一个至关重要的步骤，我们使用DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA过程来验证待处理区域内的新计划配置是否合法，这次系统没有抛出ORA-29378错误，返回了成功的消息,说明我们的修改解决了冲突。
5. 提交更改：验证通过后，使用DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA提交待处理区域,将新的计划定义保存到数据字典中。
6. 切换计划（谨慎操作）：为了确保最小影响，我们选择在业务低峰期，使用ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '新计划名'命令来切换资源计划，因为计划名称没有变，只是更新了内容，我们也可以选择重启数据库实例使其在下一个启动周期生效，但为了快速验证修复效果，我们采用了在线切换，切换后,立即密切监控了数据库的性能指标和相应会话的资源使用情况。

经过一段时间的观察，报表任务的运行时间恢复了正常，ADHOC_GROUP中的查询也能获得合理的资源而不再完全停滞,确认问题得到解决。

这次远程协助的经历让我深刻体会到，ORA-29378虽然报错信息直接，但其背后往往是资源配置逻辑上的矛盾，在处理时，不能仅仅满足于让错误消失，必须深入理解资源管理器的调度原理（来源：Oracle官方文档中关于多级调度的说明），找到并修正那个不合理的配置点,才能从根本上恢复资源的有序分配。