HIS 数据库中oracle 分区表的使用

winterkss

分区对系统的性能影响是非常大的，分区字段有很多种，但一般用得多的是按时间。主要是针对查询事务大数据量访问用，假设费用明细表中有3年1亿记录，你按年度分区，一年只有3000万，保留两年，OFF LINE第一年，这样你用分区索引访问时，性能要提高很多，相当于你查一本书，通过目录索引查，你要快，分区就是这概念。通过分区，当OFFLINE和ONLINE数据时要简单得多。
    不过，分区不是从根本上解决性能问题，在一个800Session的事务中，生产事务与查询统计事务在一个库中会导致严重的资源申请冲突，但一过了上班时间，你的主机资源被极大的浪费了。所以业务生产库和统计分析库分离是一种比较好的处理办法，当我们的系统采用双机热备的时候，可以让生产库和统计分析库分布在两台主机上进行互备，目前很多医院系统是用PC服务器做群集，原理跟这差不多，不过性能和维护相关还是有点大。在晚上业务量小的时候，根据业务系统设计元数据，在主机资源空闲时自动提取元数据，按天进行提取，这样即使业务高峰时期，生产事务和统计分析事务不会对资源申请造成冲突，并且经过元数据的的形成，查询、统计、分析的访问数据量将会大减少。如果需要进一步提高业务的I/O，可以将统计库设计独立阵列。

fals

HIS实际业务非常复杂，在生产库中使用分区表来提高性能，只能是某些业务能得到提高，但代价是其他业务性能更差。比如说门诊处方数据，通常使用时间进行分区，但是在查找某病人的历史处方时（门诊医生站的主要功能之一），只能按ID号或病人的相关信息进行查询。如果门诊处方数据使用ID号分区，那么药房在按时间统计处方量，或者按时间区间查询处方的时候，性能仍然极差。

住院系统的数据就更不用说了，数据查询的条件非常复杂，分区表提升的性能有限，大多数时候，建立了分区表，还得使用全表索引，而不能使用分区索引，一些时候反而降低了性能。

从医院的实际业务来看，还是强烈建议把生产库和历史库分开。在生产库上最多保留一年的门诊数据，一到两年的住院数据，甚至可以更少。西南医院的生产库门诊数据只保留3个月，住院数据保留6个月，生产库的规模一直保持在20G左右，性能挺好的。

而且，建立历史库和生产库，对于大规模的数据统计也是非常有利的，院长可以比较一两年的数据变化趋势，甚至更长时间的变化情况，分区表----也就是把历史数据和在线数据都放在一个库上的情况下，是不敢想象的。

HIS对性能的要求非常复杂，实际业务中又不可能控制某些客户端的统计只允许在某个时间内进行，很多时候，单一技术根本不能解决性能问题，必须是一个完整的方案----DBA的价值也就在这里

花好月不圆

不建议在生产库中使用分区表来提高性能
HIS 实际业务非常复杂，在生产库中使用分区表来提高性能，只能是某些业务能得到提高，但代价是其他业务性能更差。比如说门诊处方数据，通常使用时间进行分区， 但是在查找某病人的历史处方时（门诊医生站的主要功能之一），只能按ID号或病人的相关信息进行查询。如果门诊处方数据使用ID号分区，那么药房在按时间 统计处方量，或者按时间区间查询处方的时候，性能仍然极差。

住院系统的数据就更不用说了，数据查询的条件非常复杂，分区表提升的性能有限，大多数时候，建立了分区表，还得使用全表索引，而不能使用分区索引，一些时候反而降低了性能。

从医院的实际业务来看，还是强烈建议把生产库和历史库分开。在生产库上最多保留一年的门诊数据，一到两年的住院数据，甚至可以更少。西南医院的生产库门诊数据只保留3个月，住院数据保留6个月，生产库的规模一直保持在20G左右，性能挺好的。

而且，建立历史库和生产库，对于大规模的数据统计也是非常有利的，院长可以比较一两年的数据变化趋势，甚至更长时间的变化情况，分区表----也就是把历史数据和在线数据都放在一个库上的情况下，是不敢想象的。

