双活
双活数据中心，是近年来各大企业对关键业务非常热门的一种技术。Oracle RAC数据库是天然的双活数据中心解决方案的核心技术。双活的核心其实就是双份存储，和实时的远程数据同步，简而言之，双活对IO和网络要求比一般的本地进群数据库要高很多。一般的双活解决方案又分为，基于ASM的复制，和基于硬件的复制（比如EMC，IBM 的解决方案）。 双活数据中心实施是一个比较复杂的工程， 本文对双活实施中的一个重要的方面： 数据库心跳网络测试进行探讨。
对于RAC而言，这种远程数据中心方案的最大瓶颈是节点之间的心跳网络，因为它对验收和流量的要求都非常高。一般来说，同在一个机房的两个节点间传输时延在1ms以内，在双数据中心方案，随着网络距离的增长，延时则会增加，如果网络设计，和质量达不到较好的水准，那么就可能大大影响双活的性能。
Oracle ACS部门一般会对Extended RAC进行严格的网络测试，这个测试和一般网络测试（比如iperf，iperf测试可以作为该测试的补充）不同， 这类测试是由数据库发起，利用SQL语句模拟出大量心跳网络流量，这样和实际生产中的高峰期压力更为接近，更能直观的反应当前RAC构架的性能和稳定性。
该测试我们主要测试和关注4个方面：
1. 在本地心跳和远程心跳网络发起大的网络流量，观测网络质量。
2. 在大量心跳流量，RAC等待事件和统计分析。
3. 本地节点间测试和远程节点测试的对比分析（延迟增加），为生产上线前的业务分割提供一定的性能依据。
4. 在大心跳流量期间，数据库，集群以及操作系统的状态。测试也是对数据库，操作系统网络相关配置的检测。
下面我们以一套4节点的Extended RAC环境举例。主机采用IBM的小型机，AIX操作系统，存储采用EMC Vplex ，网络采用光纤（WDM）。1-2节点主机和存储在siteA，3-4节点的主机和存储在siteB。测试中，最小测试方案为，测试1-2节点（本地），测试1-3节点远程，测试2-4节点远程。如果在测试中发现问题，则可能加测更多的节点组合方案。
测试案例分别会在两个节点运行DML，操作为
节点1并发发起 insert + 节点1并发发起 select和 delete
节点2并发发起select ， update，
所有的会话操作的相同的一片数据区域。在写入数据的量为300M-500M/秒（根据硬件，有所不同）。
在本地心跳和远程心跳网络发起大的网络流量，观测网络质量
可以看出在本次测试中的1-2节点（local-local）测试中，模拟的心跳流量大约在120M/秒左右。主要考察GC流量大小，GC BLOCK LOST。远程数据交换带来的延迟，Oracle集群和数据库的健康状态
在本次测试中，可以看出1-2测试中gc流量比较稳定,没有丢失块.
1-3（local-remote）的测试情况
在1-3的测试,发现一定的gc blocks lost,这和extended RAC 的远程链路的质量和配置有关。丢快的比例大约为万分之一。
继续测试2-4（local-remote）节点
发现2-4节点远程链路质量较好。
这时，我们发现的问题，就是1-3节点之间的链路可能存在问题。这个时候，就需要配合网络管理员进行排除。在问题解决后，再次进行测试。
RAC等待事件和统计分析
在测试期间进行awr 的采样，创建awr report，分析RAC 统计和等待事件。
可以看出，Top 10几乎都是gc相关等待事件。
确保流量正常，gc块的平均接收和发送时间正常（小于5ms），
比较重要的几个指标：
gc cr block send time
gc cr block receive time
gc current block send time
gc current block receive time
具体分析的方案和一般RAC并无太大区别。
本地节点间测试和远程节点测试的对比分析（延迟增加）
对远程数据交换带来的延迟的分析。
对比1-2节点的性能数据库和1-3节点，2-4节点的性能数据。我们可以发现，相同的SQL语句，等待事件的时间差异。在当前的测试案例中，各项等待事件的平均等待事件要慢1ms， 测试用SQL的平均执行时间，在1-2节点和1-3节点对比中，1-2节点要慢大约30ms，性能下降约10%，这反应远程网络带来的性能损耗。
1-3 远程节点测试
1-2 本地节点测试
在大心跳流量期间，数据库，集群以及操作系统的状态
最后是数据库和集群日志分析，确保没有发生异常。
<最后是如何利用OTEST进行一次RAC cache fusion测试>
打开OTEST，配置好测试环境以后，我们开始进行RAC测试。
RAC测试，分别会在两个节点并发的运行SQL，操作为
节点1 insert 节点2 select ， update，节点1 select delete
模拟的心跳流量在完美情况下大约在150M/秒左右。主要考察GC流量大小，GCBLOCK LOST，GC其它指标是否健康，集群的稳定性，数据库稳定性。
连接到节点1，
准备第一个步骤
打开第二个窗口，连接节点1，准备第二个步骤，注意不在选取fg logging
连接到节点2，准备节点2的步骤
三个步骤准备好以后， 再依次点击latch Test 开始测试。
在测试启动后，采样awr
execdbms_workload_repository.create_snapshot();
在测试达到95%后，再次采样
execdbms_workload_repository.create_snapshot();
在Watcher 面板观测gc指标
最后对测试分析需要利用到：
fg logging 日志。
awr 报告。
db watcher监控。
数据库和集群日志。
操作系统监控日志，比如nestat
Geting better resull with Oracle ACS ！
更多extended rac文章即将推出
双活数据库中的复杂IO测试
基于asm复制的双活和EMC Vplex方案的实际生产对比
专家简介：王文杰: 甲骨文公司资深技术专家，多年Oracle&Java项目构架，开发，运维经验。擅长于数据库性能调优、SQL优化，数据库疑难问题诊断，同时拥有丰富的软件开发经验。曾作为构架师，Team Leader设计开发某省电信网元激活系统，曾任美国某500强公司DBA team Leader, Commercial DBA Project Manager。 |
|
