验证共享存储可访问oracle,oracle-RAC和共享存储技术

存储是网格技术中的关键组成部分。传统上，存储都直接依附在每个Server(directly attached to each inpidual Server DAS)上。在过去的几年来，更灵活的存储出现并得到应用，主要是通过存储空间网络或是正规的以太网来实现访问。这些新的存储方式使得多个Servers访问相同的磁盘集合成为可能，在分布式环境中，可以获得简单的存取。

storage area network(SAN)代表了数据存储技术在这一点的演进。传统上，C/S系统中，数据被存储在Server内部或是依附它的设备中。随后，进入了network attached storage(NAS)阶段，这使得存储设备与Server和直接连接它们的网络向分离。它在SAN遵循的原则进一步允许存储设备存在于各自的网络中，并直接通过高速的媒介进行交换。用户可以通过Server系统对存储设备的数据进行访问，Server 系统与本地网络(LAN)和SAN相互连接。

文件系统的选择是RAC的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将文件存储在没有任何文件系统的裸卷标或是支持多系统并发访问的文件系统中。

因此，三个主要的方法用于RAC的共享存储有：

裸卷标：既是一些直接附加的裸设备，需要用于存储，并以block模式进程操作。

Cluster file system：也需要以block模式进程存取。一个或多个Cluster file 系统可以被用于存储所有的RAC文件。

自动存储管理(ASM)：对于Oracle Database files，ASM是一个轻便的、专用的、最佳化的Cluster file system。

6、Oracle Cluster file system

Oracle Cluster file system(OCFS)是一个共享文件系统，专门为Oracle RAC设计。OCFS排除了Oracle Database files被连接到逻辑磁盘上的需要，并使得所有的节点共享一个ORACLE Home，而不需每个node在本地有一个副本。OCFS卷标可以横跨一个或多共享disks，用于冗余和性能的增强。

下面时可放入OCFS中的文件类表：

Oracle software的安装文件：在10g中，此设置只在windows 2000中支持。说是后面的版本会提供在Linux中的支持，但我还没具体看。

Oracle 文件(控制文件、数据文件、redo logs文件，bfiles等)

共享配置文件(spfile)

在Oracle运行期间，由Oracle创建的文件。

voting和OCR文件

Oracle Cluster file system对开发人员和用户时免费的。可从官方网站下载。

7、自动存储管理(ASM)

是10g的新特性。它提供了一个纵向的统一管理的文件系统和卷标管理器，专门用于建立Oracle Database 文件。ASM可以提供单个SMP机器的管理或是贯穿多个Oracle RAC的Cluster节点。

ASM无需再手动调节I/O，会自动的分配 I/O 负载到所有的可用资源中，从而优化性能。通过允许增加Database大小而不需shutdown数据库来调节存储分配，来辅助DBA管理动态数据库环境。

ASM可以维护数据的冗余备份，从而提高故障的容错。它也可以被安装到可靠的存储机制中。

8、选择RAW或CFS

CFS的优点：对于RAC的安装和管理非常简单;对RAC使用Oracle managed files(OMF);single Oracle软件安装;在Oracle data files上可以自动扩展;当物理节点失败时，对归档日志的统一访问。

裸设备的使用：一般会用于CFS不可用或是不被Oracle支持的情况下;它提供了最好的性能，不需要在Oracle和磁盘之间的中间层;如果空间被耗尽，裸设备上的自动扩展将失败;ASM、逻辑存储管理器或是逻辑卷标管理其可以简化裸设备的工作，它们也允许加载空间到在线的裸设备上，可为裸设备创建名字，从而便于管理。

9、RAC的典型Cluster栈

\

在Cluster中的每个节点都需要一个被支持的相互连接的软件协议来支持内部Instance的交互，同时需要TCP/IP支持CRS的轮询。所有的UNIX平台在千兆以太网上使用user datagram protocol(UDP)作为主要的协议并进行RAC内部Instance 的IPC交互。其他支持的特有协议包括用于SCI和Sunfire的连接交互的远程共享内存协议和超文本协议，用于超光纤交互。在任何情况下，交互必须能被平台的Oracle所辨识。

使用Oracle clusterware，可以降低安装并支持并发症。但如果用户使用非以太交互，或开发了依赖clusterware的应用程序在RAC上，可能需要vendor clusterware。

同交互连接一样，共享存储方案必须被当前平台的Oracle所辨识。如果在目标平台上，CFS可用，Database area和flash recovery area都可以被创建到CFS或ASM上。如果在目标平台上，CFS不可用，则Database area可以创建在ASM或是裸设备上(需要卷标管理器)并且flash recovery area必须被创建在ASM中。

10、RAC certification Matrix：它设计用于处理任何认证问题。可以使用matrix回答任何RAC相关的认证问题。具体使用步骤如下：

点击菜单栏的“certify and availability”按钮

点击“view certifications by product”连接

选择RAC

选择正确的平台

11、必要的全局资源

\

一个single-Instance环境，锁坐标通向一个共享的资源就像表中的一行。lock避免了两个进程同事修改相同的资源。

在RAC环境中，内部节点的同步时关键，因为它维持着不同节点中各自进程的一致性，避免其在同时修改相同的资源数据。内部节点的同步确保每个Instance看到buffer cache中block的最近的版本。上图中显示了当不存在加锁的情况。

1)全局资源的协调

\

