惯例闲话：这次不说闲话了，刚刚解决一个系统事故级别的问题，没被领导问责已经很幸运了。
分享下处理问题的过程
事件经过
和往常一样，早上闲人打开电脑第一件事情是打开SAP，查看系统日志，结果跳出来一大堆锁定日志，锁定日志在闲人以往的经验判断，这是很正常的事情。但是这次很不同，因为马上微信群就开始炸锅
——计划部、采购部、生产部、仓库管理部、财务部…所以所有使用SAP的部门的问题反馈洪水一样袭来。
几轮下来被用户的消息轰炸了，原本淡定的闲人，也不由地产生慌乱。这种系统级别的错误，闲人以前经历过，业务部门直接停摆做不了业务。出现这种情况，通常是事故级别的。
所以闲人立马放下手头的工作，赶紧亲自处理。
闲人的做事思路，通常是让业务部门提供第一手单据信息
但是这一次，这个办法不好使了，因为是全局性的红灯错误，光看单据已经无法找到规律。但是SAP这一点还是做得很有帮助，这些报错信息中都含有锁定的关键字。
所以闲人直觉，SM12看锁定记录，光看锁表记录，好像也觉得很正常，做单锁定很正常的操作。
这里有个数字引起了闲人的注意，250000！！！好家伙，250000条当前锁定。而且都是指向同一个表ZTMM0024。
闲人的直觉告诉自己——系统这么多锁定记录，肯定不正常。ZTMM024这个表是用于存放PLM传输给SAP的采购申请单数据，业务部门录入组，会每天执行一个特定的事务码，读取表里数据，然后执行转物料主数据、采购申请等操作，是交互量最大的一个表。
闲人先尝试着让当前的操作人退出事务，果然效果立竿见影——业务操作都正常了。
至此，基本可以锁定，问题出在这个ZMM015查询功能上。
原因分析
这个功能设计是查询和处理混合模式
为了防止多人查询同一单重复生成采购申请，系统做了锁表处理，按行锁定。
当时正好有人全量查询了数据，这就解释了为何锁定记录中出现这么多记录。
解决方案
root cause找到了，下面就对症下药了。办法也简单，处理和查询分开即可解决：
1、处理时候锁表，且对数据的读取范围做强制限定。
2、查询时则不锁表
小结
虽然最后只是对程序做了小改动解决了问题，但是这给闲人又一次启发，为何SAP在标准事务设计时创建、修改、查询分开事务，从这次事故中，可以看出SAP的ERP傲视群雄的设计思路。SAP设计思想非常值得国产软件学习——另外一个侧面反映了当下国产化大潮下，SAP顾问不用愁饭碗。
