OracleRAC深度解释.doc

上传人:sk****8 文档编号:3534346 上传时间:2019-06-02 格式:DOC 页数:11 大小:109.50KB
下载 相关 举报
OracleRAC深度解释.doc_第1页
第1页 / 共11页
OracleRAC深度解释.doc_第2页
第2页 / 共11页
OracleRAC深度解释.doc_第3页
第3页 / 共11页
OracleRAC深度解释.doc_第4页
第4页 / 共11页
OracleRAC深度解释.doc_第5页
第5页 / 共11页
点击查看更多>>
资源描述

1、1.1 并发控制在集群环境中, 关键数据通常是共享存放的,比如放在共享磁盘上。 而各个节点的对数据有相同的访问权限, 这时就必须有某种机制能够控制节点对数据的访问。 Oracle RAC 是利用 DLM(Distribute Lock Management) 机制来进行多个实例间的并发控制。1.2 健忘症 (Amnesia)集群环境配置文件不是集中存放的,而是每个节点都有一个本地副本,在集群正常运行时,用户可以在任何节点更改集群的配置,并且这种更改会自动同步到其他节点。有一种特殊情况: 节点 A 正常关闭, 在节点 B 上修改配置, 关闭结点 A,启动结点 B。 这种情况下,修改的配置文件是丢

2、失的, 就是所谓的健忘症。1.3 脑裂 (Split Brain)在集群中,节点间通过某种机制(心跳) 了解彼此的健康状态,以确保各节点协调工作。假设只有“心跳“出现问题, 各个节点还在正常运行, 这时,每个节点都认为其他的节点宕机了, 自己是整个集群环境中的“唯一建在者“,自己应该获得整个集群的 “控制权“ 。 在集群环境中,存储设备都是共享的, 这就意味着数据灾难, 这种情况就是“脑裂“解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下:集群中各个节点需要心跳机制来通报彼此的“健康状态“,假设每收到一个节点的“通报“代表一票。对于三个节点的集群,正

3、常运行时,每个节点都会有 3 票。 当结点 A 心跳出现故障但节点 A 还在运行,这时整个集群就会分裂成 2 个小的 partition。 节点 A 是一个,剩下的 2 个是一个。 这是必须剔除一个 partition 才能保障集群的健康运行。 对于有 3 个节点的集群, A 心跳出现问题后, B 和 C 是一个 partion,有 2 票, A只有 1 票。 按照投票算法, B 和 C 组成的集群获得控制权, A 被剔除。 如果只有 2 个节点,投票算法就失效了。 因为每个节点上都只有 1 票。 这时就需要引入第三个设备:Quorum Device. Quorum Device 通常采用饿是

4、共享磁盘,这个磁盘也叫作 Quorum disk。 这个 Quorum Disk 也代表一票。 当 2 个结点的心跳出现问题时, 2 个节点同时去争取 Quorum Disk 这一票, 最早到达的请求被最先满足。 故最先获得Quorum Disk 的节点就获得 2 票。另一个节点就会被剔除。1.4 IO 隔离(Fencing)当集群系统出现“脑裂“问题的时候,我们可以通过“投票算法“ 来解决谁获得集群控制权的问题。 但是这样是不够的,我们还必须保证被赶出去的结点不能操作共享数据。 这就是 IO Fencing 要解决的问题。IO Fencing 实现有硬件和软件 2 种方式:软件方式:对于支持

5、 SCSI Reserve/Release 命令的存储设备, 可以用 SG 命令来实现。 正常的节点使用 SCSI Reserve 命令“锁住“存储设备, 故障节点发现存储设备被锁住后,就知道自己被赶出了集群,也就是说自己出现了异常情况, 就要自己进行重启,以恢复到正常状态。 这个机制也叫作 Sicide(自杀). Sun 和 Veritas 使用的就是这种机制。硬件方式:STONITH(Shoot The Other Node in the Head), 这种方式直接操作电源开关,当一个节点发生故障时,另一个节点如果能侦测到,就会通过串口发出命令,控制故障节点的电源开关,通过暂时断电,而又上