cluster操作要求在所有Instance中对控制共享资源的访问进行同步。RAC使用Global Resource Directory来记录cluster Database中资源的使用信息。Global Cache Service(GCS)和Global Enqueue Service(GES)管理GRD中的信息。

每个Instance在其本地的SGA中维护GRD的一部分。GCS和GES指定一个Instance管理特殊资源的所有信息，它被称为资源的master。每个Instance都知道resource的Instance masters。

维护RAC的活动中的cache的依附性(cache coherency)是非常重要的。所谓cache coherency是保持在不同Oracle Instances中的多个block版本的一致性的技术。GCS通过所谓的cache融合算法来实现cache coherency。

GES管理所有非cache 融合算法的内部Instance资源操作和Oracle入队机制的状态轨迹。GES主要的控制的资源是字典cache locks和library cache locks。同时，它还对所有死锁敏感的队列和资源起到死锁检测的作用。

2)Global cache coordination实例

\

假设某data block被第一个节点修改，成为脏数据。并且在clusterwide中，只有一个block copy版本，其内容用SCN号代替了。则具体的步骤如下：

① 第二个Instance视图修改该block，向GCS提出请求。

② GCS向block的holder(持有者)提交请求。在此，第一个Instance就是holder。

③ 第一个Instance接到消息，并将block发送给第二个Instance。第一个Instance保存脏buffer用于恢复的目的。block的脏镜像被称作block的past image。一个past image block将不能进一步被改变。

④收到block后，第二个Instance通知GCS，告知已经holds该block。

3)write to disk coordination：example

\

在cluster结构中的Instances中的caches中，可能存在同一个block的不同的修改版本。由GCS管理的写协议确保了只有最近一个版本被写入磁盘中。它同时需要确保其他之前的版本从其他cache中被清洗。一个写磁盘的请求可以从任意一个Instance上发起，无论它是保存了block的当前版本还是过去的版本。假设第一个Instance hold过去的block镜像，请求Oracle将buffer写入磁盘，如上图，过程如下：

①第一个Instance发送一个写请求给GCS

②GCS将请求转给第二个Instance，当前该block的holder

③第二个Instance接到写请求后将block写入磁盘

④第二个Instance通知GCS，告知其写操作完成

⑤当接到GCS接到通知后，GCS命令所有的过去的镜像的holders删除其过去的镜像。此镜像将不会在因恢复而需要。

12、RAC和Instance/crash recovery

1)当一个Instance失败，当该失败被其他Instance检测到，第二个Instance将会执行下面的恢复操作：

①在恢复的第一阶段，GES重新灌入队列

②GCS也重新灌入其资源。GCS进程只重新灌入那些失去其控制的资源。在这期间，所有的GCS资源请求和写请求都临时被挂起。然而，事务可以继续修改data blocks，只要这些事务已经获得了必要的资源。

③当队列被重新配置后，一个活动的Instance可以获得占有该Instance恢复队列。因此，当GCS资源被重新灌入的同时，SMON确定需要被恢复的blocks的集合。这个集合被称作恢复集。因为，使用cache 融合算法，一个Instance传送这些blocks的内容到请求的Instance，而不需要将这些blocks写入磁盘。这些blocks在磁盘上的版本可能不包含其他Instance进程的data的修改操作的blocks。这意味着SMON需要合并所有失败的Instance的redo logs来确定恢复集。这是因为一个失败的线程可能导致一个在redo 中的hole(洞)需要用指定的block填补。所以失败的Instance的redo 线程不能被连续的应用。同时，活动的Instances的redo 线程不需恢复，因为SMON可以使用过去和当前的通信缓冲的镜像。

④用于恢复的缓冲空间被分配，并且那些之前读取redo logs被辨识的资源被声明为恢复资源。这避免了其他Instance访问这些资源。

⑤所有在随后的恢复操作中需要的资源被获得，并且GRD当前是不冻结的。任何不需恢复的data block现在可以被访问。所以当前系统时部分可用的。此时，假设有过去或当前的blocks镜像需要被恢复，而其在cluster Database中的其他caches中，对于这些特殊的blocks，最近的镜像是开始恢复点。如果对于要恢复的block，过去镜像和当前镜像缓冲都不在活动的Instance的caches中，则SMON将写入一个log，表明合并失败。SMON会对第三步中辨识的每个block进行恢复和写入，在恢复之后会马上释放资源，从而使更多的资源在恢复时可以被使用。

当所有的block被恢复，占用的恢复资源被释放，则系统再次可用。

note：在恢复中，log合并的开支和失败的Instances的数目是成比例的，并且与每个Instance的redo logs的大小有关。

2)Instance recovery和Database availability

\

上图显示了在进行Instance恢复时，每一步执行时数据库的可用程度：

A. RAC运行在多节点上

B. 有节点失败被检测到

C. GRD的队列部分被重新设置;资源管理被重新分配到活动的nodes。此操作的执行比较快

D. GRD的缓冲部分被重新设置，SMON读取失败Instance的redo logs辨识那些需要恢复的blocks的集合

E. SMON向GRD发起请求，获得所有在需要恢复的blocks集合中的Database blocks。当请求结束，所有的其他的blocks都可被访问了

F. Oracle执行滚动的向前恢复。失败线程的redo logs被应用到Database，并且那些被完全恢复的blocks将马上可以被访问

G. Oracle执行滚回恢复。对于尚未提交的事务，undo blocks被应用到Database中

H. Instance的恢复完成，所有的data可以被访问

13、有效的内部节点行级锁