ASM如何识别磁盘
在ASM中,要创建diskgroup或者往已有的diskgroup里添加新的disk,则该disk必须已经识别,也就是要在v$asm_disk里有记录。ASM会根据asm_diskstring指定的路径去检查所有的磁盘。另外,查询v$asm_diskgroup和v$asm_disk也会导致这个识别磁盘动作的发生,所以平时最好查询v$asm_disk_stat来替代v$asm_disk。
Oracle也提供了一个工具来手工识别磁盘,就是KFOD,注意不是KFED哦。
_asm_a/llow_only_raw_disks KFOD allow only raw devices [_asm_allow_only_raw_disks=TRUE/(FALSE)]
_asm_l/ibraries ASM Libraries[_asm_libraries='lib1','lib2',...]
_asms/id ASM Instance[_asmsid=sid]
a/sm_diskstring ASM Diskstring [asm_diskstring='discoverystring', 'discoverystring' ...]
d/isks Disks to discover [disks=raw,asm,all]
g/roup Group discover [group=controlfile]
n/ohdr KFOD header suppression [nohdr=TRUE/(FALSE)]
o/p KFOD options type [OP=DISKS/GROUPS/ALL]
p/file ASM parameter file [pfile='parameterfile']
s/tatus Include disk header status [status=TRUE/(FALSE)]
v/erbose KFOD verbose errors [verbose=TRUE/(FALSE)]
可以看到KFOD使用起来还是比较简单的。一个实际执行的例子如下:
---------------------------------------------------------------
Disk Size Header Path
==========================================================
1: 1023 Mb FOREIGN /dev/raw/raw1
2: 273708 Mb MEMBER /dev/raw/raw10
3: 273708 Mb MEMBER /dev/raw/raw11
4: 273708 Mb MEMBER /dev/raw/raw12
...
--------------------------------------------------------------
ORACLE_SID ORACLE_HOME
=========================================================
+ASM4 /u01/oracle/product/10g/db
+ASM3 /u01/oracle/product/10g/db
+ASM2 /u01/oracle/product/10g/db
+ASM1 /u01/oracle/product/10g/db
lvm2与powerpath的Found duplicate PV问题
HP的DL580,OS是Redhat Enterprise Linux 4.5,接EMC CX700的存储,在安装了powerpath多路径软件后,系统能正确的识别出路径合并后的/dev/emcpower*设备。但是如果用lvm2来管理这些设备,会发现无论是创建还是查看pv/vg/lv都会报一堆的重复pv的问题:
Found duplicate PV ia0wzQ0pQ8J5H4Hu8hsubKjmx0T7bCNf: using /dev/emcpowert not /dev/sdc
Found duplicate PV OYmrYleEE05bGKm0pBWT60afWjl827a6: using /dev/sde not /dev/emcpowers
Found duplicate PV 0MWBXuho29Gnr5WKm3v0sZbXun3Mso2x: using /dev/sdg not /dev/emcpowerr
...
这个还可以勉强忍受,最头痛的是pvcreate后的名字,也有些是/dev/emcpower*,有些是/dev/sd*,这时候你要在这些pv上创建vg,要从不同的raid组来选取lun,也就是想知道pv对应lun的关系的时候,就一个头两个大。
...
/dev/emcpowerk vg_u03 lvm2 a- 167.03G 2.34G
/dev/emcpowerl vg_u01 lvm2 a- 167.03G 2.34G
/dev/sdaa vg_log lvm2 a- 127.41G 160.00M
/dev/sdab vg_log lvm2 a- 127.41G 160.00M
...
没有办法,只有通过修改/etc/lvm/lvm.conf中的过滤规则来强行让lvm略过非powerpath设备:
上面这个过滤串的意思是,接受(Accept)所有路径中包含cciss和emcpower的设备,拒绝(Reject)所有其他的设备。由于是HP的pc server,其本地硬盘的设备在os中的路径是/dev/cciss/cndn。假如是其他系统,本地盘是传统的sd或者hd的,则需要做相应修改。sd比较麻烦点,因为duplicate出来的也是/dev/sd*,所以需要确认哪些是需要accept的本地硬盘,哪些是需要reject的重复pv。另外,lvm识别出来的设备可以在/etc/lvm/.cache中查看,也可以根据这个文件的内容来制定过滤规则。
整个世界终于清净了
PV VG Fmt Attr PSize PFree
/dev/emcpowera lvm2 -- 100.24G 100.24G
/dev/emcpoweraa lvm2 -- 100.24G 100.24G
/dev/emcpowerab lvm2 -- 100.24G 100.24G
...
Oracle11g ASMCMD新命令
Oracle10g的ASMCMD命令,提供了通过命令行方式管理ASM的接口,但是功能非常有限,比如无法在asm和os之间直接复制文件,就是一件很让人头痛的事情,只能通过rman或者dbms_file_transfer实现。
Oracle11g的ASMCMD终于加上了一个比较实用的cp命令,不但可以在ASM和OS之间复制文件,也可以在不同的ASM Instance和Diskgroup之间复制文件,这就非常的方便了。
source +dgtest/test/datafile/USERS.264.646186565
target users.dbf
copying file(s)...
file, E:\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\USERS.DBF, copy committed.
ASM环境中有关磁盘的操作要慎重
这两天遇到一个ASM损坏的案例,环境是AIX,单机ASM,采用/dev/rhdiskn字符设备直接做为ASM Disk。损坏的diskgroup无法mount,alert中记录错误如下:
WARNING: cache failed to read fn=279 indblk=0 from disk(s): 6
ORA-15196: invalid ASM block header [kfc.c:7910] [endian_kfbh] [279] [2147483648] [6 != 0]
NOTE: a corrupted block was dumped to the trace file
System State dumped to trace file /u01/app/oracle/admin/+ASM/bdump/+asm_rbal_950452.trc
NOTE: cache initiating offline of disk 6 group 1
WARNING: offlining disk 6.4247132900 (DATA_0006) with mask 0x3
从报错中可以知道disk 6的某个block损坏了,kfbh.endian=6,本来应该等于0的。Trace file中可以找到损坏块的dump信息:
kfgbBind: binding kfgpn for group 1/0xA5A6EA25 (DATA)
kfgbRecoverCod: queued COD recovery for group 1/0xa5a6ea25 (DATA)
kfgbPeelWaitCIC: ignored, not rebalancing gn=1
kfgbRegister: registering group 2/0xA5F6EA26 (FLASH_RECOVERY_AREA)
kfgbBind: binding kfgpn for group 2/0xA5F6EA26 (FLASH_RECOVERY_AREA)
kfgbRecoverCod: queued COD recovery for group 2/0xa5f6ea26 (FLASH_RECOVERY_AREA)
kfgbPeelWaitCIC: ignored, not rebalancing gn=2
kfgbRebalanceCont: continuing-op COD for group 1/a5a6ea25lx (DATA)
kfgbRebalGrp: queued rebalance (power 1) for group 1/0xa5a6ea25 (DATA)
OSM metadata block dump:
kfbh.endian: 6 ; 0x000: 0x06
kfbh.hard: 162 ; 0x001: 0xa2
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 113817841 ; 0x004: T=0 NUMB=0x6c8b8f1
kfbh.block.obj: 581177085 ; 0x008: TYPE=0x2 NUMB=0x40efd
kfbh.check: 262 ; 0x00c: 0x00000106
kfbh.fcn.base: 2627010571 ; 0x010: 0x9c95000b
kfbh.fcn.wrap: 33554432 ; 0x014: 0x02000000
kfbh.spare1: 76002 ; 0x018: 0x000128e2
kfbh.spare2: 581177083 ; 0x01c: 0x22a40efb
这个比disk header损坏更严重,disk header中包含的信息有限,重建一下就可以恢复了。而具体的块损坏,则不可避免的导致数据丢失。后来发现导致块损坏的原因,居然是disk 6,对应的/dev/rhdisk8,被错误加入到一个vg当中了,这明显是一次误操作导致磁盘数据被覆盖了。在ASM环境中,对于磁盘操作,需要慎重,一个disk的损坏可能导致整个diskgroup无法使用,而且由于file分布在很多disk上,一个disk的损坏也会导致很多file失效,使得找回数据更加困难。
当然,这也可以说明另外一个问题,就是ASM还没有获得OS的足够支持。如果OS能够正确的识别ASM的Disk Header,就能够禁止该类型的操作,至少要给出提示,Oracle要推广ASM,还有很长的路要走。这也告诉我们,在DBA的日常操作中,要注重设计的简单性,文档的规范性和可操作性,并且操作要严格的安装手册执行。下命令前多检查,执行完后多监控,良好的习惯比任何高超的技巧都要来得有效。