6、电的方式使故障节点被重启动, 这种方式需要硬件支持。二 RAC 集群2.1 Clusterware在单机环境下,Oracle 是运行在 OS Kernel 之上的。 OS Kernel 负责管理硬件设备,并提供硬件访问接口。 Oracle 不会直接操作硬件,而是有 OS Kernel 代替它来完成对硬件的调用请求。在集群环境下, 存储设备是共享的。OS Kernel 的设计都是针对单机的,只能控制单机上多个进程间的访问。 如果还依赖 OS Kernel 的服务,就无法保证多个主机间的协调工作。 这时就需要引入额外的控制机制,在 RAC 中,这个机制就是位于 Oracle 和 OS Kernel

7、 之间的 Clusterware,它会在 OS Kernel 之前截获请求,然后和其他结点上的 Clusterware 协商,最终完成上层的请求。在 Oracle 10G 之前,RAC 所需要的集群件依赖与硬件厂商,比如 SUN,HP,Veritas. 从Oracle 10.1 版本中,Oracle 推出了自己的集群产品. Cluster Ready Service(CRS),从此 RAC 不在依赖与任何厂商的集群软件。 在 Oracle 10.2 版本中,这个产品改名为:Oracle Clusterware。 所以我们可以看出, 在整个 RAC 集群中,实际上有 2 个集群环境的存在,一个是

8、由Clusterware 软件组成的集群,另一个是由 Database 组成的集群。2.2 Clusterware 组成Oracle Cluster 是一个单独的安装包,安装后,在每个结点上的 Oracle Clusterware 会自动启动。 Oracle Clusterware 的运行环境由 2 个磁盘文件(OCR,Voting Disk),若干进程和网络元素组成。 2.2.1 磁盘文件:Clusterware 在运行期间需要两个文件:OCR 和 Voting Disk. 这 2 个文件必须存放在共享存储上。 OCR 用于解决健忘问题,Voting Disk 用于解决脑裂问题。 Oracl

9、e 建议使用裸设备来存放这 2 个文件,每个文件创建一个裸设备,每个裸设备分配 100M 左右的空间就够了。2.2.1.1 OCR健忘问题是由于每个节点都有配置信息的拷贝,修改节点的配置信息不同步引起的。 Oracle 采用的解决方法就是把这个配置文件放在共享的存储上, 这个文件就是 OCR Disk。OCR 中保存整个集群的配置信息,配置信息以“Key-Value“ 的形式保存其中。 在Oracle 10g 以前, 这个文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g, 这部分内容被重新设计,并重名为 OCR.在 Oracle

10、Clusterware 安装的过程中, 安装程序会提示用户指定 OCR 位置。并且用户指定的这个位置会被记录在 /etc/oracle/ocr.Loc(Linux System) 或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。 而在 Oracle 9i RAC 中,对等的是 srvConfig.Loc 文件。 Oracle Clusterware 在启动时会根据这里面的内容从指定位置读入OCR 内容。1). OCR key整个 OCR 的信息是树形结构,有 3 个大分支。分别是 SYSTEM,DATABASE 和 CRS。每个分支下面又有许多小分支。

11、这些记录的信息只能由 root 用户修改。2) OCR processOracle Clusterware 在 OCR 中存放集群配置信息,故 OCR 的内容非常的重要,所有对OCR 的操作必须确保 OCR 内容完整性,所以在 ORACLE Clusterware 运行过程中,并不是所有结点都能操作 OCR Disk. 在每个节点的内存中都有一份 OCR 内容的拷贝,这份拷贝叫作 OCR Cache。 每个结点都有一个 OCR Process 来读写 OCR Cache,但只有一个节点的 OCR process 能读写 OCR Disk中的内容,这个节点叫作 OCR Master 结点。 这个

