道路日出品的第一次尝试
FM日出品,领导要求道路版的图幅转换时间缩短到2个小时以内，得知这个要求，我焦虑的不行，这可能完成吗？瞅瞅现...
日出品要求very fast，领导说在这个迭代中，虽然你们是新来的，但是图幅转换时间必须缩短到2个小时以内！以后还要更短。FM迭代三结束，出品模块首次登场，冒个头，小小亮个相！
Oh，my god，得知这个要求，我焦虑的不行，这个可能吗？
瞅瞅现状，咱们的全要素图幅出品大约得10个小时左右，差了8个小时啊，并且还要求程序变动最小，减少开发和测试的工作量，环境还得在linux下运行…巴拉巴拉，工作量好大啊，还要不要人过下去了！
唉，指令第一，我和小伙伴们只好默默审视各个转换节点，对比整个出品转换流程和FM道路日出品的转换要素差异，做出第一个缩减方案：
- 只转出FM道路日出品转换的要素，其他不需要的要素不转出。
- 与道路无关的批处理不执行。
- 去掉GDBG环节，把上面的批处理分解到分省之前和之后，减少整库拷贝的时间。
- 把知识库中无关的表全部不导入，原因同上。
- 根据现有POI日出品一天的图幅量，测算道路转换的预期时间。
谁知道，刚拿起FM道路日出品表，打开一看，傻眼了，怎么全是地图术语啊！！！不是常见的具体表名，这跟以前到手的需求文档完全不一样啊。领导真够勇气，为了锻炼我们、够胆安排。
唉，硬道头皮上吧，费了俺九牛二虎之力，终于把哪些要素不转出的规格表分析出来了，不过还是没有信心，又请小吕大师帮忙把了把关，她老人家一看，果真又给我检查出好几处错误。大拿就是牛，下次看我的！
剩下的咱就不怕了，这可是偶的强项。linux没玩过，学就是了。
怎样让程序改动最小，适应linux？灵光一闪，如果ant能在linux执行，一切OK。程序的大框架基本就不用动了，只要做方案中的修改就可以,那些就是小case。待俺上网一查，果然可以！Yeah!
然后，Linux中没有出品转换框架，怎么把三个程序连起来还可以自动生成配置文件呢？据说shell脚本可以搞定，不会不要紧,程序语言是相通的，技不压身，咱可以继续学。
经过了这样种种困难，技术坑都被趟过、也找到了解决办法，到检验成果的时候了。
一执行还不错，效过基本达到了要求，但中间遇到了一个奇怪的问题，同时转11个省份，为什么每次转换的时间都不一样呢，有时相差很大，难道是并行竟争资源造成的？？？
问了几个大拿，都说有这种可能，不行，这次一定要搞明白这个问题，不能凭感觉，一定要找出问题出在哪里。即使是并行竟争资源，也要找到具体是哪一块。
说干就干，先查log，但log日志不全啊，有的没有log，改程序工作量太大。能不能在ant中加日志呢？一翻研究，终于实现出来了，这样，再去分析日志，就能够定位到是一个最简单的模块貌似有问题：每个省此模块运行时间，居然每次都不一样，有时相差10多分钟。得进去看看哪位大神，这么牛，还带变化的。
略一翻查，这个存储过程很简单，其就做了一件很easy的事情,判断此用户是否有进程连接，有就kill session，然后drop user ,最后create user。单个用户执行肯定没有什么问题，为什么并发执行会存在问题呢？
通过查看v$session表，等待事件为“enq: TM – contention”，（TM）表级锁，即正在处理一个表时别人不能删除，保护表或视图定义不被修改的锁。原因为drop user 是DDL语句，ORACLE会加DDL锁，所谓DDL锁是，在DDL操作是系统会自动为对象加上DDL锁，保护这些对象不被其他会话锁修改。这也就是为什么在drop user时会出现等待。并发执行没有产生效果的原因。
再看具体等待进程，可以根据v$lock视图的lmode和request mode判断谁是owner、waiter和converter。
● lmode > 0,request =0 → owner
● lmode = 0,request >0 → waiter
● lmode > 0,request >0 → converter
搞清楚问题，解决办法就出来了，在执行程序之前，把所有的用户全部删除，就可以不占用转换程序时间，从而解决并发产生的等待，节约出品转换时间。
一番努力下来，11个省份转出此存储过程基本都在1分钟左右完成。并且每次都是固定的，不会再变化。
整个事情，从头到尾学到不少东西，除了技术上的知识外，还有一种工作心态，只有打破砂锅问到底的探索精神，才能学到真才实学。
关注 四维研发Family
微信扫一扫关注公众号
