近些年来，随着互联网的不断发展，金融企业增加了很多与互联网及数字化转型相关的业务，相对应的应用系统和数据库数据迅猛增加，数据库类型也变得多元化。这样的发展趋势造成两个方面的问题：首先，数据库在不断增加多元化的过程中，架构的稳健性和扩展性考虑不足，最终会导致系统的高可用性及业务的连续性不能形成一个标准化的发展模式而层次不齐；其次，在这个过程中很多可以进行整合的资源缺乏必要的共享和优化机制，导致企业的软硬件投资不断增加， IT 整体的 TCO 过高。因此，金融传统企业的数据库资源在不断发展的过程当中有必要进行有序化的整合。

在这样的背景之下，越来越多的金融企业开始探寻系统整合之路。有的是通过数据库软件层面实现资源池化的方式进行实例的整合，存储的整合以及相关计算资源的整合。有的是通过 OS 层面的虚拟化方式来实现数据库载体的整合。但是无论哪一种整合，承载数据库的框架平台还是依赖于通用的服务器，其高可用、计算能力、扩展能力会影响数据库资源的整合。

本次交流活动， twt 社区特别邀请了星联云服的技术专家和光大证券的资深工程师分享基于开放平台整合核心及重要数据库的解决方案，帮助大家解决整合过程中的难点和问题。以下是本次活动的核心议题：

1. 金融行业各个系统的数据库使用是否可以从标准化的角度来进行类型、版本、配置等方面的发展约束？
2. 数据库整合究竟应该从什么维度出发，整合到什么粒度？是应该从平台角度出发还是从数据库本身角度出发？是应该整合到实例还是应该整合到服务？
3. 数据库整合的过程是否也要进行分级？根据业务的要求不同，在高可用、扩展性、资源分享等方面如何进行分级？
4. 数据库在从服务化、动态化、细颗粒度等软件特性方面进行整合的同时，是否也应该从硬件平台上做一个合适的选择？
5. 数据库整合的整个生命周期，是否可以进行一个可持续的有序化的管理？

以下是本次交流的总结：

1 、数据库整合过程中，各类数据库的整合解决方案？

数据库整合过程中，比如 oracle 数据库，现在有租户 cdb 和 pdb ，可以有效的做用户之间的隔离，请问现在主流 db 的用户之间隔离的解决方案是怎么样的？如 db2 、 mysql 、国产分布式 db 等等。

icycastle 数据库管理员 , 某证券公司

oracle 数据库在 12c 多租户之前，都是单实例单数据， 11g 及以前版本都是通过创建不同的 schema 进行隔离的； db2 和 mysql 数据库本身都是单实例多数据库的结构，都可以创建不同的数据库进行隔离；

2 、各类数据库如何做到有效整合，整合后上层的应用对数据库的访问有何影响？

各类数据库如何做到有效整合，整合后上层的应用对数据库的访问有何影响？

赵海 技术经理 , 大连

随着企业 IT 的不断发展，那么系统越来越多，数据库也就越来越多。这样就产生了大量的关于资源利用的浪费问题、管理上的纷繁复杂以及人力资源上的冗余投入。于是产生了要对数据库资源进行整合的想法。 那么作为企业的 IT 部门，我们得回过头来考虑考虑数据库资源整合的驱动力在哪里？数据库资源整合的最终目标是什么？然后才能制定有序的整合方案和计划。

首先，我们得明确自身的数据库资源现状。数据库的数量、类型、版本、负载、数据量以及重要性等等。一般来讲企业的数据库与企业的应用系统基本呈正比趋势。那么这些数据库的数量一定是呈不断发展的态势；对于类型来讲，可能会以关系型数据库为主，非关系型数据库为辅的模式居多；对于版本来讲，可能同一种数据库多种版本并存的现场是司空见惯的；对于负载来讲，随着不同的应用系统场景不同，会有若干种区分；同样数据量也会因不同的应用场景会有巨大的差异。面对这些复杂的现状因素，我们如何往下进行？