12、节点的 OCR process 负责更新本地和其他结点的 OCR Cache 内容。所有需要 OCR 内容的其他进程,比如 OCSSD,EVM 等都叫作 Client Process, 这些进程不会直接访问 OCR Cache,而是像 OCR Process 发送请求,借助 OCR Process 获得内容,如果想要修改 OCR 内容,也要由该节点的 OCR Process 像 Master node 的 OCR process 提交申请,由 Master OCR Process 完成物理读写,并同步所有节点 OCR Cache 中的内容。2.2.1.2 Voting DiskVoting D

13、isk 这个文件主要用于记录节点成员状态,在出现脑裂时,决定那个 Partion 获得控制权,其他的 Partion 必须从集群中剔除。在安装 Clusterware 时也会提示指定这个位置。 安装完成后可以通过如下命令来查看 Voting Disk 位置。$Crsctl query css votedisk2.2.2 Clusterware 后台进程Clusterware 由若干进程组成,其中最重要的 3 个是:CRSD,CSSD,EVMD. 在安装clusterware 的最后阶段,会要求在每个节点执行 root.sh 脚本, 这个脚本会在/etc/inittab 文件的最后把这 3 个进

14、程加入启动项,这样以后每次系统启动时,Clusterware 也会自动启动,其中 EVMD 和 CRSD 两个进程如果出现异常,则系统会自动重启这两个进程,如果是CSSD 进程异常,系统会立即重启。1). OCSSDOCSSD 这个进程是 Clusterware 最关键的进程,如果这个进程出现异常,会导致系统重启,这个进程提供 CSS(Cluster Synchronization Service)服务。 CSS 服务通过多种心跳机制实时监控集群状态,提供脑裂保护等基础集群服务功能。CSS 服务有 2 种心跳机制: 一种是通过私有网络的 Network Heartbeat,另一种是通过 Vot

15、ing Disk 的 Disk Heartbeat.这 2 种心跳都有最大延时,对于 Disk Heartbeat, 这个延时叫作 IOT (I/O Timeout);对于Network Heartbeat, 这个延时叫 MC(Misscount)。 这 2 个参数都以秒为单位,缺省时 IOT 大于 MC,在默认情况下,这 2 个参数是 Oracle 自动判定的,并且不建议调整。可以通过如下命令来查看参数值:$crsctl get css disktimeout$crsctl get css misscount注:除了 Clusterware 需要这个进程,在单节点环境中如果使用了 ASM,也

16、需要这个进程;这个进程用于支持 ASM Instance 和 RDBMS Instance 之间的通信。 如果在使用了ASM 的节点上安装 RAC,会遇到一个问题:RAC 节点要求只有一个 OCSSD 进程,并且应该是运行$CRS_HOME 目录下的,这时就需要先停止 ASM,并通过$ORACLE_HOME/bin/localcfig.Sh delete 删除之前的 inittab 条目。 之前安装 ASM 时,也使用这个脚本来启动 OCSSD: $ORACLE_HOME/bin/localconfig.Sh add. 2). CRSDCRSD 是实现“高可用性(HA)“的主要进程,它提供的服

17、务叫作 CRS(Cluster Ready Service) 服务。Oracle Clusterware 是位于集群层的组件,它要为应用层资源(CRS Resource) 提供“高可用性服务“,所以, Oracle Clusterware 必须监控这些资源,并在这些资源运行异常时进行干预,包括关闭,重启进程或者转移服务。CRSD 进程提供的就是这些服务。所有需要 高可用性 的组件,都会在安装配置的时候,以 CRS Resource 的形式登记到OCR 中,而 CRSD 进程就是根据 OCR 中的内容,决定监控哪些进程,如何监控,出现问题时又如何解决。也就是说,CRSD 进程负责监控 CRS R

18、esource 的运行状态,并要启动,停止,监控,Failover 这些资源。 默认情况下,CRS 会自动尝试重启资源 5 次,如果还是失败,则放弃尝试。CRS Resource 包括 GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance 和 Service. 这些资源被分成 2 类:GSD,ONS,VIP 和 Listener 属于 Noteapps 类Database,Instance 和 Service 属于 Database-Related Resource 类。我们可以

