军惠系统的优化系列

lfree

再论绑定变量1:

绑定的问题前面已经讲了许多,单独拿出来再讲,在我开始接触的时候,就发现
军惠存在大量这方面的问题,这个跟早期程序员不知道oracle这个特性有关,
但是现在的程序员应该不会范这个错误,可惜我发现这个团队在不断的重复前
面的错误.
我见过的系统中,绑定变量做的最好的是东软的医保,以及天健的体检程序.
这个从一个方面讲只要程序员知道,经过培训,基本很少范这类的错误.

东软就是一些调用存储过程的语句没有做到,实际上这个效果在<expert>书上
提到的"一个烂苹果放入好苹果里面",中文的翻译书没有采用直译,而是翻译成
"一颗老鼠屎搞坏一锅汤".如图:

另外我个人发现现象:就是程序员一般对性能影响不大的问题,往往不愿意修改,
我曾经给东软程序员提过这个问题,可惜这个调用存储过程的语句一直没有修改.
我们单位有三套医保系统:区医保,金保,离休医保,都是有这个问题.

lfree

再论绑定变量2:
我想在提的是,如果大部分使用绑定的,优化sql是很容易的,扫描一下
共享池,按照几个方式排序:buffer get/exec,physics read,buffer get,
executions,sort等排序,很容易确定有问题的sql,实际上就是awr报表上的sql的
几种排列方法.

还有,如果程序完全绑定,你可以发现军惠的许多模块,护士站,医生站等sql语句
的变化不会超过300条.集中分析这些sql,并且发现有问题的sql还是很容易的.

fals

系统的性能问题，实际上并不是一个单一问题，大部份公司没有专业的DBA，在系统总体架构设计上也没有认真的考虑性能问题，因此到系统上线的时候就麻烦了。

绑定变量的问题，说到底还是开发经理自己不了解不重视的原因，或者就是公司没有开发管理。

lfree

像前面的例子:
SELECT MAX (TO_NUMBER (prepayment_rcpt.rcpt_no))
  FROM prepayment_rcpt
WHERE TO_NUMBER (SUBSTR (prepayment_rcpt.rcpt_no, 1, :1)) = :2

如图(snapg.jpg):就是明显的过度绑定.:1参数就可以确定,为什么要带参数.

举东软医保的例子:
在ii_inmaininfo的in_state中定义如下:
1-住院登记  2-病房接诊 3-出院登记 4-出院结算 5-预约出院,6-无费退院

SELECT   COUNT (*), in_state   FROM ii_inmaininfo GROUP BY in_state

  COUNT(*) I
---------- -
       305 2
        15 3
      9191 4
       413 6

4 rows selected.

很明显,像in_state这样的字段,最好不要使用绑定,主要它取值少,如果查询in_state='3',使用索引就很好,
而像'4'使用索引就很差.如图(snaph.jpg snapi.jpg):

ccwlm741212

支持LZ钻研的精神，加精华

lfree

在ini文件里面应该放参数性的东西,不应该包含像:
PREP_RCPT_CURR_NO=1
MED_RCPT_CURR_NO=1108
PREP_ACCT_CURR_NO=1
MED_ACCT_CURR_NO=402

将这些信息放在ini文件，如果在运行时候死机或者掉电，会导致ini文件没有更新，结果在业务操作中
程序会报ora-00001,主键冲突。另外的问题就是如果更换机器还要把旧机器的配置拷贝回来（当然也可以
访问数据库获得这些信息，来修改ini文件。）这样维护带来许多麻烦！

这个问题实际上在开始上线的时候一直再提,可惜对方一直不该.
因为门诊影响太大了,结果修改像1楼的帖子那样,

SELECT MAX (rcpt_no)  FROM outp_rcpt_master  WHERE rcpt_no LIKE :1
SELECT MAX (rcpt_no)  FROM inp_settle_master WHERE SUBSTR (rcpt_no, 1, 2) = :1

结果在登录时又出现性能问题!我一直在想,是不是他们发现使用像
SELECT MAX (rcpt_no)  FROM outp_rcpt_master  WHERE rcpt_no LIKE :1
这样的形式存在性能问题,不过我觉得这样的可能性太少.

lfree

字符集问题，军惠的系统开始使用的是US7ASCII，而现在的应用都是使用中文字符集，在升级
我脑子里闪过改变字符集的想法，但是很快就消失，主要是害怕麻烦，要修改用户端的设置以及相关测试。
这个算是给新上系统的一个提示，如果你现在要上军惠系统，一定要开发商选择中文字符集。

关于这个问题,我现在认为是我们自己的无知造成的,如果我们自己内部了解这些,这个问题根本不存在,
奉劝那些现在还没有上军惠的,不要在使用US7ASCII!!!!

lfree

门诊医生站的一条sql语句:

如何snapj.jpg,实际的语句后面还有一节,这个语句的作用就是查询3天内该病人来这个医生就诊记录.
实际上如果你不输入病人ID,查询的条件就是:
   ("CLINIC_MASTER"."PATIENT_ID" LIKE '%%') OR ("CLINIC_MASTER"."NAME_PHONETIC" LIKE '%%')

在上线的时候我一直想优化这些sql,最后发现oracle已经选择最好的执行计划.实际上这条语句对我们的系统影响很大.


首先看看
问题1.查询"CLINIC_MASTER"."NAME_PHONETIC" 这个功能是多余的,在南方许多人拼音不准,而且很少
有人知道在这个输入栏里面还可以输入查询病人的名字拼音.(如果我不看代码,也不会知道)

问题2.在高效与性能选择,我会选择性能,我修改的代码如下(如图snapk.jpg):
完全没有必要使用前面的使用前面的'%'

看看逻辑读的变化就知道.

lfree

优化到底谁来做的问题？这个问题一直是我思考的问题,由单位的计算人员做会存在一些问题,
我们先要了解数据结构,数据的增长模型,才能更好的优化,并且我们内部要有这类的人才,相对许多
医院讲有点难度.

  我觉得许多his的开发商家没有注意到这个问题，没有注意到这方面人才的培养，这种培养即
包括对程序员编程素质的培养,实际上要程序员注意一些问题很容易,1-2个小时的培训就可以
达到:
1.绑定变量 , 并且要合理的使用它
2.在where条件中使用函数要小心.除非你不使用这方面的索引.
3.能简单评估合理的执行计划.
4.学会看简单的执行计划.

   要程序员来建立索引,会存在一些弊端,看看我们lis系统就明白了,在一些表上竟然有17个索引,
而且许多是单字段的索引,我删除了不下6x-7x个.实际上我个人的观点这样的人最好从开发团队产
生，这样的人即了解应用有熟悉自己的模式,最佳的位置是项目经理以及技术经理,可惜我几乎没有
看到把优化看得很重的人。要知道错误最好在内部测试出现，如果在用户面前暴露，那是一件很难
堪的场面。
   
   看看东软医保,军惠,我们的lis,OA,合理用药......,我看到太多的垃圾,像我们也不是一家小医院.
其它的医院就可想而知了.....

jhdryb

你应该去搞开发