XXXX的LIS系统的性能问题

fals

如果厂商不愿意改,有几种可能,一个是实施人员本身不愿意把客户的修改意愿提交到公司去,嫌麻烦,另一个可能就是公司客户化资源不足,改起来周期很长,甚至他们认为这种小问题,排不到修改的重要项去.

客户化一直是医卫行业实施的一个大问题,也是成本最高的地方.在总体价格较低的情况下,多半的厂商不愿意做太多的客户化.

hongzhiqi

lfree 楼主能留下联系方式,有事想请教哈.....谢谢!!!!

lfree

你是谁?
联系方式已经发到消息板.

展翼

版主很受欢迎哦

lfree

他问的是ms sql的东西，我自己也很少使用。

findecho

主要是杏和开发人员不行，，，华西锁表是常有的事，，哈哈！

findecho

如果我是张**就回把版主请出来好好搞搞，，，不过徐**估计又要拍桌子了哦，，

lfree

原帖由 findecho 于 2008-11-24 23:21 发表
如果我是张**就回把版主请出来好好搞搞，，，不过徐**估计又要拍桌子了哦，，

不知道你是谁？实际上我比较注重优化，而没有考虑业务的流程。

顺便更正一下，我以前写的一些错误，在补充一些内容：

1.
滥用临时表，XXXX系统在存贮过程为了生成中间的结果，大量的使用临时表，而且程序中
大量的执行delete这些临时表的语句，导致产生了大量的垃圾日志。程序已经写成这样，目前
的改进仅仅是将delete换成truncate。我们使用redo文件每个100M，而每天基本最少产生是300M的
日志。而表空间的增长每天不过20M。

这个我的分析有错，实际上关于临时表的日志并不是太大，我保守估计大约在80－100M之间。也许日志大主要可能集中在表结构数据冗余以及update语句很多，
因为LIS_INSPECTION_RESULT的操作主要是先insert，再update，也是出现大量行迁移的表。

2.
另外我发现一个问题就是odbc的驱动问题，这个可能是逻辑读很高的原因，就是后台写的一些服务，使用ms odbc驱动，写的程序在调用存储过程的时候会执行一个检测参数的sql语句
这个语句很长，我贴出来：

SELECT   procedure_catalog, procedure_schema, procedure_name, parameter_name,
         ordinal_position, parameter_type, parameter_hasdefault,
         parameter_default, is_nullable, data_type, character_maximum_length,
         character_maximum_length character_octet_length, numeric_precision,
         numeric_scale, description, type_name, type_name, overload
    FROM (SELECT NULL procedure_catalog, owner procedure_schema,
                 DECODE (package_name,
                         NULL, object_name,
                         package_name || '.' || object_name
                        ) procedure_name,
                 DECODE (POSITION,
                         0, 'RETURN_VALUE',
                         NVL (argument_name, CHR (0))
                        ) parameter_name,
                 POSITION ordinal_position,
                 DECODE (in_out,
                         'IN', 1,
                         'IN/OUT', 2,
                         'OUT', DECODE (argument_name, NULL, 4, 3),
                         NULL
                        ) parameter_type,
                 NULL parameter_hasdefault, NULL parameter_default,
                 65535 is_nullable,
                 DECODE (data_type,
                         'CHAR', 129,
                         'NCHAR', 129,
                         'DATE', 135,
                         'FLOAT', 139,
                         'LONG', 129,
                         'LONG RAW', 128,
                         'NUMBER', 139,
                         'RAW', 128,
                         'ROWID', 129,
                         'VARCHAR2', 129,
                         'NVARCHAR2', 129,
                         13
                        ) data_type,
                 DECODE (data_type,
                         'CHAR', DECODE (data_length,
                                         NULL, 2000,
                                         data_length
                                        ),
                         'LONG', 2147483647,
                         'LONG RAW', 2147483647,
                         'ROWID', 18,
                         'RAW', DECODE (data_length, NULL, 2000, data_length),
                         'VARCHAR2', DECODE (data_length,
                                             NULL, 4000,
                                             data_length
                                            ),
                         'DATE', NULL,
                         'FLOAT', NULL,
                         'NUMBER', NULL,
                         NULL
                        ) character_maximum_length,
                 DECODE (data_type,
                         'DATE', 19,
                         'FLOAT', 15,
                         'NUMBER', DECODE (data_precision,
                                           NULL, 0,
                                           data_precision
                                          ),
                         'CHAR', NULL,
                         'NCHAR', NULL,
                         'LONG', NULL,
                         'LONG RAW', NULL,
                         'RAW', NULL,
                         'VARCHAR2', NULL,
                         'NVARCHAR2', NULL,
                         NULL
                        ) numeric_precision,
                 DECODE (data_type,
                         'DATE', 0,
                         'NUMBER', DECODE (data_scale, NULL, 0, data_scale),
                         'CHAR', NULL,
                         'NCHAR', NULL,
                         'FLOAT', NULL,
                         'LONG', NULL,
                         'LONG RAW', NULL,
                         'RAW', NULL,
                         'VARCHAR2', NULL,
                         'NVARCHAR2', NULL,
                         NULL
                        ) numeric_scale,
                 NULL description, data_type type_name, overload
            FROM all_arguments
           WHERE data_level = 0 AND data_type IS NOT NULL) procedure_parameters
   WHERE procedure_name = 'XXXX'
ORDER BY 1, 2, 3, 5

这个在9i下产生大量的逻辑读，每次大约58XXX，如果分析里面的系统表sys.user$,可以使执行计划走cbo，虽然oracle不主张分析系统表，我觉得应该问题不大。
这样逻辑减少到9XX。

3.还有其它，等一会在写，另外我们最近升级到10g，我还在检测，看看还有那些可以优化的地方。

lfree

另外我可能一些索引乱建，导致日志偏高，不过我删除了许多好像改善并不是很大。
在历史模式下还有许多表上建立了许多无用的索引。

如图：

lfree

而且可以发现，大量的是单键索引。

出现这个问题我猜测原来在ms sql下出现大量的死锁，开发人员认为这些能够加快sql的执行，建立了许多无用的索引。

不如group_id 的索引，check_person等索引，仔细看这个表
PATIENT_BED
PATIENT_DEPT
PATIENT_TYPE
SAMPLE_NUMBER
CHECK_PERSON
SAMPLE_CLASS
GROUP_ID
还有
CLINICAL_DIAGNOSES
都是无用的索引。