19、这样理解: Nodeapps 就是说每个节点只需要一个就够了,比如每个节点只有一个 Listener,而 Database-Related Resource 就是说这些资源和数据库有关,不受节点的限制,比如一个节点可以有多个实例,每个实例可以有多个 Service。GSD,ONS,VIP 这 3 个服务是在安装 Clusterware 的最后,执行 VIPCA 时创建并登记到OCR 中的。 而 Database, Listener, Instance 和 Service 是在各自的配置过程中自动或者手动登记到 OCR 中的。3). EVMDEVMD 这个进程负责发布 CRS 产生的各种事件(E

20、vent). 这些 Event 可以通过 2 种方式发布给客户:ONS 和 Callout Script. 用户可以自定义回调脚本,放在特定的目录下,这样当有某些事件发生时,EVMD 会自动扫描该目录,并调用用户的脚本,这种调用是通过racgevt 进程来完成的。EVMD 进程除了复杂发布事件之外,它还是 CRSD 和 CSSD 两个进程之间的桥梁。 CRS 和 CSS 两个服务之前的通信就是通过 EVMD 进程完成的。4). RACGIMONRACGIMON 这个进程负责检查数据库健康状态,负责 Service 的启动,停止,故障转移(Failover)。 这个进程会建立到数据库的持久连接,

21、定期检查 SGA 中的特定信息,该信息由 PMON 进程定时更新。5). OPROCDOPROCD 这个进程也叫作 Process Monitor Daemon. 如果在非 Linux 平台上,并且没有使用第三方的集群软件时,就会看到这个进程。 这个进程用来检查节点的 Processor Hang(CPU 挂起), 如果调度时间超过 1.5 秒, 就会认为 CPU 工作异常,会重启节点。 也就是说这个进程提供 “IO 隔离“ 的功能。 从其在 Windows 平台上的服务名: OraFnceService 也可以看出它的功能。 而在 Linux 平台上, 是利用 Hangcheck-timer

22、 模块来实现“IO 隔离“的。2.3 VIP 原理和特点Oracle 的 TAF 就是建立在 VIP 技术之上的。 IP 和 VIP 区别在与: IP 是利用 TCP 层超时,VIP 利用的是应用层的立即响应。VIP 它是浮动的 IP. 当一个节点出现问题时会自动的转到另一个节点上。假设有一个 2 个节点的 RAC,正常运行时每个节点上都有一个 VIP。 VIP1 和 VIP2. 当节点2 发生故障,比如异常关系。 RAC 会做如下操作:1). CRS 在检测到 rac2 节点异常后,会触发 Clusterware 重构,最后把 rac2 节点剔除集群,由节点 1 组成新的集群。2). RAC

23、 的 Failover 机制会把节点 2 的 VIP 转移到节点 1 上,这时节点 1 的 PUBLIC 网卡上就有 3 个 IP 地址: VIP1,VIP2, PUBLIC IP1.3). 用户对 VIP2 的连接请求会被 IP 层路由转到节点 14). 因为在节点 1 上有 VIP2 的地址,所有数据包会顺利通过路由层,网络层,传输层。5). 但是,节点 1 上只监听 VIP1 和 public IP1 的两个 IP 地址。并没有监听 VIP2,故应用层没有对应的程序接收这个数据包,这个错误立即被捕获。6). 客户段能够立即接收到这个错误,然后客户段会重新发起向 VIP1 的连接请求。VI

24、P 特点:1). VIP 是通过 VIPCA 脚本创建的2). VIP 作为 Nodeapps 类型的 CRS Resource 注册到 OCR 中,并由 CRS 维护状态。3). VIP 会绑定到节点的 public 网卡上,故 public 网卡有 2 个地址。4). 当某个节点发生故障时,CRS 会把故障节点的 VIP 转移到其他节点上。5). 每个节点的 Listener 会同时监听 public 网卡上的 public ip 和 VIP6). 客户端的 tnsnames.Ora 一般会配置指向节点的 VIP.2.4 Clusterware 的日志体系Oracle Clusterwar