接着，我们需要从众多的差异因素来对我们的数据库资源进行分级和分类。个人认为首要因素一定是业务的统一性。也就是说业务上的需求一致性是第一条件，因为只有业务上的统一性才能决定其架构高可用、资源使用以及其他方面的相通。其次是负载上和数据量上的平衡，也就是说当所有数据库的负载和数据量能在空间上和时间上进行充分的平衡，才具备整合的条件。如果这些因素在时间上和空间上都非常集中和一致，那么资源整合的必要性就没有了，就算整合了也会导致瓶颈问题。最后，我们需要从版本及类型等外在因素上进行分析，如果从业务和应用角度可以进行统一的，那么就应该用标准将其统一，因为只有这些特征上的统一才具备软件层面的整合条件。

以上是我们对要整合资源的分析统计和归类。当我们完成这个工作之后，接下来的工作自然是整合的具体策略和方法了。对于可以通过软件整合的资源，我们尽量通过数据库软件去进行统一整合，比如说数据库的资源池模式。通过合适的资源共享和限制策略以及合适的软件平台来形成一个数据库资源池。对于不能通过软件模式整合的，我们可以试图通过平台模式来进行整合，比如说某些数据库可以通过云数据库服务的模式代替，可以通过数据库平台的云化模式实现平台层的整合。

总而言之，个人觉得这个工作不是依靠某一个平台或者某一个产品就能解决的问题，是需要我们对现有资源进行深刻的业务分析和理解之后，然后选择合适的工具和方法因地制宜实现的一套综合式解决方案。

3 、对于亿级数据量的 oracle 数据库，应该如何备份？

oracle 数据库，数据量也太大了，如果是亿级的，备份怎么搞？

baizhaoxian 数据库架构师 , 万国数据服务有限公司

对亿级数据量的 Oracle 数据库备份措施为：
跟亿级数据量关系不大，跟数据容量有关：
策略一：全备与累积增备和差异增备结合。
策略二： Oracle 数据库合成备份。
策略三：全备和 Oracle 日志连续性备份。

赵海 技术经理 , 大连

这个问题，我觉得需要从两方面入手考虑。
首先，这个数据量是不是必须的？能达到这样的数据量，那么数据库里面的数据到底保留了多少历史数据？相信大部分都是历史数据。把这么大的历史数据和活动数据放在同一个表里面，一旦有全表扫描发生，查询性能会很糟糕。所以我认为首先得从业务层面去考虑是否可以采取合理的历史数据和活动数据的管理方法，不管是周期性归档还是其他有效方法，得先将两部分数据尽量切分。
其次，才是从备份层面的增量、日志、快照等方面结合着考虑大数据量的备份策略，因为历史数据和活动数据的量级、备份频度、恢复要求等各个方面的需求都不一样。我们需要根据不同的需求制定合理的策略。

4 、在云平台上部署的数据库，如果只是进行实例级的整合，好处是什么？

在云平台上部署的数据库，如果只是进行实例级的整合，好处是什么

telnet4730 数据库运维工程师 , 光大证券

** 实例级的整合一是得到了数据的完全隔离，另外如果存在实例级的维护，比方重启等 相互没有影响，另外实例的整合可以减少相互之间的影响， 避免频繁的缓冲读写 造成的 延迟读写 等性能问题及实例整合更容易控制各个内存的大小

5 、数据库系统是采用多个系统共用数据库的集中方式部署还是每个系统单独部署数据库呢？

随着金融行业业务种类的不断增长，要求 IT 系统的数量也不断增多，而每个系统必须相应的数据库系统支持，在这种情况下，数据库系统是采用多个系统共用数据库的集中方式部署还是每个系统单独部署数据库呢？集中方式部署的优点是维护方便、资源节省、投入较少，但不便于业务连续性管理，且风险集中并相互影响；独立部署优点是不存在相互影响，业务连续性管理方便，但是管理维护难度大、成本高、资源浪费多、投资大。面对这些问题，如何寻找平衡点就成为了一个难点。

telnet4730 数据库运维工程师 , 光大证券

在做这件整合这件事情之前，要清楚主要是为了什么，再此基础上做平衡，就会找到突破点。有的公司实例太多，服务器太多，维护人员少，运维工作繁杂效率低， 这时管理成本、硬件成本或者机房基础环境就是是公司运维工作的主要问题，那么这时整合就是一个好的途径，来解决这类主要问题；但是如果你的系统是核心系统，非常重要 那么你的业务连续性保障是第一的，那么独立部署我想就是唯一的选择。

6 、数据库整合的过程是否也要进行分级？

数据库整合的过程是否也要进行分级？根据业务的要求不同，在高可用、扩展性、资源分享等方面如何进行分级？

