2017年3月，我们终于迎来了Oracle 12cR2，作为国内首批Beta测试用户，我们在2016年1月应邀进行Oracle 12c Sharding 技术测试，并于去年10月完成了12cR2 Sharding 预研报告。由于受Oracle新技术发布限制，直至今日才发布与各位分享。

在Oracle 12cR2之前的版本中， Oracle分区表的所有分区都是在一套数据库中，而Sharding技术，则是使用新的分片技术可以将不同的分区部署到不同的数据库（后面称之为分片节点），而这些数据库都是相互独立且没有地理位置的限制。Oracle宣称这种分片架构具有以下特性：

• 支持数据水平分片，支持数据海量扩展

• 支持按地理分布、内网部署、公有云或混合云部署方案

• 支持全面故障隔离

• 每个分片节点具有独立的硬件资源(CPU、内存、硬盘等)

• 支持弹性扩展和自动重分布（Auto Rebalancing）

• 自动部署（Auto deployment）

Oracle sharding技术下的sdb架构（shared database architecture），包括：shard Directors（分片路由器GSM）、shard catalog（分片目录库）、shardgroup（分片组）。

1. shard catalog目录库主要作用

• 存储sdb的元数据

• 协调数据库

• 分片表的元数据定义和复制表存储

2. Shard director分片导向器主要作用

• 提供从应用层到分片连接请求的路由导向

• 跨数据库服务故障切换和管理

• 连接时负载均衡

3. Oracle Routing（两种模式）

• session-based Routing

所有的事务都只连接到一个单一的shard进行操作。

• Cross-shard 模式

适用于报表类的查询

事务需要跨多个shard执行操作

4. Sdb模式下oracle的连接请求方式分为两种

• ucp：带shard key的连接请求，sdb数据库是依据shard key来划分shard的，当我们使用shard key进行操作的时候，连接池会将该链接请求发送到正确的shard库中并建立链接。

• 如果没有sharding key，sdb会将连接请求交给catalog库，它会将目标sql解析并路由请求到正确的shard库。

环境准备：测试环境使用三台虚拟机进行测试，分别为：shard0(GSM和shardcate)，shard1（sh1），shard2（sh2）。

软件要求：12.2.0.0.3及以上版本。

1. GSM软件部署

第一步修改环境变量如下：

第二步解压缩GSM.zip包并且执行runInstaller脚本（这里使用了图形化界面）

直接点下一步（检查操作系统是否符合安装条件）：

点next下一步：

点击install，这样GSM包就安装完成了。

后续的数据库软件安装就不展开介绍了，选择NO-CDB选项即可。其他均与之前版本没有任何区别。

2. shardcate库上用户及相关权限操作

3. shardcate上配置remote scheduler

4. 分片库信息注册

5. 配置GSM

此时一套测试的sdb搭建成功，由于环境有限这里没有做容灾，Oracle提供了OGG和ADG两种方式对shard节点做容灾并且也支持一键部署。

根据Oracle官方对sharding的应用场景介绍描述，Oracle分片技术主要适用以下场景：

• 面向 OLTP 应用场景

• 为了优化性能应用程序应该使用分片键

• 业务场景中 80% 的事务都基于单个分片操作

• 跨分片操作目前版本支持并不完善

对于已知的分片技术使用场景限制，结合浙江移动的业务特点，最后选择客户中心做为本次的测试模型，由于存储资源有限我们选择了数据量相对较小的湖州地市作为测试地市。

客户中心业务简介：

1. 客户中心储存的数据来源于原CRM系统中的三户信息和用户订购信息，承载的是客户管理业务；

2. 三户信息的核心是用户信息表，其中用户信息表的业务入口是bbb_id，在获取bbb_id和uuu_id的对应关系后，后续都是以uuu_id为主，查询到相应的uuu_id对应的ccc_id/aaa_id的信息，再根据ccc_id和aaa_id的值去查询对应的客户和帐户信息，而用户的订购信息都是根据uuu_id来查询的；

3. 对所有前台或用户发起的针对单用户的业务中，基本能保证这些业务都是在同一个分片内操作；

4. 用户信息会随着系统承载的用户量的增加有所增长，但这种增长的速度不是海量的扩展速度。

测试结果：所有的业务操作大致可以分为以下这三类：

• 单分片查询

• duplicate表查询

• 跨分片查询

针对基于单分片的分片表查询，相比于传统的数据库查询速度提升不明显，因为uuu_id列本身加了索引查询速度已经够快了。但是当时数据库的压力提升以后，多个分片节点的sdb带来的优势预计会有一定的体现，因为所有的数据库操作被均匀地负载到多台物理主机上面，由于硬件限制我们没有做性能测试，对于duplicate表的查询本身设计就是从catalog库上通过物化视图到各个shard库里，所以对查询的速度提升没有实质的提升作用。

最后的跨分片查询我们在测试过程中发现Oracle不支持where条件用in或者or，我们大部分的应用都会用到这种条件的查询，所以跨分片的查询目前版本支持并不完善。

1. 环境部署

• 软件的版本需要12.2.0.0.3及以上的版本

• 在配置GSM的时候报错信息不会很直观的展示出来，这对于安装部署有很大阻碍。

2. 数据导入

• Duplicate表的数据导入是从catalog库导入，分片表的导入可以从各个shard库导入进去（由于环境有限暂时12.2.0.0.3从catalog库导入还未来得及测试）。

• 12.2.0.0.3版本以前分片表直接从catalog库导入会报ora-600错误，而且这些错误也没有相应的psu修复。

• 通过dblink用create table as select的方式创建会报不支持的操作类型的错误。

3. 业务测试

跨分片查询在 12.2.0.0.3版本支持并不完善，例如用in或者or 的查询Oracle会直接报错。我们已将改进建议提给Oracle，可能会在正式发布版本中得到解决。

所有的连接都经过catalog库，当连接请求并发上去后catalog将成为瓶颈，需创建多个catalog库分担压力。

同一schema下的各个分片表必须要有主外键关系。