您好,欢迎访问三七文档
当前位置:首页 > IT计算机/网络 > 数据库 > 11gASM新引入的特性
1.1影响管理的11gASM新引入的特性下面这些特性在维护10g版本的ASM将不被支持。但多数特性能维护ASM来说影响不大。1.1.1快速重新同步(ASMFastMirrorResync)短暂的磁盘路径发生问题时,恢复ASM磁盘组(DISKGROUP)的允余性是很费时间的,特别是这种恢复操作需要重新布局整个磁盘组的情况下。ASM快速磁盘重新同步这个新特征能显著减少重新同步一块坏磁盘时这种情况的时间,当你更换了坏磁盘,ASM能够快速的同步ASM磁盘的extent。任何使磁盘组临时不可用的问题被认为是暂时的失效,这是ASM快速重新同步新特征可以恢复的。磁盘路径失效,例如接口线问题,主机适配器问题,磁盘控制器问题,或者是磁盘电源问题这些都能引起瞬时失效。缺省的情况下,当一块磁盘脱机时,ASM会立刻移出该磁盘。ASM快速再同步功能够记录脱机磁盘在脱机期间该磁盘上区的所有的变化,当磁盘被修复或再次联机时,这期间更改的extent能够被快速的重新同步到刚才失效的这些磁盘中。你可以设定DISK_REPAIR_TIME这个属性使失效磁盘在被修复和再次联机这段时间内重新整理这样的操作不发生。这个时间可以以分钟(m或M)或者小时(h或H)为单位,如果你不指定时间单位,缺省的时间单位为小时。如果DISK_REPAIR_TIME这个属性没有设定,其缺省值为3.6小时。需要注意的是,这个缺省值适用于磁盘被设定为脱机模式而操作语句没有DROPAFTER子句这样的情况。大部分来说环境,3.6个小时这个DISK_REPAIR_TIME缺省属性数值应该都是合适的。注意:使用这项新功能,ASM磁盘组的兼容性需要设定至11.1或更高。例:CREATEDISKGROUPasmdskgrp1DISK'/dev/raw/*'SETATTRIBUTE'compatible.rdbms'='11.1','compatible.asm'='11.1';只有当包含脱机磁盘的磁盘组再次被挂上,消逝时间(自磁盘被设定成脱机模式后)都是增加的,V$ASM_DISK的REPAIR_TIME这列显示的是脱机磁盘在被删除之前所剩余的时间(单位:秒),当指定的时间到达后,ASM删除磁盘,可以用带有DROPAFTER的ALTERDISKGROUPDISKOFFLINE语句来覆盖这个属性。注意:DROPAFTER也是11g的新特征。如果一条ALTERDISKGROUPSETATTRIBUTEDISK_REPAIR_TIME操作的磁盘组含有脱机的磁盘,这个属性只对当前那些非脱机模式的磁盘是生效的。当一块脱机磁盘被第二次执行脱机操作,消逝时间会被重置并重新开始计算。如果另一个时间这块磁盘又被执行了DROPAFTER操作,上一个值会被覆盖并且新值生效。不能用ALTERDISKGROUPDROPDISK语句删除处于脱机状态的磁盘,这样操作时会报错。如果在某时情况,例如磁盘不能够被修复,需要在DISK_REPAIR_TIME到达前把磁盘删除时,可以再次执行带有DROPAFTER子句的OFFLINE语句,DROPAFTER指定0H或0M,表示立刻删除。你可以用ALTERDISKGROUP来设定磁盘组的DISK_REPAIR_TIME属性,可以是分钟,也可以是小时,例如4.5小时或270分钟,例如:ALTERDISKGROUPdg01SETATTRIBUTE'disk_repair_time'='4.5h'ALTERDISKGROUPdg01SETATTRIBUTE'disk_repair_time'='270m'在你修复磁盘后,运行ALTERDISKGROUPDISKONLINE这条SQL语句可以使磁盘组恢复到联机状态,新的读写操作都可以正常进行了,这条语句也触发把磁盘维修期间内更改的extent从磁盘组冗余的数据重新同步到刚才失效的这些磁盘中。1.1.2ASM滚动升级在ORACLE11g及之后的版本,你可以把ASM的集群置为滚动升级模式,充许不同版本的ASM结点共同工作。滚动升级模式中的每个结点能够独立的升级或打补丁,而不会影响到数据库的使用,因些其很大的提升数据库的正常运行时间。需要注意的是你只可以对ORACLE11g及之后的版本进行滚动升级,换句话说,你不能用这种功能把ORACLE10g的数据库升级到11G的。在进行滚动升级前,你的环境也一定要做一定的准备的。举例来说,如果你使用了ORACLEClusterware软件,在你开如做滚动升级前,Clusterware也一定要完整的升级到下一个满足要求的版本。当然,做Clusterware升级时也应当用滚动的方式,更大的确保高稳定性和最大的正常运行时间。在对一个结点的ASM软件打补丁或进行升级之前,必须把ASM集群置为滚动升级模式,这允许开始升级和操作你的环境在多个软件版本的模式,语句如下:ALTERSYSTEMSTARTROLLINGMIGRATIONTOnumber;number是由版本号、发行号、更新号、端口发行号和端口更新号这几部分组成的,中间以逗号分开,例如11.2.0.0.0。实例在运行这条语句时会检查你指定的number与当前已安装的软件版本是不是兼容。当升级开始后,ASM实例只有如下的一些操作才是充许的:l磁盘组挂载和卸载l数据库文件打开,关闭,重新设定尺寸和删除l限制访问ORACLE自带的视图和包,所有的全局视图都是失效的在滚动升级开始后,可以任意一个宕掉ASM实例来进行软件升级,升级完的ASM实例在启动后会自动重新加入ASM集群。当集群中的所有实例都完成升级到最新的软件版本后,你就可以结束滚动升级模式了。如果一块磁盘在ASM实例进行滚动升级时是脱机的,那么直到升级结速这块磁盘都会保持脱机的状态,而且直到ASM集群回到正常模式触发删除磁盘的记时器也是停止的。如果升级过级出现问题,可以用同样的过程回滚结点的软件到之前的版本。集群的任一地方有数据重整操作,升级会失败,所以必须等数据重整操作完成才可以开始滚动升级。另外,只要集群中有一个结点是活动的,滚动升级状态是保留的。如果一个集群正在进行滚动升级时一个新的ASM实例加进来,新的实例会被告知集群正处在滚动升级模式,你可以用如下的SQL语句查询ASM集群环境的状态:SELECTSYS_CONTEXT('sys_cluster_properties','cluster_state')FROMDUAL;如果ASM集群所有的实例都停了,那么当任何一个ASM实例重新启动,这个实例都会脱离滚动升级模式。如要实例都重新启动后还要进行升级,必须重新开始滚动升级操作。当滚动升级完成后,运行如下的SQL:ALTERSYSTEMSTOPROLLINGMIGRATION;发出这条语句后,ORACLE做了如下的一些操作:l校验ASM集群的所有成员的软件版本是不是相同,如果一个或几个实例运行在不同的软件版本,这条语句会报错,集群继续处在滚动升级模式.l使集群的所有实例都脱离滚动升级模式,集群开始全功能工作l如果设定ASM_POWER_LIMIT参数允许数据重整理,因滚动升级而被阻塞的数据重整理操作会重新开始。1.1.3为ASM管理员新增SYSASM权限和OSASM操作系统用户组在ORACLE10g这个版本,ORACLE没有为ASM管理员定制相应的角色,ASM管理员以SYSDBA角色进行管理工作,在实际工作中ASM管理员与数据库管理员可能是不同的两个或几个人完成的,相对来说权限界定不清晰.11g这一新特征引入SYSASM这一新权限目的就是为了清晰ASM管理员与数据库管理员的界面,防止越权操作的发生,使ASM管理员更好的进行ASM管理工作.这一新特征同时在操作系统中也为ASM新增了OSASM用户组,OSASM这个组是专门为ASM设计的,可以通过操作系统授权,被授权的这个组成员本地连接具有SYSASM权限,能够以SYSASM角色进行全权限的ASM管理工作。最初,只有ASM的安装用户是这个组的成员,在后继的工作,你可以添加新的用户到OSASM这个用户组,使新用户有ASM管理的全部权限。需要注意的是,在ORACLE11gRelease1的这个版本,系统OSDBA组的成员,连入数据库据有SYSDBA的权限,这样的用户仍然可以连接并管理ASM的实例,但相信在后续的版本中有SYSDBA权限的用户不会被授权有ASM实例的管理权限。1.1.4新的ASM命令行(ASMCMD)命令和选项ASMCMD有下列的四个新的命令:lsdsk、md_backup、md_restore和remap。除此之外,你还能使用带有新选项的ls和lsdg命令。下面描述一下这四个新的ASM命令:lsdsk-不论是否有一个ASM的实列正在运行,这个命令都能列出ASM磁盘的信息。当系统管理员或存储管理员想查看一下ASM实例都用了哪些磁盘时这个命令是非常有用的。md_backup和md_restore-这两个命令使能能够用相同的磁盘路径、磁盘名、失败组、属性、模板及目录结构别名来重新建立已经存在的磁盘组。你可以使用md_backup备份磁盘组的环境,在出现问题的时侯用mk_restore来恢复相应的磁盘组。Remap-你可以使用这个命令重映射或者回复normal及highredundancy模式ASM磁盘组中的坏块,ASM读取ASM映像好的拷贝中相应的块,并且把这些块重新写回到磁盘组中一个替代的位置
本文标题:11gASM新引入的特性
链接地址:https://www.777doc.com/doc-3058356 .html