Oracle · 2017-01-10 0

Oracle Parallel Server

1.概述
虽然去IOE如火如荼搞了那么多年了,O还是顽强的活在有钱的企业中,类似能源,交通,政府等大型企业。去IOE之前和之后有哪些区别呢?
去IOE之前是:小机+中高端存储+oracle,去IOE之后是:一体机+oracle。可以看出这期间唯一不变的oracle。凡是用oracle的环境,我相信没几个人敢搞单实例裸奔,大多数都是双节点rac。在rac横行的这个世道,你可曾听过oracle并行服务器(Oracle Parallel Server),oracle老鸟肯定知道,rac的前身就是Oracle Parallel Server(后面简称ops)。
oracle从哪个版本开始由ops变为rac呢,Oracle 8i Parallel Server,Oracle9i Real Application Clusters,看到这个也就明白了,oracle在i时代从ops跨越到rac。

oracle 8i/9i   oracle 10g/11g    oracle 12c
i是internet的意思,Oracle8和9都是i,表明当时是internet概念盛行的年代,oracle为了迎合当时环境,而做出的internet方面的改进。
g是grid网格运算,当时也是非常火的,10g和11g就是oracle为了迎合分布式计算而做出的变化。
c是cloud表明云计算的意思,现在云计算如火如荼,oracle 12c。

我在第一次听说ops是在老白(行业老尊,可能很多同学都只知道某某某是ACED,某某某是阿里出来的OCM)的那本oracle rac日记里面看到了,那本书出来好多年了,里面各种优化思路在现在也是非常非常先进的,有兴趣大家可以去读一读这几本书,非常经典,也是这几本书把我带入DBA大门。
这里也推荐老白的几本经典著作:

《Oracle优化日记:一个金牌DBA的故事 》:通过这本书,好好去感悟下,DBA做优化。
《Oracle RAC日记》:教你怎么用好RAC,现在很多运营商的RAC应用模式和该书介绍模式类似。
《DBA的思想天空:感悟Oracle数据库本质》:谈谈数据库本质,不要整天想着怎么dump share pool,怎么dump数据块,从不一样的层面看数据库。

可能大家最关心的就是oracle集群都是支持多点写入的,这也是最最核心的特性,目前世界上最成熟的支持多点写入的数据库也就oracle rac和db2 pure scale。对于多点写入,rac和ops实现方式有什么不同呢,下面我们分别在8i个9i两个版本里面来讲解一下。
2.Oracle 8i Parallel Server
下面我们看这幅图

Multiple Instances Updating the Same Data Block

20170109234043
我们简单解说一下这幅图。这幅图表示跨节点更新block,整个流程如下。
1).在time 0的时候,实例X持有数据块n的Parallel Cache Management lock(理解为全局锁吧,全局锁维护是通过心跳网),并且更新第一行
2).实例Y请求修改数据块n的第四行
3).在time 1的时候,实例X将数据块n写回共享存储,并且释放Parallel Cache Management lock(全局锁)
4).实例Y持有数据块n的Parallel Cache Management lock,并且更新第四行
5).在time 2的时候,实例X请求更新数据块n的第七行
6).实例Y将数据块n写回共享存储,并且释放Parallel Cache Management lock
7).实例X持有数据块n的Parallel Cache Management lock,并且更新第七行
8).实例X提交事务,此时仍然持有数据块n的Parallel Cache Management lock,直到其他节点请求数据块n

3.Oracle9i Real Application Clusters
下面看这幅图

Requesting a Changed Block for a Modification Operation

20170109235238
我们也简单解释一下这幅图。这幅图也表示跨节点更新block,整个流程如下。
1).实例1需要修改数据块n,实例1将这个请求提交给GCS(global cache service)
2).GCS通过将这个请求转发给实例2(GCS知道每个块每个版本在哪里)
3).实例2收到请求,并且LMS(Lock Manager Server)进程将数据块发送给实例1。在发送数据块n之前,实例2需要将数据块n的锁模式从x模式降级为null模式,实例2仍然会保存数据块n的脏块,数据库n的角色变为全局(可能在多个节点都变成脏块,是全局模式,大家都知道数据块n可能在多个节点变脏了),在传送数据块的同时,还是附加以下消息:实例2保存着数据块n的一个脏块,请求者必须将数据块n置为全局角色,并且持有x锁。
4).实例1收到数据块n,持有数据块n的排他锁,并且数据块n是全局模式,然后修改数据块。此时实例1还不能将数据库n落盘.

Writing Blocks to Disk

既然实例1 不能将数据块修改完后落盘,那我们做checkpoint或者age out block的时候,数据块怎么落盘呢?首先不管节点持有数据块的当前版本(most current version)或者旧版本(past image),都可以发出数据块落盘的请求;其次数据块的任何版本可以存在任何节点,我们写只能写最新版本,这就需要GCS协调。请看下图:
20170110001549
我们简单讲解一下这个过程,
1).实例2发出数据块n的落盘请求,并且将这个请求提交给GCS
2).GCS通过查找,发现数据块n的最新版本在实例1,故将数据块落盘请求转发给实例1
3).实例1收到GCS的请求,然后将数据块n落盘
4).实例1向GCS反馈,数据块n已经落盘完毕,此时数据块n的角色可以变为本地啦,没有更多的脏块存在于多个节点啦。
5).GCS通知所有实例,数据块n已经落盘啦,past image版本的数据块n可以丢掉啦,没用啦。

以上就是8i和9i处理多节点写入的整个流程,我们发现最大区别在于rac(9i)不需要落盘数据块就可以跨节点修改数据块,8i则需要将数据块落盘。关于更多GCS/Parallel Cache Management lock这两个神奇的东东,大家可以自行翻阅oracle 8i和9i的Concepts.