oracle 11g RAC 的一些基本概念（四）

 

在Grid Infrastructure安装完以后，我们把注意力转移到集群上的Oracle软件的安装上来。我们看到，Grid Infrasctructure提供了运行RAC的框架，包括集群通讯链接、节点分离、节点成员关系等服务。ASM是Oracle存储数据库的首选方式。RAC利用这些概念并扩展了需要的基本服务。

 

 

 

成功安装了Grid Infrastructure/Clusterware以后，Oracle Universal Installer检测到集群环境的建立，然后提供安装整个集群上或是用户指定其中几个节点的RAC选项。使用集群检验工具cluvfy来为RDBMS的安装检测是否满足先决条件是良好的做法。和安装集群一样，Oracle Universal Installer将首先在第一个节点上对软件进行拷贝和链接，然后将Oracle主目录push到指定的其他节点中。和Grid Infrastructure不同的是，Oracle RDBMS可以被安装在共享文件系统上(例如OCFS2或ACFS上)，在集群中增加新节点被简化，因为不需要在新的节点上重新安装软件，打补丁同样被简化了--只有一个Oracle主目录需要打补丁。但是补丁不能以rolling方式安装，因此停机时间不可避免。

在安装过程中，Oracle Universal Installer将提醒管理员安装或升级数据库，或只安装软件。如果安装的时候有新的版本发布，那么仅仅安装软件，打补丁升级后再创建数据库是比较好的做法。

 

RAC和单实例数据库在很多重要方面都有所不同。

在RAC中，一个数据库在共享存储中为多个服务器上的实例所访问。数据库文件、在线redo文件、控制文件和服务器参数文件(spfile)都必须共享。此外，闪回日志、已归档的redo日志、数据泵转储文件、和dataguard broker配置文件也可以共享，根据你的配置来决定(这是可选的，但还是强烈建议这么做)。在使用ASM的时候，你同样可以在每个RAC的节点中找到一个本地的pfile文件，这个文件指向对应磁盘组中的spfile。另一个存储在本地的文件是Oracle密码文件。集群文件系统中的用户常常把这些文件放在一个共享的位置，通过符号链接指向$ORACLE_HOME/dbs

 

 

数据库文件包含数据库中的所有数据，包括表、索引、数据字典和经过编译的PL/SQL代码，不胜枚举。在RAC中，每个数据文件都只有一个拷贝，位于共享存储中，并为所有实例所访问。Oracle默认不为数据文件提供镜像，大部分用户选择在存储层面来做冗余，避免介质故障导致的数据丢失。在存储阵列没有这个功能时，可以使用Oracle ASM来提供冗余。

 

 

控制文件储存数据库的物理结构的相关信息，包括它们的状态。如果你使用RMAN且没有专门的RMAN catalog数据库，控制文件中也可以储存RMAN备份的信息。在单实例数据库和RAC中，控制文件应该做镜像以防止损坏或存储故障。当同时使用ASM和闪回恢复区时，会自动做多路复用。默认情况下，Oracle在db_create_file_dest和db_recovery_file_dest指定的磁盘组中对控制文件做多路复用。这种情况下，若你使用spfile，control_files参数将自动更新。要知道控制文件会成为RAC中的一个争用点，因为它们会被频繁更新。因此不要对控制文件做过多的镜像拷贝，而且应该把它们放置在高速存储上。

 

 

在RAC中，每个实例有它自己的联机日志文件，称为线程(thread)。线程的信息可以在V$LOG和相关的视图中查看。
每个线程中你需要两组redo日志，而且若没有使用ASM和闪回恢复区，你应该考虑手动对组中的成员做多路复用。由spfile负责实例和线程间的映射(通过初始化参数thread)。当添加一个新的实例到集群中时，就需要一个相应的redo线程，这可以使用两种方式来做到：第一种，执行SQL语句alter database add logfile group x thread y; 第二种，在使用策略管理的数据库(policy-managed)中，会自动创建。然后由Oracle来启用。
lgwr后台进程将redo buffer刷新到redo log中。online redo log需要放在高速存储中，否则它可能会成为一个争用的点，特别是在一个高频率提交的系统中。通常对设计不合理的应用的优化是减少commit的频率，并至少将redo log和控制文件移到高速存储中，以减少一些性能瓶颈。在日志切换频繁的系统中，增加每个线程的重做日志组数会有所帮助，它能给归档进程更多的时间来归档redo日志。这种方法在归档进程需要将归档的redo传送到standby数据库中时也能获益，但是，现在的大部分系统采用Log Network Service(LNSn)进程来异步传送redo给standby数据库的Remote File Server(RFS)进程。在Oracle 10.2和11.1中，每个destination有一个LNS进程，到了11.2，LNSn进程被NSSn何NSAn后台进程所代替。NSSn进程被用来同步传送redo，NSAn用来异步传送redo。redo log大小设置的原则是，日志切换不会太频繁(AWR和statspack能够帮助定义一个合适的大小)。Oracle 11.2还允许管理员来选择redo log的块大小，现代存储单元使用4kb扇区大小代替了原先的512b。
当RAC中的一个实例发生故障，所有线程被合并来帮助建立恢复集，由服务器监控进程来执行前滚或回滚操作。
在lgwr进程将一个redo log写满以后，其中一个归档进程会将该文件拷贝到指定的目录中。
闪回恢复区在Oracle 10.1中引入，看是来是归档日志的最佳存放位置。如果你没有使用闪回恢复区，建议将归档日志放在一个共享文件系统中，以便每个节点都可以访问到。与单实例数据库不同，RAC需要所有线程的归档日志。当一个实例执行介质恢复时，你可以从它的alter日志上看到，Oracle使用了每个线程的所有日志文件。

