商云方的技术博客 (沪ICP备14046774号-1)

客户：达芙妮

现象：1 并发节点文件系统满，导致并发管理器挂起

             2用户删除了部分日志和输出文件，并重新启动管理器，所有管理器都正常启动，只有库存管理器actual=0, target=10

分析&解决 

一、灏明（Oracle) 10日去现场看了下，发现后台库存管理器进程状态为defunct，mtl_tranasctions_interface中有大量待处理数据（从出故障到现在的所有库存事物处理），并采取了一次处理少量数据来解决问题，下面是他的脚本

——————————————–

1.运行完请求

UPDATE mtl_transactions_interface mti

   SET MTI.PROCESS_FLAG = ‘1’,

       mti.lock_flag    = ‘2’

 where rownum <= 10000

   and MTI.PROCESS_FLAG = ‘2’/*

   and mti.lock_flag != ‘2’*/;

 

2,运行中检查已处理行数

select count(mti.transaction_interface_id)

  from mtl_transactions_interface mti

 where MTI.PROCESS_FLAG = ‘1’

   and mti.lock_flag = ‘2’;

 

3.确认已更改的接口表数据

select count(mti.transaction_interface_id)

  from mtl_transactions_interface mti

 where MTI.PROCESS_FLAG = ‘1’

   and mti.lock_flag = ‘2’;

 

4.如果数据处理有误或需重新处理时，执行

update mtl_transactions_interface mti

   set mti.process_flag = ‘2’

 where MTI.PROCESS_FLAG = ‘1’

   and mti.lock_flag = ‘2’;

 

 

5.如果长时间没有运行，检查:process transaction interface，取消此请求

  然后，以库存管理员登录，打开接口管理器，重新提交此请求.

6.重复1-5步

——————————————————-

 

二、我今天拨VPN上去看了下，发现库存管理器actual=0的原因在于提交Process transaction interface后该请求正常完成，他会自动提交Inventory transaction worker，

由于Inventory transaction worker出错（每出一次错就搞死一个库存管理器），因此库存管理器的数目不断减少，减少到0后，无法处理Process transaction interface，我已经取消了Inventory transaction worker的出错自动重新提交的设置，现在Inventory transaction worker出错后直接退出，不会保持在运行状态，库存管理器也可以自动重启，数目即使减少到0也可以自动恢复回来

 

今天和明天是周末，没什么业务，我目前取消了Process transaction interface的定期运行，改为手动运行，每次更新mtl_transactions_interface中的记录process_flag=1，再手工提交Process transaction interface，这个脚本用户已经写了个存储过程，以保证可以按事物处理的顺序重新提交，今天晚上提交了20万条数据，希望明天能过去大部分，如果可以成功，就可以按同样方法处理下面的60万条数据。

 

三、我暂时无法确定ROOTCASE，目前这个问题LOG 了1级SR7745189.994，你可以看下，研发那边建议打补丁，我已经建议用户尽快使用最新的数据克隆测试环境，回头你再催促下吧。

其他：

库存管理器出问题，大多因为某种意外导致MTI中数据暴增，管理器针对大量数据的并发处理出现了问题，包括worker数的大量增加，MTI表访问资源的冲突，大量的僵死进程(defunc)的出现等，一般处理原则都是停掉自动提交的程序，减少Worker的并发数，尽量串行处理。等把意外处理掉了，MTI的数据量进入正常状态后，再把自动计划请求打开。

 

本文的提供者： Iflex (xiaoqiang)