我看手术麻醉系统

lfree

昨天,跟别人聊天,提到了这个优化.链接:
http://www.itpub.net/viewthread. ... ;page=4#pid17733698

这个优化巧妙的把原来的nested loops执行计划转变成了HASH JOIN.

实际上这个问题就是很典型数据结构问题.
再会过头问题6. 表结构设置不合理的问题.

我记得以前跟一个程序员有过一个小小的争论,对方讲这样存日期可以节省空间.

看来程序员根本没有仔细思考过.

再拿这个例子来说明:

即使仅仅是年月日(yyyymmdd)的格式串也要占用8个字符.而日期仅仅占用8个字符.
如图:

程序中的MONITOR_VALUE="10-12-09 12:27=aa,bb,cc...."

前面的日期部分占用了(不包括=)14个字符,不知道程序为什么不考虑yyyymmddhh24mm的格式.(哈哈,开个玩笑)

做一个简单的运算:
MED_PAT_MONITOR_DATA的记录平均长度是75.

小小的改进每条记录就可以减少6个字符.按pct_free=10计算,(仅仅粗略估算)
(8192-204-819)/75*6/(75-6)=8.312
几乎每个块可以多插入8条记录.

[ 本帖最后由 lfree 于 2011-5-22 10:33 编辑 ]

lfree

补充11 在刷屏吗？

今天再仔细看awr报表：



取样是缺省每小时1次。看看大屏程序在大约1个小时的时间内，执行了3610，几乎是每秒1次。
有必要这样刷屏吗？再看看有几个“大屏程序”在运行。



可以发现仅仅一个程序在执行。真的有必要这样刷屏吗？
在看看med_screen_config 是否经常修改。




前面两个是我执行的，仅仅一条select语句，根本没有对这个表的dml语句。在看看这个select的结果如何？



这些东西不过定位屏幕字体，大小位置的信息，根本不会变。
写程序的人，为什么频繁扫描，写完代码后自己看了没有？？？
失望！！！！！

[ 本帖最后由 lfree 于 2011-5-26 10:51 编辑 ]

FrancescoLongo

连SSCJ这个用户都不给你做分离，只要SSCJ这个用户被锁了，急诊ICU程序就无法从军卫里面提出医嘱，真TMD搞笑。

FrancescoLongo

手术麻醉跟急诊ICU这样的稀烂，幸好这两个系统不是俺负责，要是俺负责的话，天天喊麦蒂斯顿的技术人员过来修改。

FrancescoLongo

原帖由 FrancescoLongo 于 2011-5-31 22:34 发表
连SSCJ这个用户都不给你做分离，只要SSCJ这个用户被锁了，急诊ICU程序就无法从军卫里面提出医嘱，真TMD搞笑。

如果不是俺发现的这个问题，他们天天只会用SYSMENT给SSCJ用户解锁

lfree

SSCJ是手术麻醉系统的用户吗？我们这里没有，或许没上。

为什么这个会锁，技术人员找原因没有。

FrancescoLongo

原帖由 lfree 于 2011-6-1 09:06 发表
SSCJ是手术麻醉系统的用户吗？我们这里没有，或许没上。

为什么这个会锁，技术人员找原因没有。

SSCJ是手术麻醉系统的用户，也是急诊ICU系统的数据接口用户名，真的很搞笑咧，这就是麦蒂斯顿技术人员的能力。
另外给急诊ICU新增了一个用户名也就是跟军卫数据接口用户，提取军卫相关数据。
不是俺所负责的系统。

lfree

哈哈，看一个系统是否良好。我个人的观点要从这几个方面：
1. 从使用者的角度，可以通过机房的电话来反映。如果平时电话很多，基本说明这个系统问题多多。
这个方面从我们系统看军惠可以讲是垃圾中的极品。这么多年来，系统问题还是一大堆。
当然这个也和系统使用人员太多太杂有关。
我更多的认为，这个软件仅仅数据结构良好，里面可以讲太差，许多地方做好后，到了开发商哪里，
没有很好的bug采集机制，导致现在问题很多。
电子病例又是一种情况，内部语句结构很差，但是程序运行问题到不是太多。

2.从长期看，系统一定要满足可持续运行的要求，也是我个人最关心的。
这点军惠问题一样。这个跟开发时间太早，当时的技术以及管理人员不了解oracle有关。

手术麻醉系统实际上从我们目前情况下，用户的问题还是很少的。
实际上，很多用户和使用方的技术人员不看内部，如果看内部，许多系统代码都存在问题。

ccwlm741212

LZ不怕辛苦啊，我们开发人员只管数据出来准确，优化的问题考虑的确实不多。。。

ncxiongst208

这么多医院，还是文胜哥对系统分析的透彻！