Undo表空间

 

和redo线程类似，每个集群数据库的实例由它自己的undo表空间。spfile中配置了实例和undo表空间之间的一对一映射关系。但这个映射并不代表该undo表空间就长期绑定在该实例上，所有的其他实例同样可以访问该undo表空间来创建块的读一致前镜像。

当添加一个实例到集群中时，需要添加新的undo表空间并映射到该实例，和redo log一样。在policy-managed数据库中，Oracle可以自己来做这件事。

虽然还是可以使用手动的undo管理，但是强烈建议使用自动undo管理(AUM)。

 

 

管理员可以在如下的选项中选择：

• ASM 这是Oracle的首选存储选项，而且是RAC标准版中支持的唯一配置
• OCFS2
• 裸设备 不推荐使用，不仅是因为被新版的linux内核弃用，在Oracle 11.2中同样不支持
• 网络文件系统(NFS)
• Red Hat Global File System 只在红帽和Oracle Enterprise Linux中支持，可以用在闪回恢复区和数据库文件上

 

一个RAC数据库包含2个或更多的实例，一般每个实例都在不同的节点上，由一些共享内存结构和后台进程组成。

每个实例都有自己的SGA，在实例启动的时候分配。Oracle在10g中引入了自动共享内存管理(ASMM)，在11g中引入了自动内存管理(AMM)。但是AMM与linux的大页面不兼容，这对大内存的系统来说是个问题。

Oracle需要同步访问本地共享内存和整个集群。所有实例都能访问其他实例的SGA。

在RAC中Oracle内核对共享内存的保护措施和单实例中是一样的，同样使用了闩和锁。闩是一个低级别、轻量级的串行装置。请求闩的进程不会排队，如果进程不能获得闩，它就会进入spin状态。spin的意思是，这个进程会进入一个紧密循环来预防被操作系统的调度程序从CPU中取下。如果一个进程长时间得不到闩，它会进入睡眠，在一个时间间隔后再次尝试申请。闩是实例级别的，没有集群范围的闩。

另一方面，锁在更长的时间请求一次，比闩更为复杂。锁可以是共享或独占的，请求锁的进程以先进先出(FIFO)的机制来等待，由队列来控制锁的访问，这个队列是集群范围内的。

缓存一致性的需求意味着锁和闩在RAC中比单实例要更加复杂。和单实例中一样，对buffer cache中数据库的访问和队列必须在本地实例中管理，但是，远程实例的访问也需要管理。因为这个原因，Oracle使用全局资源目录(GRD)和一些额外的后台进程。

(Oracle将V$视图加上实例标识组合起来形成GV$视图，一个GV$视图包含了集群中所有实例的动态性能视图)

 

 

RAC中使用了一些附加的后台进程来做缓存间的同步——记住RAC使用cache fusion结构来模拟一个横跨集群内所有节点的全局SGA。访问buffer cache中的块需要在读一致和写的访问间进行协调，共享资源的队列现在也是在集群全局上的。全局缓存服务(Global Cache Service GCS)用来对公共buffer cache的访问，全局队列服务(Global Enqueue Service GES)用来管理集群中的队列。

GCS和GES对应用而言都是透明的。内部使用的原结构就是先前提到的GRD，由GCS和GES进程来维护。GRD分布在集群的所有节点上，是SGA的一部分，这就是为什么一个RAC数据库的SGA比同等情况下的单实例数据库要来得大。资源管理由GCS和GES来协商。特定的资源完全由一个实例来管理，这个实例就是resource master。但它并是不固定的，Oracle 9.2以后的版本实现了动态的资源管理(DRM)，在9.2以前，资源的remastering只发生在实例故障、GRD重建的时候。新的版本中，如果Oracle检测到一个resource master以外的实例在一个给定的时间间隔中对一个特定的资源的访问过于频繁，就会发生resource mastering。在这种情况下，该资源就会被remaster到其他节点上，也就是说，频繁访问该资源的另一个节点将成为resource master。很多用户反馈了动态remastering的一些问题，当它过于频繁发生的时候会造成一些不必要的开支。这种情况下，可以禁用DRM。
（GRD还记录了哪些资源由哪些实例来管理，当一个实例发生故障时，恢复起来将非常方便）

 

下图说明GCS如何与GES协同工作来维护GRD

 

 

 

LMSn后台进程使用GCS在全局buffer cache中维护缓存的一致性，SGA中可以存在同一个数据块的多份拷贝(当前版本只有一个)，GCS对数据块的状态和位置进行跟踪，并通过内部连接将块传输到其他节点的实例中。

 

 

和GCS类似，GES工作在块级别，管理集群中的全局队列。根据经验，如果一个操作没有涉及在全局buffer cache中控制/移动数据块，那么很可能是经过了GES的处理。全局队列服务负责所有的实例中的资源操作，比如对数据字典和库缓存的访问或事务的全局管理。它同样可以检测集群中的死锁。它跟踪多个实例同时访问资源时Oracle队列机制的状态。全局队列服务监控(LMON)和全局队列服务后台进程(LMD)组成全局队列服务的一部分。锁进程LCK0负责无缓存方式的访问，比如library和row cache请求。

 

缓存融合(Cache Fusion)

读一致性

System Change Number(SCN)

转载：http://blog.sina.com.cn/s/blog_5fe8502601016avf.html