telnet4730 数据库运维工程师 , 光大证券

分级这个是必要的，因为整合要控制整体风险的影响范围，关于分类分级 各个行业公司都不同，业务系统按故障恢复时间点 RTO 、核心业务量 / 天、单笔平均资金量 等维度进行评估；管理系统按服务层级（公司级、业务条线级、部门级）、故障影响范围、连续性要求等维度进行评估 。根据等级的不同，配备不同的资源及相关投入 .

7 、企业的数据库类型： Oracle ， mysql ， sqlserver ， db2 等等针对这些多种数据库版本如何整合？

在大型平台级别的金融行业 IT 系统，对数据库进行整合已经是大势所趋，但究竟如何整合是既安全可靠，又省成本，省事呢？至少我存在一些疑问，比如公司的数据库类型有 Oracle ， mysql ， sqlserver ， db2,postgreSQL ， OceanBase 等； Oracle 版本有 11g,10G,12C;sqlserver 版本有 SQL2005 ， SQL2008R2 ， SQL2014 ， SQL2016 等； MySQL 版本有 5.1 ， 5.5 ， 5.6 ， 5.7 等； db2,pG,ob 等数据库也有不同的版本；单单就是数据库版本这块如何整合？

telnet4730 数据库运维工程师 , 光大证券

1 、没有非常完美的解决方案，数据库的整合每个产品都有自己的整合方案，甚至跨产品也有工具和方法，最重要是应用是否支持、是否配合测试 . 这个成本往往是很高的。单单数据库版本这块，本身技术不是问题，考虑比较多的是：低版本的系统的使用频度是怎样、新的服务器是否还支持老的版本，对于是使用少的低版本的老的系统，建议按实例虚拟化整合 , 可以做版本升级整合的就升级到一个版本进行 等等。 这么多的版本不能一概而论，一定要结合系统的实际情况进行整合， 一般金融行业对主要系统的版本都是有规范化要求的， 如果主要系统有这么多版本，是不是先从规范化入手。

8 、数据库整合究竟应该从什么维度出发，整合到什么粒度？

数据库整合究竟应该从什么维度出发，整合到什么粒度？是因该从平台角度出发还是从数据库本身角度出发？是应该整合到实例还是应该整合到服务？

telnet4730 数据库运维工程师 , 光大证券

首先要明确到底要解决什么问题，要搞清楚为了什么整合，整合的维度，个人经验还是从系统的重要程度出发，按照应用是管理类型（ olap ）还是在线业务（ oltp ）进行 区分组合。对于分析型的系统通常是体量大重 io 的库相对 oltp 连续性的要求较低，而平时的资源利用率又较低的系统，适合整合到一起。而 oltp 的系统一般体量小、随机读写较多，连续性要求高。应根据前期整合系统的运行情况来评估是否可以进行整合，整合的粒度包括数据库（ scheme 整合），实例级整合，虚拟化整合。通常情况下按 schema 整合设计到应用的改动稍大，按实例整合应用的改动通常比较少，整合的粒度还是要按照实际的情况权衡。 通常情况下 从数据库本身角度整合投入比较少，从平台的角度出发投入比较多。从长远来看 从平台的角度出发更好，平台的起点高，便于立项，通常这样比较成熟的平台（开放类）也比较多。个人认为对于企业来说并没有公有云那么多的需求，整合到实例已经基本满足需求，整合到服务一般投入比较大，而使用的频率有比较低，意义不大。

9 、如何有效避免集中度过高带来的负面影响？

整合过程中集中度的提高，如何进行有效的系统间资源使用隔离以及故障隔离，做到某一系统的故障失控不影响整体平台的运行。另外整合迁移中如何规避平台不同带来的对应用的影响，如基于 linux one 等专有平台，是否能做到完全对应用透明。

JasonZH 技术总监 , 星联云服科技有限公司

整合分很多层面，例如硬件资源整合、系统整合、数据库整合。在设计整合迁移计划的时候，需要涉及进行哪个层面的整合，设计层面的高可用，确保在资源出现问题时，可以快速隔离，不影响整体平台运行。我们通过 LinuxONE 进行整合，就是利用了 LinuxONE 平台的高可用性。硬件平台、操作系统、数据库这是三个层面的内容，由数据库向应用提供数据服务，因此底层的硬件平台的不同，对应用是完全透明无关的。