25、e 的辅助诊断,只能从 log 和 trace 进行。 而且它的日志体系比较复杂。 alert.log:$ORA_CRS_HOMEloghostnamealert.Log, 这是首选的查看文件。Clusterware 后台进程日志:crsd.Log: $ORA_CRS_HOMEloghostnamecrsdcrsd.Logocssd.Log: $ORA_CRS_HOMEloghostnamecssdocsd.Logevmd.Log: $ORA_CRS_HOMEloghostnameevmdevmd.LogNodeapp 日志位置:$ORA_CRS_HOMEloghostnameracg这里面放

26、的是 nodeapp 的日志,包括 ONS 和 VIP,比如:ora.Rac1.ons.Log工具执行日志:$ORA_CRS_HOMEloghostnameclientClusterware 提供了许多命令行工具: 比如 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 这些工具产生的日志就放在这个目录下还有$ORACLE_HOMEloghostnameclient 和$ORACLE_HOMEloghostnameracg 也有相关的日志。 一 RAC 并发RAC 的本质是一个数据库,运行在多台计算机上的数据库,它的主要任务是数据库就是事务处理,它通过

27、Distributed Lock Management(DLM:分布式锁管理器) 来解决并发问题。因为 RAC 的资源是共享的,为了保证数据的一致性,就需要使用 DLM 来协调实例间对资源的竞争访问。RAC 的 DLM 就叫作 Cache Fusion。在 DLM 中,根据资源数量,活动密集程度,把资源分成两类:Cache Fusion 和 Non-Cache Fusion。Cache Fusion Resource 指数据块这种资源,包括普通数据库,索引数据库,段头块(Segment Header),undo 数据库。 Non-Cache Fusion Resource 是所有的非数据库块资

28、源, 包括数据文件,控制文件,数据字典,Library Cache,share Pool 的 Row Cache 等。Row Cache 中存放的是数据字典,它的目的是在编译过程中减少对磁盘的访问。在 Cache Fusion 中,每一个数据块都被映射成一个 Cache Fusion 资源,Cache Fusion 资源实际就是一个数据结构,资源的名称就是数据块地址(DBA) 。每个数据请求动作都是分步完成的。首先把数据块地址 X 转换成 Cache Fusion 资源名称,然后把这个 Cache Fusion 资源请求提交给 DLM, DLM 进行 Global Lock 的申请,释放活动,

29、只有进程获得了 PCM Lock才能继续下一步,即:实例要获得数据块的使用权。Cache Fusion 要解决的首要问题就是:数据块拷贝在集群节点间的状态分布图, 这是通过GRD 实现的。 GRD(Global Resource Directory)可以把 GRD 看作一个内部数据库,这里记录的是每一个数据块在集群间的分布图,它位于每一个实例的 SGA 中,但是每个实例 SGA 中都是部分 GRD,所有实例的 GRD 汇总在一起就是一个完整的 GRD。RAC 会根据每个资源的名称从集群中选择一个节点作为它的 Master Node,而其他节点叫作 Shadow Node。 Master Nod

30、e 的 GRD 中记录了该资源在所有节点上的使用信息,而Shadow Node 的 GRD 中只需要记录资源在该节点上的使用情况,这些信息实际就是 PCM Lock 信息。PCM Lock 有 3 个属性: Mode,Role 和 PI(Past Image)二 RAC 架构2.1 SGA 的变化和传统的单实例相比, RAC Insance 的 SGA 最显著的变化就是多了一个 GRD 部分。 Oracle 中的数据操作都是在内存的 SGA 区完成的,和传统的单实例不同,RAC 是有多个,每个数据块可以在任何一个 Instance 的 SGA 中都有拷贝, RAC 必须知道这些拷贝的分布版本,

