相对于SAP而言，Oracle ERP的另一个显著特征或许就是大量的BUG和补丁吧，也或许正因为如此，Oracle ERP中的故障诊断越来越便捷，方式也越来越，有Server级的诊断（如Form Server），有DB级的诊断，也有功能级的诊断（输出程序步骤和关键业务数据）。对于Form/Report Server之类的故障诊断，通常有专门的技术顾问负责，多数情况下，功能顾问在Oracle Support的建议下也会进行各种形式的、针对各个模块和功能的诊断，有的记录在表里，有的形成日志文件，也有的直接显示在页面上。对于不影响用户操作的诊断，事后很容易就忘记了关闭，于是大量的五花八门的被遗弃的debug和trace偷偷占用着宝贵的系统资源。 通常，功能顾问们涉及的诊断功能可直接通过配置文件启用，主要有下面这些： FND：启用调试日志 启用日志。如果为否 (‘N’)，则运行时不会进行记录和发出预警。 OE：调试 选择“是”以激活 Oracle 订单分录管理系统表单用户退出和并发程序中的调试信息 OE：调试跟踪 选择“是”以激活 oracle 订单分录管理系统并发程序的跟踪输出 OSO：启用调试消息 用于显示/隐藏调试消息的 Sales Online 配置文件 PA：调试模式 指明是否按调试模式运行项目会计管理系统报表和流程；在调试模式下运行时，线索会被打开，附加信息会打印至日志文件 PO：将调试工作流设置为“打开” 启用/禁用 PO 工作流调试模式 PO：启用对接收处理程序的 SQL 跟踪 启用数据库 SQL 跟踪，以便调试接收事务处理程序。 RCV：调试模式 如果将此模式设置为“是”，则将在日志文件中打印消息。 初始化 SQL 语句 – 自定义 初始化会话的自定义 SQL 语句 其中“初始化 SQL 语句 – 自定义”比较特殊，可以自行设置event。它的格式如： BEGIN fnd_ctl.fnd_sess_ctl(”,”,”,’TRUE’,”,’ALTER SESSION SET TRACEFILE_IDENTIFIER=’ [...]
Archives for May 2010
计划管理器(Planning Manager)技术概要
计划管理器简介 计划管理器属于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 [...]
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不可免，立此存照，以备后用。
