张家港网站关键词优化,wordpress主题开发,表白网页在线生成制作源码,wordpress漂浮广告插件CACHE FUSION 原理 为了更深入的了解Oracle的后台进程的工作原理#xff0c;需要先了解一下 RAC 中多节点对共享数据文件访问的管理是如何进行的。要了解 RAC 工作原理的中心#xff0c;需要知道 Cache Fusion 这个重要的概念#xff0c;要发挥 Cache Fusion 的作用#xf…CACHE FUSION 原理 为了更深入的了解Oracle的后台进程的工作原理需要先了解一下 RAC 中多节点对共享数据文件访问的管理是如何进行的。要了解 RAC 工作原理的中心需要知道 Cache Fusion 这个重要的概念要发挥 Cache Fusion 的作用要有一个前提条件那就是互联网络的速度要比访问磁盘的速度要快。否则没有引入 CACHE FUSION 的意义。而事实上现在 100MB 的互联网都很常见。
什么是 CACHE FUSION Cache Fusion 就是通过互联网络高速的 Private interconnect在集群内各节点的 SGA 之间进行块传递这是RAC最核心的工作机制他把所有实例的SGA虚拟成一个大的SGA区每当不同的实例请求相同的数据块时这个数据块就通过 Private interconnect 在实例间进行传递。以避免首先将块推送到磁盘然后再重新读入其他实例的缓存中这样一种低效的实现方式(OPS 的实现)。当一个块被读入 RAC 环境中某个实例的缓存时该块会被赋予一个锁资源与行级锁不同以确保其他实例知道该块正在被使用。之后如果另一个实例请求该块的一个副本而该块已经处于前一个实例的缓存内那么该块会通过互联网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变但改变尚未提交那么将会传递一个 CR 副本。这就意味着只要可能数据块无需写回磁盘即可在各实例的缓存之间移动从而避免了同步多实例的缓存所花费的额外 I/O。很明显不同的实例缓存的数据可以是不同的也就是在一个实例要访问特定块之前而它又从未访问过这个块那么它要么从其他实例 cache fusion 过来或者从磁盘中读入。GCSGlobal Cache Service全局内存服务和 GESGlobal EnquenceService全局队列服务进程管理使用集群节点之间的数据块同步互联。 这里还是有一些问题需要思考的 在所有实例都未读取该块而第一个实例读取时是怎么加的锁加的什么锁如果此时有另一个实例也要读这个块几乎是同时的那么 Oracle 如何来仲裁如何让其中一个读取而另一个再从前者的缓存中通过 cache 来得到 如果一个块已经被其他实例读入那么本实例如何判断它的存在 如果某个实例改变了这个数据块是否会将改变传递到其他实例或者说其他实例是否会知道并重新更新状态 如果一个实例要 swap out 某个块而同时其他实例也有这个块的缓存修改过的和未修改过的本实例修改的和其他实例修改的如何操作? truncate 一张表drop 一张表… 和单实例有何不同 应该如何设计应用以使 RAC 真正发挥作用而不是引入竞争导致系统被削弱 RAC 下锁的实现。
锁是在各实例的 SGA 中保留的资源通常被用于控制对数据库块的访问。每个实例通常会保留或控制一定数量与块范围相关的锁。当一个实例请求一个块时该块必须获得一个锁并且锁必须来自当前控制这些锁的实例。也就是锁被分布在不同的实例上。而要获得特定的锁要从不同的实例上去获得。但是从这个过程来看这些锁不是固定在某个实例上的而是根据锁的请求频率会被调整到使用最频繁的实例上从而提高效率。要实现这些资源的分配和重分配、控制这是很耗用资源的。这也决定了 RAC 的应用设计要求比较高。假设某个实例崩溃或者某个实例加入那么这里要有一个比较长的再分配资源和处理过程。在都正常运行的情况下会重新分配以更加有效的使用资源在实例推出或加入时也会重新分配。在 alert 文件中可以看到这些信息。而 Cache Fusion 及其他资源的分配控制要求有一个快速的互联网络所以要关注与互联网络上消息相关的度量以测试互联网络的通信量和相应时间。对于前面的一些问题可以结合另外的概念来学习它们是全局缓存服务和全局队列服务。
全局缓存服务(GCS):要和 Cache Fusion 结合在一起来理解。全局缓存要涉及到数据块。全局缓存服务负责维护该全局缓冲存储区内的缓存一致性确保一个实例在任何时刻想修改一个数据块时都可获得一个全局锁资源从而避免另一个实例同时修改该块的可能性。进行修改的实例将拥有块的当前版本包括已提交的和未提交的事物以及块的前象(post image)。如果另一个实例也请求该块那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么以及块处于何种模式。LMS 进程是全局缓存服务的关键组成部分。
猜想Oracle 目前的 cache fusion 是在其他实例访问时会将块传输过去再构建一个块在那个实例的 SGA 中这个主要的原因可能是 interconnect 之间的访问还是从本地内存中访问更快从而让 Oracle 再次访问时可以从本地内存快速获取。但是这也有麻烦的地方因为在多个节点中会有数据块的多个 copy这样在管理上的消耗是很可观的Oracle 是否会有更好的解决方案出现在后续版本中如果 interconnect 速度允许的话…
全局队列服务(GES)主要负责维护字典缓存和库缓存内的一致性。字典缓存是实例的 SGA 内所存储的对数据字典信息的缓存用于高速访问。由于该字典信息存储在内存中因而在某个节点上对字典进行的修改如DDL)必须立即被传播至所有节点上的字典缓存。GES 负责处理上述情况并消除实例间出现的差异。处于同样的原因为了分析影响这些对象的 SQL 语句数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。LMON、LCK 和 LMD 进程联合工作来实现全局队列服务的功能。GES 是除了数据块本身的维护和管理由 GCS 完成之外在 RAC 环境中调节节点间其他资源的重要服务。 SQL select * from gv$sysstat where name like ‘gcs %’ 这里可以看到 gcs 和 ges 消息的发送个数。如果没有使用 DBCA 来创建数据库那么要 SYSDBA 权限来运行CATCLUST.SQL 脚本来创建 RAC 相关的视图和表
1.资源模式三种 null (默认的) share(S) (查询) exclusive(X) (修改block的内容,其它的实例就为null mode) 2.资源角色两种 local 第一次请求资源的初试模式;只有一个实例可以有这个block的dirty copy(即磁盘数据块的元数据内容) global 当一个Block在多个实例中变dirty时Local就变成了Global 并最终只能由GCS发送请求写到磁盘中
下面说下 cache fusion block 是如何传输的。 环境A,B,C,D四个节点实例D有拥有数据块的MASTER资源权限每个数据块都拥有一个master 1、Read from no transfer 假设四个实例的sga从未缓存过该数据块如果节点C需要向shared data disk 读一个block。 则节点C向GCS发送请求此时请求被指向节点D因为节点D是数据块的masterGCS把该块的资源改为share modeS和local role 并在D节点的GCS记录状态并通知C的GCS把此资源模式从Null-Share C开始I/O读磁盘读取该块。
2、Read to Write transfer B要读写这个数据块B的GCS向D发出请求D的GCS向C发出请求要求C把数据块给BC把数据块CP传给BB的GCS修改块的模式Null-ExclusiveX 且其他节点的模式为-null
3、Write to Write transfer A节点也要修改数据块A的GCS向D发出请求D的GCS指向B如果此时该请求还没完成则放到GES队列中B取消修改并把block传给A 此时会强制log flushb的块模式变为null A收到块后加X锁 此时虽然B有块的cp但不能修改因为b块模式为null
4、Write to Read transfer C要读blockC的GCS向D发送请求D指向AA把该块的锁由X-Share模式C收到A的块CP 取出SCN,由GCS更新元数据块CP的SCN。
通过设置参数gc_files_to_locks可以关闭Cache Fusion。 关闭后则别的节点要读/写数据块时必须等待占用该块的实例节点提交写回数据文件中。 注1当有新的节点添加/崩溃时原节点的锁资源会重新平衡 注2当一个节点不再需要master动态资源控制进程会把他移到请求频率最高的一个节点上 什么是高可用 Oracle failsafe、Data Guard 和 RAC 均为 ORACLE 公司提供的高可靠性HA解决方案。然而之三者之间却存在着很大区别。 HA 是 High Availability 的首字母组合翻译过来可以叫做高可用或高可用性高可用环境。我觉得应该说 HA 是一个观念而不是一项或一系列具体技术就象网格一样。作过系统方案就知道了评价系统的性能当中就有一项高可用。也就是 OS 一级的双机热备。RAC 是 real application cluster 的简称它是在多个主机上运行一个数据库的技术即是一个 db 多个 instance。它的好处是 可以由多个性能较差的机器构建出一个整体性能很好的集群并且实现了负载均衡那么当一个节点出现故障时其上的服务会自动转到另外的节点去执行用户甚 至感觉不到什么。 FAILSAFE 和 RAC 的区别 操作系统 failsafe 系统局限于 WINDOWS 平台必须配合 MSCSmicrosoft cluster server而 RAC 最早是在 UNIX 平台推出的目前已扩展至 LINUX 和 WINDOWS 平台通过 OSDoperating system dependent与系统交互。对于高端的 RAC 应用UNIX 依然是首选的平台。 系统结构 FAILSAFE 采用的是 SHARE NOTHING 结构即采用若干台服务器组成集群共同连接到一个共享磁盘系统在同一时刻只有一台服务器能够访问共享磁盘能够对外提供服务。只要当此服务器失效时才有另一台接管共享磁盘。RAC 则是采用 SHARE EVERYTHING组成集群的每一台服务器都可以访问共享磁盘都能对外提供服务。也就是说 FAILSAFE 只能利用一台服务器资源RAC 可以并行利用多台服务器资源。 运行机理 组成 FAILSAFE 集群的每台 SERVER 有独立的 IP整个集群又有一个 IP另外还为 FAILSAFE GROUP 分配一个单独的 IP后两个 IP 为虚拟 IP对于客户来说只需知道集群 IP就可以透明访问数据库。工作期间只有一台服务器preferred or owner or manager对外提供服务其余服务器(operator)成待命状当前者失效时另一服务器就会接管前者包括FAILSAFE GROUP IP与CLUSTER IP同时FAILSAFE会启动上面的DATABASE SERVICELISTENER 和其他服务。客户只要重新连接即可不需要做任何改动。对于 RAC 组成的集群每台服务器都分别有自已的 IPINSTANCE 等可以单独对外提供服务只不过它们都是操作位于共享磁盘上的同一个数据库。当某台服务器失效后用户只要修改网络配置如TNSNAMES。ORA即可重新连接到仍在正常运行的服务器上。但和 TAF 结合使用时甚至网络也可配置成透明的。 集群容量 前者通常为两台后者在一些平台上能扩展至 8 台。 分区 FAILSAFE 数据库所在的磁盘必须是 NTFS 格式的RAC 则相对灵活通常要求是 RAW然而若干 OS 已操作出了 CLUSTER 文件系统可以供 RAC 直接使用。 综上所述FAILSAFE 比较适合一个可靠性要求很高应用相对较小对高性能要求相对不高的系统而 RAC则更适合可靠性、扩展性、性能要求都相对较高的较大型的应用。
RAC 和 OPS 区别 RAC 是 OPS 的后继版本继承了 OPS 的概念但是 RAC 是全新的CACHE 机制和 OPS 完全不同。RAC 解决了 OPS 中 2 个节点同时写同一个 BLOCK 引起的冲突问题。 从产品上来说 RAC 和 OPS 是完全不同的产品但是我们可以认为是相同产品的不同版本
双机热备、RAC 和 DATA GUARD 的区别 Data Guard 是 Oracle 的远程复制技术它有物理和逻辑之分但是总的来说它需要在异地有一套独立的系统这是两套硬件配置可以不同的系统但是这两套系统的软件结构保持一致包括软件的版本目录存储结构以及数据的同步其实也不是实时同步的这两套系统之间只要网络是通的就可以了是一种异地容灾的解决方案。而对于 RAC则是本地的高可用集群每个节点用来分担不用或相同的应用以解决运算效率低下单节点故障这样的问题它是几台硬件相同或不相同的服务器加一个 SAN共享的存储区域来构成的。
节点间的通信INTERCONNECT 通常在 RAC 环境下在公用网络的基础上需要配置两条专用的网络用于节点间的互联在 HACMP/ES 资源的定义中这两条专用的网络应该被定义为private 。在实例启动的过程中RAC 会自动识别和使用这两条专用的网络并且如果存在公用public 的网络RAC 会再识别一条公用网络。当 RAC 识别到多条网络时RAC 会使用 TNFF (Transparent Network Failvoer Failback) 功能在 TNFF 下所有的节点间通信都通过第一条专用的网络进行第二条( 或第三条等) 作为在第一条专用的网络失效后的备份。
CLUSTER_INTERCONNECTS 是在 Oracle RAC 中的一个可选的初始化(init.ora) 参数。此参数可以指定使用哪一条网络用于节点间互联通信如果指定多条网络RAC 会在这些网络上自动进行负载均衡。然而当CLUSTER_INTERCONNECTS 设置时TNFF 不起作用这将降低 RAC 的可用性任何一条节点间互联网络的失效都会造成 RAC 一个或多个节点的失效。ORACLE RAC 用于 INTERCONNECT 的内网卡的物理连接方式的选择采用交换机连接或是网线直连。直连的弊端是一旦一个节点机的内网卡出现故障oracle 从 OS 得到两个节点的网卡状态都是不正常的因而会导致两个实例都宕掉。在 INTERCONNECT 线路出现问题的时候oracle 一般情况下会启动一个竞争机制来决定哪个实例宕掉如果宕掉的实例正好是好的实例的话 这样就会导致两个实例都宕掉。在 9i 中oracle 在启动竞争机制之前会先等待一段时间等待 OS 将网络的状态发给 oracle如果在超时之前oracle 获得哪个实例的网卡是 down 的话则将该实例宕掉这样的话则可以保留正常的那个实例继续服务否则还是进入竞争机制。 综上所述节点间通信分为两种情况 是接在交换机上面此时一般情况下是会保证正常的实例继续服务的但有的时候如果 os 来不及将网卡状态送到 oracle 时也是有可能会导致两个节点都宕掉的。 如果是直连的话则会导致两个实例都宕掉。
CSS 心跳 OCSSD 这个进程是 Clusterware 最关键的进程如果这个进程出现异常会导致系统重启这个进程提供CSS(Cluster Synchronization Service)服务。 CSS 服务通过多种心跳机制实时监控集群状态提供脑裂保护等基础集群服务功能。 CSS 服务有 2 种心跳机制 一种是通过私有网络的 Network Heartbeat另一种是通过 Voting Disk 的 DiskHeartbeat。这 2 种心跳都有最大延时对于 Disk Heartbeat这个延时叫作 IOT (I/O Timeout);对于 Network Heartbeat, 这个延时叫 MC(Misscount)。这 2 个参数都以秒为单位缺省时 IOT 大于 MC在默认情况下这 2 个参数是 Oracle自动判定的并且不建议调整。可以通过如下命令来查看参数值 c r s c t l g e t c s s d i s k t i m e o u t crsctl get css disktimeout crsctlgetcssdisktimeoutcrsctl get css misscount