HIS对性能的要求非常复杂，实际业务中又不可能控制某些客户端的统计只允许在某个时间内进行，很多时候，单一技术根本不能解决性能问题，必须是一个完整的方案----DBA的价值也就在这里
============================================================
赵兄此言差已,
现在应用系统的设计已经从主机升级为中心变化到以存储为中心的时代.从长远看,数据集中的设计模式比之数据分布的模式更加有利. 且不说历史数据越来越多,越远离实际应用服务器的时候,关心它的机会可能就更少了.历史数据也存在安全\备份,且性能要求不会太低.
现在中端阵列价格不到四/五 十万,每秒io可到数十或百兆以上,对于大型医院来说,这个成本不存在问题
从管理上说,管理一个数据中心的数据比管理多个服务器/存储的模式其实更加便宜 现在,把HIS作为财务为核心,的系统应用,财务数据具有连续性要求,历史也好 当前也好,分成若干机器/存储保存不但增加client 应用设计开发的难度,也难保证迁移的完整性，徒增加工作量而已.
  从业务上说,门诊病人费用信息分区存放自然没有争议,至于门诊病人处方引用查询,一般从诊断结果上引用的概率比较大,平时就可以统计归类TOP100/200疾病的处方表,可先找中间表,再去索引实际处方,并且该中间表可随时更新,即使查询不到,也无大碍.
        即使查询某病人历史处方,也可按全局病人ID索引,何来性能更差一说?
        同样sql语句,分区,可能是分区扫描, 如果不分区,很可能 FTS ,于性能有何益处?建立全局索引,分区不分区的效果相差不会很大.不至于更加差把.

住院系统数据,存在大量中间数据,包括发药申请\医技\化验申请等,按照分区存储,有益无害,性能必定比不分区好,费用明细自不必说,
        Oracle 索引的大小与物理IO的量不是线形比例的,与索引级别有关系.
对于大规模数据统计而言,可采用任务分时处理,避开高峰业务时间,由用户建立Scheduler 或job 运行,
比较长期数据,亦有层层汇总的过程,在历史库统中,从最明细的数据中统计,院长等难道就有耐心等待?
个人看法,认为分区不会降低系统性能,并且降低设计管理难度.
历史库/历史表一说,在mssql 中或更早的foxpro 中尚有市场,但在oracle 中,还采用历史库,未免被人贻笑大方.

花好月不圆

最初由 winterkss 发布
[B]
    不过，分区不是从根本上解决性能问题，在一个800Session的事务中，生产事务与查询统计事务在一个库中会导致严重的资源申请冲突，但一过了上班时间，你的主机资源被极大的浪费了。所以业务生产库和统计分析库分离是一种比较好的处理办法，当我们的系统采用双机热备的时候，可以让生产库和统计分析库分布在两台主机上进行互备，目前很多医院系统是用PC服务器做群集，原理跟这差不多，不过性能和维护相关还是有点大。在晚上业务量小的时候，根据业务系统设计元数据，在主机资源空闲时自动提取元数据，按天进行提取，这样即使业务高峰时期，生产事务和统计分析事务不会对资源申请造成冲突，并且经过元数据的的形成，查询、统计、分析的访问数据量将会大减少。如果需要进一步提高业务的I/O，可以将统计库设计独立阵列。 [/B]

统计库分离也需要迁移数据,也要占用大量资源,在生产库做job 统计
会聚 数据还少了数据迁移的诸多问题,
包括数据结构升级, 你得升级两边的把,
再说 oracle 的 mv  , oracle11g的可读standby ,技术的变更,都会宣告多个数据库的时代漫漫终结.
医疗数据库如此小,性能如果是突出问题,大多是不良设计导致,关分区何事

winterkss

1、历史库不可取，把生产库数据清掉，迁移到历史库，在历史库出现性能问题时，又得考虑，是治本不治本；
2、生产与统计分析分离,不是分多库,数据信息的提取对资源的要求从两个方面来解决：一是分散，二是提取方式；不要简单的看成是把生产库的rows COPY到另一个库，元数据是有选择性的，跟生产库的结构没有太大的关联，统计分析要的是关键的数据。
3、我赞同系统逐步发展为“以存储为中心”建设：统计分析的原理类似HP、SyBase公司推的信息周期管理，不过他们的IFM就不是OLTP了，在当前环境下做事务分离还是能解决些实际问题。

fals

