企业在数据库方面面临的现状是一个历史积累的过程，在这个过程当中我们的科技标准和需求在不断发展，同时数据库技术也是在不断发展，那么我们的梳理也是要从多个方面进行整体性分析，具体主要从以下几个维度来进行。
1） 数据库所承载的业务对数据层面的要求。主要为业务响应、业务负载特点等。
2） 数据库现有的架构状况。主要从实例的高可用架构、数据分布、存储架构等等方面来进行梳理。
3） 数据库本身的属性特点。包括数据库的版本信息、设计信息、数据库参数属性等方面。
4） 数据库的数据发展状况。主要从数据库的量级、数据膨胀速度、数据变化状况等方面进行梳理。
5） 数据库载体的资源利用状况。主要从硬件资源方面来分析其目前的合理性。
表 1 数据库业务特性梳理明细
表 2 数据库属性梳理明细
2. 问题分析及优化策略2.1 数据库发展过程中存在的问题
由于数据库的发展是由不同的历史阶段发展而来，不同的历史阶段其业务对数据的需求和不同历史阶段的产品及技术发展也有所区别，那么导致企业的数据库资源�ּ�,����整体发展呈现出很多问题，从第一章节的梳理过程来看，基于以上的分析，我们认为数据库存在以下几个问题：
1、数据库版本不一致，包括数据库的大版本信息和具体的集群及实例补丁信息。从管理上来讲，我们无法进行标准化的运维管理和资源管理。
2、资源分配不均匀，随着业务的发展变化，数据库在初始设计阶段所定义出来的一系列属性信息和资源的分配状况在面临众多变化的时候会呈现出极大的不均匀：有的数据库处于非常空闲的状态；有的数据库处于非常重的负载状态；不同的时间段对于资源的利用也呈现出极大的不平衡。
3、存储空间利用存在极大浪费，一方面由于存储架构的不一致性导致存储资源相互不能平衡，另外一方面由于日志和数据的极大差异性导致存储空间利用不能在时间和空间达到一个很好的平衡。
4、架构的差异性导致业务的连续性不能满足发展要求，传统的 HA 架构无法保障业务的绝对连续性，单节点的架构无法保障计算资源的高可用， VM 架构无法保障应用层面的高可用。
5、数据保护层面的多样化无法保障业务上的发展要求和管理上的便利性，有的数据库没有数据镜像，有的数据库采用存储的镜像模式，有的数据库采用的操作系统层面的镜像模式，有的数据库采用的是应用层面的 ASM 镜像模式。
2.2 数据库整合的基本原则基于以上分析，我们认为有必要对企业的数据库资源进行整合，以保障数据发展能够满足企业未来的业务发展和企业 IT 资源运维管理要求。但是对于数据库的整合必须依照科学合理的原则进行，具体说来本人认为在整个方案的执行过程当中需要遵循以下几个原则：
1、应用层面的整合为最优选择。
数据库本身是有事务性要求的，只有从数据库应用层面实现的整合才能保障数据库的事务性要求。从平台层面实现的整合是无法保障数据库本身的事务性要求的，也就无法保障上层业务的连续性。
2、业务的连续性要求或者重要性标签是我们进行数据库整合的第一依据。
我们不能将 A 类系统和 B 类系统整合到同一个只能符合 B 类要求的资源池当中，只能将其整合到可以满足最高要求的资源池当中。因为业务的特性是我们对数据库架构、数据保护策略、数据库属性配置等一系列规划的前提条件，因此在整合过程当中也不能突破这个前提。
3、业务重要性和负载是决定资源池归属的前提条件。
非常重要的应用系统以及负载非常重的应用系统，其数据库资源池的归属需要尽量与其他类型应用系统进行区分，其资源利用模式尽量采用独占模式。同要求业务类型的中轻量级数据库具备统一资源池的可能性，但是同时要满足其他整合的原则。
4、从业务负载在时间维度上的分布特点平衡数据库资源的配置方式。例如在满足以上 3 个原则的前提条件条件下，我们可以利用数据库负载在时间上的不均衡性去平衡资源使用上的共享性。
5、从业务灵活性和运维管理响应的及时性角度来分析资源池的整合策略。由于业务灵活性导致的数据库配置以及数据等需要变化或者快速部署升级的，如果满足其他原则的情况下，那么我们有理由将其作为同质资源整合到同样的资源池当中，同时也要考虑相对的逻辑隔离性要求。
2.3 整合后的数据库资源池架构那么基于 2.2 当中所述的原则，我们采用 Oracle 本身的资源池模式或者服务模式对不同的业务系统数据库进行统一整合后的架构应该是什么样的预期呢，我们认为主要分为三种基本架构模式。详细参见以下架构图：
图 1 重量级集群架构
对于负载极高，业务重要程度极高或者业务需求为相对独立的数据库系统来讲，我们拟采用单独的 RAC 集群架构，容灾可以采用 DG 方式来实现。那么随着配套的硬件资源要求也是独立的并且可以支撑相应负载需求的计算能力的服务器资源，例如：沿用小型机架构或者是计算能力非常强的服务器设备。配套存储也需要单独的逻辑视图和独立的卷组管理模式。
对于分析类的重量型数据库（例如报表类、报送类、分析类等），同样可以采用如此的架构，但是我们可以将业务的服务模式修改为主备模式，并且将业务系统平衡在不同的活动实例上。也就是说 AB 两个实例属于两套分析类业务共享的实例（从业务活动的时间差异上寻找资源的共享切合点），数据库存储属于相互独立的卷组管理模式，这样我们既可以保障高负载的处理能力，同时也可以计算资源在不同时间点上实现的资源共享。当然在硬件资源的选择上，这类数据库系统也可以选择面向数据库应用的一体机，具体选型完全取决于业务的负载量和分析结果的时间性要求。
图 2 中轻量级资源池架构
对于负载中等或者轻量级的数据库系统，我们可以采用资源池的共享模式。Oracle11g 之后的版本全部支持资源池模式。到了 Oracle12c 之后的版本同时支持了可插拔式的数据库模式，完全向着云计算的服务模式发展，非常适合我们对数据库的资源池整合。我们可以将多数具备同样业务需求规格，具体同样负载特点等属性的数据库放在一个通过多台服务器设备组成的共享资源池当中实现资源的共享。
对中轻量级资源池的配置来讲，资源池的自动化运维或者快速部署等方面也是我们对资源池整合的一个重要目标， Oracle12c 之后的版本完全具备 DaaS 的特性，通过其版本的改进特性以及相应的工具包，完全可以实现数据库云化的快速部署方式和灵活的批量化配置。
2.4 企业数据库资源整合规划方案基于我们对数据库系统的业务分析及配置梳理以及我们对数据库系统进行资源整合的基本原则考虑，我们最终形成数据库系统资源整合的具体规划方案，具体资源划分和资源池配置信息如下描述：
表 3 重量级数据库系统规划
以上几个系统整合为三个独立的资源池环境。其整合的结果是基于对负载、重要性、业务隔离性等方面的考虑，在不违背整合原则前提下选择的结果。
ebk_vcl 是一个同一个基于平台虚拟化之后组成的 RAC 集群资源池，其计算资源的平衡是基于平台虚拟化来实现。alp_cl 是同一套传统 RAC 架构下实现的实例层面的共享，主要原因是这两个分析类业务系统的业务能在时间分布上进行均衡。
表 4 中轻量级数据库系统规划
以上几个系统整合为两个各自独立的数据库资源池，整合方式完全是通过数据库应用技术（ Server Pool ）的方式实现。chl_pl 是一个由三台 X86 服务器组成的 Oracle 数据库服务器资源池，他们的架构设计要求完全是 A 类业务要求标准，对于三个不同类的渠道业务，我们分别从池中选择其中两个节点作为他们的服务实例。在这个资源池当中的所有数据库其存储视图模式完全是一个共享的模式。对于服务器节点数量的选择完全是基于业务在不同时间段上的负载分布来决定的。如果后续渠道业务持续扩展，我们可以持续加入新的资源节点来实现其动态扩展性。ota_pool 是一个以 B 类和 C 类业务系统为主的大数据库资源池，由 5 台通用 X86 服务器组成，同样根据业务的负载特点，我们会从服务器资源池当中选择适当数量的节点作为不同数据库的服务实例。同样在这个资源池当中的所有数据库其存储视图模式完全是一个共享的模式。
3. 方案的评估分析
通过以上的数据库资源整合规划方案，我们预期达到以下几个方面的收益：
1、现有硬件资源释放。通过资源池整合之后，在保障既有业务系统需求的前提下实现了服务器资源从 29 台到 18 台的批量释放。
2、未来硬件资源的合理使用。通过资源池的架构改造，数据库载体平台已经由传统的固定式架构修改为可以动态扩展并且继承原有资源池共享模式的灵活架构，那么资源的使用也会遵循节省模式。
3、数据库应用与硬件资源的解绑。资源池中所有的计算资源都是可以共享的，数据库实例可以通过服务定义的方式灵活实现客户端方案和具体服务器节点的解绑。
4、运维管理的统一性和标准化。版本走向标准化，资源池属性配置走向统一化，那么企业的运维管理也会走向统一化和标准化，快速部署之类的自动化运维也会随之推进。
4. 总结及展望
本文基于银行企业数据库系统的现状梳理及分析，以节约资源优化管理为目标，本着业务为先、技术支撑、统筹整合的基本原则对企业的数据库系统提出一套整合规划方案。该方案当中涉及到的资源可能仅仅是实际企业当中的一部分，但是对于现状的梳理和问题的分析基本抽象了大家的共性问题，所以基于同样的问题，我们可以套用同样的原则和方法论来进行具体整合项目的方案规划。对于企业的一些特殊问题，可能还需要大家本着相应的原则来具体问题具体分析。