客户信息系统之Oracle方案

2024-05-07

客户信息系统之Oracle方案（精选5篇）

篇1：客户信息系统之Oracle方案

适用行业

各行业用户，中型企业

需求分析

用户提出信息管理服务器的需求：

运行7x24的核心业务应用(core business) 要求系统的稳定性与可靠性。

作为数据中心的核心服务器要求系统的性能扩展与灵活性。

作为企业的长期投资项目要求系统的投资保护和投资回报。

合理有效地利用系统资源要求系统管理工具好用、实用。

对系统分区的期待。

需要对复杂系统的支持与维护的机制。

要求全方位系统支持服务。

用户对系统升级方案的要求：

(1)平台要求：

管理系统数据库服务器。系统数据库服务器运行oracle 8i enterprise edition 、oracle application 11.5.4、workflow2.5，预计有 1000(700并发用户)用户使用oracle 应用系统；要求管理系统数据库服务器的 tpc-c值应高于：40,000 tpm 。

管理系统应用服务器。管理系统应用服务器运行developer6i(forms server，reports server，graphics 6i)、apache server 1.3.9、oracle jre 1.1.8，预计有1000 (700并发用户)用户使用oracle应用系统；要求管理系统应用服务器的tpc-c 值应高于：42,000 tpm。

信贷综合管理系统数据库服务器。信贷综合管理系统数据库服务器运行oracle，预计1000个数据库连接；要求信贷综合管理系统数据库服务器的tpc-c值应高于 360,000 tpm。

信贷综合管理系统application服务器。信贷综合管理系统application服务器，预计个并发用户；要求信贷综合管理系统application服务器的tpc-c值应高于 320,000 tpm，采用双机运行，每台app服务器的tpc-c值应高于160,000 tpm。

(2) 存储要求：

管理系统数据库服务器

管理系统数据的存储容量大约在150gb。

一般从业务数据的安全性和稳定性出发，建议数据库服务器预留15%的空间，以应付数据膨胀、系统日志消耗等情况。所以管理系统的存储可用容量配置为：150gb/0.85 = 177gb。

从保存数据的高可靠性方面考虑，存储设备要采用raid技术保存数据，raid 0/1后，系统存储容量要冗余50%左右，则某银行管理系统的存储设备配置容量(裸盘容量)至少为： 177 gb/0.5= 354gb。

具体实施

本方案使用的是hp proliant ml570服务器构建中型企业客户信息系统crm(中型数据库应用)。

随着网络流量的不断加大，原有的服务器已经不堪重负，hp proliant ml570的出现则满足了今天对电子商务的需求，它具有最大的升级性、高性能和高可用性。其采用最为先进的4 路intel xeon处理器，为企业应用带来了更好的性能。同时具有更好的可用性，如先进的ecc内存技术，热插拔冗余电源模块、网卡、风扇、硬盘等，使宕机时间减至最低。hp proliant ml570 可满足所有企业级用户的数据存储需求，在4u 高度的服务器中可支持4块热插拔硬盘，内存可扩至32gb。hp proliant ml570采用新的机箱设计，这样更易维护而无需借助工具。新的led指示灯和内置诊断显示可帮助故障诊断。

对于一些应用比较复杂的用户，所使用的数据库系统占用系统资源比较多，因此需要更加强大的处理能力，可以考虑使用hp的proliant dl740 和dl760服务器。

模拟配置：

处理器：双路以上至强处理器，2.8ghz主频

内存：至少16gb

硬盘： 4块以上scsi硬盘,可做raid5，硬盘转速 10000转以上

网络：2块千兆网卡(支持捆绑)存储

首选服务器： hp proliant ml570(服务器支持外置存储) 存储器支持san架构的可扩展存储

首选存储器： hp storageworks modular san array (msa1000)

后期收益

对于本方案中的中型企业用户，客户资源的信息储备与查询同样重要。所以，在系统服务器选择上，我们发现，它既保证了服务器强大的数据处理能力，并能持久地保持稳定的运行状态，同时也在存储磁盘上增强了其扩展性与安全保护能力。因此，该方案的实施可以让用户最终得到一个稳定与性能并存的操作平台，同时它也便于系统的维护与数据管理。

