XXXX的LIS系统的性能问题

fals

我问的客户使用这个LIS大约半年多，门诊量还是很大的，目前日门诊量接近1500，住院病人1400余。详细的功能上我倒没有细问，不过因为他们与HIS对接，我估计查询主要是以病人ID号或者是检验申请单号为主检索条件来查询的，针对姓名的查询量应该不大。

服务器也是新买的。

据客户讲，数据库结构设计上不太合理，客户讲了好多的事例，这里我就不转述了，因为我自己没有细细的看过，所以也不做评论

lfree

》客户讲了好多的事例
能讲一些就好了，也许我没有发现的呢。
下午我在提交今天的监测图，我们目前逻辑读大约在8000上下。
我的优化基本完成，剩下的仅仅要改sql或者程序才能做到。

另外我想知道他们每天的日志是多少。

lfree

/* Formatted on 2008/03/31 11:39 (Formatter Plus v4.8.8) */
SELECT   TRUNC (first_time) "Date", TO_CHAR (first_time, 'Dy') "Day",
         COUNT (1) "Total",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '00', 1, 0)) "h0",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '01', 1, 0)) "h1",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '02', 1, 0)) "h2",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '03', 1, 0)) "h3",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '04', 1, 0)) "h4",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '05', 1, 0)) "h5",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '06', 1, 0)) "h6",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '07', 1, 0)) "h7",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '08', 1, 0)) "h8",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '09', 1, 0)) "h9",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '10', 1, 0)) "h10",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '11', 1, 0)) "h11",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '12', 1, 0)) "h12",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '13', 1, 0)) "h13",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '14', 1, 0)) "h14",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '15', 1, 0)) "h15",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '16', 1, 0)) "h16",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '17', 1, 0)) "h17",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '18', 1, 0)) "h18",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '19', 1, 0)) "h19",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '20', 1, 0)) "h20",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '21', 1, 0)) "h21",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '22', 1, 0)) "h22",
         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '23', 1, 0)) "h23"
    FROM v$log_history
GROUP BY TRUNC (first_time), TO_CHAR (first_time, 'Dy')
ORDER BY 1

tanyiqiang

晕,要是我们的员工写出这种语句,不被骂死才怪.

lfree

是指like '%这些%'吗？

我已经再交涉中，按照他们的说法是用户要求，我给他们的建议是既然是用户要求，
那样他们自己输入前面的百分号。

lfree

最后帖三个图：
逻辑读大约在5000-7000上下，上午相对忙一些。没有使用绑定，可以看见share pool的变化。
看等待事件，除了sql*net , 平时主要是多块读，以及log write。

还可以发现，下午3点上下，是发单处查询做多的时段。
就是因为这个like '%姓名%';

[ 本帖最后由 lfree 于 2008-3-31 17:40 编辑 ]

tanyiqiang

like '%这些%'
这种语句是无法利用索引的,肯定是全表扫描,数据量一大,查询时间会急剧上升.
我们是提供参数选择的方式,用户自己去把握,缺省是没有左边的百分号的.
会有很多这种查询应用吗?我见到的客户查询几乎没有这样用的.
病人信息表中会有姓名住院号门诊号ID号等,其它数据全部是通过ID号关联的,在LIS系统中,极少用到LIKE,几乎全是精确匹配.正常业务几乎是用不到LIKE的.

fals

估计只能修改查询方式。


想不明白为什么一定要把姓名作主要查询的条件，太不可靠了。为什么不用ID号，或者检验申请号也行啊，医院有特殊需求吗？

lfree

原帖由 fals 于 2008-3-21 11:14 发表
去年下半年我们的HIS刚和杏和LIS对接，到现在客户还没有反映明确的性能问题，这个系统用的是SQL server数据库，我也没太关心别人的系统。
过段时间我倒时可以问问

如果是ms sql，那时间也许会久一些。

lfree

原帖由 fals 于 2008-3-31 23:19 发表
估计只能修改查询方式。
想不明白为什么一定要把姓名作主要查询的条件，太不可靠了。为什么不用ID号，或者检验申请号也行啊，医院有特殊需求吗？

我问一下发单，主要是病人取结果的时候可能不带卡，而且操作人员一般仅仅看门诊病例，
而门诊病例上没有写就诊卡号（一些认真的挂号人员会写在病例上），操作人员只好输入姓名。

实际上那个查询窗口，有几个组合条件的，一个是时间，还有就是姓名，卡号，
不过仅仅使用姓名的时候使用这种模糊查询。

我已经跟实施人员讲了，不过好像对方不愿意修改。