ASM文件系统

1.确认数据库版本

2.个人理解的存储解决方案的发展趋势

2.1图示说明

2.2图示描述

如上图我们描述了在不同时期的IT行业(数据库)出现的存储文件系统,下面我们将分别说明:

ü  裸设备:所谓裸设备是指那些没有安装文件系统的一些存储设备,像比较老一点的IDE磁盘,到现在常用到的SCSI磁盘等,只要没有安装文件系统就属于裸设备;我们在使用裸设备的时候或者说数据库在使用裸设备的时候,必须为每一个文件单独创建一个裸设备,这种情况下对于数据的复制和备份很不方便,所以这种存储方案大多不被人们所接受。

ü  文件系统:自从计算机操作系统出现以后,就出现了用于管理存储的文件系统,如微软的FAT16FAT32NTFS,LINUX下的EXT2EXT3等,不同文件系统的管理存储能力各不相同,像FAT16只能存储单个文件的大小为2G的文件,而后来发展的FAT32能够存储的单个文件的大小为4G,大大提高了文件储存管理的能力。在早期的ORACLE7&8版本上都是可以把数据文件存储在操作系统提供的文件系统和裸设备上。

ü  共享文件系统:随着IT系统的发展,简单的裸设备存储和操作系统的提供的文件系统存储已不能满足业务发展的需要,为了提高系统的运算能力,ORACLE数据库开发出了多种高可用的架构,相对应的ORACLE也开发出了自己的一套文件系统ASM/OCFS。我们主要来说一下ASM,ASM俗称自动存储管理系统,可以通过ASMCMD工具来管理,它绕开过底层操作系统的存储管理,不受操作系统层参数的影响直接处理磁盘上的数据,效率要比操作系统层高。

ü  分布式文件系统:近年来随着云计算和大数据时代的到来,数据的大小以几何级增长,这时期数据存储的特点是存储数据量大并且要求运算能力快,在这种情况下以前的文件系统存储方案都会受限于IO瓶颈而达不到要求,而分布式文件系统就是为解决这种情况而开发的一种文件存储方案,现成的产品有HADOOP下的HDFS分布式文件系统等,分布式文件系统的原理的把数据进行切割分成不同的数据块,分别存放在不同的机器下,运算时通过MapReduce算发进行分发聚合任务,达到存储量运算能力快的要求,分布式文件系统很少存在IO瓶颈的问题。

3.说明ASM实例同数据库实例协同工作的原理图

3.1图示说明

3.2图示描述

ü  图示中一共包括了2个ORACLE实例、1个ASM实例、3个磁盘组,他们之间的关系是1个ASM实例服务于2个ORACLE实例,且ASM实例挂载了3个磁盘组(+DATA1、+DATA2、+DATA3)。

ü  图中1个ASM实例为2个ORACLE实例提供服务,同时这1个ASM实例又管理了3个磁盘组,可以根据业务类型对不同磁盘组进行规划,例如存放数据文件和日志文件分别放在+DATA1和+DATA2,将一些备份数据放在+DATA3,ASM磁盘组类似于操作系统的逻辑卷。

ü  ASM将数据文件或其他数据结构分成区间,将区间分配到磁盘组中所有磁盘上来提高性能和可靠性,并非是镜像整个磁盘卷,ASM会镜像数据库对象以提供类型镜像和条带化数据库对象的灵活性。

ü  ASM要求使用特殊类型的ORACLE实例来提供传统ORACLE实例和文件系统之间的接口。在ORACLE10G中,对于使用ASM磁盘的数据库引入了三个新的后台进程支持ASM实例RBAL(rebalance,重新平衡程序)、ARBn、ASMB,其中RBAL协调磁盘组的磁盘活动,在添加或卸下磁盘时执行重新平衡操作;ARBn进程主要用于磁盘组中的磁盘之间执行实际区间移动,n可以是数字0到9。ASMB进程主要执行数据库与ASM实例间的通信。

ü  在ASM中CSS集群同步服务服务负责ASM实例与数据库实例的相互通信。他们之间的启动顺序是首先启动ASM实例然后再启动数据库实例,关闭的时候首先关闭数据库实例然后再关闭ASM实例。

ü  ASM数据分为元数据和真正数据,其中元数据用于描述对象的字典信息,也就是物理磁盘信息,例如块大小、AU大小、条带宽度、数据分布情况、冗余情况,在数据再平衡的时候元数据和真正的数据都会发生移动。

4.视图方式和asmcmd方式,分别计算出你所用ASM管理的存储大小,使用空间和剩余空间数

4.1查看ASM后台进程

可以看到当前环境ASM实例已经启动。

4.2视图方式计算ASM存储大小

4.3 ASMCMD方式计算ASM存储大小

备注:在ORACLE实例中可以利用select table_name from dictionary wheretable_name like '%ASM%';查询出ASM相关的视图。

5.查询asm实例正常情况下的运行状态(nomount,mount或者open)

5.1启动ASM实例

5.2查看ASM实例状态

5.3解释说明

从5.1ASM实例的启动过程中我们可以看到在ASM实例启动的时候,它不像ORACLE实例那样有NOMOUNTMOUNTOPEN三个状态,而是直接分配内存直接把磁盘组加载到ASM实例中就可以了,此时查询5.2看到ASM实例的状态为STARTED,总的来说ASM实例是没有控制文件的,其只有一个参数文件,参数文件里面只是指定了需要加载的磁盘、ASM需要的内存空间、实例的类型等,这主要是因为ASM只是管理磁盘组的分配和数据的平衡,不需要关注数据的一致性和数据库结构,其逻辑上只做数据的查询与抽取工作,所以ASM不需要自己单独的控制文件,只需要给ASM分配内存区及相应的后台进程就可以了。

6.比较ASM实例和数据库实例在监听器中注册的状态

6.1启动监听

正常情况下PMON进程会1分钟后把ORACLE实例和ASM实例注册到监听中,我们等1分钟后再查询监听状态。

6.2再次查看监听状态

6.3服务状态说明

通过上面的图中可以看到在监听器里ASM实例服务和数据库实例服务都已经注册到了监听器里(如图中的红线处),其中服务+ASM下面有1个实例+ASM,服务ORCL下有一个实例ORCL,数据库实例服务下实例的状态为READY,表示此实例可以对外提供服务,可以接受外部用户TNS的连接。而+ASM服务的状态为BLOCKED,这是+ASM实例服务的正常状态,表示PMON监听进程这个实例不能经由监听对外提供服务,也就是通过TNS是访问不了这个服务的。

7.ASM的后台进程包含哪些,分别说说它们的用途。

7.1查看ASM后台进程

7.2后台进程说明

ü  PMON:进程监控进程,用于监控ASM实例进程,对异常进程进行报警保护。

ü  PSPn:启动其他ASM实例进程,一旦有问题将导致ASM实例故障。

ü  MMAN:负责ASM内存动态管理。

ü  DBWn:与数据库实例的DBWn进程类似,将ASM CACHE中的脏数据写到磁盘。

ü  LGWR:写REDO日志进程,凡事更改就会触发此进程写redo日志。

ü  CKPT:检查点进程,触发ASM检查点写脏数据。

ü  SMON:系统监控进程,监控ASM实例的状态,一个ASM实例只能有一个。

ü  RBLA:磁盘组走再平衡的后台进程,该进程有故障将导致ASM实例宕机。

ü  GMON:磁盘组监控进程,用于磁盘组状态监控和状态表维护。

ü  ASMB:负责ASM进程与数据库进程的通信。

原文地址:https://www.cnblogs.com/myrunning/p/4222422.html