应用设备

hp proliant ml570/dl740/dl760服务器

篇2：客户信息系统之Oracle方案

交通银行在信息化的战略主要包括二个方向的发展:

业务处理集中化，主要体现在业务系统大集中上，取消了以往分散在各个支行的业务系统而将业务处理系统集中到总部，崭新的大集中业务系统能够理顺各地业务的不一致性，从而起到集约化管理的作用，降低了业务成本，提高业务流程的规范性和有效性，

企业分析构架的建设，主要体现在银行集中精力进行数据仓库的建设，目标是创建企业核心的数据视图，从而满足越来越多样性的各种数据分析，和业务发展决策管理的需要。目标是通过数据仓库以及相关的数据集市分析应用帮助银行建立差异化的服务和特殊的业务管理能力，从而提高银行客户的满意程度，并相应地获取更大的市场份额和较高的利润率，最终使交行能够在激烈的市场竞争中处于更有力的态势。

交行的客户信息系统就是银行的分析架构的重要组成部分，其基本定位如下:

— 客户综合信息系统是交行数据大集中工程的重要组成部分，是建立在交行数据大集中工程的三个生产系统所产生的客户业务数据信息的基础之上的一个客户信息的收集、整理、分析、应用的系统。

— 客户综合信息系统属于后台的集成管理信息系统，是决策管理层面的重要组成部分，在功能层次上与其它生产系统的区别在于，它是侧重于客户的业务信息的分析系统，而不是侧重于客户业务的流程控制管理的系统。

— 客户综合信息系统的目标是建立全行的客户信息的单一视图，有效的汇集客户、机构、产品、账户、渠道等分析要素的基础信息，成为一个服务于我行各级管理决策人员和业务分析人员的公共信息查询分析平台，使全行的客户信息能够共享，它服务的对象是业务管理部门、营销部门以及与客户信息相关联的非业务部门。

— 客户综合信息系统也是一个营销工作的管理平台。?建立基础框架，为后续的深度开发内容做准备。一期的开发内容不仅需要解决客户的基本信息查询分析，满足当前的营销管理、考核辅助等应用问题，还需要在系统的基础框架设计方面为后续的深度开发做一些准备，诸如产品清理、产品的毛收入的分析、主题分析的可扩展性等，以便能与未来的系统开发内容对接。

项目建设的评估和过程

Sybase IQ是Sybase针对数据查询和数据分析应用而设计的关系型数据库系统，具有数据压缩，高效率即兴查询分析，和线性可扩展的特点，其开放的架构以及标准的访问接口非常适用于面向大数据量情况下的数据集市以及以分析为主的业务应用使用，

4月起，交行进行了一系列针对Sybase IQ的测试，Sybase IQ表现出在普通的硬件环境下远超过一般数据库运行性能的结果。IQ与OLTP数据库相比存储原始数据的存储比为1 vs 3-8，索引化数据后存储比达到1 vs 3, IQ可以预先优化索引而且索引的空间很小和建造索引的时间很短，对不同查询无需改变索引，无需人工干预; 从测试来看IQ能够高速地进行大数据下的复杂查询操作，性能是传统数据库的2-20倍，而且IQ使用资源与传统数据库不同，IQ主要提高了CPU的使用效率，而并不依赖于I/O性能的提高; 从并发操作来看，IQ具有更好地满足大用户并发条件下复杂查询的能力在多用户并发下查询效能降低很慢。

交通银行根据IQ在测试中表现出的: 出色的数据压缩比，高性能的汇总和查询能力以及存储过程的灵活方便性选择IQ作为客户数据分析平台的数据库。

根据技术测试的情况，重新规划的整体系统的构架如下:

系统为集中访问的架构，各分行通过Intranet集中访问总部的数据分析集市。交行采用ETL服务器DataStage从业务系统上抽取数据到ODS服务器的DB2数据库上，然后进行ETL处理生成需要IQ需要的数据文件进行装载，在IQ中更具需要进行一些汇总处理，分行或总行客户端通过应用服务器直接访问IQ数据库的数据。

项目成果

客户综合信息系统，目前数据库数据存储超过 100GB，总共的应用用户数量1，平均在线用户数量260人，每天增量加载数据量为3GB，数据汇总处理时间 30-60分钟，每年新增数据存储约300G。