31、状态,而 GRD 就是这些信息的内存区。GRD 虽然位于 SGA 中,但是不像 Buffer Cache 或者 Log buffer 等 SGA 组件,有明确的参数来对应,每个节点中都只有部分 GRD 内容,所有的节点合在一起才构成完整的 GRD.2.2 后台进程的变化每个 RAC 的实例和传统的单实例一样,都有 DBWR,LGWR,ARCn,CKPT 这些后台进程,除了这些进程外,每个实例还增加了若干 RAC 特有的进程,要注意的是,这些进程名称和进程提供的服务名称差异很大,比如 LMS 进程提供的是 GCS 服务,很不便与记忆,造成这种现象的原因是进程名称从 9i 之前的 OPS(RAC

32、前身)延续下来的,但是服务却已经在 RAC 中重新设计并命名。2.2.1 LMSn 这个进程是 Cache Fusion 的主要进程,负责数据块在实例间的传递,对应的服务叫作GCS(Global Cache Service), 这个进程的名称来源与 Lock Manager Service。 从 Oracle 9 开始,Oracle 对这个服务重新命名成 Global Cache SErvice, 但是进程名字确没有调整。 这个进程的数量是通过参数 GCS_SERVER_PROCESSES 来控制,缺省值是 2 个,取值范围为 0-9. 2.2.2 LMD这个进程负责的是 Global Enq

33、ueue Service(GES ) ,具体来说,这个进程负责在多个实例之间协调对数据块的访问顺序,保证数据的一致性访问。 它和 LMSn 进程的 GCS 服务还有GRD 共同构成 RAC 最核心的功能 Cache Fusion。2.2.3 LCK这个进程负责 Non-Cache Fusion 资源的同步访问,每个实例有一个 LCK 进程2.2.4 LMON各个实例的 LMON 进程会定期通信,以检查集群中各个节点的健康状态,当某个节点出现故障时,负责集群重构,GRD 恢复等操作,它提供的服务叫作:Cluster Group Services(CGS) 。LMON 主要借助两种心跳机制来完成健

34、康检查:1) 节点间的网络心跳(Network Heartbeat): 可以想象陈节点间定时的发送 ping 包检测节点状态,如果能在规定时间内收到回应,就认为对方状态正常2) 通过控制文件的磁盘心跳(Controlfile Heartbeat): 每个节点的 CKPT 进程每隔 3 秒更新一次控制文件一个数据块,这个数据块叫作 Checkpoint Progress Record,控制文件是共享的,所以实例间可以相互检查对方是否及时更新来判断。2.2.5 DIAGDIAG 进程监控实例的健康状态,并在实例出现运行错误时手机诊断数据记录到 alert.log 文件2.2.6 GSD这个进程负责

35、懂客户端工具,比如 srvctl 接收用户命令,为用户提供管理接口。2.3 文件Oracle 文件包括二进制执行文件,参数文件(pfile 和 spfile) ,密码文件,控制文件,数据文件,联机日志,归档日志,备份文件。2.3.1 spfile这个参数文件需要被所有节点访问,需要放在共享存储上2.3.2 Redo ThreadRAC 环境下有多个实例,每个实例都需要有自己的一套 Redo log 文件来记录日志。这套Redo Log 就叫作一个 Redo Thread,其实单实例下也是 Redo Thread,只是 Thread 这个词很少被提及,每个实例一套 Redo Thread 的设计

36、就是为了避免资源竞争造成性能瓶颈。Redo Thread 有两种,一种是 Private 的,创建语法: alter database add logfile . Thread n; 另一种是 public,创建语法: alter database add logfile.; RAC 中每个实例都要设置 thread 参数,该参数默认值为 0. 如果设置了这个参数,则实例启动时,会使用等于该 Thread 的Private Redo Thread。如果没有设置这个参数,则使用缺省值 0,启动实例后选择使用Public Redo Thread,并且实例会用独占的方式使用该 Redo Thread