10 、单台 LinuxONE 整合多套数据库，高可用怎么保障、运维风险如何控制？

看嘉宾的文档里面有涉及到单台 LinuxONE 整合多套数据库，那么高可用如何保证？运维风险如何控制

JasonZH 技术总监 , 星联云服科技有限公司

LinuxONE 服务器采用了具有 50 多年历史的主机硬件架构。其通过 10 多代的研发，不断增加新的可靠性功能来不断减少资源不可用的情况。其高可用设计原理如下：

 通过研究前代的服务器 RAS 属性及实际效果，进行改进
 研究业界信息，获得相关 RAS 的参考
 理解可靠性技术（硬件和软件）的发展趋势，确保 RAS 设计可以有效满足这些要求
 增加 RAS 设计，包括硬件和微码，以此来给 LinuxONE 和客户带来独一无二的价值 .

通过 ITIC （ INFORMATION TECHNOLOGY INTELLIGENCE CONSULTING ）发布的全球服务器硬件操作系统可靠性报告可用看出， IBM 运行 Linux 的主机（ LinuxONE ）年化意外宕机时间只有 0.91 分钟，是业界最高标准。

由于 LinuxONE 机器内部部件都是采用 N+1 以上的设计，因此在但模块出现故障时，进行及时维修就可以避免由于出现双点故障引起的其他问题。这就要求在运维过程中，做到经常巡检，出现故障及时处理。

在金融行业，由于高可用需求更高，针对这样的场景还是建议上多台机器，减少运维风险。

11 、数据库整合后的管理问题，何解？

在进行数据库实例整合之后，项目组共用一台数据库主机，那么原先各项目组连自己的机器进行各自库的一些日常运维（备份、恢复等）现在变成大家共用机器。这时候的用户权限如何来进行更好的，更安全的管理。是分各自的 oracle 用户？
假如主要的生产环境都是 11g 的库，那么共用一台机器后不能进行各数据库实例的资源隔离，假设某库发生大量全表扫描可能引发 cpu 利用暴涨、大量 IO 吞吐等，导致影响到其他库，这些问题如何规避。

telnet4730 数据库运维工程师 , 光大证券

** 1 、两个角度，为了实现要是在系统上区分用户来备份恢复，通常比较复杂，也不利于管理， 整合后由专门的人来负责 备份恢复 相对比较安全 ， 对于有频繁的备份恢复的系统，通常这样的系统都有特殊的要求，比方安全、测试要求都比较高，建议暂时不整合。
2 、对于 11g 的整合，性能问题的规避，我觉得不是规避，应该是尽量减少，第一分析原来系统的性能基线 第二依赖于监控系统 。 如何在多实例的情况下快速的定位问题、解决问题也非常关键。比如如何快速判断是那个实例、那个应用、什么 sql 导致了性能问题， 这确实是个挑战，但是通过监控手段是可以快速发现的，比方说现在 cpu 使用高，我们可对比 db time 的走势和 cpu 利用率的走势，就可以很快的判断出那个实例正在消耗了较多的 cpu ，进而找到是那个应用的什么 sql ，最后快速的解决问题

12 、两个应用系统都是采用 oracle 数据库，字符集不一致，请问如何进行库整合？

两个应用系统都是采用 oracle 数据库，字符集不一致，一个是 gbk 一个是 utf-8 ，需要进行数据库整合，并且字符集统一成 UTF-8, 请问有无好的实施方案，既要控制成本，满足进度要求，又要保证质量

t elnet4730 数据库运维工程师 , 光大证券

用导入导出就可以解决

13 、 LinuxONE 相比 PowerVM 、 x86 虚拟化（ Vmware 、 KVM ），整合数据库方案的优势在什么地方？

JasonZH 技术总监 , 星联云服科技有限公司

1.LinuxONE 在整合数据库方案时，会使用逻辑分区技术，这个是微码层面实现的虚拟化技术，效率更高。
2.LinuxONE 单机容量更大，可以体现出资源池的优势，消峰填谷提供整机利用率。
3.LinuxONE 处理器主频更高， 4 级缓存，更适合处理数据库业务。

4. 商用数据库在 LinuxONE 上是由认证的，而在 x86 虚拟化上没有认证。 **

14 、 LinuxONE 与 PCserver 平台对于 Oracle 数据库的支撑优劣？