系统的整体效率也获得很大提升，整个批处理汇总处理时间由原来3小时减少到1小时; 目前系统最大的单表数据已逾3亿，用户对任意时段数据的查询速度有了大规模的提高，其中95%查询都是秒级内完成，只有5%左右的复杂查询是分钟级。

系统软硬件平台

服务器:IBM P690, 8 CPU, 32G mem

磁盘阵列: EMC Symetrix

数据库服务软件: Sybase IQ v12.6 For AIX 64bit

篇3：客户信息系统之Oracle方案

关键词：医院信息系统,Oracle,数据库,备份

1 医院信息系统及数据库备份的意义

笔者所在医院由总院、骨科医院、传染病医院三个院区和市中社区服务中心组成, 医院信息系统 (HIS) 包括门诊医生工作站、住院医生工作站、护士工作站、医学影像系统 (PACS) 、检验信息系统 (LIS) 、药局管理系统、门诊住院收费管理系统、病案信息管理系统、手术麻醉管理系统、医疗统计系统、院长综合查询与辅助决策系统、电子病历系统 (EMR) 、移动查房系统、设备器械后勤物资管理系统、社区卫生服务、体检信息系统、医疗保险接入系统、学术论文期刊查询系统等40余个系统应用。各院区分别由光纤接入总院服务器, 实现三院区医院信息系统无缝联接。

1.1 系统环境及配置

网络总体结构为主干千兆, 百兆到桌面, 采用IBM服务器, 另有备份服务器, 服务器端使用网络操作系统Windows 2003, 数据库为Oracle 10g;客户端使用Windows XP操作系统, 采用Power Builder 9为前台工具。

1.2 数据库备份的意义

医院信息系统在日常工作中积累的数据, 如果因为没有保护好而遭到破坏和丢失, 将会给医院和病人带来无法弥补的损失, 同时也会给医院带来不良的社会影响。当由于计算机网络系统故障, (如机器故障、介质故障、系统故障、进程故障等) 影响数据库系统的操作, 影响数据库中数据的正确性, 严重时甚至会使数据库中全部或部分数据丢失, 特别是在医院信息系统中, 对数据库要求7*24小时无故障运行, 一旦发生上述故障时, 需要能够在尽可能短的时间内, 尽可能完全地恢复系统运行, 数据库的恢复必须基于数据库有一个完善的备份, 并且经常性备份也有利于服务器的软、硬件升级。

2 备份方案

2.1 备份策略

根据笔者所在医院信息系统的特点, 选择合适的备份周期、备份介质和备份方法, 以确保为数据库提供一个完整的全备份。对Oracle数据库的备份, 采用冷备份和热备份以及逻辑备份 (Export/Import) 相结合的方法。

2.2 Oracle数据库三种备份方案的比较

2.2.1 冷备份 (脱机备份)

冷备份发生在数据库正常关闭的情况下, 当正常关闭时会提供给我们一个完整的数据库, 然后使用操作系统备份工具或第三方工具备份所有相关的Oracle文件, 这些文件包括 (1) Oracle可执行代码/代码、配置文件和控制文件; (2) Oralce数据文件或联机重做日志文件。特别要注意不在一个物理盘上的多个数据文件、多个控制文件和多个联机日志文件。通常利用IMMEDIATE选项关闭数据库, 备份工作完成后, 再以正常方式启动Oracle。优点是备份简单、迅速, 恢复时间较短;缺点是必须关闭数据库, 不能进行点恢复。

2.2.2 热备份 (联机备份)

热备份可在数据库打开的情况下进行, 此时数据库必须运行在可归档日志模式, 否则Oracle将产生错误并禁止使用联机备份过程。一般情况下, Oralce的LGWR后台进程以一种循环方式写入redo日志文件, 从第一个redo日志到下一个, 直到该组的最后一个, 然后再重写第一个redo日志, 因此在非归档模式下不能使用热备份。在可归档日志模式, ARCH后台进程在每一个redo日志被覆盖前, 就读取全部redo日志, 然后将其写到归档日志 (也就是给它做一个拷贝) , 熊掌, 这些文件被写入硬盘或磁带中, 建议使用硬盘, 这样可大大减少完成备份所需的时间。其备份过程包含以下步骤 (1) 进行表空间的联机备份; (2) 备份归档重做日志; (3) 备份控制文件。优点是备份时不必关闭数据库, 可以进行点恢复;缺点是执行过程复杂, 测试困难, 同时热备份可能造成CPU、I/O过载, 应在数据库不太忙时进行。