37、。RAC 中每个实例都需要一个 Redo Thread,每个 Redo Log Thread 至少需要两个 Redo Log Group,每个 Log Group 成员大小应该相等,每组最好有 2 个以上成员,这些成员应放在不同的磁盘上,以避免单点失败。要注意的是,在 RAC 环境下,Redo Log Group 是在整个数据库级别进行编号的,比如实例1 有 1, 2,3 三个日志组,那么实例 2 的日志组就应该从 4 开始编号,不能在使用1, 2,3 这三个编号。在 RAC 环境下,所有实例的联机日志必须放在共享存储上,因为如果某个节点异常关闭,剩下的节点要进行 Crash Recovery

38、, 执行 Crash Recovery 的这个节点必须能够访问到故障节点的连接日志,只有把联机日志放在共享存储上才能满足这个要求。2.3.3 Archived LogRAC 中的每个实例都会产生自己的归档日志,归档日志只有在执行 Media Recovery 时才会用到,所以归档日志不必放在共享存储上,每个实例可以在本地存放归档日志。但是如果在单个实例上进行备份归档日志或者进行 Media Recovery 操作,又要求在这个节点必须能够访问到所有实例的归档日志,在 RAC 环境下,配置归档日志可以有多种选择。1)使用 NFS这种方式实际是归档到共享存储,比如 2 个节点,每个节点都有 2 个

39、目录,Arch1 ,Arch2分别对应实例 1 和实例 2 的日志。每个实例只配置一个归档位置,归档到本地,然后通过NFS 把对方的目录挂到本地。2)实例间归档(CIA: Cross Instance Archive)这种方式是上一种方式的变种,也是比较常见的一种配置方法。两个节点都创建 2 个目录Arch1 和 Arch2 分别对应实例 1 和实例 2 产生的归档日志。 每个实例都配置两个归档位置。位置 1 对应本地归档目录,位置 2 对应另一个实例。3)使用 ASM这种方式也是归档到共享存储,只是通过 Oracle 提供的 ASM,把上面的复杂性隐藏了,但原理都一样。2.3.4 Undo

40、Tablespace和 Redo Log 一样,在 RAC 环境下,每个实例都需要有一个单独的回滚表空间,这个是通过参数 SID.undo_tablespace 来配置的。2.4 SCN(System Change Number)SCN 是 Oracle 用来跟踪数据库内部变化发生的先后顺序的机制,可以把它想象成一个高精度的时钟,每个 Redo 日志条目,Undo Data Block,Data Block 都会有 SCN 号。 Oracle 的Consistent-Read, Current-Read, Multiversion-Block 都是依赖 SCN 实现。在 RAC 中,有 GCS

41、 负责全局维护 SCN 的产生,缺省用的是 Lamport SCN 生成算法,该算法大致原理是: 在所有节点间的通信内容中都携带 SCN, 每个节点把接收到的 SCN 和本机的 SCN 对比,如果本机的 SCN 小,则调整本机的 SCN 和接收的一致,如果节点间通信不多,还会主动地定期相互通报。 故即使节点处于 Idle 状态,还是会有一些 Redo log 产生。还有一个广播算法(Broadcast) ,这个算法是在每个 Commit 操作之后,节点要想其他节点广播 SCN,虽然这种方式会对系统造成一定的负载,但是确保每个节点在 Commit 之后都能立即查看到 SCN.这两种算法各有优缺点

42、,Lamport 虽然负载小,但是节点间会有延迟,广播虽然有负载,但是没有延迟。 Oracle 10g RAC 缺省选用的是 BroadCast 算法,可以从 alert.log 日志中看到相关信息:Picked broadcast on commit scheme to generate SCNSRedoLog Checkpoint 和 SCN 关系http:/ Cache Fusion, GCS, GES 关系Cache Fusion(内存融合)是通过高速的 Private Interconnect,在实例间进行数据块传递,它是 RAC 最核心的工作机制,它把所有实例的 SGA 虚拟成一个

