XXXX的LIS系统的性能问题

lfree

>华西锁表是常有的事，，哈哈！

这个应该是使用ms sql的产品。使用oracle最多是慢，不会阻塞的。

lfree

目前存在的问题主要是name like  '%张三%'的问题。

还有就是绑定变量的问题。

如果解决odbc 的问题，系统可以提高1倍。
再解决like以及绑定变量的问题，系统在可以提高1倍。

lfree

关于绑定，许多开发人员讲这些总不以为然，认为提高两倍不大可能，我举一个例子：

在程序中调用存储过程直接带值，如图：
使用绑定执行54次，elapsed time＝52710，平均每次 52710 / 54 = 976.11 us ,下降还是很可观的，并且减少了shared pool的内存占用。

对比原来的28XX，不是几乎提高3倍吗？累计起来还是很可观的。

而且带来shared pool 的管理开销是很显著的。

lfree

另外，我修改系统参数cursor_sharing=force.

这样可以减少一些绑定的问题，我发现使用odbc驱动的程序，或者一些程序并不能使用这个特性。

如图：

lfree

就是许多sql都是相似的，为什么没有绑定，如图，我仔细检查对比里面的sql，才发现里面的sql是拼接的。
每次连接的时候都要加入一个空格，才会出现这样的情况。

lfree

这样会带来另外的问题，我不知道程序是否会出现，就是如果：
select sysdate from dual;
如果中间有2473 个空格。

SP2-0027: Input is too long (> 2499 characters) - line ignored

就是一行的长度不能超过2499字符。


但是sql还是照样执行。

lxh504

原帖由 lfree 于 2008-11-25 15:17 发表
这样会带来另外的问题，我不知道程序是否会出现，就是如果：
select sysdate from dual;
如果中间有2473 个空格。

SP2-0027: Input is too long (> 2499 characters) - line ignored

就是一行的长度不能超过2499字符。


但是sql还是照样执行。

楼主分析的不错，一定是个80后愤青，要不然咋这么滴激动呢？？？补充下
1.关于   like  %姓名 %   这种语句 ，模糊查询；在lis中无非也就是通过病人姓名查找检验结果的，lis也不可能是频繁的进行这种操作滴。
  因此，对数据库性能影响不大。
2.关于索引，你删掉了很多，教科书上的说法不一定适用！根据你的lis运行时间以及业务特点，一次500000行的表扫描操作无论如何不会快，所以，对你来说（注意，是对你）重复，多余索引对系统性能影响应该不大。

3.数据操作引起的日志增大。

其实最重要的是，我认为：就是大量存储过程的嵌套使用，以及中间临时表的产生。这是最要命的！

通过存储过程简化开发代码，通过视图进行多表的关联这种开发技术是最差劲的！为了代码易于修改，于是写大量的存储过程，用户所需数据

不能直接产生，单张表信息过于简化，就通过临时表汇总处理，每进行一次汇总或者查询统计就执行一次存储，重复的删除，创建临时表,

数据库单张表记录数应该处于一个比较低的数量级的时候这确实是个好办法，但随着记录数不断增加，导致数据库性能会很差！大部分资源在

数据库进行处理，白白浪费了客户机的资源。


因此，对于你做的优化，我认为对于数据库性能的提高也只能提高最多5％。。。。。（类似的情况我也碰到过，哎）

lfree

似乎找到了redo产生多的原因。

原来许多记录在LIS_INSPECTION_RESULT的表，许多记录要多次修改，实际上我仔细看修改语句，实际上update根本没有修改。
不知道是什么回事？

我看了这条记录，中间的四次修改都是一样的。

我看了许多记录好像都是一样的。

按照这样的推算，日志高就正常了。

zhang_angran

请问版主这些截的图用的什么DAB工具啊？（不是指截图工具）

lfree

我使用toad。