2.2.3 逻辑备份 (Export/Import)

逻辑备份是使用软件技术从数据库中提到数据, 并将结果写入一个称为“导出转储文件”的系统文件内, 可以使用专用工具软件 (Import) 将该文件恢复到数据库中。它有三种模式: (1) 完全导出模式:导出数据库中所有对象; (2) 用户模式:导出用户所有对象以及对象中的数据; (3) 表模式:导出用户所有表或者指定的表。该备份有三种类型: (1) 完全型 (complete export) :备份整个数据库; (2) 积累型 (cumulative export) :备份上一次完全或积累型备份所改变的数据; (3) 增量型 (increamental export) :备份上一次备份后改变的数据。这种备份包括以下步骤: (1) 数据库运行时, 利用Export实用工具导出数据 (例如导出用户或表) ; (2) 把导出的文件拷贝到硬盘或磁带上。逻辑备份的优点是能执行对象或实现恢复, 能够跨操作系统平台迁移数据库;缺点是当数据量大时, 恢复的过程相当耗时。

2.3 备份介质

磁带具有体积小、大容量、可长期保存等特性, 是一种安全可靠、价格低廉的备份介质。为保证备份介质的安全, 介质与服务器应异地并分开保存, 对保存介质的环境温度、湿度以及防磁措施有相应的要求, 应严格遵守。可根据备份的内容、日期, 将介质统一编号, 以免备份和恢复时弄错介质, 造成原有备份丢失。

3 某医院数据库的备份方法

笔者所在医院采用三种备份相结合的方法进行数据库备份。每周日晚进行冷备份, 关闭Oracle数据库, 执行转储, 将所有相关的Oracle文件以及归档日志文件全部拷贝至备份服务器硬盘中, 完毕后启动数据库, 并将备份内容转至磁带, 做好标记, 妥善保存。每天则采用热备份的策略备份归档重做日志文件, 注意启动数据库时数据库需要运行的模式。每两个星期做一次指定重要用户和表的导出, 确认数据库在逻辑上的正确性。

参考文献

[1] (美) Kevin Loney, Bob Bryla;朱洁梅, 王海涛译.Oracle Database 10g DBA手册——管理健壮的、可扩展的、高可用的Oracle数据库[M].北京:清华大学出版社, 2006

[2] (美) Kevin Loney;刘伟琴, 张格仙译.Oracle Database 11g完全参考手册[M].北京:清华大学出版社, 2010

篇4：客户信息系统之Oracle方案

关键词：信息系统；Oracle数据库；性能优化

中图分类号：TP392

从我国实况来看信息系统还存在各种不足，比如怎样充分发挥计算机系统资源，怎样确保用户的服务质量及响应速度等。因此，研究优化Oracle数据库的性能具有适用价值。

1 信息系统Oracle数据库性能优化

笔者就从Oracle数据库系统中选择I/O、内存、SQL语句以及网络性能方面入手，分析这些组成部分在运行中性能发送的一些问题，并且针对这些问题提出合理的优化措施。

1.1 对内存进行优化

优化内存比较常用方法就是调整系统的全局区（SGA）。具体操作就是调整内存中各种组件，包含JAVA池、缓冲区高速缓存等，对内存结构进行调整时需要加大SGA大小，但是必须要确保SGAS长度一定在实际所用内存范围之中。

1.2 调整共享池

