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哦。

$kfod -h
_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使用起来还是比较简单的。一个实际执行的例子如下：

$kfod disks=all status=true
---------------------------------------------------------------
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

Posted by NinGoo at 2008-06-22 14:56 | 『存储, 数据库』 | 4 Comments »

Oracle数据库如何识别ASM磁盘组

假如使用ASM做为Oracle数据库的数据存储方式，那么Oracle数据库是怎么来识别ASM的diskgroup的呢，也就是数据库的instanc和ASM的instance之间是如何沟通的呢？简单的说，就是ocssd(Oracle Cluster Support Services daemon)。本文假设为Linux环境下的RAC+ASM系统。

对于ASM来说，ocssd是必须的，所以在使用dbca创建ASM Instance的时候，就会提示要先安装ocssd。如果是单机，执行$ORACLE_HOME/bin/localconfig add安装ocssd。ocssd通过inittab自动启动，在安装的时候就会在/etc/inittab中加入以下条目(rac环境)：

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null

其中，35表示在os的运行级别(runlevel)为3或者5的时候启动/etc/init.d/init.cssd
respawn表示init.cssd进程如果异常终止，则自动重新启动

ocssd进程启动后会打开一系列的文件(通过/proc/pid/fd或者lsof -a -p pid可以获得filedescriptor的信息)：
消息文件
– $CRS_HOME/srvm/mesg/procus.msb
– $CRS_HOME/css/mesg/clssus.msb
– $CRS_HOME/has/mesg/clsdus.msb
日志文件
– $CRS_HOME/log/hostname/cssd/cssdOUT.log
– $CRS_HOME/log/hostname/cssd/ocssd.log
– $CRS_HOME/log/hostname/alertSID.log
OCR(Oracle Cluster Registry)，本例中在裸设备上，如果是单机也可能在本地文件系统中，典型路径$ORACLE_HOME/cdata/localhost/local.ocr
– /dev/raw/raw1
– /dev/raw/raw2
以及一些socket端口
– socket:[578057]
– socket:[578062]
…

ASM instace启动以后，通过gmon进程和osccd通信，将ASM的一些信息告诉给ocssd，而数据库则从ocssd获得这些信息，也就是说，ocssd是ASM Instance和Database之间的纽带。

ASM/ocssd/database之间具体通信的步骤，可以参考这里。

Posted by NinGoo at 2008-06-22 11:57 | 『数据库』 | 4 Comments »

Oracle11g ASMCMD新命令

Oracle10g的ASMCMD命令，提供了通过命令行方式管理ASM的接口，但是功能非常有限，比如无法在asm和os之间直接复制文件，就是一件很让人头痛的事情，只能通过rman或者dbms_file_transfer实现。

Oracle11g的ASMCMD终于加上了一个比较实用的cp命令，不但可以在ASM和OS之间复制文件，也可以在不同的ASM Instance和Diskgroup之间复制文件，这就非常的方便了。

ASMCMD> cp +dgtest/test/datafile/USERS.264.646186565 users.dbf
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.

[继续阅读全文]

Posted by NinGoo at 2008-04-05 1:23 | 『存储』 | 2 Comments »

ASM环境中有关磁盘的操作要慎重

这两天遇到一个ASM损坏的案例，环境是AIX，单机ASM，采用/dev/rhdiskn字符设备直接做为ASM Disk。损坏的diskgroup无法mount，alert中记录错误如下：

NOTE: assigning ARB0 to group 1/0x5646ea2f (DATA)
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信息：

kfgbRegister: registering group 1/0xA5A6EA25 (DATA)
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的日常操作中，要注重设计的简单性，文档的规范性和可操作性，并且操作要严格的安装手册执行。下命令前多检查，执行完后多监控，良好的习惯比任何高超的技巧都要来得有效。

Posted by NinGoo at 2008-03-09 19:12 | 『存储』 | 10 Comments »