整合数据库对于硬件平台的选择，个人认为很重要，目前 IBM 强势收购 redhat ， linuxONE 的发展比较蓬勃，对于 LinuxONE ，据了解 LinuxONE 的价格仍然处于一个较高价位，希望张老师可以就 LinuxONE 和 PCserver 进行一些对比，通过实际的落地项目，阐述下 LinuxONE 与 PCserver 的差别，当然最好说明下 Oracle 在这两个平台上的对比结果。

JasonZH 技术总监 , 星联云服科技有限公司

稳定性： LinuxONE 与 PC server 的区别还是比较大的，从本质看 LinuxONE 是企业级服务器，有 50 多年的历史了。而 PCserver ，是由个人电脑发展过来的，虽然已经有很大进步，但仍不能提供企业级高可用。出现故障 LinuxONE 服务器可以进行在线维护，而 PCserver 基本上都需要停机。

性能： LinuxONE 服务器针对数据处理进行设计，高主频、 4 级缓存设计、系统协处理器等，同时 LinuxONE 服务器可以长期运行在很高的利用率。而这些都是 PC server 不具备的特点。

单机容量： LinuxONE 服务器单台最多可以配置 170 颗处理器，而最新一代可以提供更多的处理器。这都保证数据库的纵向扩展能力。

实际客户中遇到的两个问题： 1 ，客户的 14 台 PC Server ，平均每月有一次内存故障，对运维人员造成很大的压力。 2 ，客户的单体数据库太大， PC server 已经不能满足需求。

15 、传统数据库整合是否已经存在瓶颈，分布式数据库是否优于传统数据库，大大降低成本？

整合数据库，目前我们这使用的 Oracle 数据库，采用单库多实例的方式对外提供服务，但是个人认为纵使采用这种方式也仅仅是降低部分成本，而且对数据的要求也比较严格，处理的都是关系型数据，但是目前的业务发展趋于多元化，数据的来源越来越多，数据的格式也正在成多元化发展，想要依靠传统的关系型数据库的整合、调优做到成本的缩减，已经比较艰难，我们正在探索分布式数据库的使用，前段时间就在研究 green plum 这个数据库，据个人理解，该数据可以完美融合关系型数据，非关系型数据，接受 SQL 、 NoSQL 、 NewSQL 、 Hadoop 的使用，能够应对大数据的计算、分析，在研究的过程中了解其高可用性，但是我一直感觉这个数据库存在入口瓶颈，其客户端的访问全部通过 master 来实现，但是 master 貌似只支持主备模式，而其处理数据的 segment 有一个节点故障，那么整个数据库就会故障，当然你的 segment 可以创建多个镜像来保障安全性， 但是相对应的同等体量基础设备的情况下，其真实可用的资源又减少了，所以这种分布式数据库到底是提升了成本还是减少了成本，我很迷茫 , 我的问题是：
1 、目前传统数据库整合还能提高多少，到我们公司现在的状况，是不是就已经没有办法整合下去了（目前我公司采用一库多实例），如果能，有什么更好的方案；
2 、银行业是否可以接受分布式数据库的使用，并且是否能够应用到核心业务上；
3 、目前的分布式数据库，是否真正优于传统数据库，或者说在什么场景下（针对银行业务）优于传统数据库，是否能够大幅度降低公司成本。

JasonZH 技术总监 , 星联云服科技有限公司

1 、目前传统数据库整合还能提高多少，到我们公司现在的状况，是不是就已经没有办法整合下去了（目前我公司采用一库多实例），如果能，有什么更好的方案；

传统数据库整合，需要选择纵向扩展能力强的服务器，这样可以将更多的数据库整合到一起，同时也可以利用消峰填谷，提高整机的资源利用率，降低成本。 LinuxONE 服务器会是一个很好的选择。
2 、银行业是否可以接受分布式数据库的使用，并且是否能够应用到核心业务上；

分布式领域 CAP 理论， Consistency( 一致性 ), 数据一致更新，所有数据变动都是同步的； Availability( 可用性 ), 好的响应性能； Partition tolerance( 分区容忍性 ) 可靠性。而银行业对数据一致性和性能都有很高的要求，因此分布式数据库不适合核心业务。
3 、目前的分布式数据库，是否真正优于传统数据库，或者说在什么场景下（针对银行业务）优于传统数据库，是否能够大幅度降低公司成本。
在大规模的查询业务场景下，分布式数据库可以发挥其优势。至于是否真的能降低成本，这个需要根据规模进行评估，包括由于使用分布式数据库带来的人员及运维成本都需要考虑在内。

