Fans Or Not

MPS计划的冲减主要通过MPS Relief Worker (MPS 冲减工作流程)进行，如有异常，则将导致MPS数量无法冲减，计划不准。作为Oracle ERP的核心功能之一，程序方面自然经过了诸多考验，然而在实际工作环境中，却依然会出现问题。这种问题，或许来自异常的数据量，也可能出在服务器性能上。MPS计划冲减说白了是一件很简单的事情，就是在需要冲减的环节，比如在下达离散任务或创建采购订单等特定事件发生时，系统会自动对比需求数量，并作相应冲减。在技术实现上是如下进行的：

1. 指定事件（如创建采购订单）发生
2. 触发器将数据插入接口 MRP_RELIEF_INTERFACE
3. MPS 冲减工作流程处理接口数据

由于计划管理器的存在，可以保证数据被及时处理。计划管理器其中一个重要的步骤就是由MPS 冲减工作流程处理接口数据，实现冲减逻辑。但是有些时候，却发现系统总是出现很多的意外，比如可能找到这些错误：

mrupwj_update_wip_jobs 中出现 ORACLE 错误 1555

原因：由于 ORA-01555: snapshot too old: rollback segment number 2 with name "_SYSSMU2$" too small
ORA-06512: at "APPS.MRP_UPDATE_MRP_INFO_PK", line 284
ORA-06512: at line 1
, mrupwj_update_wip

或

mrupwj_update_wip_jobs 中出现 ORACLE 错误 1652

原因：由于 ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
ORA-06512: at "APPS.MRP_UPDATE_MRP_INFO_PK", line 284
ORA-06512: at line 1
, mrupwj_update_wip_jobs 失败。

一方面，是因为DB配置的原因，另一方面，也是程序本身的问题。但是作为实施人员，这两块都无法改动，则只好对症下药，以其他方式来避免此类不是问题的问题了。

对于计划管理在冲减方面的逻辑，处理步骤上大致可以分为以下三步：

Step 1
取所有PROCESS_STATUS=2，并且REQUEST_ID为空的记录，将PROCESS_STATUS标记为3，同时将REQUEST_ID标记为处理的冲减流程请求ID。可以通过以下SQL观察哪些待处理数据：

SELECT *
  FROM mrp_relief_interface rel1
 WHERE inventory_item_id IN
       (SELECT inventory_item_id
          FROM mrp_relief_interface rel2
         WHERE rel2.request_id IS NULL
           AND rel2.error_message IS NULL
           AND rel2.relief_type = 2
           AND rel2.process_status = 2
           AND rownum <= 500
           AND inventory_item_id NOT IN
               (SELECT DISTINCT inventory_item_id
                  FROM mrp_relief_interface rel2
                 WHERE rel2.request_id IS NOT NULL
                   AND rel2.error_message IS NULL
                   AND rel2.relief_type = 2
                   AND rel2.process_status = 3))
   AND rel1.request_id IS NULL
   AND rel1.error_message IS NULL
   AND rel1.relief_type = 2
   AND rel1.process_status = 2;

REQUEST_ID先为计划管理器的并发请求ID，如果需要由MPS冲减工作流程来处理，则更新为新请求的ID。

Step 2
MPS 冲减工作流程在处理时，会根据配置文件预设值确定数量和方式。相关配置文件如下：

1. MRP:Consume MPS (MRP：冲减 MPS)
   是否冲减MPS，设置为是
2. MRP:Planning Manager Batch Size MRP：计划管理器批量
   每次处理接口数据的数量，建议值为500。最好不要超过1000
3. MRP:Planning Manager Max Workers MRP：计划管理器最大工作进程数
   在设置批量大小时，每个MPS冲减流程只处理对应数量的记录，因而如果接口数据量较大，会同时出现多个并发。该配置文件就是用于限制最大并发数量的。

计划管理器也会处理PROCESS_STATUS=3的数据，但是这里的批数量只约束MPS冲减工作流程。

Step 3
如果第二步正常处理，则接口数据会被标志为PROCESS_STATUS=5。Planning Manager启动时，会检查接口数据，并启动Planning Manager Worker (once-a-day tasks)，该请求会定期清理接口表中PROCESS_STATUS=5的数据。保留的时间范围由配置文件 MRP:Interface Table History Days 决定，默认是5天。

如果出现异常，则异常消息会记录在ERROR_MESSAGE，同时将PROCESS_STATUS标记为4。具体处理措施因事而异，如果需要重新处理，则必须先重置状态：

UPDATE mrp_relief_interface m
   SET process_status = 2,
       request_id     = NULL,
       error_message  = NULL
 WHERE m.relief_type = 2
   AND m.process_status = 4;

不要一次性更新太多数据，最好在配置文件 MRP:Planning Manager Batch Size 的数量范围内，分批次进行。在处理时，需要先停止计划管理器，修改完毕后再重新启动计划管理器。

下面的SQL可以检查接口表中各类数据的数量：

SELECT organization_id,
       SUM(decode(process_status, 1, 1, 0)) status1, --Do not process
       SUM(decode(process_status, 2, 1, 0)) status2, --Waiting to be Processed
       SUM(decode(process_status, 3, 1, 0)) status3, --In Process
       SUM(decode(process_status, 4, 1, 0)) status4, --Error
       SUM(decode(process_status, 5, 1, 0)) status5 --Successful completion
  FROM mrp_relief_interface
 GROUP BY organization_id;

需要留意的时，如果在功能逻辑范围内的错误，并不影响整个MPS冲减流程继续下去，但是如果是其他错误，如回滚段不足、快照陈旧等，会令MPS冲减工作流程挂起。在整个流程中，是根据并发请求状态来判断步骤是否完成的，因而可采取的措施是可以尝试手工修改并发请求状态，然后下一步继续执行。这种操作的后果就是冲减数量不正确。也可以先停止整个流程，待问题修正后重新启动MPS。

每次手工启动MPS计划流程时，都必须先执行MPS Relief Worker，就是为了保证计划数量的正确。而该程序正常执行的前提，就是接口中不应存在太多的数据。整个主计划的性能，由此可见一斑。