XXXXXXXXXXXX平台数据库升级方案XXXXXXXXXXXXXXX有限公司2016年11月28日目录1. 概述 (4)1.1. 背景 (4)1.2. 目标与目的 (4)1.3. 可行性分析 (4)1.4. 参考依据 (5)2. 数据库高并发方案 (5)2.1. 数据库均衡负载(RAC) (5)2.2. 数据库主从部署 (8)2.3. 数据库垂直分割 (9)2.4. 数据库水平分割 (10)3. 二代办公平台数据库优化设计 (11)3.1. 数据库集群 (11)3.2. 重点业务表分区 (11)3.3. 任务表历史数据分割 (12)3.4. 数据库表结构优化 (12)3.5. 数据访问优化 (12)4. 实施方案 (13)5. 工作量及预算评估 (14)5.1. 工作量及预算评估 (14)5.2. 其他费用 (15)1.概述1.1.背景随着XXXXXX平台及其他子系统业务量增多，且用户已面向各地州市，用户数量增大，现有的二代办公平台及其他子系统在单一环境下的架构体系和数据库架构体系也无法高效的满足这样的场景。

当前XXXXXX平台及其子系统通过搭建多台WEB服务器和双机热备份的方式进行部署运行。

虽已提高了整体效率，但对于部分的业务处理还是未解决。

部分业务量并发处理多，业务关联多等因素，导致对数据库并发处理的业务量大，读写量大等也无法用双机热备份进行解决。

因此，在此背景下提高数据库访问效率，增大访问吞吐量等将成为二代办公平台及其子系统运行顺畅的关键因素。

1.2.目标与目的目标：依托现有系统服务和设备环境，建立可扩容、高并发、高吞吐量的数据库架构体系。

目的：为缓解当前XXXXXX平台机器及其他子系统对数据库访问过大，造成的访问效率低下的问题，提升数据库访问效率和并发效率。

对部分业务繁杂的表和访问进行优化设计，缓解因此造成的使用效率低下问题。

1.3.可行性分析数据库性能分析：根据当前的数据库性能分析，当前硬件设备的提高也无法满足数据库性能的提升，因此应考虑数据库访问控制和数据访问方面进行优化。

现有的数据库虽也实现双机热备份，但访问的效率未较大改善，因此应考虑各健全的数据库高并发访问方案。

数据库优化分析：当前的数据库采用的ORACLE数据库，同时，现有的均衡负载、读写分离、数据分割技术较为成熟，在对系统进行适当调整和优化的情况下，能保证系统的正常运行。

1.4.参考依据《Oracle RAC核心技术详解》2.数据库高并发方案2.1.数据库均衡负载(RAC)RAC，全称real application clusters，译为“实时应用集群”，是Oracle 新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。

Oracle RAC主要支持Oracle9i、10g、11g版本，可以支持24 x 7 有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。

在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。

当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。

RAC是一种并行模式，并不是传统的主备模式。

也就是说，RAC集群的所有成员都可以同时接收客户端的请求。

RAC具备以下特点：双机并行：RAC是一种充分利用服务器资源的高可用性实现方案，RAC的并行模式实现方式与传统的双机热备实现方式截然不同，图1-1是两者的比较。

如图1-1所示，两个节点在传统的双机热备环境中，始终有一台机器作为备用机，只有当主节点出现问题的时候才会切换到备用机上;如果主机一直没有出现问题，那么备用机始终处于空闲状态，这在资源的利用上以及成本方面都是巨大的浪费。

但RAC是一种并行模式的架构，也就是说，两个节点的集群节点间是一种并行运行的关系，当一台机器出现问题，请求会自动转发到另一台机器，没有任何一台机器作为备用机一直不被使用，这样就充分利用了服务器资源。

同时，传统的双机热备构架在出现问题时，常常需要数分钟的切换时间，而RAC在出现问题时，针对存在的会话只需要数十秒的时间就可以完成失败切换过程，对新会话的创建不会产生影响，在切换时间上也有比较大的优势。

▲图1-1 双机热备与RAC并行模式对比高可用性：RAC是Oracle数据库高可用性解决方案。

高可用性包含两部分的内容：首先是在这种解决方案下要确保数据不丢失，这是最基础的也是必须要保证的;其次是确保不停机，使Oracle数据库一直维持在正常的运行状态，避免停机给客户带来的损失，这是讨论最多的内容。

停机一般分为两类，计划停机和非计划停机。

所谓计划停机是有计划地安排节点或者系统的停机，一般在Oracle升级、系统维护或者硬件维护的情况下会出现。

非计划停机就是在非人为计划的情况下突然停机，这种情况一般是在Ora cle bug、系统故障、硬件故障或人为操作失败的时候出现。

在没有较高花费的情况下，想实现系统100%的不停机几乎是不可能的。

表1 -1列出了特定百分比高可用性比率运行停机的时间，详细记录了每种高可用性比率每年、每月、每周可以出现最大的停机时间。

通常情况下，以每月停机时间来计算对应的可用性比率。

根据系统的重要性情况，应该为系统设定合理的可用性比率。