共享池主要有两个部分组成，即高速缓存和数据字典缓存。其参数就确定了共享池的大小。而在高速缓存模块中又是由SQL语句文本，执行计划以及PL/SQL块、JAVA类共同组成。将“select namespace，gethitratio from v$librarycache”输送到执行栏目中，就能够从数据库中获取到缓存的统计信息。在该执行语句中gethitratio主要是实现查询对象的句柄标识名字和次数之间比率。在该数据库中，如果该比率低于了95%，就要进行调整。其查询语句是“select sum（pins-reloads）/sum（pins）*100 from v$librarycache”，通过执行该局于就可以得到高速缓存命中率。数据字典的缓存就是把数据字典中所含的各种信息存储进去。SQL语句查询对象信息时是通过数据字典进行高速存取，降低了不缓存之时从数据字典中查询的次数，通过这种查询方式就能够提升其性能。而且对v$rowcache动态性能视图进行查询，可以得到数据字典中缓存相关信息，输入执行语句“select（sum（gets-getmisses））/sum（gets） from v$rowcache”，通过执行后就可以得到数据字典中的缓存命中率。一旦最终结果值低于85%，必然要增大共享池容量才可以。

1.3 调整缓冲区的高速缓存

在SGA中，高速缓存是重要的组件之一，在执行保持之时高速缓存区就是负责对磁盘中相关数据进行读取、拷贝，保持服务器就能够对所有拷贝块进行共享。假如该服务器要得到数据块，就会先到高速缓存之中去查询所需数据，如果需要的数据在这个缓冲区之中，那么该进程就可以从高速缓冲区之中直接读取所需数据，如果数据并未在这个高速缓存之中，必然会从磁盘中相关数据文件进行读取，同时还将所读取数据存储进高速缓存之中，之后这些存储的数据就能够被服务器的进程使用。因此要尽可能让进程读取缓冲区的高速缓存中数据，并且经过相关的查询语句就可以执行，还能够通过查询得到使用高速缓存各种情况。

1.4 调整重做日志缓冲区

重做日志的缓冲区，也就要在内存中对高速缓存进行重做。一般情况下，该缓冲区的容量有1MB就可以的。但是该缓冲区一旦占据的空间三分之一，就会发出“rollback”和“commit”的命令，或者将DBWn进程写进到LGWR之中，通过这种方式就可以重做日志的缓冲区，将磁盘中重新写入内容。如果要想恢复数据库，必须要通过重做日志的缓冲区之中各种项目，这一种操作非常重要。要查询重做日志缓冲区中效率，输入相关的查询语句就能够查询结果，最终查询结果值只有接近0才正常，假如这个值不断的增大，就要适当增大log_buffer大小。

1.5 优化I/O

事实上，影响Oracle数据库性能一种主要原因就是磁盘I/O，一旦解决好了I/O，就能够有效提升数据库性能，配置数据库性能准则即为尽可能的降低磁盘I/O及平衡多个磁盘的驱动器，并且还要尽可能使用本地管理的空间，对动态视图进行查询就可以得到数据文件中的I/O 性能。在平衡I/O，能够采用的策略主要有如下几种：

（1）把访问次数比较多的数据文件促进独立的磁盘上。

（2）给用户数据创建出单独的表空间，并且把这个表空间单独放到system表中。

（3）有几个数据文件存在于同样表空间之中，就要存放到不同的磁盘之中。

（4）索引应该处于独立表空间中，还应该把索引以及表的数据存放至不同磁盘之中。

（5）构建出临时的表空间，用来实现排序操作，这样就能够有效阻止数据库中碎片进入表空间中，同时创建独立表空间给回滚段。

（6）尽可能做大日志文件，避免切换日志过于频繁；同时重做日志文件不要和数据库文件放进同一个磁盘中，降低磁盘之间的竞争。

1.6 优化CPU

当数据库中的I/O操作到了最低的程度，同时也分配了足够的内存，但是应用软件依然遭到CPU约束。优化CPU目标就要让CPU尽可能滿足用户所需，同时尽可能减小等待以及额外的开销影响到CPU，并且服务器能不能够正常的工作直接关系着CPU，当工作高峰CPU使用率处于90%标识着服务器具有良好工作状态。但是假如空闲之时CPU的使用率超过了90%，说明服务器中的CPU资源不足。如果出于工作的高峰，CPU的使用率依然比较低，这就说明服务器中的CPU资源比较充足。