43、大的 SGA 区。每当不同的实例请求相同的数据块时,这个数据块就通过 Private Interconnect 在实例间进行传递。整个 Cache Fusion 有两个服务组成:GCS 和 GES。 GCS 负责数据库在实例间的传递,GES 负责锁管理The following resource information is available in GRD:* Data Block Addresses (DBA). This is the address of the block being modified.* Location of most current version of the

44、 data block. This exists only if multiple nodes share the data block. * Modes of the data blocks (N)Null, (S)Shared, (X)Exclusive ).* The Roles of the data blocks (local or global). This indicates the role in which the data block is being held by the instance.* SCN ?System Change Number.* Image of t

45、he Data Block ?it could be past image or current image. Current image represents the copy of the block held by the current instance. Past image represents the global dirty data block image maintained in the cache.These row locks or row-level locks are stored in the block, and each lock refers to the

46、 global transaction lock.Oracle 集群需要存储的软件和数据 项目 内容 最少磁盘空间 Clusterware 软件 集群软件 500M(安装完成后不变) voting disk(表决磁盘) 记录集群节点信息 20M OCR(Oracle 集群注册) 存储集群配置信息 100M Oracle 数据库软件 数据库软件 1.3G(安装完成后不变) RAC 数据库 存储所有数据库文件 1.2G(使用过程中不断增加)Recovery File(恢复文件) 快速恢复数据 2G Oracle 集群中各部分的存储机制(非第三方集群文件系统) 项目 存储系统 存储位置 Cluste

47、rware 软件 NFS(要求 NAS 设备)、ext2、ext3 等本地文件系统 本地磁盘、网络磁盘(NFS) voting disk OCFS2、Raw device、NFS 共享磁盘、网络磁盘(NFS) OCR OCFS2、Raw device、NFS 共享磁盘、网络磁盘(NFS) 数据库软件 OCFS2(共享)、NFS(网络)、ext2、ext3 等本地文件系统 本地磁盘、网络磁盘(NFS)、共享磁盘(OCFS2) RAC 数据库 OCFS2、ASM、Raw device、NFS 共享磁盘、网络磁盘(NFS) 恢复文件 OCFS2、ASM、NFS 共享磁盘、网络磁盘(NFS) 从存储位

48、置中可以看出,所有的内容均可使用网络磁盘,但是网络磁盘要求有 NAS 设备。如果不使用 NAS 设备,除软件外,其它的数据都必须存储在共享磁盘上。对于 Oracle 数据库软件,如果要存储在共享磁盘上(所有服务器共享一个 Oracle Home),需要使用 OCFS2 文件系统。 Clusterware 和 Oracle 数据库存储选项 支持的文件类型 存储选项 Clusterware 数据库 恢复文件 ASM 否 是 是 OCFS2 是 是 是 Raw Device 是 是 否 NFS 是 是 是 从上表中可以看出,想要使用单一文件系统,必须使用 OCFS2 或 NFS 文件系统。但是,Or

49、acle 10g 提供了非常方便的存储管理系统 ASM,因此,大多数情况下建议使用 OCFS2 来存储 Clusterware 的数据和 Oracle 数据库软件,使用 ASM 来存储数据库文件。 综上所述,在 Linux(x86)上安装 Oracle 集群,推荐采用以下几种策略之一: (1)将 Oracle 数据库软件安装在本地磁盘(每个节点上一个拷贝),使用裸设备来存储 Clusterware ,使用 ASM 来存储数据库和恢复文件。 项目 存储系统 存储位置 Clusterware 软件 ext2、ext3 本地磁盘 voting disk Raw device 共享磁盘 OCR Raw device 共享磁盘 数据库软件 ext2、ext3 本地磁盘 RAC 数据库 ASM 共享磁盘 恢复文件 ASM 共享磁盘 (2)数据全部使用 OCFS2 来存储,并将 Oracle 数据库软件安装在 OCFS2 上(所有节点共享一个 Oracle Home) 项目 存储系统 存储位置 Clusterware 软件 ext2、e

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 实用文档资料库 > 策划方案

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。