在上一篇中写到了 DBA和开发同事的一些代沟(一) 可以参考 http://blog.itpub.net/23718752/viewspace-1837743/ 有些朋友给我反馈了他们遇到的小故事，我后续再整理整理，看看有多少。 我还是继续来分享我这边碰到的一些小插曲，这些除非你确实碰到，想遍出来还着实需要想象力。 ##和开发的博弈 在Oracle中有资源管理的概念，其中一个功能就是设置每个用户可以使用的session数，即sessions_per_user,这个设置通过profile来完成。 一般的线上库都还是有一定的配额设置，保证不会出现过量的资源使用情况，这一点也和开发达成了共识。如果违反了共识，那就需要博弈一番。 前段时间监控发现某一个环境的sessions_per_user使用有一些异常，经过和开发沟通，他们反馈说新增了一些客户端，所以会需要一些额外的连 接数，我说可以的，那能不能给我反馈一些信息，比如增加了多少客户端，大概需要增加多少连接数，开发的同学又说不出，只是知道应该增加，为了让问题先解 决，我就把资源管理先给关了，保证他们能够连接进来，这样也就不会收到额外的报警了，但是临时解决之后，他们就不陪我玩了，没有了任何反馈，这件事我首先 短消息提醒，发邮件提醒，邮件抄送提醒，都没有任何反馈，无奈我只好继续开启资源管理，结果很快他们就主动找过来了，和我商量需要多少客户端，大概需要多 少连接数，他们领导也热心给我解释，问题就很快解决了。这个小案例只是说明一些地方开发可能不以为然，但是如果出了问题，这问题很自然就会落到DBA头 上，当初为什么没有提醒我，所以我也是先礼后兵。最终的目的就是解决问题。 ##物化视图日志的增量刷新 开发的同学最近找到我说，他们需要做一个需求，需要把一个大表中的增量数据通过时间字段来抽取，同步到另外一个库中，在这种情况下，如果表中发生了 delete,update操作，那么这类数据就会出现不一致的情况，但是在这一点上，开发同学也不能保证，对于这类数据的不一致之前也是勉强接受。认为 也就只能这样了。 这类需求，还是可以考虑用物化视图的增量刷新来做的，只要能够确认目标库中的数据不需要修改即可，物化视图快速刷新，在数据变更量不是很大的情况下，还是不错的选择，轻巧轻便。 他们也是半信半疑，还能够把update,delete的操作给同步过来，而且在源库中还不需要创建时间字段相关的额外索引。 ##需要注意的 sql编写规范 这个问题之前也提起过，通过ORA错误反思sql语句规范 http://blog.itpub.net/23718752/viewspace-1431617/ 大体是这样的意思，执行下面的语句没有问题，但是单执行子查询中语句就会报错。 select *from test1_customer where customer_id in (select customer_id from test2_customer where cycle_code>100); 执行这个语句没有错误。 81 rows selected. 但是执行子查询中的语句却报出了ORA-00904的错误。 select customer_id from test2_customer where cycle_code>100 * ERROR at line 1: ORA-00904: "CYCLE_CODE": invalid identifier 对于这类问题，其实字段cycle_code是在子查询外的表test1_customer中的，这是在oracle解析的时候会默认去标记，还是写sql语句的时候不够规范，没有用到别名这类的来标示，想想如果有有成百上千行，那么出问题的时候排查那就是难上加难了。、 ###防不胜防的数据变更 这个问题之前也提起过。使用闪回查询备份数据 http://blog.itpub.net/23718752/viewspace-1226414/ 大体的意思就是有一个update的变更，在测试环境中都没有问题，数据，结果和预期都是一致的，但是到了生产环境中部署的时候执行的时候发现预期的变更 条数和实际的就有了很大的差别，最后发现原来是过滤条件太大导致的全表update.对于这类问题，等我接到这种问题的救援时，优先能够想到的就是山会查 询的功能了，结果硬生生尝试把10多个G的表在变更之前的状态给恢复了回来，对比之后发现，现网的数据变更其实没有数据的损坏，最后也算是虚惊一场，不过 对于这类变更也还是需要DBA来认真评估。真出了问题，也能够及时恢复，看来DBA在这类变更操作中还是要给自己留点后路。尽管开发不要求备份，但是如果 出现了差错，还有尽快恢复的可能。 ##sql审核机制 对于sql的审核，之前也提到过一些，审核做得不到位，除了DBA的责任，还是需要开发同学的及时反馈，一方面开发同学可能嫌麻烦，或者他们嫌DBA麻烦，大体都是如此吧。 关于评审开发人员的sql语句 http://blog.itpub.net/23718752/viewspace-1286287/ 不管怎么样，sql审核是很重要的一个环节，工具只是形成了一个知识库，但是实际来审核的时候开发同学和DBA同学考虑的角度也不一样，DBA可能更侧重 于语句的结构和性能评估。而开发更侧重于业务的实现。所以两者之间还是需要磨合，之前就有过一次沉痛的经历，是在生产环境升级之前，开发突然提过来一个紧 急变更，说这个变更很重要，但是时间紧，语句只是测试了一下，没有让DBA做评估，结果带着侥幸心理来部署的时候就出了问题，一个pl/sql执行了近4 个小时，在这4个小时里，自己也是被各路领导追随，大半夜在那做优化，最后发现其实可以把这个pl/sql简化成1到两条sql语句，执行耗费的时间其实 也就不到一分钟。有了这类沉痛的经历之后，对于紧急变更也要严格来审核。我们评估技术风险，让领导来评估业务风险。 还有一大波案例在酝酿中，后续继续更新。