作者简介

任小闯

云和恩墨交付技术顾问，6年以上数据库开发维护工作经历，Oracle 10g OCM，Oracle 11g OCP，曾就职于某互联网行业任数据库的设计和开发优化，现任某省移动运营商负责数据库的维护和交付工作。 擅长数据库的日常维护，设计开发，故障诊断，数据迁移，性能调优等工作。

本文由恩墨大讲堂149期线上分享整理而成。课程回看可点击文末“阅读原文”。

Oracle RAC 在设计的时候只是考虑应用的高可用，即通过一个共享存储，搭建2个或者多个 Oracle 实例，对外提供 Oracle 服务，没有考虑到这个共享存储的故障问题。而 ADG 只是提供了数据级别的异地 HA，最主要功能是容灾、数据保护、故障恢复等。跨数据中心双活的，它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。但是由于它的架构确实有着跨数据中心实现负载均衡和高可用性的潜力，所以有几家存储设备供应商对它的使用环境做了扩展，提出了跨数据中心的解决方案。Oracle 对此采取了默认的态度，但是建议所有的解决方案在投入客户生产之前进行仔细的测试。

对于 RAC 而言，跨数据中心解决方案的最大瓶颈是节点之间的 Interconnect，因为它对时延和带宽的要求都非常高。一般而言，本地 Interconnect 传输时延在 1~2ms 之间，本地 IO 的延时则在 8~15ms 之间。这两个时延对性能的影响相当大，如果使用双数据中心方案，随着机房距离的增长，它们都会严重影响性能。而且由 Interconnect 的时延基数低（1~2ms），导致机房距离产生的时延对整个 Interconnect 影响的占比更大，所以在搭建 Oracle 双活的 RAC 存储架构时需要对各个节点的 IO 性能做严格的测试，标准的 Oracle 双活方案架构如下。

安装部署存储双活，需要至少6快盘，详细磁盘规划需求如下：

安装 grid 创建磁盘组时候选择临时 tmporc 盘作为临时的 ocr 磁盘组。

Grid 安装好之后，需要创建 normal 冗余的 ocr 磁盘组和 data 磁盘组，创建 ocr 磁盘组需要指定两个 failgroup 和一个 QUORUM FAILGROUP（只做仲裁，不存储 ocr 数据）：

创建 Data 磁盘组需要指定两个 failgroup，命令如下：

如果上线后有添加磁盘的需求，Data 磁盘组添加磁盘命令如下：

双活的 ocr 磁盘组创建好之后需要将 OCR 和 votedisk 设备迁移至 OCR 磁盘中，命令如下：

将 ASM 实例的参数文件迁移到 asmspfile 至 OCR 磁盘组

ASM 实例的参数需要做如下设置（优先读本地磁盘组）：

Oracle 双活存储安装完毕之后需要重点做读写性能速度测试，在这里我们通过主机层的软件和数据库及的写入速度测试：

① 主机层测试

这里我们采用 Orion 软件分别在2个 RAC 节点上对两块异地测试盘做读写速度测试：（同样块大小，100%写）

/home/oracle/orion-run advanced -testname yt -num_disks 1 -size_small 64 -size_large 64 -typerand -write 100 -duration 20

测试结果如下：

然后再对比2个 RAC 节点分别测试2块盘的写速度

测试结果描述：因为 RAC1节点和 aa 的存储在一个本地机房，RAC2 节点和 bb 存储在一个机房，所以 RAC1 节点写 aa 存储的速度和 RAC2 节点写 bb 存储的速度都接近理想值 。但是 RAC1 存储写 bb 存储和 RAC2 存储写 aa 存储需要跨两个机房之间定的光纤和传输网络，实际速度根据两个机房的距离，存储光纤的信号传输速率，进而影响 Orin 写入速率，通过上表我们可以看出跨光纤距离为理想值的50%左右，而且两端的写入速度比较对称（从 RAC 写入到 bb 和从 RAC2 写入到 aa 的速度）。

② 数据库层测试

数据库层的测试主要是在2个 RAC 节点对两个异地机房的磁盘模拟插入数据测试，详细测试方案如下：

创建2个磁盘组，分别为两个异地机房的磁盘

创建2个表空间，datafile 分别为两个机房的磁盘组

模拟创建一个 10G 的表，分别再 RAC 的两个节点上写两个磁盘组，并测试速度（因为 Redo 在 Data 磁盘组上，data 磁盘组跨两个异地存储节点，这里我们测试需要绕过 Redo，直接写在对应磁盘组上，这里我们用 create table as 测试写入速度，（绕过 Redo 直接测试写到某个磁盘）

测试结果如下：

通过数据库级的插入速度测试要尽量接近 Oracle 的写入速度为最佳，如果上述测试的速度严重低于 orion 测试速度，或者某个链路的测试速度比预估值低很多，这时候我们就需要联系主机存储或者光纤链路负责人员进行原因排查和问题定位，尽量在系统上线之前解决问题，避免出现系统上线之后因写入速度慢导致数据库性能严重下降的问题。

如果两个异地机房的存储中有个一个存储出现故障，则会出现如下报错，这时候 ASM 磁盘组状态会变成 UNKNOWN 状态，这时候需要存储工程师修复好磁盘，链路或者磁盘修复好之后需要对磁盘进行 dd 操作，因为和正常盘数据出现不一致，命令如下：

dd if=/dev/zeroof=/dev/asm-bbdata bs=8k  count=2000

删除 UNKNOWN 状态的磁盘

alter diskgroupDATA drop disk DATA_0001 FORCE;

添加新的磁盘

alter diskgroup dataadd FAILGROUP bb disk '/dev/asm-bbdata' rebalance power 111;

如果出现问题的是仲裁存储这时候我们的操作步骤如下：

alter diskgroupOCR drop QUORUM disk OCR_0004 FORCE;

添加新的磁盘

alter diskgroupocr add QUORUM FAILGROUP RZ disk'/dev/asm-zcocr' rebalance power 1;

添加好 ocr 磁盘组之后需要检查 ocr 磁盘的状态

[grid@ytaeplogdb1~]$ crsctl query css votedisk

##  STATE   File Universal Id               File Name Disk group

--  -----   -----------------               --------- ---------

1. ONLINE  a7af9b05365e4f1ebfe22a8bf6ee06a0 (/dev/asm-bbocr) [OCR]

2. ONLINE  65f9bba630ac4f21bf12a84ae761e660 (/dev/asm-zcocr) [OCR]

3. ONLINE  140f879fc7524fe0bffc464f9a5730cf (/dev/asm-aaocr) [OCR]

上文中提到仲裁存储节点，仲裁存储节点最好放在第三地的中心机房，如果有些客户没有第三地机房，最好单独划分一个存储。

Oracle 双活存储方案和存储厂商的双活方案（如 EMC 的 Vplex）对比有更大的灵活性，透明性，因为底层的存储磁盘对于 Oracle 来说完全可见，而且通过 Oracle 的 Normal 磁盘组的功能实现，大大节省成本。

如果存在性能问题时重点关注 AWR 报告中存储的延时情况。

无论是 Oracle 的双活存储还是存储厂商的双活解决方案，均适用于两个存储机房距离小于 50 公里的情况，而且最大的瓶颈在于远端的存储节点写入速度，因此在部署双活存储方案时，提前做好底层的磁盘写入速度测试，同时在应用上做部署优化尽量减小 Oracle 的写入操作，才能达到数据库的最佳性能。

点击阅读原文，回看课程视频