telnet4730 数据库运维工程师 , 光大证券

为确保不受彼此的影响，必须根据 工作负载和服务器资源的基线 及实际的需要分配服务器的内存。 固定每个实例关键内存的大小 主要的参数也要设置下，比方内存 sqlserver 建议设置 maxserver, 在 cpu 的的分配上 sqlserver CPU 关联掩码配置 ，而 db2 instance memory 不自动调整， oracle sga 的值也安需要分配下。固定关键内存的大小。关于 cpu 的使用，要对整合前的 cpu 使用率进行分析，保证整合后的 cpu 利用率不能太高。 在 io 层面 可以使用不同的存储池。 详细的依据与整合的数据库类型和整合的硬件平台是怎样的。 最大和最小资源 有些内存可以动态调整，但是 cpu 和 io 的资源都是预先分配好的，一般不方便调整

jasonZH 技术总监 , 星联云服科技有限公司

从 LinuxONE 硬件的角度来回答一下您这个问题：

LinuxONE 的逻辑分区在进行配置过程中，可以设置使用 CPU 的数量以及 weight 值，其实 CPU 数量是能使用到的最大数量，而通过 weight 计算的值，是这个分区的最低保障值。可以参考《某银行 29 套数据库业务系统规模化整合最佳实践》。同时 LinuxONE 的处理器和内存可以在线进行动态调整，这样在有需要的时候，可以保证有足够的资源来支撑业务。

16 、 linux 数据库服务器如何实现高可用？

目前我行数据库服务器下移，一般情况下数据库还使用单机运行，部分系统数据库通过虚拟化的方式实现了硬件高可用。但是无论是 X86 裸机还是虚拟机，在 OS 层的高可用还没用保障，目前业内有 Rose 等高可用软件，但是据了解这些软件还没有像 PowerHA 软件成熟，因此我们没有采用。请问如何保障 linux 服务器上数据库服务器的高可用，尤其是虚拟机上数据库服务器的高可用（数据库集群技术除外）

张文正 系统工程师 , 神州数码系统集成服务有限公司

用 linux 自己带的 RHCS 集群软件或者 ibm powerha for linux 版本的都可以

JasonZH 技术总监 , 星联云服科技有限公司

Linux 上面有 Linux-HA 软件。如果您使用 SuSE 系统，可以使用 SuSE HAE 的。同时 IBM 也有 TSAMP 软件，可以提供高可用。

michael1983 技术经理 , 某证券

我们用 RHCS 来做，如果数据库有就用数据库的

17 、数据库的整合不仅数据库问题还涉及到硬件资源，整合方案设计应该如何兼顾这些？

数据库的整合应该远远不是数据库的问题，更涉及后台硬件资源池（ CPU ，内存，磁盘存储等），网络资源，安全资源，监控告警，审计留痕， cdp 恢复，核心系统故障追踪回放等切实需求，鉴于这些难题，如何整合数据库是比较系统的工程，如何整合才能兼顾这些问题呢？

telnet4730 数据库运维工程师 , 光大证券

这些确实是需要梳理的，但也没有那么复杂，关于硬件资源 （ cpu 内存网络）是在整合前做评估的，整合的前提是性能的 sla 不降低 ，配置的服务器按需配置就可以了。网络、安全、审计和监控 都可以嵌入到现有的运维规范和监控系统中，比方网络资源如果原先网络区域不同，那么跨区域的整合，一般是不符合规范的，自然没有办法整合， 比方说审计也可以沿用老的方案。 关于故障追踪依赖于监控系统和运维人员的经验，可以通过市场上整体的产品解决方案来解决。例如判断到底是那个实例占用了 cpu ，可以对比 db time 和系统 cpu 的走势来判断是那个实例，要快速解决这些问题，要整套的监控工具或方案如 maxguage 、 Prometheus 。总之需要综合评估系统的重要性及实际的需求来得到符合实际需要的整合方案

JasonZH 技术总监 , 星联云服科技有限公司

数据库整合是一个系统工程，因此需要一个详细的方案，从多个层面去进行梳理并完成整合计划。

