日归档：2014 年 3 月 9 日

先看一下ASM实例的大体部署： 我们都知道，ASM实例管理着元数据，普通数据库实例通过查询元数据的信息来访问相应的ASM文件。 ASM实例和数据库实例都可以访问一组普通的磁盘，这套磁盘被称为磁盘组。 然后，数据库实例直接访问ASM文件的内容，并在与ASM实例通信时获取有关这些文件的分布信息。 Group Services用于注册数据库实例查找ASM实例时所需要的连接信息： Group Services用于注册数据库实例查找ASM实例所需要的连接信息。 当ASM实例mount一个磁盘组时，它就将磁盘组的信息和连接串注册到Group Services。 数据库实例知道了磁盘组的名称，就可以找到应该连接到哪个ASM实例。 ASM实例有哪些独特地方： 1，INSTANCE_TYPE = ASM 2，startup = startup mount(11.2以后，可以直接对ASM实例 startup，但是本质还是startup mount)，对于ASM实例，mount选项不会去mount数据文件，而是mount在参数文件中ASM_DISKGROUPS指定的磁盘组 3，connect / as sysdba(10g) 和 connect / as sysasm(11.2) ASM的后台进程有很多，具体可以参考reference中的描述，这里只想研究一下数据库和ASM之间负责心跳机制的ASMB进程。 我们知道ASMB进程实际上是提供了一个数据库实例和ASM实例之间通信的桥梁，比如在数据库中创建、删除文件，或者修改文件等等的跟存储物理变化相关的操作。首先，我们观察下，他们在CRS,ASM和数据库启动过程中的启动顺序和先后关系： ASM的alert： DB的alert： ASM和数据库实例的ASMB进程都分别将信息注册到css中，参看ocssd.log: 这里，数据库启动时，ASMB的活动过程： 1，ASM实例的ASMB进程启动(spid: 3637，asm_asmb_+ASM1) 2，ASM实例的ASMB进程启动了一个连接到ASM实例的进程（spid：3641，oracle+ASM1_asmb_+asm1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))） … 继续阅读 →