集群最大的优势在于它的高可用性，通过使用RAC可以在一定程度上避免因为硬件或软件故障引起的数据丢失和非计划停机，并在一定程度上减少或排除计划停机时间。

这是很多客户选择RAC的最直接原因。

RAC中包含了非常多的高可用特性，主要包含如下几点：·实现节点间的负载均衡。

·实现失败切换的功能。

·通过Service组件来控制客户端的访问路径。

·集群软件能够自动化管理各个资源，并且有定时的节点状态检测机制，能自动对一些失败的进程以及心跳检测失败的节点进行重启，使其重新恢复到正常的运行状态。

在Oracle 11gR2版本中，Clusterware得到了改善，提供了更高的可用性。

例如，大量新的基于代理的监控系统用于监控所有的资源。

这些代理使用更少的资源执行更频繁的检查，即更快速的失败扫描和更短的恢复时间。

在Oracle监听的例子中，平均失败扫描时间从5分钟减少到30秒，同时，检查间隔从每10分钟减少到1分钟。

另外，Clusterware的“Out-of-Place Upgrade”等特性也减少了软件维护需要的停机时间。

易伸缩性：RAC为需要重新规划的应用提供了易扩展性。

为了在系统初始阶段保持较低的成本，避免造成不必要的浪费，集群可以按照标准硬件配置，选择适当的服务器资源、存储资源来搭建数据库环境。

当系统需要更多的处理能力或者需要增加存储时，通过添加另一台服务器或存储设备到集群中，能够在不停机的情况下获得水平的扩展。

在一个集群中， Clusterware和RAC支持多达100个集群节点。

当某个集群的处理能力过剩，另一个集群的处理能力不够时，可以从处理能力过剩的集群移动一个节点到处理能力不够的集群中。

这样能够充分利用服务器资源，节约成本。

11gR2版本中推出了网格即插即用(Grid Plug and Play，GPn P)，可以实现节点的快速添加。

低成本：通过多台普通的PC服务器组成一个集群，可以提高集群的处理能力，这样要比采用一台高性能的服务器的成本低很多。

如果想提高系统的处理能力，给集群添加节点比为高性能服务器添加硬件要容易得多。

另外，使用集群还能动态地移除节点，更加充分地利用管理者掌握的所有服务器资源，从服务器整体使用上降低了服务器的采购成本。

越来越多的企业愿意将集群解决方案应用到他们的系统中，以降低成本，提高系统的可用性。

高吞吐量：RAC是由多台服务器构成的逻辑主体，比单台数据库服务器能接收更多的客户端请求。

这在要求高吞吐量的系统中，能够得到非常明显的体现。

在RAC的架构中，多个实例分布在多个服务器上，能同时打开同一个数据库，而每个实例能够接收相等数量的客户端请求，这样，随着服务器的增加，吞吐量也在不断地增加。

2.2.数据库主从部署主从复制：几乎所有的主流数据库都支持复制，这是进行数据库简单扩展的基本手段。

Oracle的主从复制可采用DataGuard技术,DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。

DataGuard提供了三种日志传输（Redo Transport）方式，分别是ARCH 传输、LGWR同步传输和LGWR异步传输。

在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（Maximum Performance Mode）、最大保护（Maximum Protection Mode）和最大可用（Maximum Availability Mode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。

读写分离：读写分离是架构分布式系统的一个重要思想。

不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。

针对业务类型特点，需要从架构模式上进行一系列的调整，比如业务模块的分割，数据库的拆分等等。

2.3.数据库垂直分割主从部署数据库中，当写操作占了主数据库的CPU消耗的50%以上的时候，我们再增加从服务器的意义就不是很大了，因为所有的从服务器的写操作也将占到 CPU消耗的50%以上，一台从服务器提供出来查询的资源非常有限。

数据库就需要重新架构了，我们需要采用数据库垂直分区技术啦。

最简单的垂直分区方式是将原来的数据库中独立的业务进行分拆（被分拆出来的部分与其它部分不需要进行Join连接查询操作），比如WEB站点的BLOG和论坛，是相对独立的，与其它的数据的关联性不是很强，这时可以将原来的数据库拆分为一个BLog库，一个论坛库，以及剩余的表所组成的库。

这三个库再各自进行主从数据库方式部署，这样整个数据库的压力就分担啦。

另外查询扩展性也是采用数据库分区最主要的原因之一。

将一个大的数据库分成多个小的数据库可以提高查询的性能，因为每个数据库分区拥有自己的一小部分数据。

假设您想扫描1亿条记录，对一个单一分区的数据库来讲，该扫描操作需要数据库管理器独立扫描一亿条记录，如果您将数据库系统做成50个分区，并将这1 亿条记录平均分配到这50个分区上，那么每个数据库分区的数据库管理器将只扫描200万记录。

2.4.数据库水平分割在数据库的垂直分区之后，假如我们的BLOG库又再次无法承担写操作的时候，我们又该怎么办呢？数据库垂直分区这种扩展方式又无能为力了，我们需要的是水平分区。