数据库系统整改是指对数据库系统的软硬件运行环境进行调整的过程。数据库系统在其生命周期过程中都会经历大大小小的整改，对业务的影响大小不一，通常情况下都需要关闭业务后进行。对于连续性要求极高的医院信息化系统，数据库系统整改影响较大，这就要求整改过程要做充分的准备，并且进行有效的测试和确认，还要有可行的回退机制。
对于数据库系统整改的分类可以按停机时间长短来分类，如需要超过半小时停机的整改，还有需要半小时以上的整改；也可以按改动的大小来分类；也可以根据整改的具体类别来区分，本文侧重介绍数据库系统的整改具体类别。一般来说数据库系统的整改可分为数据库软件版本升级，服务器和存储割接导致的数据迁移，数据库参数、操作系统参数及其他配置参数的变更，数据类型的修改和重定义，历史数据归档，访问优化性整改六大部分。作为最常见的数据库系统变更类型，数据库软件版本的升级是最为典型的，通常来说软件版本的升级影响最大，不可预知的因素最多，需要的测试工作量最大，回退的难度也是最大的。一般来说如果不是特别的需求，都不会轻易变更数据库系统软件的版本，只有当数据库软件已经超过官方支持期限而且又遇到很多bug而必须升级，或者是应用软件的升级需要数据库软件也要进行升级时才进行数据库版本的升级。数据软件版本的升级需要进行严格的测试并且选择停机时间最短的数据迁移方式，对于实施方的技术要求较高，一般情况下是作为项目形式由第三方公司进行。数据库系统在使用生命周期过程中可能需要进行多次的数据迁移。数据迁移的原因很多，如数据库软件版本的升级就可能造成数据迁移，最常见的是由于服务器和存储割接造成的数据迁移。一般来说由数据库软件版本的升级造成的数据迁移可以归为第一种类型，而我们常见的由于服务器和存储割接造成的数据迁移如果不涉及数据库软件版本和操作系统平台的变化，其实施难度还是要小于前一种的。此类的数据迁移最需要关注的是数据迁移的时间，如何减小停机时间是考虑的关键。数据库系统在使用生命周期过程中经常会遇到数据库参数或者操作系统参数以及其所在的环境的变更，例如将数据库参数修改成更大的值以优化性能，修改操作系统的参数以优化内存和I/O性能，增加数据库的组件模块等。此类的修改通常变更难度较小，而且回退也最为容易。数据类型的修改和重定义在数据库系统的使用过程中非常常见，尤其是应用系统还在完善过程中及应用升级都会需要。对于数据类型的修改和重定义大多都可以在线进行，不需要系统停机，有时仅需要暂停部分受影响的业务。通常情况下此类修改由应用开发商负责测试和实施，医院信息科需要对其进行监督，要求其必须在测试环境上进行全部的修改和重定义测试，只有经过确认后才能在正式环境进行变更，千万不能因为修改的动作小而放任应用开发商自行处理变更。当医院的数据库系统经过五年乃至更长时间的使用后，会沉淀很多历史的数据，这部分历史数据通常情况下访问的次数相对已经很小，如果不进行迁移就会因为数据库过于庞大而影响表的访问效率。对于影像系统此问题更为突出，由于存储空间不足而面临必须归档的局面。但由于国家法律对医院病史病案及病人影像图片的保留时间有要求，又不能直接删除掉历史数据，这时候需要必要的手段进行历史数据的归档。对于历史数据的归档，在数据库层面和存储硬件层面有很多成熟的技术方案可供参考。通常医院数据库系统的历史数据归档需要作为一个单独的项目实施。对于仅将个别表的数据进行归档的需求，作为日常的普通变更来实施时，也要注意归档数据的方式方法和经过严格的测试，避免对生产系统造成不必要的影响。当数据库系统的访问出现性能瓶颈时，可能需要对数据库进行访问优化性整改。对于数据库系统的性能调优，在第三节已经有详细的介绍。当性能调优的方案是决定要对数据库的数据结构，数据分布及数据库的优化器进行调整时，会需要用到访问优化性整改。通常包括表重建，索引重建，表的统计信息收集和执行计划调整等。此类整改由性能调优的方案提出方提出并实施。对于此类整改必须要在测试环境上进行测试，确认整改可以达到改善和提高数据访问效率，并且需要衡量整改需要的停机时间可以接受后才能在生产数据库中进行优化性整改。所有的数据库系统整改严格上来说在正式环境上部署前都需要进行测试工作。测试目的就是为了早发现，早处理。很多数据库系统在整改后出现的问题90%可以在测试中发现，但测试工作却很容易被忽视或者是走过场。整改测试的步骤通常包括测试环境准备和测试过程。对于如何进行测试的方法、工具、样本和次数，要根据数据库整改的类型和目标来决定。这里主要介绍测试的思路，数据库系统的整改测试包括整改目标测试，功能测试，性能测试和安全测试四部分。测试环境的搭建通常来说需要与生产数据库相同的数据库版本和操作系统版本。对于割接和迁移类整改来说软件版本与生产库不同，测试环境等同于以后的正式环境。从正式的数据库系统中导入需要测试的数据，根据测试的目标大小决定，有可能是全库的数据，也有可能只是一张表，也有可能不需要生产的数据，只需要一个无数据的环境。在完成了数据的准备之后可以开始测试工作，首先要进行的是整改目标测试。这项测试主要是测试数据库整改方案的可行性和效果。只有此项测试能够实现后才表明数据库整改方案具备初步的可行性。测试的每个步骤都需要整改参与的各方进行效果确认并且生成记录。在通过了整改目标测试后，初步的整改方案已经形成雏形。接下来的测试主要是检验数据库系统在整改后的表现，以确保数据库系统整改产生的影响在可以接受的范围内。功能测试主要是检测数据库系统的可用性，包括数据库的可连接性，数据库的高可用性以及应用功能的可用性。其中应用功能的可用性是测试的关键环节，应用测试需要组织业务人员对所有的应用业务功能做全体测试，确保及时的发现和修正应用功能的问题，从而可以避免和减少整改上线后遇到的问题。数据库系统的性能测试是检验新的数据库系统是否能承担上线后的压力。通常性能测试需要借助测试工具，目前市面上有许多的类似工具。1. 数据库事务处理压力测试 数据库的事务处理能力是衡量一个新的数据库系统的性能的关键指标。比如能够检验数据库的事务处理能力的压力，关键性的指标是每秒传输的事物处理个数（transac-tions per second，TPS）。2. 数据库连接数压力测试 对于数据库的连接数压力测试是检验数据库系统在上线后是否能够承担目前的连接业务量的关键指标，同时也对连接数的上限作出预测。这项测试可以通过专业级测试软件来进行模拟，不过此类软件是需要付费的。也可以编写一个小程序模拟反复连接数据库来实现。3. 业务模拟压力测试 业务模拟压力测试是通过数据库操作来检验数据库的响应能力，包括I/O响应速度，数据插入速度等。这项测试可以通过创建一张数据库表，然后往里面插入数据来检测插入速度。通过创建数据文件来检测I/O速度。也可以利用专业级测试软件来进行模拟真实的业务操作，检验新的数据库系统在应用业务压力下的表现。安全测试主要检验数据库系统是否存在安全漏洞以及进行预防性措施。通常这项需要第三方监理机构来进行，如果条件不成熟也可以使用专业的漏洞扫描工具或者聘请专家检测。数据库及操作系统漏洞扫描测试，检测数据库和操作系统是否存在严重的安全漏洞，通过专业的漏洞扫描工具或者聘请专家检测来发现，提前补上安全漏洞；检测数据库及操作系统用户及角色权限，对新数据库及操作系统的用户口令进行管理，配置密码长度，有效期和复杂度要求等，关闭和禁用不经常使用的用户账号；检查数据库及操作系统的用户权限是否过大，回收超时使用范围的权限；同时考虑是否需要打开数据库审计，对数据库中的操作行为进行记录，如果医院内已经使用其他的安全设备和软件，如堡垒机、防火墙和准入系统，可以与新搭建好的数据库系统进行安全联动配置，一来是为了提高安全性，二来也是为了避免安全设备影响数据库的正常运行。