机器性能的提升能缓减业务对系统的压力，而且从目前的情况来看，个人感觉硬件性能和基础平台性能提升的速度比数据积累带来的性能压力要更快一些，也就是说，机器性能越来越好，但数据积累产生的性能压力并没有到机器性能满足不了的地步。从这个方面来讲，历史库的建立确实是要逐步退出历史舞台的。

但是请注意，硬件性能提升和基础平台性能提升是要花钱的，而且不是花小钱。做硬件的升级和基础平台（操作系统和数据库版本）也不是一个小操作，其中存在的风险也不能低估，因此，在实际的工程中不应该指望通过采购更快的机器，使用更高的数据库版本来解决性能问题，我倒是觉得，更应该立足于现有设备基础来解决性能问题。在这样的情况下，迁移历史数据到历史库中，对生产库减肥是提升性能最明显，代价最低廉的方法，也是风险最小的方法。

至于多建立索引对性能的影响，仁者见仁，智者见智。在实际的业务中，我们不可能为每一个查询条件或查询类型都建立一个相应的索引，如果某个查询不得不全表扫描，不分离历史数据就会带来严重的性能问题，有可能这个单一的，不常用的查询就会导致全系统响应缓慢。这是有有历史教训的。

我也见过程序员每做一个新的查询，发现有走全表就建索引，结果我就见过一个表一共才不到20个字段，索引就建立了十多个，我想这个表的insert,delete,update性能都不会高。而在实际业务中，这个表的insert 和update操作是比较多的。为一个查询的性能，牺牲了联机事务的性能，是否值得，也是需要考虑的。

关于分区表全局索引对系统性能的影响，我没有什么经验，是从道理是猜想的，当然有可能不正确。但我还是比较固执地认为，至少在目前的HIS应用阶段来固执地认为，期望通过建立分区表来解决数据积累带来的性能问题，是不太妥当的。

欢迎大家拍砖。

fals

至于统计数据的连续性问题，我想不同的系统有不同的处理办法。在“军字一号”系统中，统计数据是通过后台过程，将数据结果存放到统计中间表中的。建立历史数据库，迁移历史数据，不需要迁移这些统计中间表，仅仅需要迁移数据增长量比较大的业务明细表，比如门诊收费明细，门诊处方及处方明细，住院收费明细，医嘱相关表等，对统计查询的影响是比较小的。

迁移历史数据，并不需要全库的数据都迁移，而是根据实际业务来迁移数据的。这个过程，可以根据业务的变化而相应的变化，我想还是一种比较灵活的处理手段，也是一种比较低成本的手段。

fals

没人讨论这个话题了吗？我觉得挺值得讨论的啊

纯技术的问题，又不涉及什么商业机密，又不涉及哪家公司的好歹，正是可以大谈特谈的啊！

husthxd

一点意见：
关于历史数据的保留，其实跟分区表关系不大。
有两种方案：
1)        在业务表上加入“有效标志”字段，0-当前 1-历史 9-无效
优点：
        java程序处理方便，只对同一张表操作，无需书写额外的代码
        查询历史信息和无效信息只需要更改标志标志即可，通过持久层的封装统一处理
缺点：
        后台查询不方便，加入有效标志=x,才能区分有效、历史还是无效记录
        PL/SQL处理不方便，理由同上
        对于存在业务主键（业务唯一性约束）的情况，要保证有效标志＝0(当前)的情况下，保证唯一，目前Oracle有这样的机制实现，迁移到数据库，未确定使用数据库的机制是否可以实现
        性能损失，a)在同一张表保留历史和无效数据，日积月累会降低查询当前记录的性能，尤其是对于频繁修改的表，很可能会况会出现历史数据＋无效数据>当前数据的情况；b)降低使用索引的性能，对于某些存在业务主键的表，由于不能对全表数据建立业务主键上的唯一索引，只能建立普通索引，必然会导致性能的下降
        数据量特别大的表情况，出于性能上的考虑，不太合适

husthxd

2)        建立历史表，表结构跟原表一样，但需要加入
优点：
        历史、无效数据和当前数据隔离，不存在性能降低的问题
        可以在业务主键上建立唯一索引，不存在“有效标志”出现的问题
缺点：
        对每张需要保留历史记录的表都需要建立历史表