通常需要对现状进行收集，收集信息包括后台硬件资源池（ CPU ，内存，磁盘存储等），网络资源，安全资源，监控告警，审计留痕， cdp 恢复，核心系统故障追踪回放等。

然后针对现状，进行分层次设计 :

硬件资源池：包括整合后的配置，监控（和监控平台 / 审计平台对接），高可用

网络：包括整合后的配置，监控（和监控平台 / 审计平台对接），高可用

系统：配置参数，监控（和监控平台 / 审计平台对接），高可用

数据库： 配置参数，监控（和监控平台 / 审计平台对接），高可用

其他：包括安全，监控平台，审计平台等。

在每层设计过程中，需要考虑现有的问题，并针对性的解决这些问题。

18 、如何避免集中度过高故障发生时影响范围过大的问题？

整合集中度过高后，即使通过系统层数据库等手段实现接管，但均会存在对业务的影响，整合前故障限定在部分系统，整合后如何避免故障发生时影响范围过大的问题。

telnet4730 数据库运维工程师 , 光大证券

另外一般公司的系统都会按重要程度分类分级， 应根据重要性来评估整合的可行性和分险。整合后故障的影响范围的大小应在整合前做评估。另外现行的市场产品可以实现自动切换，也可保证切换的时间。 主要看你的投入，一般情况下影响范围是可控的。

JasonZH 技术总监 , 星联云服科技有限公司

进行数据库整合，需要设立好目标，确定整合范围，期待获得什么样的效果。在确定范围的过程，就是对数据库的重要等级的梳理过程，通过对业务的影响来判断是否适合整合，通过什么样方式进行整合。在方案指定的过程中，就可以确保影响范围可控

icycastle**

数据库管理员 , 某证券公司

19 、基于日志复制的数据库灾备技术，如何考虑备机整合？

基于日志复制的数据库灾备技术，如 Db2 的 HADR ， Oracle 的 ADG ， mysql 的 bin-log 复制，很多备机的角色就是纯备机，只读功能也只是摆设，这样放着资源利用率很低，是否有备机整合的一些思路？大家有什么好的建议？

lsx 信息技术经理 , 大唐控股

只读的库至少可以做 bi 的数据源吧？如果开发能配合做到读写分离，那么适当调整分表分库，性能有提升数量级的可能。

bjzhangsq 产品经理 , sinodata

基于日志的备份方案，还是要配置 hacmp ，以实现自动切换接管。可以在 hacmp 中部署其他的 application group ，实现备机复用。 hadr 比纯 db2 + hacmp 优势是快速切换接管。如果考虑业务复用，还是建议考虑 cdc 这类跨平台数据库传输抽取软件。

JasonZH 技术总监 , 星联云服科技有限公司

您的这个思路很好，使用一台备机进行一备多的配置。还有一个 LinuxONE 的思路，供您参考。生产和灾备机器采用不同配置。例如生产配置 10 颗处理器，灾备配置 2 颗处理器及 8 颗 CBU 处理器，在生产出现问题后，可以将 CBU 激活，满足生产的需求。

20 、采用数据库软件建设数据库资源池有什么注意点？

采用数据库软件建设数据库资源池，比如使用 db2 purescale 搭建集群，使用单实例多数据库的结构整合一批数据库，这样的架构在实施时需要注意些什么

telnet4730 数据库运维工程师 , 光大证券

1 、应用要测试，要稍作修改。
2 、整合前的性能基线要分析，应对原有系统运行情况又足够的了解，对目标系统根据实际情况配置合适的硬件。

21 、 数据库整合后的好处显而易见，但是如何考虑版本升级或者 bug 问题呢？

数据库整合后的好处显而易见，但是如何考虑版本升级或者 bug 问题呢？会不会因为某个 bug 或者版本升级时，出现影响一大片业务情况的出现呢？对实时性交易比较敏感的行业的影响还是挺大的。
应该如何考虑这个问题呢？

telnet4730 数据库运维工程师 , 光大证券

版本升级和 bug 的问题无论是否整合都会出现的，版本的升级因该遵循公司的升级测试策略，只是要协调维护的时间。另外 bug ，如果数据库按照 schema 或 db 整合，有可能出现全局的问题，影响也会很大。 如果按照实例整合， bug 影响会较小。 对于实时性敏感交易，我的建议是不整合，因为它的连续性和可用性是有很高要求的。 容不得有不相关系统产生影响