在运行中，管理数据库人员只要查询数据字典中相关统计项，就可以查询Oracle 数据库使用CPU所占据时间，同时将相关查询语句输入到执行程序中，就可以获取到该操作系统使用了CPU所占据的时间，当然操作系统使用时间也就是用户态+系统态的时间总和。数据库占据了时间超过了总时间90%，这就说明服务器之中CPU几乎都让Oracle数据库占据了，表明运行良好；如果其他各种程序将CPU资源全部占有，Oracle数据库必然无法活儿更多的CPU资源及时间。查询v$sesstat数据字典就能够知道目前所连接的Oracle 数据库中每一个回话所占用CPU时间，就能够知道会话所占用服务器CPU的时间情况，以及导致CPU资源缺乏根源，事实上重解析SQL语句，锁冲突等均可能造成CPU资源严重不足。管理人员将相关查询语句输入，该语句能够查询解析SQL语句的情况，执行语句中的parse time cpu就表示出系统所用时间，执行语句中的parse time elapsed为响应时间，而用户等待的时间采用公式可获取。而且从该公式之中还能够得到解析SQL语句中平均等待的时间，如果这个平均值靠近0，就表明系统正常，一旦等待解析的平均时间较长，就要从中查询解析效率比较低，应该优化相关的语句，同时还应该改变Oracle中的参数，通过参数来增加高速缓存的光标数值。当然，数据库的管理人员还能够采取查询语言（select buffer_gets， executions， sql_textfrom v$sqlarea），而且该查询语句还能够对低效率的SQL语句进行查询，对该语句进行优化同样能够提升CPU利用效率。

1.7 优化网络性能

数据库的应用不断增加，自然网络这个承载数据库服务器的平台至关重要，直接影响着用户发送数据。因此，调整网络性能也是必然趋势，而优化网络就需要尽可能降低网络中数据流量，从而降低了网络资源的使用。

1.7.1 Oracle 网络协议

Oracle数据库比较常用的网络协议为SQL*Net或者Net 8，该协议处于七层开放式的回话层中，将透明连通性提供给Oracle服务器与客户端。透明连通性就是通过接口层SQL*Net/Net 8接收来自Oracle应用的SQL语句。而且按照相关的标准格式打成包，同时把该包传送至数据库。SQL*Net/Net 8主要是用来负责构建及维护客户和服务器间的网络会话。

1.7.2 检测网络性能的方法。数据通过了网络程序之后必然会出现延迟，因此就需要优化其性能，才能够有效保障网络的吞吐量，才能够降低网络的流量。从使用现状分析可知，要想非常精确的确定出网络的延迟十分困难。但是在Oracle数据库中设计了三个动态性能表，这些表就能够用来测量出网络延迟，这些表分别是v$session_event，v$session_wait与v$sesstat。

（1）v$session_even，该操作主要是操作时Oracle的等待时间，该值就可以多网络效率进行有效评估。

（2）v$session_event；将目前正在运行的会话（等待事件）全部列出来，所谓等待事件就是说明共享或者前台进程中正处于等待的消息。只要存在等待事件，一定要查询等待事件是不是被Oracle接收或者被客户端发送，而且还能够查该表是不是意外被中止，只要客户端发出消息就能够确定出Oracle是否已经作出回应或者依然在等待。

（3）通过v$sesstat查看已经接收或者发送到客户端的字节数，还能够查询到客户端传递过来的请求数目。

2 结束语

笔者依据自身经验，做了如上Oracle数据库相关优化探讨。但是该分析属于一项比较复杂工作，涉及到多个方面，不但要具备扎实数据库技术，还要非常熟悉操作系统、硬件设备以及机器结构等各个方面。笔者全面了解了Oracle体系结构，并且探讨了对该体系结构的优化，包含了优化I/O、优化内存等等，从而更确保了房产信息系统的实时监控。

参考文献：

[1]翟岩龙，宿红毅，战守义.数据库性能监控体系的研究与应用[J].计算机科学，2009（11）.

[2]王娜，宿红毅，白琳等.数据库性能监控分析系统的设计与实现[J].计算机工程，2010（24）.

[3]滕永昌.Oracle10g数据库管理系统[M].北京：机械工业出版社，2012.

[4]杨华千，刘勇国，杨德刚，廖晓峰.Oracle的存儲体系结构及其对象空间分配研究[J].计算机科学，2013（09）.

