计划管理器简介 计划管理器属于Immediate类型的可执行并发程序，作为MRP 管理器的子例程运行。MRP 管理器是一种特殊的并发管理器，和计划管理器是完全不同的存在。它主要作用在以下几个方面： 针对发运冲减MDS 针对完工产品冲减MPS 预测冲减 MRP接口数据的处理 相关数据清理 实际上，计划管理器和相关的MPS/MRP冲减工作流程是通过下列存储过程完成的： MRP_MANAGER_PK 这个包里面的各个过程执行不同的任务。 MRP_UPDATE_MRP_INFO_PK.mrp_update_mrp_cols 该过程用于MPS Relief Worker MRP_AUTO_REDUCE_PK.mrp_auto_reduce_mps 该过程用于每日清理 计划管理器的启动 进入供应链管理员(Supply Chain Planner)职责，在设置菜单里有计划管理器的设置。 间隔时间是指计划管理器每次隔多久处理一次数据，它是指每次的开始时间的间隔长度，如果执行时间超过间隔时间，则执行结束后等待该时间后再次执行。若间隔时间太短，则可以近乎当作不间断执行，这时的冲减也是最及时的，但是系统资源消耗较大。同时，间隔时间过短，日志会更加大，如果启用了DEBUG模式，则每日的日志将可能多出数百兆(视业务数据多少有所不同)。 如果计划管理器处于Active状态，则设置窗口中的Messages界面会显示每次执行的时间。该界面仅仅告知每次的执行时间，并没有多大保留意义，可以安全删除。如果想停止计划管理器，则直接根据请求号取消相应的并发请求即可。需要留意的是，由于计划管理器是依附于MRP管理器执行的，因此在异常诊断时，应当先确认MRP管理器是正常运行的。 每次重新启动计划管理器时，都会自动提交“Planning Manager Worker (once-a-day tasks)”。每天，计划管理器都会分配一个新的请求号，开始新的请求号时，“Planning Manager Worker (once-a-day tasks)”工作流程也会被自动提交。这也是个并发程序（派生类型）， 该程序主要执行各类清理工作。其中，对于MRP相关接口表的清理，主要取决于配置文件 MRP:Interface Table History Days 设置的保留天数。涉及的MRP接口表包括： MRP_FORECAST_INTERFACE MRP_SCHEDULE_INTERFACE MRP_RELIEF_INTERFACE MRP_FORM_QUERY MRP_WORKBENCH_CRITERIA MRP_WORKBENCH_QUERY MRP_LOAD_PARAMETERS MDS Relief 创建新的订单时，会有记录插入到MTL_DEMAND，当发运确认后，相关记录会插入MTL_TRANSACTIONS_INTERFACE，接口数据被验证通过才会在MTL_MATERIAL_TRANSACTIONS产生新的纪录，在此同时，如果库存事务管理器判断出所处理的记录是销售订单，就会插入记录到MRP_RELIEF_INTERFACE以供冲减MDS。 在MRP_RELIEF_INTERFACE中的MDS待冲减条目的各字段含义如下： RELIEF_TYPE 为1 PROCESS_STATUS 为2，表示等待处理 DISPOSITION_ID [...]
Archives for 2010
Planning Manager诊断过程和10046事件
在一次Planning Manager性能问题的诊断中，用到了Oracle ERP环境中非常典型的诊断操作和过程，特全程记录于此。 当发现某个程序存在性能问题时，首先当然是快速检查一下SESSION的相关信息，看看主要在执行或等待些什么： SELECT stat.sid, n.name, n.class, stat.value FROM v$sesstat stat, v$statname n WHERE stat.statistic# = n.statistic# AND stat.sid = 121 ORDER BY upper(n.name); 这里观察到bytes received via SQL*Net from client, bytes sent via SQL*Net to client 和 SQL*Net roundtrips to/from client 都在飙升。这对应了两个events：SQL*Net message to client和SQL*Net message from client，这两个事件数值大并不意味着网络状况不好，前者仅仅表示Oracle数据库将数据放入TCP send buffer的时间，而后者表示从客户端接收到反馈指令的时间，两者反映了SQL*Net和数据库之间的时间消耗，而不是网络传输的时间消耗。基于对系统架构的了解，排除SQL*Net的性能问题，那么两个事件预示了什么呢？ SELECT * FROM v$sess_io [...]
我们需要监控什么？
今天一个很偶然的时间里，我想看看我们的系统有没有异常，其中某个检查点是通过下面这个SQL进行的： SQL> SELECT local_tran_id, 2 state, 3 fail_time 4 FROM dba_2pc_pending 5 / LOCAL_TRAN_ID STATE FAIL_TIME ———————- —————- ——— 31.16.528671 collecting 25-FEB-10 通常情况下，我关注更多地是业务数据异常，很少动手检查此类底层的问题，也不会发现任何异常，但是这次，它来了。当然，在我发现下面这个错误之前，它丝毫不是个问题： SQL> commit force ’31.16.528671′; commit force ’31.16.528671′ * ERROR at line 1: ORA-02058: no prepared transaction found with ID 31.16.528671 SQL> exec dbms_transaction.purge_lost_db_entry(”); BEGIN dbms_transaction.purge_lost_db_entry(”); END; * ERROR at line 1: ORA-30019: [...]
关于10.2.0.5 agent无法连接9i (9.2.0.6)的问题
升级GC到10.2.0.5后，在给9i(9.2.0.6)数据库配置Agent时，主机监控可以顺利配置，但数据库连接总是无法配置成功。查看agent日志显示： ERROR vpxoci: ORA-03113: end-of-file on communication channel WARN vpxoci: Login 0x27fa600 failed, error=ORA-03113: end-of-file on communication channel 事实上，不论是test connection，还是在服务器上用sqlplus做测试，都是没有问题的。那么，估计会是个agent的程序bug。翻遍Metalink[ID 828464.1]才最终发现这样一个补丁信息：升级RDBMS到9.2.0.8，或者应用agent补丁到10.2.0.5.2。 就像选数据库，总是倾向于最新主版本号的上一个版本，因为相对稳定，GC也是如此。Bug不可免，立此存照，以备后用。
关于RepositoryPatchUpgrade失败
在打Patch的过程中，最不痛快的就是在过程中出现一些莫名其妙的错误了。今天将OMS版本从10.2.0.2.1升级到10.2.0.5，在进行到Repository Upgrade一步时报错了。 按提示检查cfgtoollogs/configToolFailedCommands文件，有以下内容： rem 版权所有 (c) 1999, 2009, Oracle。保留所有权利。 oracle.sysman.emcp.oms.RepositoryPatchUpgrade -verbose oracle.sysman.emcp.oms.OmsPatchUpgrade -configureOms oracle.sysman.emcp.aggregates.ConfigPlugIn oracle.sysman.emcp.oms.StartOMS -configureOms oracle.sysman.emcp.oms.EMCLISetup oracle.sysman.ccr.configCCR.ConfigCCRPlugIn oracle.sysman.ccr.configCCR.ConfigRepeaterPlugIn 这部分更新应当是执行一系列SQL出现异常。检查sysman/log目录下的emrepmgr.log.10.2.0.5.0日志，里面最后部分内容是： SQL> 从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开 [13-05-2010 08:50:23] Checking repository version.. [13-05-2010 08:50:23] Running setSchemaStatus: BEGIN EMD_MAINTENANCE.SET_VERSION(‘_UPGRADE_’,’0′,’0′,’SYSTEM’,EMD_MAINTENANCE.G_STATUS_UPGRADING);END; [13-05-2010 [...]