作者简介：冯育栋（1982.09-），男，江苏靖江人，科员，本科，研究方向：信息系统管理维护。

篇5：客户信息系统之Oracle方案

现在大部分大中型医院现有信息系统的架构现状是:以Client/Server(C/S)架构为主,代表系统为HIS、LIS、RIS系统等;同时新的Browse/Server(B/S)架构的二层及三层结构逐渐增加,代表系统为电子病历(EMR)、办公系统(OA)、移动查房系统等,这样整个医院系统处于混合架构的情况,如图1所示,而稳定性好、又易扩展的ORACLE数据库已成为大中型医院的主流数据库。医院系统C/S架构以Power Builder(PB)与ORACLE结合的架构最为普遍,B/S架构以.net开发平台最为常见,这种混合架构的IT应用环境下,ORACLE的性能优化面临的问题很值得研究。

1. 混合架构下ORACLE优化面临的问题

现在一个典型的三甲医院,客户端终端数都在1000个以上,高峰期C/S系统连接数在400左右,B/S系统连接数在200左右,业务数据(除PACS图片外)一年增长在30G左右。从联入ORACLE数据库会话方式看,C/S是稳定的长连接方式,B/S联入是短连接方式,两种不同的会话方式对数据库的资源占用与性能开销都不一样。另一方面,因医院业务系统的集成,要通过不同的方式对C/S系统与B/S系统进行集成,而集成方法不管是接口表方式、Web Service方式、还是中间平台方式,都带来了新的ORACLE性能优化的问题。

2. 混合架构下ORACLE优化的整体思路

优化问题是一个整体系统的问题,首先得有全局观,需从整个信息系统涉及的各方面资源进行分析、跟踪、优化、测试、评估。现阶段一般医院的网络主干都达1000M以上,基本满足医院系统需求,信息系统的性能问题主要在应用系统与数据库层面。本文重点从软件层次的三个方面:业务应用软件、中间件及中间系统、ORACLE数据库对混合架构下的医院信息系统进行整体性能优化。

3. 混合架构下ORACLE优化措施

3.1 从前端开发工作层优化ORACLE性能

通常开发人员很少注意SQL代码的效率,他们更着眼于功能的实现,至少性能问题通常被认为是次要的,而且在应用系统开发初期,由于数据库数据量较少,特别是查询SQL语句等,用户不容易体会出各种SQL句法的性能差异。

但是一旦这些应用作为生产系统上线运行,随着数据库中数据量的增加,大量并发访问,系统的响应速度可能就会成为系统需要解决的最主要问题之一。在少量用户下性能可以接受的SQL,可能在大量用户并发的条件下就会成为性能瓶颈。

从应用角度来讲,ORACLE性能优化,主要是应用要避免全表扫描。而实际应用中,大部分的性能问题是ORACLE的INDEX在实际代码中没有起效。

3.1.1 从业务系统ORACLE表及SQL代码对索引失效情况进行优化

(1)布尔值上的索引无效

例:病区医嘱表(bqyz)中医嘱记费标志(jfbz)为布尔型,虽然在该列上建立索引,但要检索哪些医嘱未曾记费,速度依然较慢。后来在做优化时把jfbz数据类型改为Number(1),再在该列上重新创建索引,PB程序配合修改,同样硬件下,速度提高近30倍。

(2)隐式转换与索引失效

例:出院病人信息表(zy_brry)中病人ID号(zybrid)字段定义为varchar2(10),但在查询时把该字段作为number类型以where条件传给Oracle,这样会导致索引失效。

错误的例子:

正确的例子:

(3)对索引列进行运算导致索引失效

例:住院收费项目(zysfxm)中项目金额(xmje)上建有索引,where子句中对列的任何操作结果都是在S QL运行时逐列计算得到的,因此它不得不进行全表搜索,而没有使用该列上的索引。

错误的例子:

正确的例子:

3.1.2 结合开发工具特点,进行程序优化

程序优化上原则:“有效降低SQL的逻辑读是SQL优化的基本原则之一”。

(1)比如PB执行ORACLE代码的特点优化

例:门诊系统的窗口收费人员每日需要生成日报表进行财务结算,门诊收费信息表(mzxt_mzsf)大约有399多万条记录,SQL语句如下:

该语句运行速度很慢,生成一张日结报表竟然要30min,对该模块的SQL语句做了优化,如下:

查询速度快了10多倍,优化效果显著。

(2)PB建索引语句的差异造成索引没有起效

在门诊系统中,病人挂号明细(ms_ghmx)表查询速度慢,查看此表已有BRID索引对象,但导出此表索引定义竟为:

造成索引对象虚存在。

严格按SQL重建索引:

再次查询,速度恢复正常。ORACLE系统在长期运营过程中,有时存在这种索引对象虚化指定的情况,造成PB查询很慢。

(3)从ORACLE中抓取性能开销最大的SQL语句,根据业务逻辑定位到应用系统,对这些SQL语法进行调整,以提高SQL执行性能。

3.2 从中间层及WEB SERVICE优化ORACLE性能

3.2.1 通过优化中间层代码来提高ORACLE性能

对于C/S与B/S系统间是接口表模式的优化方法如下。

(1)优化接口表的逻辑视图结构,这是最重要的,主要是为了在视图来源表上建立合理的索引。

(2)优化建立视图的SQL语言,增加辅助表来优化视图来源表。

(3)对于视图来源的接口表数据量很大情况,根据业务系统的业务逻辑引入物化视图,以空间换时间,提高接口表视图的性能。

3.2.2 通过优化WEB SERVICE代码来提高ORACLE性能

web Service技术是一种面向服务架构的技术,通过标准的Web协议提供服务,目的是保证运行在不同平台上的应用服务可以互操作。web Service技术是构建松散耦合的、可复用的软件模块,自包含的、自描述的、模块化的应用程序的利刃。但Web service方式也有一个缺点就是:造成应用频繁地向数据库连接与断开又连接。

医院基于B/S WEB架构的EMR系统与移动查房系统,我们采用Web service进行集成。移动查房系统执行医嘱时,需要调用HIS系统的记费、药品提交等服务,通过将HIS功能用Web service发布的形式来调用实现。

HIS为PB开发,通过PB11将用PB写的代码发布为web Service对象并发布到IIS中,提供给B/S应用调用。在这种结构下,很多HIS代码中用到Datastore(隐性Data Window),生成的web Service在执行时要在内存中重构Datastore结构,占用内存高,数据库访问时资源占用大。在医院实际移动查房系统运行中发现,每当全院移动查房系统用户联入时,有大量的web Service发送解析(床位1000的医院,全院都上线移动查房系统,每天web Service与ORACLE数据库联入、解析、注销次数达天6000次/天)。

因此对HIS Web Service关键业务代码进行优化,特别是Data Store对象代码,用PL/SQL重写,其中使用频率高的代码,写成ORACLE存贮过程,在多用户并发状态下,web Service的性质提高3倍以上。

3.2.3 将web service涉及的业务逻辑进行分层

对HIS web service中的业务代码分多层进行,中间业务逻辑部分通过中间件的进行,只有第三层才直接访问数据库,典型的是WEBSPHERE中间件技术。

3.3 ORACLE数据库优化

3.3.1 ORACLE单结点传统优化

在CPU高速发展的情况下,ORCLE的性能问题,80%以上的系统问题是SQL与数据库结构造成的IO问题。在数据库服务器的硬件投入和CPU够用的情况下,选择一台性能优良的存贮以保证高速的IO性能,是ORACLE数据库性能硬件系统要求。

在单实例数据库的优化上,主要是优化ORACLE实例的系统参数,这里就不具体阐述。

3.3.2 引入ORACLE RAC多节点提高运算能力

混合架构下的医院信息系统,表现为多用户高并发,混合长会话与短会话同时访问数据库,引入ORACLE RAC(Real Application Cluster)多节点技术分而处理来提高数据库性能。

核心ORACLE数据库是用一套4节点LINUX平台上的ORACLE RAC系统,具体见表1。

把His Web Service与HIS数据库放在一个物理数据库中,少了不同数据库服务器之间中间传输环节,提高了性能;多节点分担了多用户的并发性,提高了服务器性能;通过不断增加RAC节点以提高ORACLE性能。

3.3.3 ORACLE优化时技巧